NetworkNick.net

Magnum 1 and 2 in the TACC datacenter. Amazing. Magnum = a 5-stage, 3500 port IB switch @ TACC. Cable management? …I’d call that cable execution! More details (and Andy’s math) here:

http://blogs.sun.com/jonathan/entry/size_matters

For all of you that were wondering, I’ve left HP ProCurve for a new opportunity, Arista Networks. Arista is a 10 gigabit Ethernet provider, focusing on next generation data center interconnect. I’ll still be around to answer questions and post thoughts, even if they are about ProCurve. However, I may have more of a 10 gigabit data center bent from here on in…

For your downloading pleasure.

There is another often requested feature now in the code base. The “pipe”.

Strangely it isn’t documented, but you have the standard begin/include/exclude set of options.

Usage:

show run | begin vlan

So here’s one for you…as of the K.13.X release of code, you now can use DHCP options 66 and 67 to specify a TFTP server and filename for configuration at boot. The switch listens by default for these options. Combine that with the “auto-tftp” command, and voila!…You have a switch that is configured and standardized with your version of software.

Not bad at all..

So it looks like I was running an older version of Wordpress for my blog and fell victim to this vulnerability. NOT PRETTY. Cleaned it all up and upgraded to 2.5, but man, what a pain. Either way, hope no one visited and got a virus from the hidden frame code. I’ll be more diligent to upgrade/watch for security holes in the future…

So I was at a client site this week troubleshooting a strange traffic mirroring issue. It went something like this:
I thought the ProCurve 3500 mirror port was dropping specific inbound oversized SIP packets on the outbound mirror port. The actual traffic went through, but the mirror port only saw the continuation frame, not the initial 1500 bytes frame. This was a standard 1 port>1port mirror configuration, bi-directional, no filtering. So we dug in to find out why the mirror port wasn’t forwarding that first frame. For a while we were stumped, but then I did a netstat -e on the sniffer (Windows based) and whatdya know, it’s got 63,000 unknown frames…! So here is what happend:

When you mirror an interface on the ProCurve switch, even locally, any traffic sent outbound on the monitored port has a VLAN tag appended for the VLAN it is part of, even when you are monitoring an untagged port. When you are sniffing traffic with a non 802.1q compliant NIC, and the packet size exceeds 1514, (you get fragmentation obviously). HOWEVER, because the total packet size is 1514+4 bytes for the VLAN tag outbound, the sniffer NIC drops it completely as it is oversized. This was causing the sniffer to miss the first packet (total size~1800 bytes) and just see the second fragment(~300 bytes). Once we connected a 802.1q compliant NIC to the system, we saw all packets.Moral of the story: Use a .1q compliant NIC if you what to see all bidirectional traffic on a ProCurve mirror port. If you don’t have a .1q compliant NIC, make sure to enable the .1p setting in the driver, this will allow it to recieve the oversized packet (although it won’t interperet the VLAN tag).

I speaking with one of the developers, the intent of appending the tag was to allow an IDS system to delineate traffic from multiple networks on a single upling/mirror session, but this obviously breaks some expected behaviors elsewhere. ProCurve is going to be releasing an enhancement that allows you to disable the VLAN tag on the mirror session, but until them, make sure your NIC can take the tag!

When working with ProCurve products and SNMP, we do a lot with ifIndex, standardized in the RFC 2863 IF-MIB. Of course, the physical/logical correlation of the ProCurve interfaces with the MIB ifindex entries don’t line up, ie, port A1=ifindex 1, but port B1=ifindex 25. Also, VLAN’s and loopbacks get their own entries, and those aren’t static. The best way to find out what the ifindex entry to port/VLAN map is to do a “walkmib ifdescr” from an enable prompt. I will show you every interface/VLAN/lo interface and it’s “name” in ProCurveese.

Pretty much everyone knows that reserved multicast addresses are always flooded on ethernet networks. IGMP does not program filters for packets addressed to the “Reserved Multicast Address” range. There are Reserved Addresses at Layer 3 (i.e., 224.0.0.1 – 224.0.0.255) that at layer two are indistinguishable from a broader range of MAC Addresses (because the Multicast Mac Address always begins with 01005E-XXXXXX, which covers the leading byte plus one more bit of the IP Address). No filters are programmed for these, nor should they be as this will break other multicast protocols.

So the story here is, L3 reserved addresses are the 224.0.0.X, but L2 really has more reservations because of the way the IP maps to the MAC.

That being said, the following addresses are always flooded (i.e., never filtered):

224.0.0.XX 224.128.0.XX
225.0.0.XX 225.128.0.XX
226.0.0.XX 226.128.0.XX
227.0.0.XX 227.128.0.XX
228.0.0.XX 228.128.0.XX
229.0.0.XX 229.128.0.XX
230.0.0.XX 230.128.0.XX
231.0.0.XX 231.128.0.XX
232.0.0.XX 232.128.0.XX
233.0.0.XX 233.128.0.XX
234.0.0.XX 234.128.0.XX
235.0.0.XX 235.128.0.XX
236.0.0.XX 236.128.0.XX
237.0.0.XX 237.128.0.XX
238.0.0.XX 238.128.0.XX
239.0.0.XX 239.128.0.XX

Good to keep in mind when choosing that arbitrary address for your multicast application. Make sure that it doesn’t end up in the reserved L2 space!

I’ve had a lot of partners and customers lately asking me for a Cisco interop document from ProCurve. These aren’t officially sanctioned, but should do the trick.

Here is the link to a zip file containing the following:

Cisco interop powerpoint: This was put together by one of the European technical consultants, and discusses things like migration strategies and command comparisons.

Cisco interop PDF: The semi formal guide for L2-L3 interop with Cisco devices and proprietary protocols.

Spanning tree notes: MSTP and RSTP/PVST interop notes. Maximize your STP!