proxy-arp is unspeakably evil and will result in much pain.
real-arp can override routing a destination IP address to a
specific IP address on the same interface.
if you have dynamicly changing arp, you need to set arp-timeout
to a non-default (4 hours) value, probably on he order of
minutes.
You should set arp-timeout to <= switch mac address timeout,
especially if you have multiple layers of switches.
You need to watch out for 100% uni-directional traffic on a port
resulting in mac address timeout on the switches, with
fallback to flooding behavior.
Having a monitoring system that pings an IP associated with every
mac address (especially the low / no activity ones) will avoid
(or mask) some switch / arp problems.
There are some specific 6500 pVLAN restrictions noted here, which may
have bearing on the general issues:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/relnotes/78_7190.htm#xtocid195516
George
> From cisco-nsp-request@puck.nether.net Tue Nov 13 19:58:06 2001
> Resent-Date: Tue, 13 Nov 2001 19:57:55 -0500
> Received-Date: Tue, 13 Nov 2001 19:54:37 -0500
> Date: Wed, 14 Nov 2001 03:05:14 +0200
> From: Dmitri Kalintsev <dek@hades.uz>
> To: cisco-nsp@puck.nether.net
> Mail-Followup-To: Dmitri Kalintsev <dek@hades.uz>,
> cisco-nsp@puck.nether.net
> Content-Disposition: inline
> User-Agent: Mutt/1.3.16i
> X-Class: Fast
> Subject: [nsp] 6500/IOS+CatOS [12.1(7a)E1+6.2(2)], HSRP + local-proxy-arp problem
> Resent-From: cisco-nsp@puck.nether.net
> X-Mailing-List: <cisco-nsp@puck.nether.net> archive/latest/8213
> X-Loop: cisco-nsp@puck.nether.net
> List-Post: <mailto:cisco-nsp@puck.nether.net>
> List-Help: <mailto:cisco-nsp-request@puck.nether.net?subject=help>
> List-Subscribe: <mailto:cisco-nsp-request@puck.nether.net?subject=subscribe>
> Precedence: list
> Resent-Sender: cisco-nsp-request@puck.nether.net
>
> Hi good people,
>
> Does anybody have something similar and actually working:
>
> Internet Data Centre, 2x6500s as a gateway to the world, running pVLANs,
> primary VLAN interface is configured for HSRP and local-proxy-arp . We are
> having some major troubles with this configuration (see Subject line for
> software revisions), when customers have intermittent connectivity or no
> connectivity to outside world at all, which seems to get sorted out by
> installing static ARP entries for them on both 6500's. It looks to me that
> some sort of ARP race condition takes place, and proxy-arp'd ARP takes
> precedence over real ARP as sent by customer machines. Did anybody see
> something like this before? We're at complete loss, and our Cisco NSA is
> too. :(
>
> SY,
> --
> CCNP, CCDP (R&S) Dmitri E. Kalintsev
> CDPlayer@irc Network Architect @ connect.com.au
> dek @ connect.com.au phone: +61 3 9674 3913 fax: 9251 3666
> http://-UNAVAIL- UIN:7150410 cell: +61 414 821 382
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:23 EDT