Multicast MAC address issues w/A5506B 10/100 quad NIC

[Dan Hardison]

I have a rx4640 (Itanium2) running HP-UX 11.23 with an A5506B 10/100 quad NIC. Port #1 of this NIC is configured with the following:

IP = 170.186.166.123
MASK = 255.255.255.128
GW = 170.186.166.1

The default route for this subnet is through a clustered firewall environment utilizing a special purpose multicast MAC address and therein lies my issue. Because the default route is pointed at a special MAC address (0:0:5e:0:1:1), the nic card doesn't understand how to exit the gateway.

If I change the default route to point specifically at one of the firewalls in the cluster it works fine.

For example I WANT the default route to be 170.186.166.1, which when it's configured in that fashion and I execute an arp -a I get:

170.186.166.1 (170.186.166.1) at 0:0:5e:0:1:1 ether

**Note the multicast MAC address (0:0:5e:0:1:1)

When I point the default route at a specific firewall server (170.186.166.2) vs. the cluster IP (170.186.166.1) and execute an arp -a, I get:

170.186.166.2 (170.186.166.2) at 0:a0:8e:42:38:49 ether

**Note the NON-multicast MAC address.

Does anyone know how to get this NIC to work with that special purpose MAC address (0:0:5e:0:1:1)? I really need to utilize the obvious benefits of the cluster.

Thanks,
Dan

[Ron Kinner]

Given that the multicast stuff is annoying the HPUX, can you turn off the Multicast capability flag on the interface somehow? hpbtlanconf or ifconfig or lanadmin perhaps?

Ron

[rick jones]

Strictly speaking, routes point at IP addresses, not MAC addresses. IP address to MAC address translation is not really part of routing, it is simply plart of the layer 3 (network) to layer 2 (data link) glue - aka ARP.

The MAC address in the ARP entry will be the MAC address in the ARP reply from whomever responded to the ARP request for 170.186.166.1. That being the case, I would suggest running tcpdump (HP Internet Express bits from software.hp.com) to capture ARP traffic, delete the ARP entry with arp -d and then ping the gateway IP address. Examine the ARP packets you see.

something like

tcpdump -i -o -s 512

in one window and the the other stuff in another and then ctrl-c the tcpdump once you've finished pinging and such.

If I were to take a wild guess, I would say that the ARP code is taking the source MAC from the Ethernet header of the ARP reply rather than the HW address in the ARP reply header. I suspect that the MAC address you see is the actual MAC address of one of the firewalls.

Another thing - are you _sure_ that 0:0:5e:0:1:1 is a _multicast_ MAC address? I'm admittedly a little rusty on MAC addresses, but I thought the group bit was set on a multicast MAC address, and the group bit was the least signigicant bit of the first octet of the MAC - so I would have expected to see something like:

1:0:re:0:1:1

So is the 0:0:5e:0:1:1 actually a "virtual" MAC address instead?

[Ron Kinner · Accepted solution]

Rick,

I found this on his MAC:

"The RFC for VRRP (at
http://www.faqs.org/rfcs/rfc2338.html ) says:

The virtual router MAC address associated with a virtual router is an
IEEE 802 MAC Address in the following format:

00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)
The first three octets are derived from the IANA's OUI. The next two
octets (00-01) indicate the address block assigned to the VRRP
protocol. {VRID} is the VRRP Virtual Router Identifier. This
mapping provides for up to 255 VRRP routers on a network."

at:

http://article.gmane.org/gmane.comp.security.full-disclosure/21183


Dan,


Apparently Cisco routers also have a problem with this address. You have to assign static arp entries to make them work.

Don't suppose that would apply here since you say arp -a shows the correct MAC but it wouldn't hurt to try putting it in with arp -s

Also

http://www.usenix.org/publications/login/2001-12/pdfs/zwieback.pdf

says that these addresses do not ping unless you do something special.

"By default, a VRRPmc IP address cannot be pinged, although this functionality can be
enabled in IPSO 3.3. In addition to being useful for troubleshooting purposes,
enabling this feature is required for certain routers and operating systems that will not
forward any traffic to a gateway that does not respond to pings (for instance, the â dead
gateway detectionâ in HPUX)."

Could be that the problem IS dead gateway detection in which case we can easily fix that.

If
ndd -set /dev/ip ip_ire_gw_probe
returns 0 then
ndd -set /dev/ip ip_ire_gw_probe 0
will set it to stop the dead gateway detection. You will need to use route to delete the gateway and then add it back since the mechanism that takes a route out of the dead category doesn't work any more. You will need to make the change in /etc/rc.config.d/nddconf to make it stay after a reboot.

TRANSPORT_NAME[1]=ip
NDD_NAME[1]=ip_ire_gw_probe
NDD_VALUE[1]=0

(use the next higher integer if you already have entries here.)

If it says it doesn't know what ip_ire_gw_probe is then you need an ndd patch or you are running something below 11.

[Dan Hardison]

Thanks for all the replies. Ron's idea of the 'dead gateway detection' was right on target. I made the suggested changes and now I can point to the 'clustered' IP address. Thanks to all and points have been assigned.

Dan