[c-nsp] L3 Policy-Map hits switched traffic

Tim Stevenson tstevens at cisco.com
Thu Sep 7 16:45:37 EDT 2006


Bernhard,

You are right that if the DMAC is not that of R2's vlan interface, 
the traffic should not be hitting the PBR at all, so something weird 
is going on somewhere; are you saying that R4 is the gateway for 
User1, or are User1 & User2 L2 adjacent (same vlan)? Your comment 
that the packet is sent w/DMAC of R4 suggests R4 is L3-switching to 
User2. Any chance R4 is for some reason sending the traffic back to 
R2 with DMAC=R2 SVI MAC?

A TAC case might be the most expedient route to resolution... Thanks,
Tim

At 01:08 PM 9/7/2006 -0700, Bruce Pinsky announced:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Bernhard Schmidt wrote:
> > Hi,
> >
> > we have an interesting issue here with four Sup720A
> >
> >
> > User1 --  R1 --------- R2 --------- R3 -------- R4 -- User2
> >        (18)SXD7    (18)SXD7     (33)SRA      (18)SXD7
> >                        |
> >                        |
> >             outside
> >
> > All links between those routers are 10GE (WS-X6704-10GE) 802.1q trunks,
> > all routers do OSPF in one common backbone VLAN. When User1 tries to
> > reach User2 we can see on a NAM installed in R1 that the packet is sent
> > on the backbone VLAN with the correct destination MAC of R4. However,
> > the traffic is processed by
> >
> > interface Vlan998
> >  ip policy route-map BLA
> >
> > on R2 which sets the next-hop for this packet to outside.
> >
> > Is this a (known) bug or a feature? Since R2 only switches this traffic
> > it should not hit the route-map on the SVI, or am I wrong here?
> >
>
>I'm not an expert on the 6500 switching path, but I suppose that adding PBR
>  to that VLAN might end up causing the hardware to be punted to the MSFC
>for forwarding to insure that the packet doesn't need to be forwarded
>according to something other than destination address.  Tim Stevenson or
>Ian Cox could probably comment a bit more on this as well as these references:
>
>
>http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/cef.htm
>http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/layer3.htm#wp1033565
>
>- --
>=========
>bep
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.4 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFFAHxNE1XcgMgrtyYRAlYaAKCnFAPBp6r+X4YQ01KOFdfyHmn+7wCg+hPD
>a7VFXNkQ0yFKTtdIV4uGCHc=
>=ZbZ9
>-----END PGP SIGNATURE-----
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/



Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Catalyst 6500
Cisco Systems, http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.


More information about the cisco-nsp mailing list