Looks good, right lets go with the upgrade.
Jloader first. The ftp load command uses the syntax 'request system software add ftp://10.10.15.23/jloader-ex-3242-11.3I20110326_0802_hmerge-signed.tgz'. This is basically saying we're using FTP to get the image and that the image is located on server with IP address 10.10.15.23. Without stating a username and password int he form ftp://username:password@ the JunOS parser will use the default username of 'anonymous' with no password. Some FTP servers come with built in anonymous support...FileZilla needs you to create a user called 'anonymous' with the password checkbox unchecked. HEre is the process:
Each node in the cluster will be upgraded in turn until it finishes and returns you back tot he prompt:
The FileZilla management console shows you the whole process as the file is pulled back to the cluster master node. Here is a brief screen shot of the download:
Right, thats the jloader upgrade bit applied (but not yet active until we reboot. To save time we're now going to upgrade the firmware so that we only do one reboot. Here is the process and remember, this is a 4 node cluster as shown by the fpc0,1,2,3. If you have a larger node number then your output will be different.
So, just like the man said 'A reboot is required to install the software'. Let us oblige...
It took about 5 minutes to come around again, I logged in and checked the firmware versions and loader.
Thats OK now I checked the state of the partitions
Looks like I have two partitions there active/backup....all looking pretty sweet. Lets get some more information on the state of those partitions...detail?...nah thats what they would expect you to do lets look at the snapshot...
We're upgraded, we've got two healthy partitions...just need to wait for a failure now to see it automatically fix itself...but I won't wish for that. I think one question we're all asking is how do I find out if there has been a partition failure if it fixes itself?
Well you've got console logs, syslog and SNMP...take your pick. From the management port you will see
WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE
You can of course always look at the chassis alarms.
user@switch> show chassis alarms
1 alarms currently active
Alarm time Class Description
2011-02-17 05:48:49 PST Minor Host 0 Boot from backup root
Thank you for reading and may all of your upgrades be as sweet.
So we take the VLAN 186 and only allow it on this port. Untagged traffic is also placed into VLAN 186 but this is necessary. We've forced the port to not use DTP (switchport nonegotiate) and we're manually configuring it as a trunk port. Forcing the port as a trunk is not required but is good practice.
Lets have a look at the 6500_BACK configuration for the port connected to the 6500_FRONT G4/11.
OK, looks like a lot of configuration here so lets go through the main lines. Now on a trunk port if you have a configuration for an access vlan (switchport access vlan) but configure 'switchport mode trunk' then the port os a trunk port and the acces vlan configuration is ignored. In our case we're configuring a dot1q tunnel port and therefore the access vlan IS IMPORTANT. So what are we saying here? Basically the 802.1q tagged traffic ingress into the port is left tagged (as if it were an access port with no tagging). The next line switchport mode dot1q-tunnel no performs the double tagging - we're going to be ramming tagged VLAN 186 traffic into VLAN 3043. The MTU is set to 9216 to accommodate for the double 802.1Q tag and should not be missed.
We're disabling CDP so that we can tunnel CDP. What?! Well to help to explain this here is an example. When you have two directly connected cisco devices and CDP is running and enabled on these ports then you can 'see' the other device by issuing a 'show cdp neighbors'. This process is true also for Q-in-Q neighbors but we must turn off CDP between the two endpoints for the tunnel or else it would stomp all over the tunnel start points (in our example CDP would be tunnelled from 6500_FRONT but since the other startpoint is a Juniper device which doesn't undertsand CDP this step is unnecessary).
The l2ptotocol-tunnel allows us to send spanning-tree BPDU's down the Q-in-Q tunnel and CDP...we don't need them in our example but maybe you are creating a spanning-tree loop in your deployment so I think these lines are useful...just in case.
So now we are going to configure a normal run of the mill ordinary 802.1Q trunk link between the 6500_BACK and 3560 switches.
6500_BACK# configure terminal
6500_BACK(config)# interface g4/12
6500_BACK(config-if) switchport trunk encapsulation dot1q
6500_BACK(config-if) switchport mode trunk
6500_BACK(config-if) switchport trunk allowed vlan 1559,2127,3043,3738
6500_BACK(config-if) mtu 9216
So here we're just creating a normal trunk as we said. We're going to be trunking the Q-in-Q vlan 3043 we already created. Don't forget the jumbo frame MTU requirement. The other VLANs allowed on the trunk are for other things.
Right, at the other end of the link between the 6500 and 3560 we're going to again configure a normal bog standard trunk.
On the 3560 there is one requirement to enable jumbo frames before this will work. In global configuration mode we issue:
3560(config)# system mtu jumbo
Then we need a reboot. Without this line the switch will not be able to support the minimum 1504 bytes required to transport the Q-in-Q frames. So when we're back we can move on - all should be fine so far...it's just trunking.
Here is the configuration for the port connected to the Juniper EX stack.
So we're still trunking 3043...and some others but ignore those.
Now onto the Juniper EX stack dot1q-tunnel configuration.
First enable the protocol frame support.
Now lets create the VLAN - this took some time to get right int he Juniper documentation.
So we have created two vlans here. The first called X_SITE_INTERNET0 is carrying the Q-in-Q trunk traffic. Vlan XSITE_BACKBONE is carrying the untagged vlan 186 traffic.
Lets configure the port connected to the Cisco 3560. Again we need a dot1q trunk port and we'll restrict it to carrying only VLAN 3043.
So the last port configuration part if for the laptop port...
A quick 'show vlans XSITE_INTERNET_0 extensive'?
We see here that the 'Customer VLANs' are 186-186...or just 186 ;-) the ports ge-1/1/0.0 and ge-2/1/1.0 are the trunk ports connected to upstream Cisco switches (we've only looked at one of them...why do you think I had the STP stuff listed earlier ;-) ). The access ports are connected to host devices and are each in VLAN 186.
So there we go, IOS to JunOS using dot1q tunnelling. IT works, it's great tech, have fu.
First things first, lets kill off the VCP ports to disable the VC traffic.
Now go into config mode by typing ‘configure’. and then we’ll load the factory default settings.
Before we can commit the blank configuration we need to set the root password...it won’t save without it...give it a go if you want.
OK so now commit the blank configuration
Back into EXEC mode we’ll take a look at the new cluster status. Note we can’t see the other node because the VCP ports are disabled.
Lets run through the same process on the other node and commit. Now back in EXEC mode we turn the VCP ports back on. By NOT putting the keyword ‘disable’ on the end they are enabled...I know thats a bit poor but there you go.
> request virtual-chassis vc-port set interface vcp-0
> request virtual-chassis vc-port set interface vcp-1
So now we check the status of the node...all good. We have a Master and Backup in a two node cluster with FPC 0 and FPC1. The mastership priorities are both the default of 128.