Blocking IP ARP per port on 3550

[jlamanna1]

Hi,

We have a setup where we assign multiple customers into the same VLAN.

We do this to save IP space, since most of our customers need only 1 public IP address, so assigning them each a VLAN would be incredibly wasteful.

However, we have had issues where a customer inadvertently assigns a device the public IP of another customer on the same switch, causing that customer to lose connectivity.

Is there any way to block ARP requests by IP on a per-port basis? Currently we have 3550 switches deployed.

If newer hardware supports this, please specify.

Or do people have other ideas as to how to go about implementing this model?

Thanks.

-- James

[Jon Marshall]

James

If you knew the mac-address of the customer device then the 3550 supports arp access-lists which allows you to permit or deny arp requests/replies based on the IP/mac-address pair and you do this per vlan -

http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.2_25_sec/command/reference/cli1.html#wp2429213

however if the customer can use any device then you are limited in what you can do because the mac-address could change. I appreciate why you are using only one vlan for address conservation but this is quite dangerous to do when the cutomer can configure any of the public IP addresses on their devices.

Does the customer actually need to use a public IP or could you simply assign private IPs to the customer and hence have a vlan per customer and then NAT that address somewhere else (obviously not on the 3550) ?

Private vlans allow you to segregate the L2 vlan but i'm not sure these would be of any use if he customer can simply change their IP.

If you can i would -

1) get the mac-address of the customer device and add that statically to the 3550. Obviously you would then need to tell the customer they cannot change the device

2) use arp access-lists to control which mac-address/IP pairs are allowed. Trouble is, if the customer is happy to change the IP then they may be just as happy to change the device.

Edit - one last point. I have never used arp access-lists before so it would need testing but from reading the docs it looks like the sort of thing you are after.

Jon

[jlamanna1]

Hi John,

Yes I've looked at using mac address lists.

However are these only per-VLAN? Or can I assign them per-port?

I'd really like to avoid having to gather mac addresses from customers for obvious reasons.

Unfortunately, most customers need public IPs because they also have routers in their office suites, and usually need RDP services, not to mention many of these customers are on VoIP to a hosted PBX, and double-NAT is death to SIP.

-- James

[Matthew Blanshard]

Hello James,

I can't think of any way which you can accomplish this without gathering the mac addresses of your clients.  You can either do ARP ACL's and dynamic arp inspection or you can setup DHCP for your clients and use static dhcp reservations on the server, and then use the dhcp snooping/dynamic arp inspection feature to do it dynamically.

Either way you end up having to know the mac addresses of all your customers. Also to answer your other question, MAC ACL's are per port, ARP ACL's are per vlan.  Inside the ARP ACL you can specify though that this mac address is only allowed to reply for this ip.

A 3rd option would be to use private vlans (would require a hardware upgrade to 3560/3750) and use static arp entries.  But again we are back to having to know ever customers mac address.

Regards,

-Matt

[Jon Marshall]

James

I agree with Matt. If the customer can change the mac-address and/or the IP, and you cannot tie down the customer macs,  then there is little you can do because whatever you do on the switch can simply be bypassed by the customer.

The only way, other than mac-address lists is to use separate vlans per customer which would solve the problem but as you say would waste a lot of addresses which is not acceptable because it is public addressing.

Jon

[cristip]

I hope I am getting this right, wouldn't Private Vlans help here ?

HTH

Cristian

[Jon Marshall]

cristip wrote:
I hope I am getting this right, wouldn't Private Vlans help here ?
HTH
Cristian

Cristian

Not sure how they would help. Private vlans restrict which ports in the same vlan can talk to each other. Each customer port could be made an isolated port but still that doesn't stop them changing the IP address on their device which is the original problem.

As far as i know there is nothing within private vlans that would stop the customer changing their IP.

Was their a particular function of private vlans you were thinking of ?

Jon

[cristip]

Sorry I din not read your second post.

However Private Vlans will save you IPs which seems to be one of the problems.

Private Vlans will for sure isolate the clients from each other which seems to be another problem you have. So you do need that in my opinion

As for the arp part, how about static ARP and disabling ARP for the router interface ...

They say you could use this

http://www.cisco.com/en/US/docs/ios/ipaddr/command/reference/iad_arp.html#wp1011416

arp authorized

To disable dynamic Address Resolution Protocol (ARP) learning on an interface, use the arp authorized command in interface configuration mode. To reenable dynamic ARP learning, use the no form of this command.

arp authorized

no arp authorized

Usage Guidelines

The arp authorized command disables dynamic ARP learning on an interface. This command enhances security in public wireless LANs (PWLANs) by limiting the leasing of IP addresses to mobile users and authorized users. The mapping of IP address to MAC address for an interface can be installed only by the authorized subsystem. Unauthorized clients cannot respond to ARP requests.

If both static and authorized ARP are installing the same ARP entry, the static configuration overrides the authorized ARP entry. To install a static ARP entry use the arp (global) command. A nondynamic ARP entry can only be removed by using the same method by which it was installed.

The arp authorized command can only be specified on Ethernet interfaces and for Dynamic Host Configuration Protocol (DHCP) networks.

Examples

The following example disables dynamic ARP learning on interface Ethernet 0:

interface Ethernet0

 ip address 10.0.0.1 255.255.255.0

 arp authorized

I would also use port security for each customer port. It is going to be paranoid but...


http://www.cisco.com/en/US/customer/docs/switches/lan/catalyst3550/software/release/12.2_25_see/configuration/guide/swtrafc.html#wp1038501

[Matthew Blanshard]

Like I said earlier Private VLANs are an option but they still dont't protect from a customer configuring an IP on their device which is not theirs.  Also 3550's don't suppot private vlans.

-Matt