Recovering a faulty Juniper 4350 CF (with an iMac and a USB Printer)

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.

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.



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.



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.



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



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.

Juniper SSG Firewall IPv6 Tunnel

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.

Removing and resetting a Juniper EX Virtual Chassis node

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

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.