Has anyone seen issues with IOS where certain MACs fail? 54:52:00 (kvm) fails out an old 10mbit port on a 7206 running 12.2 SRE. I've never seen anything like this. DHCP worked, ARP worked, and arp debugging showed responses for arp to the MAC, however, tcpdump on the host system showed no unicast or arp responses coming from the router, while the switch management ip and other stuff on the local segment communicated fine with the vm. This broke for IPv6 as well. I changed the vm's MAC to 54:51:00, 50:52:00 and still failed. Changed it to 40:52:00 and it works for both v4 and v6. Was there a change which would cause certain hardware to not accept a MAC starting with 50: or higher? Jack
On 1/29/2011 4:24 PM, Jack Bates wrote:
Has anyone seen issues with IOS where certain MACs fail?
54:52:00 (kvm) fails out an old 10mbit port on a 7206 running 12.2 SRE. I've never seen anything like this. DHCP worked, ARP worked, and arp debugging showed responses for arp to the MAC, however, tcpdump on the host system showed no unicast or arp responses coming from the router, while the switch management ip and other stuff on the local segment communicated fine with the vm. This broke for IPv6 as well.
I changed the vm's MAC to 54:51:00, 50:52:00 and still failed. Changed it to 40:52:00 and it works for both v4 and v6. Was there a change which would cause certain hardware to not accept a MAC starting with 50: or higher?
Jack
I just ran into something like this yesterday. A Belkin router with a MAC of 9444.52dc.XXXX was properly learned at the IDF switch but the upstream agg switch/router wouldn't learn it. I even tried to static the MAC into the CAM..router refused. After changing the MAC address, everything worked. Best I can figure the router treated it like a broadcast MAC. DHCP snooping at the IDF and the upstream aggregation switch/router learned the IP/MAC/interface lease information. ARP entry at the router had the correct IP/MAC binding. Nothing in the CAM for the MAC of that darn Belkin.
On 1/29/2011 8:47 PM, ML wrote:
I just ran into something like this yesterday. A Belkin router with a MAC of 9444.52dc.XXXX was properly learned at the IDF switch but the upstream agg switch/router wouldn't learn it. I even tried to static the MAC into the CAM..router refused.
That's what really tripped me out, was that the router actually did place an ARP entry and pretended like everything should be working. Scheduling some more direct tests with packet sniffers next week when I get back in the office. I'm curious now if IOS has the issue or the line card, so we'll test off different cards direct and monitor results. Jack
I had an issue on the 28xx with a static NAT that just stopped working. The router would not publish the MAC for the nat entry. I removed the NAT entry and reapplied - and magically it worked again. On Sat, Jan 29, 2011 at 10:05 PM, Jack Bates <jbates@brightok.net> wrote:
On 1/29/2011 8:47 PM, ML wrote:
I just ran into something like this yesterday. A Belkin router with a MAC of 9444.52dc.XXXX was properly learned at the IDF switch but the upstream agg switch/router wouldn't learn it. I even tried to static the MAC into the CAM..router refused.
That's what really tripped me out, was that the router actually did place an ARP entry and pretended like everything should be working. Scheduling some more direct tests with packet sniffers next week when I get back in the office.
I'm curious now if IOS has the issue or the line card, so we'll test off different cards direct and monitor results.
Jack
On 1/29/2011 10:05 PM, Jack Bates wrote:
On 1/29/2011 8:47 PM, ML wrote:
I just ran into something like this yesterday. A Belkin router with a MAC of 9444.52dc.XXXX was properly learned at the IDF switch but the upstream agg switch/router wouldn't learn it. I even tried to static the MAC into the CAM..router refused.
That's what really tripped me out, was that the router actually did place an ARP entry and pretended like everything should be working. Scheduling some more direct tests with packet sniffers next week when I get back in the office.
I'm curious now if IOS has the issue or the line card, so we'll test off different cards direct and monitor results.
Jack
Turns out I ran out of space in the CAM..embarrassing. What didn't happen was frame flooding. Since this device was part of the ME34xx product line I'd wager Cisco thought it better to drop frames than leak data. I upgraded the IOS to 12.2(50)SE5 from 12.2(25)SEG. Somehow there is more space in the TCAM for unicast MACs between software versions.
Jack Bates <jbates@brightok.net> writes: Hi, a little late, but just catching up the list.
Has anyone seen issues with IOS where certain MACs fail?
54:52:00 (kvm) fails out an old 10mbit port on a 7206 running 12.2 SRE. I've never seen anything like this. DHCP worked, ARP worked, and arp debugging showed responses for arp to the MAC, however, tcpdump on the host system
I had something similar using a Catalyst 3550. Very simple setup: Host ----- Cat3550 ----- Router You could see arp-request from the host to the router and arp-replies from the router using tcpdump, but the arp-replies didn't make it to the host. No change in the interface counters on the switch either. When using a static arp-entry on the host and then ping the router you could the echo-request and echo-replies there but still no answers. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
participants (4)
-
Herro91 -
Jack Bates -
Jens Link -
ML