Friday 28 March 2014

Juniper Part number confusion

So this is another one which should be very obvious but again I'd never questioned it until recently, so I'm jotting it down for reference.

For Juniper's larger routers (MX etc) there are a number of items which are redundant - PSU, RE, SCB etc. Now when looking through the price list these items each have 3 different part code options: -BB, -R, -S

Here are the differences:
-BB = Base Bundle - This item is purchased when buying a new chassis and is often discounted because of this. You cannot purchase this item with the complete chassis.

-R = Redundant - This item is purchased with a complete chassis when you want a redundant item. For example, if you require a chassis with 2 SCB then you would purchase 1 -BB and 1-R.

-S = Spare - This item is purchased often if you are upgrading an existing chassis - I.E. replacing an item in an existing chassis with a new item, or adding a redundant component to an existing chassis.

Cisco MSE Appliances need L2 adjacency for HA operation

HA is a wonderful thing for obvious reasons but you do have to tread carefully sometimes when designing and deploying it.  I am specifically referring to the appliances / applications themselves and their physical location. Some appliances need to be located on the same subnet, which usually means physically very close. You can often fudge this by extending the layer 2 domain (such as using OTV) but this can be dangerous due to latency etc which can cause some unpredictable results, and not always practical.

MSE (7.4) is one of these applications. It maintains a health monitor connection to keep the two appliances synchronised and up to date.

LX4 and LRM optics are not compatible

Here is something I ran into and is certainly worth noting down and remembering:

LX4 and LRM optics are not compatible

This perhaps should be obvious as they are different standards but it wasn't until I looked into it and now I know for certain.

LX4 is standard IEEE 802.3ae and LRM is standard IEEE 802.3aq, you can look into these further on Wikipedia or another resource but the gist of it seems to be that the standard work in different ways making them incompatible. There is a good support forum link in the resources below.

This all came around because a customer wanted to buy more X2-10GB-LX4 optics but these are EOS, the recommended replacement is the X2-10GB-LRM optic which is incompatible. The options here then are to upgrade the existing line cards and replace the old LX4 optics with LRM optics or try to purchase any existing LX4 optics which may be in stock somewhere, but this is only a temporary fix as Cisco are not making them any more.

So a work of caution, don't take the Cisco recommended replacements completely at face value.

As a side note, optics of different form factors are compatible, so a X2 LRM and Xenpak LRM module would be fine, in the same way a LC SFP module can connect to a SC GBIC module if they are both using the SX standard.

Resources
Cisco Support Forum post:
https://supportforums.cisco.com/discussion/11270096/x2-10gb-lx4-sfp-10g-lrm-compatibility

Juniper EX4550 Switches Airflow Confusion

So this is a quick note to clear up some confusion I had regarding the airflow on Juniper EX4550 switches.

The airflow on these switches is either front-to-back or back-to-front however this is not immediately apparent from the datasheet, and this is always my quick go-to place for information. I think this is mainly my fault for not reading this properly but it is also written in a confusing way.

The datasheet states:
"port side to PSU side airflow" which if you are reading this quickly looks suspiciously like "side-to-side"

To be sure I've had this checked with Juniper, and it is verified in the tech doc below, but the airflow is definitely front-to-back, back-to-front PSUs are also available.

References
EX4550 PSU Tech Doc:

EX4550 Datasheet:

Cisco CME v10 8831 conference Phones issues

We have a bug / issue with conference phones and Cisco Communications Manager Express (CME) v10.

The current Cisco conference phone is the 8831, the previous version was the 7937G. The 7937G is end of sale as of 31st March 2014 which means that the only available conference phone is the 8831 (unless you purchase refurbished / from distribution but this cannot be guaranteed due to stock levels). So realistically the option is the 8831.

The issue however, is that the 8831 is not supported by CME version 10, and CMEv10 is the current version, therefore companies upgrading to version 10 of CME had better be using older conference phones.

There is currently (28th March 2014) no work around for this, if you are running CMEv10 you either need to purchase older 7937G conference phones or wait for CME version 11 to be released, currently targeted for around July 2014.

Tuesday 25 March 2014

Working Out Address IPv4 Ranges using Subnet Mask and Wildcard Mask Math

So this probably is old news to a lot of people but I've just come across it and it's going to save me some long hand mathematics so I'm jotting it down here:

There is a quick and easy way to work out the valid range of addresses for a subnet knowing just the IP address and mask.

First you take the network address and mask (obviously work out the network address first if you do not have the network address) - For example 10.17.32.0/19

Write them down in dotted decimal - 10.17.32.0 255.255.224.0

Subtract the subnet mask from the 'all 255's mask' - 255.255.255.255 - 255.255.224.0 = 0.0.31.255

Add this value to the network address - 10.17.32.0 + 0.0.31.255 = 10.17.63.255

And here you have the valid range of addresses 10.17.32.0 - 10.17.63.255

Excellent!

Monday 17 March 2014

IPSLA to Track Multiple Objects

IPSLA is a very handy feature but one specific use case for it is determining if a connection is up, for example a connection to the Internet. A router can use IPSLA to continuously ping a resource on the Internet (for example Google.com) and if they resource becomes unreachable then the router can act upon this. This is especially useful if your Internet connection is not physically down but it has no connectivity, perhaps there is issues within the service provider but because the interface is not down features like HSRP tracking will not kick in.

One draw back with this is that if the resource on the Internet goes down then the router thinks the connection has gone down and will act upon this. To stop this happening Enhanced Object Tracking can be used with IPSLA so that 2 (or more) objects can be tracked, with a Boolean expression, I.E. Google.com and cisco.com with the AND boolean expression would mean both objects would have to unreachable in order for the router to act, and this is highly unlikely, unless your Internet connection is down.

Saturday 15 March 2014

Flash Directories on Cisco Devices

So here's a little qwirk, some Cisco devices seem to save IOS images within directories and some save them straight the flash. By the IOS image file I'm talking specifically about the .bin file.

I found this out because generally the image files I deal with have all been saved directly to the flash so you can copy them with the copy flash: tftp: command, then you enter the IP address of the server and the file name and off it goes, but I tried this with a new switch I've purchased, a 2960-24TT-L and I kept getting this error message:
%Error reading flash:c2960-lanbase-mz.122-35.SE5 (Is a directory)

After a bit of searching it is exactly as it describes, the IOS image file (.bin file) is in a directory with the same name. So the fix was instead of trying to copy a non-existant image file from the flash:
copy flash:c2960-lanbase-mz.122-35.SE5.bin tftp
= wrong

I had to copy the file from within the directory of the same name:
copy flash:c2960-lanbase-mz.122-35.SE5/c2960-lanbase-mz.122-35.SE5.bin tftp

Easy when you know how...


References:
Here's the link to a Cisco support site which I got my steer from, FYI: