Strange MAC Addresses

man proxyarpd?

Reply to
Manfred Kwiatkowski
Loading thread data ...

On a switched network (Catalyst 6509 wit CatOS 8.3(1)) arpwatch complains on

ethernet mismatch 57.122.145.233 0:90:69:xx:xx:xx (0:90:df:d7:4b:f4)

from a customer connected via a MPLS-Ethernernet connection. Any idea what could have happened?.

0:90:df:d7:4b:f4 does belong to MITSUBISHI CHEMICAL AMERICA, INC.

I also see similiar frames with

00-90-2A (hex) COMMUNICATION DEVICES, INC. 00-90-DB (hex) NEXT LEVEL COMMUNICATIONS 00-90-50 (hex) TELESTE OY

Regards, Arnold

Reply to
Arnold Nipper

Proxyarpd can actually be used as an arp-server to respond to arp requests with a third-party MAC to redirect traffic toward hidden/tranparent gateways and such. On the other hand unicast(?) arp replies should not be seen in a switched network (if not on a SPAN port and short of glitches.)

Reply to
Manfred Kwiatkowski

Ok, on (cisco-) routers one could configure it with

arp 1.2.3.4 0000.0000.0001 arpa alias

But why not catch him anyway, the source mac port should be in the switch cache.

Your information was sparse in any respect. If it was a request then it would be really strange. Perhaps a new HSRP/VRRP/whatever method? :-)

Reply to
Manfred Kwiatkowski

but if that would have been proxy arp then there would not have been a mismatch in the MAC address (0:90:69:xx:xx:xx != 0:90:df:d7:4b:f4). Wouldn't it? Furthermore I'm running a program which usually catches all proxy arpers very reliable. Also gratuitous ARP would look different.

Arnold

Reply to
Arnold Nipper

Well, but still the MAC address in the header would not differ from that in the frame. Didn't I mention that there are only routers connected to this network? So no one is running proxyarpd or does it have enabled. And as said: if so I would already caught him.

ARP reply? Did I say ARP reply? I guess that was an ARP request ...

Arnold

Reply to
Arnold Nipper

complains on

Just out of curiosity, how does arpwatch work when the host is sitting in another IP subnet from the monitoring device? Since arpwatch seems to work by passively monitoring MAC frames, I assume that in frames emerging from a router, arpwatch would report only the MAC address of the router, and match it with the IP address of the remote host? Unless, of course, you install arpwatch agents in every IP subnet you want to monitor, and have these agents relay the IP/MAC address pairings to some central location, e.g. using TCP/IP.

MPLS is like any other routed network in this regard. MPLS works above the MAC layer. When the final MPLS label has been popped, you're left with an IP packet as if it had emerged from any router.

Bert

Reply to
Albert Manfredi

I know where the frame is coming from. That's why I xx'ed the host portion. But that does not really help as the customer does not know.

Don't feed the dogs with too much information :-) No, I think I told everything what is relevant.

It has to be an ARP request. Otherwise it would not make any sense ... But why did you think it is a reply?

Not really. And as pointed out: all of the MAC addresses inside are really strange addresses.

Arnold

Reply to
Arnold Nipper

You may tell arpwatch which network it should expect on that given interface. Everytime it catches an adress not matching the given networks it will file a report.

Of course, if you have different interfaces, you have to start arpwatch per interface you want to monitor.

Arn -still mulling over where thes strange frame came from -old

Reply to
Arnold Nipper

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.