Ankur,

No, unfortunately they do not come from DHCP as far as I know. If they are, then it is a rogue DHCP server as well! But I don't see any trace of DHCP when I snoop the broadcasts on an access port on the VLAN, so I think they must be coming from somewhere else.

Kevin Dorrell

Luxembourg

hi,

can't you just connect a sniffer to the VLAN and use a capture filter to prevent logging the other packets?

I did consider this. There are two ways I can sniff the VLAN: I could connected the sniffer to an access port on the VLAN, or I can set up a span monitor on the VLAN.

I tried setting a sniffer on an access port on the VLAN, but I received nothing from the rogue address, even when the "router" was telling me that it had seen packets hitting the access list. That tells me that these packets were MAC-unicast to the router. So that makes me wonder where the rogue machine got the router MAC address from. What I suspect is that these packets are originating on some PC that has two NICs in it, one on the VLAN, and the other on a rogue network, and that the PC has bridging enabled on it. Therefore, the PC knows the router MAC address from its ARP on the legitimate side of the network. So I don't think there are any broadcasts to be sniffed, so I am not getting anywhere with the access port.

The alternative is to span the whole VLAN to a monitor port, and use the capture filter on the sniffer. I am reluctant to do that because the VLAN is carrying an aggregate of about 250 Mbps through this switch, and the monitor port is only 100 Mbps. If I do that, I want to absolutely sure that the monitoring process is non-blocking.

Can anyone answer that please? Is it safe to monitor source a vlan that has 250 Mbps running through it when the monitor destination has only 100 Mbps?

Alternatively, is it possible to span monitor the layer-3 vlan interface only?

I know in theory that it should be possible to filter a monitor session with an access list, but I tried that on a quieter VLAN and it did not seem to work when the source was a VLAN. Has anyone else experienced that?

Kevin Dorrell

Luxembourg

Kevin,

This is a wild idea, but... I can't remember which comes first between ACLs and policy routes? if it's the latter perhaps you could policy route the rogue IP around the ACL and out of another interface - you could put the sniffer there? or if policy routing comes second let the IP through the ACL first.....

I seem to think policy routing might not be fast switched, it could put a heavy load on the CPU...

Dave

Dave,

My initial reaction was great, good idea. And even if the access-list came before the policy route, I could still afford to let a couple of packets through just to diagnose : after all, they won't be going anywhere. And the amount of routed traffic is tiny compared to the local traffic.

But then I thought again ... the router will put its own MAC on the forwarded packets. :-(

Nice idea tho'.

There must be something in the CEF tables or the CAM that will tell me ...

Kevin Dorrell

Luxembourg

An off the wall kind of idea.

Get a PC or similar, manually configure it with an IP address close to the rogue IP address, I would initially go with a /24 mask, and try to ping the rogue MAC address and check your arp table.

Out of interest (assuming it is not sensitive info) What IP address is popping up? I am just wondering about the 169 addresses that appear from time to time...

I'm afraid I already tried that. I went to a switch that was no ip routing and created a VLAN interface on it and did something similar, but no response .. not even an ARP response.

The address is variable, but always 192.168.x.1. That is why I want to make sure there is no user(s) with a second NIC card attached to an Internet router. It looks suspiciously like the kind of address you would use on a home network router.

I have also had the 169.254.x.y, but I manage to track all those down fairly quickly. They do respond to the technique you suggested. They also tend to be quite broadcasty. It does happen from time to time when someone forgets that we don't do DHCP here. Sometimes I'm tempted to install a single-address honeypot DHCP server, and an alarm on its address on my NMC. That would make those quicker to track down.

Kevin Dorrell

Luxembourg

Hi Kevin,

Think SMURF attack, any host when hit by a broadcast will respond regardless of its configuration. More specifically now that you know the IP address you are looking for use a ping of the broadcast address or a ping of the network number from the connected router interface and the device will respond. From there you will have an entry in the arp table of the router and the corresponding MAC address.

Cheers,

Brian