Block arp packets on Catalyst switch

Hi, I'm trying to completely block arp packets per port. if not possible on a port, then blocking arp packets on a vlan would help as well.

I know all I'm going to get in replies is people telling me why I shouldn't do this, how my switch will implode, how I will upset the balance of nature, and asking me WHY I would do such a silly thing, and what an idiot I am for wanting to do this. So I will explain myself...

I am going to be setting up some automation to configure some devices, each and every device has the same IP address. meaning I can only configure one at a time. UNLESS.. I block all arp traffic, so the switch is unaware of duplicate IP addresses. I create a static arp table, artificially making each MAC a different IP address to the swtich. then I can configure each device as if it was a unique iP address. since traffic on a local LAN is layer 2 anyway. this should work.

So... I this is a VERY BAD IDEA on a production LAN, this is for a lab, this is not a production LAN, this will not be used for regular LAN traffic. I know this will make the switch not work for regular traffic.

I just want to know how to block all arp traffic on a port or vlan (preferrably port)

Thanks, Chris Toews

Reply to
cdtoews.spam
Loading thread data ...

The NICs will accept the packets, but the IP stacks in the devices will ignore them because they don't have the correct destination IP addresses. Will they be running in promiscuous mode?

And when the devices reply, the source addresses won't match the original destination addresses.

If you'll be configuring static ARP tables then you don't need to block ARP, because no one will be sending them.

Reply to
Barry Margolin

I have pretty much the same situation. One idea is to use UDP packets sent to the local subnet broadcast address. Every device will receive every message. Each message can contain an identifier of the station it is meant for and only that station processes that message. (That's the way multidrop systems typically work.) The devices must also include the identifier (or a message ID) in any reply to the server so it can keep the sessions straight. The identifier could be the device's MAC address.

This could also work using 2 IP multicast addresses, one for each direction, again with internal identifiers.

Of course quite a bit depends on the type of devices you have and their capabilities. Do your devices have fairly complete network support? If the devices and your configuration server platform support raw ethernet sockets, you can just use a different ethernet protocol ID and address the devices directly by MAC address. But such a scheme pretty much rules out using the standard tools I have available like TFTP, so that's not what I do. I just configure the devices one at a time (there aren't *that* many), and the script clears the ARP cache on the configuration server after each is completed.

I'm hoping someone suggests a clever solution to this problem.

Dave

Reply to
David Tiktin

Since a switch is layer 2 anyway, I don't think it would particularly care about IP addresses in the first place. Now, the systems _themselves_ might care about the duplicate IP addresses, but I don't think the switch will care one bit.

rick jones

Reply to
Rick Jones

The only way this will work is if the source and destination are all on the same VLAN. If the switch isn't doing layer 3, it doesn't even look at the IP address. If you are doing layer 3 then this will NOT work, because the ARP table is used to find the MAC address of destination (the layer 2 address) and then lookup the outgoing interface that the MAC is assigned to. This is why you get nasty messages when you have duplicate IPs because the layer 3 routing function can't figure out which MAC address the IP is using. The way to turn off ARP is simple, don't create a layer 3 interface for the VLAN.

Reply to
Thrill5

The devices I'm configuring don't have much capability. They have some sort of embedded software.

I will need to FTP to each device, and telnet.

This is a layer 2 switch.

My understanding of networking, is that unless you go through a layer

3 device (router), all traffic is by mac address. I have done this before to telnet to a device from a router that was not on the local LAN, but had some funky IP address. I created a static ARP entry, and then telnetted to that fake IP. The packets then flowed to the MAC address, and everyone was happy.

I will not know the MAC addresses until each device is plugged in. My thought was to open up the port for arp, then get the mac, close the port for arp, clear the arp entry, and make a static "fake" arp entry. So I would have a static arp table, but I would be changing it constantly as the devices were plugged and unplugged.

Thanks

Reply to
cdtoews.spam

In broad handwaving terms, unless the destination IP address in the header matches that assigned to the system, even though the ethernet frame will arrive at its NIC, and go into the host (since the MAC matches) it will not be accepted by IP in the host stack as being "for it." IP might try to forward the datagram (since the IP is not its own) depending on local settings.

It sounds like what you want is your own process-local IP stack capable of sending tagged VLAN packets to the switch, which is configured to strip/add the tags when sending to/receiving from the various ports where the devices have the one, duplicate, IP address. Inside of your own IP stack you could use the VLAN as the way to tell one system from the other.

rick jones

Reply to
Rick Jones

Switches do everyth> I create a static arp table, artificially making each MAC a different

I'm not really sure what you're saying. You say "to the switch", since switches don't care about IPs. Did you mean that you're going to create this static ARP table on the client you'll be telnetting from? This won't work -- the MAC addresses will be correct, but the device's IP stack should discard the packets because they don't match its IP address.

Reply to
Barry Margolin

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.