I'm off to a patchy start on this blogging thing. There's been a lot of work (as usual) and my free time has been occupied with woodworking and organizing the garage. Today was an interesting day for me, though. Today I got to work on prepping some Avaya ERS 4800 series switches for an SPBM interoperability test with the HP 5900 switches we've requested for testing.
Our initial SPBM distribution network design relied on Avaya VSP 7000 switches, but in order to do switch clustering (a must for the level of redundancy we're going for), they require additional licensing. On top of that, the HP switches have more 10gig ports (48 vs 24), more 40gig ports (4 vs 0), OpenFlow support, software upgrades without reboot (ISSU), and much simpler cluster configuration and management.
For edge switches, though, the Avaya 4800 series switches are hard to beat. They come at a decent price point, have lifetime warranties and software updates, dual power supplies, Layer 2 SPBM, and PoE+ support. Since we'll be retaining Avaya for the edge switches, I'd like to see if there are any hangups between their SPBM implementation and HP's.
One of the big advantages of SPBM is that adding new links is essentially a plug-and-play affair. Since the switches rely on a routing protocol (ISIS) for loop prevention, adding new switches forms new adjacancies and triggers the SPF algorithm. VLANs aren't trunked, they're carried using I-SIDs that point directly to the other end edge switch. No additional configuration is needed on SPBM NNI links to carry additional VLANs or I-SIDs. This means that, in the event of a link failure between two distro switches, traffic could potentially re-route through a mesh of edge switches, further improving our redundancy and reducing downtime.
Unfortunately, either due to my ineptitude (most likely) or equipment failure, my SPBM demo is not working right. I have four switches in a series, all running SPB, all with nearly identical configurations, all running the same software version. I have a single management VLAN shared among all four switches, a laptop that's a member of that VLAN, and the VLAN is mapped to the same I-SID on all four switches. Each switch can see the neighboring switches (ISIS adjacency) and each switch can see the more distant switches (ISIS LSDB), but I can't get any connectivity from end to end. Avaya supports CFM (Continuity Fault Messages) over SPBM, so you can conduct traceroutes and pings at layer 2. I can successfully l2ping and l2traceroute from one switch to its neighbors, but I can't make it passed one hop; I have no end-to-end continuity. Similarly, my SPBM unicast FIB is empty! I have no earthly idea where my data is going, but I'm guessing it's somewhere near Bermuda.
UPDATE:
We ended up going with the Avaya VSP 7254 series switches for our backbone (48x10gb, 6x40gb, switch clustering at the base license level). They overcame a lot of the limitations I found in the VSP 7024 switches.
The issues I had with the Avaya ERS 4800 series switches was a license/feature issue, not a configuration one. While operating in ERS mode (vs VSP mode which required a different boot image), they forcibly (non-configurably) flipped a bit in the SPBM handshake that was the equivalent of a stub flag. Since the same switch with the same hardware could operate either in VSP or ERS mode, I'm not entirely sure why this flag was necessary, but I was told repeatedly that it wasn't solely a licensing thing. Regardless, the fix was to swap the switch over to VSP mode and let that flag return to its now-again-normal off mode.
Follow-up: I found out that there was no fault on my behalf, but rather that the ERS4800 has a limited SPBM implementation. Any information received on an SPBM NNI port will NOT be forwarded out any other NNI ports. This means that you cannot send information using SPBM from one ERS4800 through another to a third. This is purely a software limitation - the VSP4000 software can run on the same platform via usb key sorcery and removes this limitation. I've voiced my disappointment with Avaya engineers, but I doubt they'll work to fix/change it.
ReplyDelete