Before we go into First Hop Redundancy Protocols (FHRPs) lets just for a moment consider the challenge. In any internetwork you’ll have domains (AS) and segments (IP networks). Each domain and segment will be connected to the others ‘hopefully’ with multiple paths of such extreme cunning and wit that the loss of one, two or even three paths is necessary to bring your internetwork topology to it’s knees. Internetworking is a good thing and we’ve got loads and loads of protocols to help us get it right in terms of redundancy. IGP’s like RIP, EIGRP, OSPF and IS-IS all do a great job of providing our routers with preferential paths and load balancing etc.

For the local segment however your hosts (pc's etc) will usually only have one predefined (static) way in and out, most often just the default gateway. So what happens when your LAN gateway goes down? Well frankly you and all the hosts in your network are trapped. Unlike your routed network (running with multiple point-to-point links) your LAN segment will be supporting hundreds if not thousands of devices, losing the gateway on a LAN segment is bad news if you are a user but the administrator's day is apocalyptic.

So what can we do about providing some resilience to our local LAN users?

One of the more forgotten FHRP options is IRDP or the ICMP Router Discovery Protocol. The RFC1256 describes how ICMP 'Hello' packets are sent out by the routers into the local networks. End hosts 'listen' to these ICMP packets to dynamically learn the gateway address and install it into their routing tables. Clients can poll out using multicast to find new routers to get out should their ICMP acquired host go away. It’s pretty neat to be honest but it very rare to see in the wild these days. Thats not to say you should forget it however, it’s on the Cisco CCIE blueprint for sure.

So more realistic options? Well what about maybe loading up a dynamic routing protocol on the workstation itself? Most common open protocols such as RIP and OSPF are widely supported in PC operating systems with Windows, Linux etc. If we fire up RIP on PC and get it to talk to the routers in our network then of course if one of those goes then we should be able to build up a new route. This feels pretty good right? Well maybe, but it's going to be tough setting this up on a large scale. Also, with my security hat on, I can't say I'm over the moon allowing my hosts to affect my routing tables...what if someone redistributed one of my core networks so it looked like we should send traffic to their workstation instead of the finance database network...bad! We’ve got options around filters and authentication to add some security but again, complexity...feels OK but maybe not...lets move on.

Lets get dirty again now (or desperate) and bring in dynamic host configuration protocols like BOOTP/DHCP. If we were smart maybe we’d bring down the lease period for this sort of thing. If we get a gateway failure we can reconfigure the scope handing out IP addresses, netmask and the local gateway device. Change the gateway IP address to another unit capable taking the traffic which was going to the now broken gateway, we’re golden. If waiting for a lease to expire is too long (most default to 3 days) then some members of the team could always ask all staff to reboot their machines or do a quick DHCP refresh. If this was an organisation with 1000's of customers off the air I'm pretty sure this would be your last choice..or last task in employment. Either way I hope you’re getting the point here. This sort of ‘fix’ is unworkable.

One of the better redundancy choices for the local LAN is actually one of the simplest and oldest. Let's digress a little here. Remember ARP? We use the Address Resolution Protocol in our local LAN to get the remote hosts MAC address when we only know the IP address. Now enter Proxy-ARP. Proxy ARP is enabled by default on Cisco routers and, as the name implies, proxies ARP requests for hosts beyond the physical local network made by the host. Imagine a network 10.0.0.0/8 and hosts within our network have the IP address 10.1.100.1 to 10.1.100.254. Our local segment router has the IP address 10.1.100.1. When the host 10.1.100.10 wishes to talk to host 10.1.1.10 then it simply ARPs out for it (it is on the same network after all as far as it is concerned). So the router10.1.100.1 takes the ARP request and 'pretends' to be the remote host by sending the host 10.1.100.10 it's own MAC address as the destination MAC for 10.1.1.10. Pretty neat. The issue with proxy arp though is that if router 10.1.100.1 goes down and we have another router (in the same broadcast domain) then we have to wait for the ARP table of the host to go stale before it will ARP out again for that remote host. The ARP table will refresh in a few minutes if we are trying to talk to it. This time period again, is probably too long to be considered a solution even though it will eventually work and it’s way faster than DHCP).  To speed it up we can of manually clear the ARP table on the host (again we’re using man power here which isn’t exactly reliable or efficient) or send a gratuitous ARP out on the local LAN for those remote addresses (unworkable really).

Right, we’ve been through the pain, here is the treatment.



Enter Cisco with HSRP. Defined in RFC 2281, HSRP allows two or more (up to three) devices in the same network segment to share an IP address and MAC address. One of the 'HSRP group' will be the active router and will be advertising ownership of the virtual addresses and receiving traffic. When that active router fails it can have other routers with connectivity to the same sources to take over the traffic. HSRP is automatic, it’s pain-free, it’s wonderful. Cisco have gone on to develop HSRP further to watch availability not only to the local interfaces but also remote connectivity such as lost routes int the table, high packet loss and much more. By making sure that the healthy gateway device has genuine reliable connectivity to its upstream we’re making intelligent decisions right at the source.

Now, as we’ve seen before, the Cisco proprietary protocol developed and engineered by Cisco is often picked up by the industry, reworked and brought out as a standard. In this case HSRP was reworked into VRRP. Network devices other than Cisco run VRRP to provide this same service. The two protocols are almost identical and indeed on a Cisco host which supports both HSRP and VRRP is exceptional in its ambiguity. Configuration of VRRP uses the ‘vrrp’ keyword whereas HSRP uses the ‘standby’ keyword. Apart from a few other tweaks there is little to differentiate the two. VRRP is HSRP for the masses. It works.

The final FHRP on our agenda today is GLBP. This protocol operates to provide a virtual IP address in the same way as HSRP and VRRP however where GLBP differs is in the way it works the plan. GLBP is, like HSRP, a collection of 2 or more devices which offer a redundancy to failure of each other. Unlike HSRP and VRRP however GLBP also offers load balancing between these members. HSPR and VRRP each work on the master/slave or active/backup approach where only one member of the group can be actively passing traffic at any one time. GLBP works differently by electing an AVG (Active Virtual Gateway) member which in turn decides from its pool members how to distribute the load. The other members int eh GLBP ‘cluster’ are called the AVF or Active Virtual Forwarders. In exactly the same way as HSRP and VRRP elect the ‘master’ of their respective membership the highest priority GLBP member becomes the AVG. If the AVG fails then that is passed to the next highest member and so on (if all members have the same priority then the one with the highest IP is elected).

This ends our brief look into the dark but essential world of the FHRP.

Thank you for reading.
View Comments
So, we've all heard how great JunOS is and how it saves a lot of time in configuration and downtime? So what's the deal? This article is going to attempt to describe a few of the great benefits I've personally gained from JunOS.

The first thing I think needs to be said is JunOS runs on BSD, freeBSD to be precise. The vanilla BSD kernel has been hacked by the Juniper team over years and honed to be bullet proof. It is a very secure unix platform with some blistering speed tweaks for network I/O...well they are a network company so what would you expect. As a brief digression it would be correct to point out of course that the Juniper network performance numbers are huge, so much so that this is often the deal clincher for me. Unlike HP who use off the shelf Broccade silicon, the Juniper (and indeed Cisco) hardware uses bespoke ASICs to deliver performance.

Now, being based on unix means all those ex-unix admin guys (I count myself as one) can get great help from those excellent shell shortcut commands we used to use. You know the ones right? Here are a selection of some of the keys I use all the time to speed up editing commands in the cli.

Ctrl+p is go backward through your command history.
Ctrl+n takes you forwards again.
Ctrl+a moves you to the beginning of the current line
Ctrl+e moves you to the end of the current line

Now most people would use the arrow keys but in the good old days of ‘vi’ these were the grail. Indeed for the network admin the commands to move you around quickly are essential in my opinion. These commands also work the in Cisco IOS and frankly performing a 'no' quickly after you just screwed up by using Ctrl+p then Ctrl+a followed by a swift 'no' and return...phew!

What about deleting words before your cursor..or after? The ability to make your work lighter is just fantastic and the more you use the shortcuts the more time you will save and the more accurate your cli skills will become.

Here are some more

Esc+d deletes the next word after the cursor
Esc+backspace deletes the word after the cursor
Ctrl+k deletes all text from the cursor to the end of the line
Ctrl+y pastes that deleted text back in from the flashing cursor

Awesome power I'm sure you'll agree and all from Unix.

Right, thats shortcuts done so how else are we assisted by JunOS? Well I'm pretty sure we will all be familiar with the IOS '?' command. Well not surprisingly (remember the JunOS engineers were ex-Cisco) JunOS, as you would expect has the same context sensitive inline help. Just as in IOS you can hit the ‘?’ key at any time and be presented with a two column list including the available options to you for that context and a meaning behind the choice. But of course JunOS is great so where is the win? JunOS, as well as the ‘?’ command also has a more general 'help' command. This takes us back on a unix journey and is akin to the 'man' or manual command. Using the 'help' command in both configuration and operational mode offers up a much more detailed insight into the available com ands and functions available to the administrator. This command and is ideal when google is a far away dream and time is against you.

What's next? So, would you like the parser to examine the syntax of what you just typed to make sure it isn't going to break anything? What even if you, as an admin, setup some scripts so no-one can do anything to your kit outside of your best practice or business rules? IOS has no such protection against these mistakes or deliberate shortcuts. As an example take setting up a new interface. In IOS you might go into the interface, give it an IP address, do a quick ‘no shut’ and be on your way...it works right? Yes it does but what about the poor guy who has to come after you and try to find which the right interface was connected to SLD-2S21a? You might like to put a description in the port right? With JunOS you can force everyone to create a port description. Without the description you can stop the config going live. Awesome yeah?

Now add in fat fingers syndrome. With iOS once you've typed in your command and pressed return that command is now live and the mistakes can be really bad. Now the juniper engineers know that more than 70% of downtimes is caused by human error. JunOS from the start has had checkout for command acceptance. Think of it like a sandbox for code. The developer will work on a piece of code and that will be written in a protected area and examined by peers before it is put live. JunOS works in much the same way but the software itself checks the validity of the configuration you just typed and moves it form the safety of the sandbox into live for you. If the configuration looks wrong and doesn't pass the test then it fails and is not committed to the running service, it’s that simple. IOS in comparison offers not such protection. A bad commit, judgement or lack of sleep can cause mayhem on a live system. Many a time the only option for a cisco admin is to walk up to a box, get console access or power cycle the unit to recover service. There is always the good old admin 'trick' of 'reload in 5'. Where you give yourself a grace period of 5 minutes before the box automatically reloads itself in case you brick the configuration and make the device inaccessible. Of course you’ve still had 5 mins of downtime after the mistake pus a further 5-10 minutes (at best) of reload time before the service is resumed. Now you’ve got to fill in the incident sheet and re-write the change plan, resubmit to the change board, etc etc. and all because IOS really doesn’t know how to help you. We’ve said a lot here but let's look more closely at exactly how JunOS works for you to mitigate these issues for you.

Firstly JunOS has an operation mode and configuration mode (just like IOS). Changes to the configuration must be made in configuration mode. One of the extra ‘helpful features in JunOS however is called the ‘exclusive lock’. Bear with me here. How many times have you made a configuration change on a router only to find when you check back a few minutes later its gone? When you check it’s because Roger over in the other building has also been configuring the router you are on and has overridden your configuration while you are working on it. JunOS has the power to lockout all other users (you can force it if you need to) so you can have exclusive access to the configuration. When you put the box into configuration mode simply use the ‘configure exclusive’ keyword.

Screen shot 2011-06-04 at 22.05.07

So now that we are in configuration mode where else does JunOS help us. Well when the administrator wishes to configure a command we just type it in, same as in IOS. Crucially however and unlike in IOS, when the administrator hits return then command they entered is NOT made active. Instead that new change you just made enters what is called the candidate configuration.

Take this screenshot for example. Here we’ve changed the routers hostname from R1 to R3. The command has been entered and we’re on the prompt waiting to put in more configuration. Notice that the prompt still says R1.

Screen shot 2011-06-04 at 22.05.44

The changes to the candidate configuration can be added to and taken away without affecting the running configuration at all. When the administrator is ready to make the changes permanent they can use the 'commit' keyword and that configuration will be processed by the JunOS rules engine to check syntax etc. If the configuration changes are not 'right' then they will not be committed. It’s as simple as that. You can even check the configuration syntax without committing. It makes the process quicker and just keeps you 'honest' as you put in new commands. Use the 'commit check' command to check the syntax of your current candidate configuration. Use the ‘show | compare’ command to show changes made which differ between the candidate configuration and the current running configuration.

Here is an example. First we compare the changes between the candidate and running configuration:

Screen shot 2011-06-04 at 22.08.09

JunOS politely informs us we removed (the- / minus sign) the host-name R1 and replaced it by adding (the + / plus sign) in the hostname R3. Great stuff.

But it gets better. Remember that cisco 'reload in 5' command? Well JunOS has one of those too and can be called automatically when we make the commit. By typing 'commit confirmed' we instruct JunOS to commit the candidate confirmation to the running configuration but crucially if JunOS doesn't see any more comms and interaction from our console that it should automatically regress the commit we just pushed out to the last 'good' configuration we had...no reboot required...it's all about the uptime with JunOS!

In this example we have chosen to reload the router after 1 minute of inactivity. You can cancel the reload by re-issuing the ‘commit’ keyword (or you can commit and-quit) to drop back to operational mode.

Screen shot 2011-06-04 at 22.12.23

The default here is 10 minutes but it can be changed by putting the number of minutes you are willing to wait on the end of the confirmed statement e.g. 'commit confirmed 1' will wait for 1 minute only before rolling back the configuration....rolling back?

Oh! Did I not tell you? Yes! JunOS remember the last 49 configurations we had. When was the last time you wanted to go back to a previous configuration in iOS? Maybe you were smart and made a backup or maybe you hoped your management software had done that for you? Well with JunOS its built in. You can recall any previous configuration using the 'rollback' command where you append the number (up to 49) to go back as far as you need. Using the ‘help’ command ? At the end of rollback in configuration mode ill list each of the rollback configurations and details of when they were made active. This might help you find the one you need.

Here is a screenshot of the ‘rollback ?’ command - there are up to 49 of these. My personal best was rolling back to number 47 ;-)

Screen shot 2011-06-04 at 22.13.23

You can also use the JunOS cli to show you the differences between the candidate configuration and one of the backups. What power! Use the 'show | compare' along with the rollback command for this. You can see it in this example where we show the additions (+) and removals (-) of commands between the current running configuration and the rollback ’10’ configuration.

Screen shot 2011-06-04 at 22.14.43

One final bonus for JunOS is the hierarchical configuration. In IOS you are used to having sub-levels for common such as routing protocols where you have 'router ospf 1' for example and then get a subset of commands. Well JunOS is all hierarchical, every configuration from port to vlan to dot1x is in a sub system hierarchy. Gone are the days of typing ‘no vlan 100’ when you meant ‘no interface vlan 100’ oh the joy.

JunOS has great power but the best thing I’ve found is I get way more sleep now.

Thanks for reading
View Comments
So we've got to secure our Juniper router from un-authorised access attempts. There are a couple of ways we can access the device for configuration; console, telnet, SSH, HTTP(s) and NMS to name the main ones. Each of these however *needs* a username and password to permit access before we get in, we need it for authentication.


So lets go ahead and configure a username and password for our router. We've decided to be totally cliche and use the name 'admin' for our administrator account. First we need to get into configuration edit mode by entering the configure keyword from 'exec' mode.

root@R1> configure

Now lets enter the 'system' command tree (which contains the login 'features') by entering:

root@R1# edit system

Now we can add the user:

Screen+shot+2011-05-23+at+21.23.57

Whoa! What went wrong here? Well it's simple really, JunOS saved my arse. The password I chose to input here was 'junos'. Sure it wasn't a very secure password but I figured it was for a demo so who cares? Well JunOS cares. It is very kindly reminding you that the password you put in was poor and didn't pass the restriction guidelines of minimum password length of 6 characters (junos is 5 of course) AND that it didn't contain a mixture of either case, numbers or punctuation. So lets do that again and choose the password JunOS1!

Screen+shot+2011-05-23+at+21.24.42

All good. Now you know what - our company guidelines are more strict than that. We need to have a minimum of 8 characters and we need to also make sure that the new passwords being set have at least 3 characters of difference from the last. That is to say if my current password if PassW0rd! then my new password cannot be PaSSW0rd! because I only changed two of the letters to uppercase.

So lets put in the configuration to get the company policy met:

Screen+shot+2011-05-23+at+21.32.43

OK, so user set, password right, now lets put our user into the right security group. Admin is clearly an administrator and so we'll put that user into the highest security group with the most rights. Note that this command has been entered from the 'top' of the configuration tree rather than from inside the 'system' branch:

Screen+shot+2011-05-23+at+21.40.21

Right now we need to enable the services themselves. Out of the box a fresh JunOS configuration has no services enabled. Lets turn on Telnet and SSH.


Screen+shot+2011-05-23+at+21.22.59

Now we look back at our company security policy and notice that we are told to exclude 'root' user access from SSH enabled devices. We can do this in JunOS...well done eh...

Screen+shot+2011-05-23+at+21.33.59

So now the only user configured outside of 'root' is 'admin' so we'll be using admin to access the device. All good so far. But hey, we've got a router here on the network...anyone can access it. What we really need to do now is restrict access to it. Now on a Cisco IOS device we'd be talking about an access-list. We'd write the list and then apply it to an interface (vty for telnet/ssh). Well JunOS is just the same except, like always, JunOS does things a little differently.

Lets start be creating a firewall filter (comparable to Cisco access-list). First enter the 'firewall' edit mode, notice we first skip back to the top of the configuration tree:

Screen+shot+2011-05-23+at+21.35.04

Lets setup our filter to allow access from hosts in the 192.168.1.0/24 network. Forgive the screenshot the syntax goes thus (remember we are already at [edit firewall] level:


Screen+shot+2011-05-23+at+21.36.30

root@R1# set filter ssh-and-telnet-only term source-hosts from source-address 192.168.1.0/24

So thats the network access limited, and now we'll make sure this filter is matching traffic destined for telnet and ssh ports only. Remember SSH runs on port TCP/22 and Telnet on TCP/23 but we can match those using the application name. Again, the screen host has truncated and the beginning is 'set filter ssh-and-telnet-only term sour.....'

Screen+shot+2011-05-23+at+21.36.42

Finally we need to 'accept' this traffic. This is like the IOS 'permit' keyword.

Screen+shot+2011-05-23+at+21.37.04

So what do we do with the access which is denied? Well those sessions are dropped but wouldn't it be nice to see how many we're dropping? Lets add to our filter now with the 'count' keyword followed by a 'reject'. Both of these statements are called last in the filter. In IOS the reject would be implicit as a 'deny' at the end but like IOS if we want to log access attempts we need to add the 'deny log' statement at the end too...so not too dissimilar eh?

Screen+shot+2011-05-23+at+21.39.03
Screen+shot+2011-05-23+at+21.39.41

Right, access-list done now but we need to bind it to an interface. Just like in IOS where you would use an access-group or access-class for VTY ports in JunOS we simply add the 'filter' to the interface. Again, the screenshot it truncated:

root@R1# set interfaces em0.0 family inet filter...

Screen+shot+2011-05-23+at+22.40.17

OK, lets try a telnet now. 

Screen+shot+2011-05-23+at+21.41.10

Now lets try an SSH. First attempt causes my unix based host to prompt to add the SSH key signature to my known_hosts file...the second attempt has no such issue...we login...done.

Screen+shot+2011-05-23+at+21.41.38

Screen+shot+2011-05-23+at+21.41.54

Thanks for reading
View Comments
GRE (Generic Routing Encapsulation) is an industry standard for encapsulating data within an IP packet. Unlike IP protocol 7 (IPv4) GRE runs over IP protocol 47. It is often used to manipulate routing over non-broadcast networks or for sending multicast over IPSEC tunnels. This tech note was setup between a Juniper EX 4200 switch cluster and a Cisco 2621XM router. One of the issues with GRE traffic is its extra header which means payloads are reduced when you use it by an extra 4bytes (minimum).

So here is our basic topology. Remember we’re just using this to prove out the connectivity NOT to delve deeply into GRE itself or how we could use this to fix a ‘situation’. We’ll be bringing more of these technical guides as soon as we can write them using another 24 bit subnet 12.1.12.0. From here we’ll have two loopback interfaces (one on each device) and we’ll setup the routing to divert traffic between each of these loopback interfaces across the tunnel.

.Screen shot 2011-05-28 at 22.19.00

First lets configure the EX switch ge-0/0/0 interface which is connected directly to the Cisco 2600. Notice the bit-wise mask at the end. Cisco’s recent NEXUS platform running the NX-OS also now uses the bitwise pattern for netmask...interesting ;-)

Screen shot 2011-05-28 at 22.31.29

Lets configure the loopback interface

Screen shot 2011-05-28 at 22.31.37

Right now we’ll configure the GRE interface itself. It doesn’t matter in the order of the next three configuration lines but you DO need them all ;-)

The source is the beginning of the tunnel from ‘this routers’ point of view’. As an analogy think of you in your car. You are driving toward a tunnel going under a river from Coolville to Duddberg. As far as you are concerned the start (source) the tunnel is in Coolville. When you return however the start of the tunnel is in Duddsberg. Same thing for traffic going into and out of your tunnel here.

Screen shot 2011-05-28 at 22.31.44

Now the destination. Remeber this is all relative and the other side will look the opposite.

Screen shot 2011-05-28 at 22.32.04

OK, now thats the tunnel built we need to ‘load it up’ with loely IPv4 traffic. So, just like a normal interface we’ll give it an IP address and a mask.

Screen shot 2011-05-28 at 22.42.19

Right JunOS side done now, lets nip over to the Cisco box and do the same.

Lets configure the Fast Ethernet 0/0 interface which is connected to the Juniper switch.

Screen shot 2011-05-28 at 22.47.14

Now we’ll configure the tunnel interface. For brevity I’ve taken a pumped all of the configuration in here but it follows EXACTLY the same sort of configuration as JunOS. Source IP of tunnel, desitination IP, IP address of the tunnel...done.

Screen shot 2011-05-28 at 23.03.44

Right so now thats up lets see if we can ping either side of the tunnel.

Cisco side first...

Screen shot 2011-05-28 at 22.38.30

Cool, now the Juniper side

Screen shot 2011-05-28 at 22.49.52

Awesome. Right but we’re pinging the sides of a point to point interface here which isn’t exactly right is it. So if we’re going to be ‘routing’ traffic through this tunnel and not just having a secondary route (whats the point in our topology anyway) we’ll need to give each side routes to one another. We’re going to route traffic for each sides Loopback interface through the tunnel.

Juniper side first

Screen shot 2011-05-28 at 22.53.06

...don’t forget the commit in JunOS. You know it never fails to impress me how Juniper got JunOS so right for administrators. If we screwed this up and the router happened to be 1000 miles away we’ve got options. Auto rollback is the best thing ever.

Now the Cisco side

Screen shot 2011-05-28 at 22.53.41

...if we screwed up IOS we’d be gone ;-) Of course we could always issue that great ‘reload in 10’ shortcut to save our ass.

Ok lets ping out over the tunnel interface.

Screen shot 2011-05-28 at 23.04.19

Now form Cisco side...just because we can

Screen shot 2011-05-28 at 23.05.23

What about some statistics to back that up man?! OK, here we go.

Right Juniper side first again. We got 6 in and out here...

Screen shot 2011-05-28 at 23.07.03

Cisco side...

Screen shot 2011-05-28 at 23.05.59

Job Done.

Thanks for Reading
View Comments
Working on an EX recently we came across this rather curious issue. One of the checks the JunOS loader does as it extracts the new firmware is the CRC and validity checks on the package. To our great surprise we found this installation balked at us about time. Apparently we were installing a file which hadn’t been built until 25963681 seconds (300days) in the future!

Clearly the administrators had been a little lax in their approach to time keeping and certainly could do with a quick look at NTP. Anyway, without further ado lets have a look at the work we did:

First lets upgrade the stack. We’ll be using FTP to transfer the file from our FTP server running on IP address 10.15.100.75.
 
network@EX_STACK> request system software add ftp://10.15.100.75/jloader-ex3242-11.3I20110326_0802_hmerge-signed.tgz
 
Checking pending install on fpc1
 
Checking pending install on fpc0
Fetching package...
Pushing bundle to fpc1
 
Validating on fpc1
 
Validating on fpc0
Done with validate on all virtual chassis members
 
fpc1:
tar: +CONTENTS: time stamp Mar 26 12:18 2011 is 25963681 s in the future
tar: +COMMENT: time stamp Mar 26 12:18 2011 is 25963680 s in the future
tar: +DESC: time stamp Mar 26 12:18 2011 is 25963679 s in the future
tar: +INSTALL: time stamp Mar 26 12:18 2011 is 25963678 s in the future
tar: jloader-ex-3242-11.3I20110326_0802_hmerge.tgz: time stamp Mar 26 12:06 2011 is 25962920 s in the future
tar: jloader-ex-3242-11.3I20110326_0802_hmerge.tgz.md5: time stamp Mar 26 12:18 2011 is 25963673 s in the future
tar: jloader-ex-3242-11.3I20110326_0802_hmerge.tgz.sha1: time stamp Mar 26 12:18 2011 is 25963672 s in the future
tar: jloader-ex-3242-11.3I20110326_0802_hmerge.tgz.sig: time stamp Mar 26 12:18 2011 is 25963672 s in the future
tar: certs.pem: time stamp Mar 26 08:02 2011 is 25948330 s in the future
verify-sig: cannot validate ./certs.pem
certificate is not yet valid: /C=US/ST=CA/L=Sunnyvale/O=Juniper Networks/OU=Juniper CA/CN=PackageDevelopment_11_3_0/emailAddress=ca@juniper.net
 
{master:0}

HA this is perfect. OK so lets configure NTP so we don’t see this ever again (of course we could always just use ‘set date’ to do a quick fix but we’re not going to do that right?

... OK maybe just a sneaky look at setting the time manually.

At the command prompt enter the following command to set the time and date to 10:10:00 on May 27th 2011

network@EX_STACK> set date 201105271010.00

OK now we’ve had some fun there lets setup NTP. This guide assumes you have chosen a suitable NTP server. We’re going to use one of Manchester University hosts because I’ve been using it since 1996 (you can find a list of public NTP servers here)

Firstly lets tell JunOS to synchronise it’s time with the NTP server. In the past JunOS needed to be within 128 seconds of the NTP server time or else it would never sync up. Remember, if you are going to use the DNS hostname in this configuration (and we are) then you should make sure you have a DNS lookup configured. In our setup we’ve configured DNS lookup against the Google DNS hosts.

Screen shot 2011-05-27 at 22.26.05

So lets syncronise our server manually by initiating an NTP ‘get’

Screen shot 2011-05-27 at 22.34.26

Hey thats pretty good - we were only 1 second out already!

Right now we’ll setup the NTP client process so lets go into configuration mode:

Screen shot 2011-05-27 at 22.35.27

Now add in the ntp configuration command

Screen shot 2011-05-27 at 22.35.19

Lets just check it took this in the configuration

Screen shot 2011-05-27 at 22.35.14

Now commit it to flash and pop back to exec mode with the ‘commit-and-quit’ command

So we’re out of configuration mode lets check out the ntp associations and status...

Screen shot 2011-05-27 at 22.35.41

Right well we’ve got a stratum (st) of 16 here which means we’re not totally ready yet and either out router (R1) can’t talk to the remote NTP server or they cant talk to us. Lets wait...and wait...

Screen shot 2011-05-27 at 22.36.23

Great. It took about 10 seconds but now we see that we have syncronised with a stratum 2 server called ‘turnip’. I guess the hostname ntp2d is a CNAME.

All good, all in sync. Now we performed the upgrade again and it all went perfectly. Well done Juniper.

Thanks for reading.
View Comments
Recovering from EX disk failure (db> prompt)

Recovering from disk failure
One of the common reasons a switch drops out the cluster is disk corruption. If the cluster can't see the switch and vice versa, I would look at the status of the disks. Another giveaway is the LOADING JUNOS message on the LCD display on the switch.

The EX4200 switches have 2 internal disks (called internal media)


1. da0s1 (called slice 1)
2. da0s2 (called slice 2)

A USB disk can be plugged in the back of the switch and is called external media

Both the disks retain a copy of the OS and configuration files. The switch can use either of the disks to get the files it needs. When one disk is corrupt the switch will automatically use the other disk.

The following procedure is to be used to fix a corrupt disk. The general outline is as follows:

• Identify the corrupt internal disk.
• Copy all files from the good internal disk to a USB disk.
• Boot from the USB disk.
• Fix the corrupt disk.
• Boot into the fixed disk.
• Reboot the whole stack. 
• Confirm fix.

Before you start make sure you connect a console cable to the back of the malfunctioning switch. All work will be done using this console connection in case you lose your connectivity.


Procedure 

1. Identifying the corrupted disk

Console onto the stack and issue the following commands in user mode:

show system snapshot all-members slice 1 media internal
show system snapshot all-members slice 2 media internal


This will display the contents of disks da0s1 and da0s2 on all stack memebers

A good disk will look like this:

fpc0:
--------------------------------------------------------------------------
Information for snapshot on internal (da0s1)
Creation date: Jan 8 08:43:51 2010
JUNOS version on snapshot:
jbase : 10.0S1.1
jcrypto-ex: 10.0S1.1
jdocs-ex: 10.0S1.1
jkernel-ex: 10.0S1.1
jroute-ex: 10.0S1.1
jswitch-ex: 10.0S1.1
jweb-ex: 10.0S1.1
jpfe-ex42x: 10.0S1.1



For reference, fpc0 is the Flexible PIC Concentrator for Switch 0 in the stack. fpc1 is Switch 1 and so on...

A corrupt disk will look like this:

fpc0:
--------------------------------------------------------------------------
error: cannot mount /dev/da0s2a


In this case disk da0s2 is corrupt.

Now that we have identified disk 2 in switch 0 in the stack as corrupt we move on to the next step.

2. Copy all files from the good internal disk to a USB disk

Log on to switch 0 using the following command:

request session member 0

Lets look at disk 2 to confirm you are on the correct switch using the following command:

show system snapshot local slice 2 media internal

The output should be:

error: cannot mount /dev/da0s2a

Insert a 2GB USB disk into the USB slot at the back of switch 0. Take note of this point. We tried flash bigger than 2GB and USB hard disks and none of them worked. Also it seemed that the format had to be UFS or FAT32.

Copy disk 1 files to the USB disk using the following command:

request system snapshot local partition media external

Expect the following output if the operation is successful

fpc0:
--------------------------------------------------------------------------
Clearing current label...
Partitioning external media (da1) ...
Verifying compatibility of destination media partitions...
Running newfs (720MB) on external media / partition (da1s1a)...
Running newfs (217MB) on external media /config partition (da1s1e)...
Running newfs (480MB) on external media /var partition (da1s1f)...
Copying '/dev/da0s1a' to '/dev/da1s1a' .. (this may take a few minutes)
Copying '/dev/da0s1e' to '/dev/da1s1e' .. (this may take a few minutes)
Copying '/dev/da0s1f' to '/dev/da1s1f' .. (this may take a few minutes)
The following filesystems were archived: / /config /var


3. Boot from the USB disk

Issue the following command:

request system reboot local media external 

You'll get this prompt...type 'yes'

Reboot the system ? [yes,no] (no) yes

4. Fix the corrupt disk

Copy files from the USB disk to disk 2 using the following command:

request system snapshot local partition media internal slice 2 

Expect the following output if the operation is successful

fpc0:
--------------------------------------------------------------------------
Clearing current label...
Partitioning internal media (da0) ...
Verifying compatibility of destination media partitions...
Running newfs (187MB) on internal media / partition (da0s2a)...
Running newfs (56MB) on internal media /config partition (da0s2e)...
Running newfs (124MB) on internal media /var partition (da0s2f)...
Copying '/dev/da1s1a' to '/dev/da0s2a' .. (this may take a few minutes)
Copying '/dev/da1s1e' to '/dev/da0s2e' .. (this may take a few minutes)
Copying '/dev/da1s1f' to '/dev/da0s2f' .. (this may take a few minutes)
The following filesystems were archived: / /config /var


5. Boot into the fixed disk

Issue the following command:

request system reboot local slice 2 media internal 

You'll get this prompt...type 'yes'

Reboot the system ? [yes,no] (no) yes

The switch will boot into loader mode. Issue the following command at the 'loader>' prompt

loader> reboot

When booted login to the switch

Have a look around the switch and try a few show commands to satisfy yourself that everything is working fine. A good command to try is 'show virtual-chassis'

Expect to see all your switches in the stack. like the sample output below, what you want to see is status Prsnt on all the cluster members. 

0 (FPC 0) Prsnt B00000000000 ex4200-48p 128 Linecard 2 vcp-0
1 (FPC 1) Prsnt B00000000000 ex4200-48p 254 Master* 0 vcp-0
2 (FPC 2) Prsnt B00000000000 ex4200-48p 128 Linecard 4 vcp-0
3 (FPC 3) Prsnt B00000000000 ex4200-48p 254 Backup 1 vcp-0
4 (FPC 4) Prsnt B00000000000 ex4200-48p 128 Linecard 3 vcp-0


6. Reboot the Whole stack

Issue the following command:

request system reboot 

At the reboot prompt type 'yes'

Reboot the system ? [yes,no] (no) yes

7. Confirm fix


Login into the stack. Look again at the cluster status. Confirm all member status is Prsnt.

0 (FPC 0) Prsnt B00000000000 ex4200-48p 128 Linecard 2 vcp-0
1 (FPC 1) Prsnt B00000000000 ex4200-48p 254 Master* 0 vcp-0
2 (FPC 2) Prsnt B00000000000 ex4200-48p 128 Linecard 4 vcp-0
3 (FPC 3) Prsnt B00000000000 ex4200-48p 254 Backup 1 vcp-0
4 (FPC 4) Prsnt B00000000000 ex4200-48p 128 Linecard 3 vcp-0  
 
Issue the following commands

show system snapshot all-members slice 1 media internal
show system snapshot all-members slice 2 media internal


This will display the contents of disks da0s1 and da0s2 on all stack members


Complete file structures and the absence of error messages confirm success. Confirm all disks 1 and 2 look like this.


fpc0:
--------------------------------------------------------------------------
Information for snapshot on internal (da0s1)
Creation date: Jan 8 08:43:51 2010
JUNOS version on snapshot:
jbase : 10.0S1.1
jcrypto-ex: 10.0S1.1
jdocs-ex: 10.0S1.1
jkernel-ex: 10.0S1.1
jroute-ex: 10.0S1.1
jswitch-ex: 10.0S1.1
jweb-ex: 10.0S1.1
jpfe-ex42x: 10.0S1.1
fpc0:
--------------------------------------------------------------------------
Information for snapshot on internal (da0s2)
Creation date: Jan 11 06:40:09 2010
JUNOS version on snapshot:
jbase : 10.0S1.1
jcrypto-ex: 10.0S1.1
jdocs-ex: 10.0S1.1
jkernel-ex: 10.0S1.1
jroute-ex: 10.0S1.1
jswitch-ex: 10.0S1.1
jweb-ex: 10.0S1.1
jpfe-ex42x: 10.0S1.1


Done. Thanks for reading
View Comments
Juniper EX switches come with two separate flash partitions a root (default boot) and a copy of that root in another piece of flash memory. Each partition contains a copy of the boot software and the configuration. Now we've deployed a number of EX clusters and from time to time we notice that sometimes the secondary partitions (the non-active one) doesn't get upgraded with the active one. This obviously causes problems if the active partition is corrupted and wont boot. Manually booting the secondary to get the switch up doesn't help if it's in a cluster because that node is then marked at NotPrsnt (Not Present) due to the fact it won't be running the same software as the other nodes.

So, luckily Juniper have come to the rescue and brought out the latest 10.4 firmware to do the following (source: www.juniper.net)


Resilient dual-root partitioning, introduced on Juniper Networks EX Series Ethernet Switches in Junos operating system (Junos OS) Release 10.4R3, provides additional resiliency to switches in the following ways:
  • Allows the switch to boot transparently from the second root partition if the system fails to boot from the primary root partition.
  • Provides separation of the root Junos OS file system from the /var file system. If corruption occurs in the /var file system (a higher probability than in the root file system due to the greater frequency in /var of reads and writes), the root file system is insulated from the corruption.
Great news this. So lets upgrade our firmware and get this great feature. Here is a copy of todays firmware version:

show_version

We need to get hold of the latest firmware from Juniper's website so we download that...but there was also an issue with our Jloader...it was too old. We will need to delete the old loader and upgrade that as well as the firmware (Jloader Upgrade Link). Good news is we can do both then reboot to cut down on reboot time. We've downloaded the jloader and junos image (10.4R3 is recommended at the time we wrote this).

First lets just check we can ping the FTP server holding the firmware images. We're using FileZilla server for this and we've created a new user call 'junos'. You can get hold of 
FileZilla server here

ping_check


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:


request_jloader_process

Each node in the cluster will be upgraded in turn until it finishes and returns you back tot he prompt:

request_jloader_finish

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:

request_jloader_ftp


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.

request_junos_install

So, just like the man said 'A reboot is required to install the software'. Let us oblige...

request_system_reboot

It took about 5 minutes to come around again, I logged in and checked the firmware versions and loader.

show_chassis_firmware

Thats OK now I checked the state of the partitions

show_system_storage

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...

show_system_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.

View Comments
Hi all,

I know you're all desperate to find out how we configure Q-in-Q between IOS and JunOS and here we have it. You know, when we did this the effort required to get the Juniper EX part done was worrying. The Juniper documentation was pretty good and the Cisco Q-in-Q part is very well documented of course. This techguide will hopefully help some of you out there desperate to join these two great platforms as one.

First I guess we should provide a little background to Q-in-Q services. The idea is pretty simple, Q-in-Q is a process whereby a normal 802.1q frame is attached to another 802.1q header, hence the name. You will most likely use this is you have a requirement to say connect two layer 3 networks together which are separated by a layer 2 network. The layer 3 networks at each end may be in the same subnet and each of these geographically disparate networks can act as one.

Here is our challenge:

qinq

The laptop at the top of the diagram is connected to a Cisco 6509E and is in VLAN 186 with layer 3 network 10.1.186.0/24. We have another laptop at the bottom of the diagram connected to a Juniper EX cluster again in VLAN 186 with network 10.1.186.0/24. We need to get both of these laptops to operate within the same network despite being separated by a number of switches and hops. That is to say when I ping from one side to the other I want one hop to the destination.

Lets begin.

First we're hopefully all up to speed on VLANs and what they mean. If you need to read up on VLANs then take at look at our other techguides for a reminder. Lets create VLAN 186 on the first 6500 connected to the laptop and then place the port connected to the laptop into that vlan:

6500_FRONT(config#) vlan 186
6500_FRONT(config-vlan)# name X_SITE_INTERNET
6500_FRONT(config-vlan)# exit
6500_FRONT(config)# int g0/0
6500_FRONT(config-if)# switchport mode access
6500_FRONT(config-if)# switchport access vlan 186
6500_FRONT(config-if)# no shutdown
6500_FRONT(config-if)# end
6500_FRONT#

So now lets take a look at the port connected between the FRONT and BACK 6500's. We need to configure this as an 802.1q port. Remember the Q-in-Q takes our 802.1q frames first.

show_run_int_a_end


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.

show_run_int_a_end_bk


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. 

show_run_int_b_end_it

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.

show_run_int_b_end_toex


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.

junos_ex_dot1q


Now lets create the VLAN - this took some time to get right int he Juniper documentation.

junos_ex_dot1q_part2

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.

show_run_int_ex_to_ciscotrunk

So the last port configuration part if for the laptop port...

junos_ex_dot1q_part3


A quick 'show vlans XSITE_INTERNET_0 extensive'?


junos_ex_dot1q_part4


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.

View Comments
Recovering a Juniper J4350 should be easy because the manual says so. Just remember to take your screwdriver ;-)

A few weeks ago my lab router fell off the network. The console showed me repeating hash (#) symbols followed by a HEX dump of a few characters. I figured this looked bad...don’t know what happened. Since I didn’t need it right away I’ve left it until now. So time to have a go at fixing this now.

  • You’ll have to remove chassis from the rack (4 cage screws).
  • Put the router on the bench and take off the rack ears from both sides of the chassis.
  • Now go to the back of the chassis and you’ll see three black screws on the top. You need to unscrew these.
  • Along each of the sides of the chassis (again toward the top of the case) you’ll see three more screws. Unscrew these on both sides.
  • Now the case lid should come off.

Screen shot 2011-05-08 at 20.40.08

With the router lid off I now see there are 4 x PC3200 DIMMS toward the left hand side and the compact flash (256MB) is sat snugly against the motherboard. My task here is to reformat the flash with the ‘install’ image from the Juniper software download page. Now I’ve chosen 9.3 because I felt like it but notice that there are three flavours available for 256, 512 and 1024MB flash cards...choose the right one for your flash size - this one shows the 512MB version.

Screen shot 2011-05-08 at 20.45.16

I’ve gotten the image and extracted the flash from the 4350 (man that was a pain too because the fan buffer was in the way). Now, I don’t have a flash/PCMCIA slot in my iMAC but I do have a printer connected to it with a compact flash reader so I figure I’m going to give it a try with that. Flash plugged in I see this error by loading the Terminal, changing to root (sudo -i) then doing a ‘dmesg’ to see any kernel messages.

Screen shot 2011-05-08 at 20.36.25

Check it out, maybe my luck is changing. I see /dev/disk2s1 must be my Juniper flash card. Great now I can format it. First things first I need to uncompress the gzip file I just downloaded from Juniper. The original file was junos-jsr-9.3R4.4-export-cf256.gz. I run ‘gzip -d junos-jsr-9.3R4.4-export-cf256.gz’ to extract the file. Now I run the old faithful ‘dd’ (disk duplicate) command which is fairly common on *nix platforms to copy the contents of the archive onto the flash.

Screen shot 2011-05-08 at 20.36.01

....I wait...and wait some more...then

Screen shot 2011-05-08 at 20.52.07

Awesome - looks like the data is on now. So I replace the CF card into the chassis and power on (there is no way I’m putting all those screws back in just yet)..and...it didn’t work ;-( All I see is #’s and the fan keeps spinning up and down.

So I tried a USB stick. I took out the CF card because that is booted first. Then plug the USB flash into the front of the router and power on.

View Comments
Fact is that despite the hype and buzz the uptake of IPv6 has been slow, real slow. If IPv6 was having a race with the turtle it would lose and it won’t need a rest and 40 winks either. Despite US government mandated to introduce IPv6 throughout by June 2008 we’ve not seen huge uptake around the world. World IPv6 day in 2011 will be used by big brands such as Google to demonstrate that there is a framework for using IPv6 across the internet.

So how do you use it? The IPv6 protocol is really smart and collaboration with IPv4 networks was designed in from the start. This brief article is all about how we get IPv6 over an IPv4 network using an IPv6 tunnel broker. We recommend the TE guys - so go ahead, signup for an account, get your /40 IPv6 allocation and come back when you are ready.

You have it now? Great here we go.

The Juniper SSG firewall has IPv6 support from like ScreenOS version 5.3 or so. The trouble is that it isn’t enabled and you can only ‘turn it on’ via the CLI. I’m doing this configuration using ScreenOS 6.2

> set envar ipv6=yes

Now we have to do a reboot...I know...shocking. Anyway reboot and when you get your box back we’ll go with the next bits.

Create a tunnel interface, bang it into the’ Untrust zone’.

set interface tunnel.1 zone Untrust
set interface tunnel.1 ipv6 mode host


So now we enable the tunnel interface with IPv6 and give it your end of the IPv6 network you’ve been allocated for the point-to-point tunnel (/64)

set interface tunnel.1 ipv6 ip
set interface tunnel.1 ipv6 enable


We set the encapsulation to a 6in4 or IPv6 encapsulated into IPv4 packets

set interface tunnel.1 tunnel encap ip6in4 manual

The tunnel is built and pointed at the other end (IPv4 now because we are going across the normal internet)

set interface tunnel.1 tunnel local-if untrust dst-ip

Turn off neighbor discovery - you don’t need it because you’re not running IPv6 with your ISP...probably

unset interface tunnel.1 ipv6 nd nud
set interface tunnel.1 ipv6 nd dad-count 0


Finally you need another defaultroute for your IPv6 traffic using your broker IPv6 address as the next hop

set route ::/0 interface tunnel.1 gateway

So thats all you need for the IPv6 tunnel but you want your LAN hosts to go across this right so we need to enable IPv6 on your LAN interface. The following configuration enables it into a bridge interface on my SSG but you can do the same config for any number of ports

set interface bgroup0 ipv6 mode router
set interface bgroup0 ipv6 ip
set interface bgroup0 ipv6 enable
unset interface bgroup0 ipv6 ra link-address


So we enable ra (Router Advertisements) for our LAN hosts to learn the IPv6 gateway

set interface bgroup0 ipv6 ra transmit

We really want to enable neighbor discovery now because we are runnign IPv6 on our LAN and our hosts will understand this (if they are dual stack of course...which most modern OS’s are).

set interface bgroup0 ipv6 nd nud

So thats it - if you hop into the GUI now and go to interfaces you should see the state of the tunnel.1 as ‘Active’ or ‘Ready’. If your LAN machine is IPv6 aware it should be able to learn an IPv6 address using EUI-64 and will learn the SSG as the gateway to the internet.

You’ll need so configure a policy in the SSG to allow outbound IPv6 from Trust to Untrust or it won’t let you out! Have a look at your policy and you’ll see two distinct entries for IPv4 and IPv6...all good stuff.

Now fire up a browser and go to
test-ipv6.com to see if it’s all s-a-weet.

Good Luck, Happy IPv6 Day.
View Comments
We’ve broken up the 5 node cluster and re-racked two of the nodes into a new stack. The following screen shot shows the two nodes as ‘Inactive’ and node members FPC 1 and FPC 4. Both are Linecards because the Master and Backup switches were nodes 0 and 3 in the pre-existing cluster. You can also see that only the vcp-0 virtual chassis cable has been connected (the vcp-1 cable is disconnected for no reason other than we didn’t do it).

Screen shot 2011-04-18 at 21.59.44

First things first, lets kill off the VCP ports to disable the VC traffic.

Screen shot 2011-04-18 at 22.04.16

Now go into config mode by typing ‘configure’. and then we’ll load the factory default settings.

Screen shot 2011-04-18 at 22.05.20

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.

Screen shot 2011-04-18 at 22.06.02

OK so now commit the blank configuration

Screen shot 2011-04-18 at 22.07.01

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.

Screen shot 2011-04-18 at 22.06.34

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.

Screen shot 2011-04-18 at 22.16.25

View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.