×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Local proxy arp on 3550 EMI

Unanswered Question
Oct 22nd, 2003
User Badges:

It is not very clear to me how "ip local-proxy-arp" works. Anybody care to enlighten me?


I thought that in the following configuration, host A (192.168.1.2) and host B (192.168.1.3) would be allowed to communicate, but in fact are not.

Config is as follows:


interface FastEthernet0/1

description Connected to host A

switchport mode access

switchport protected

no ip address

end


interface FastEthernet0/2

description Connected to host B

switchport mode access

switchport protected

no ip address

end


interface Vlan1

ip address 192.168.1.1 255.255.255.0

no ip redirects

ip local-proxy-arp

ip route-cache same-interface

end


I know "switchport protected" command disallows intercommunication between ports, but I thought "ip local-proxy-arp" would "fix" that...

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
t.baranski Wed, 10/22/2003 - 18:20
User Badges:
  • Bronze, 100 points or more

(This is interesting from a theoretical standpoint, though I don't see the usefulness of doing it on a real network.)


I can see how local-proxy-arp would allow traffic between two ports that are configured to be isolated at layer-2 if the routing module is running a seperate OS than the layer-2 module (e.g., a hybrid setup where the Supervisor is running CatOS but the MSFC is running IOS). Since the layer-3 module doesn't know what the layer-2 module's configuration is, it seems reasonable for it to happily proxy traffic between two isolated ports.


However, in a "native" configuration (such as a 3550) where one OS handles the layer-2 and layer-3 configuration, IOS may not allow local-proxy-arp to override layer-2 port isolation. The switch may even respond to all ARP requests per the local-proxy-arp configuration statement, but then drop any subsequent traffic that is both sourced and destined to isolated ports. This seems like the desirable behavior to me, as I'd hate to see a security feature like port security overriden by an unrelated command in such an unintuitive fashion.


Only Cisco may know the truth. ;-)

Actions

This Discussion