[nsp] CEF problem on 6509 (native)

Siva Valliappan svalliap at cisco.com
Fri Nov 14 16:59:57 EST 2003


>
> Hi,
>
> The .25 address is not directly connected, it is routed after the CUDA
> CMTS (connected in router1). As i said before, CUDA is connected in a
> FastEthernet in router1 set in routing mode, not switching.
>
> 00a0.d2a4.5003 is the MAC address of my client's NIC.
>
> Router1 and Router2 are connected via a GigabitEthernet in trunk mode.
>
> There is no layer2 connection between my client's cable modem and Router2
> unless we have a customer who has 2 local loop connections, one in the
> CUDA CMTS, and one in a fiber vlan (Router2 is the router for 2 customer
> vlans).
>
> Do you think Router2 sees ARP requests from 00a0.d2a4.5003 and, having
> proxy-arp on my vlans on Router2 causes the problem i'm trying to fix?
> Shouldn't the router learn arps only for directly connected ips?
>

so the behavior you are describing is tickling an old memory on how CEF
behaves under certain conditions.  i believe the router is receiving a
grat. arp, which is causing it to override the route with some more
specific.  yes one is a route, while the other is a ARP (and not a route),
but i have worked on a couple of situations where this occurred.  i think
it's arguable if it's a bug or a feature.

so what happens is you have a

/24 route to next hop

we build a CEF entry for the /24 traffic corresponding to the next hop
adjacency.

we then see a grat. arp for a /32 which gets populated into the CEF table.

now when we have to do a packet forwarding decision we try to make the
most precise match, so the /32 in your forwarding table is more precise
then the /24, so we use the /32.

you should open a TAC case to verify this, but this is what i believe is
happening.

cheers
.siva



> Thanks!
> --
> Sorin CONSTANTINESCU
> adonay at dumnez.eu.org
> Linux Registered User #222086
>
> Siva Valliappan said:
> > Hi Sorin,
> >
> >    are you doing proxy arp by any chance?  are you receiving a gratuitous
> > arp for the .25 address from the device with the mac address
> > 00a0.d2a4.5003?  what device has the mac address 00a0.d2a4.5003?
> >
> > cheers
> > .siva
> >
> >
> >
> > On Thu, 13 Nov 2003, Sorin CONSTANTINESCU wrote:
> >
> >>
> >> Hi again,
> >>
> >> Now, the CUDA CMTS is connected to our network via a routed port, not a
> >> switched one and the problem still exists.
> >>
> >> Client -- cable modem -- cuda -- R1 -- R2
> >>
> >> Still, R2 sees in it's mls cef table an entry pointing to my client's
> >> MAC
> >> address:
> >>
> >> r2#show ip route x.y.z.25
> >> Routing entry for x.y.z.0/24
> >>   Known via "bgp 8708", distance 200, metric 0, type internal
> >>   Last update from a.b.c.d 5d06h ago
> >>   Routing Descriptor Blocks:
> >>   * a.b.c.d, from a.b.c.d, 5d06h ago
> >>       Route metric is 0, traffic share count is 1
> >>       AS Hops 0
> >>
> >> r2#sh ip cef a.b.c.25
> >> x.y.z.0/24, version 5658497, epoch 0, cached adjacency a.b.c.d
> >> 170330 packets, 10848340 bytes
> >>   via a.b.c.d,  dependencies, recursive
> >>     next hop a.b.c.d, Vlan2 via a.b.c.d/32
> >>     valid cached adjacency
> >> r2#show mls cef x.y.z.25 255.255.255.255
> >>
> >> Index      Prefix           Mask                Adjacency
> >> 2752       x.y.z.25      255.255.255.255     00a0.d2a4.5003
> >> r2#sh clock
> >> 18:25:57.411 EETDST Thu Nov 13 2003
> >> r2#
> >>
> >> a.b.c.d is the IP address of r1 (the router Cuda is connected in).r1 and
> >> r2
> > are directly connected via Vlan2, as seen in the show ip cef.
> >>
> >> Regards,
> >> --
> >> Sorin CONSTANTINESCU
> >> adonay at dumnez.eu.org
> >> Linux Registered User #222086
> >>
> >> Sorin CONSTANTINESCU said:
> >> >
> >> > No, the address is the same for 2 months, at least.
> >> >
> >> > --
> >> > Sorin CONSTANTINESCU
> >> > adonay at dumnez.eu.org
> >> > Linux Registered User #222086
> >> >
> >> > Jack.W.Parks at alltel.com said:
> >> >> Did you happen to readdress the link with a new IP address?  For
> >> >> example:  The link toward the CMTS was 1.1.1.1/30, but recently you
> >> >> changed it to 2.2.2.1/30.
> >> >>
> >> >> We have had many problems related to this type of change and CEF.
> >> The
> >> >> ONLY fix was to reload the router after any destination next-hop
> >> change.
> >> >>
> >> >> Jack
> >> >>
> >> >> Jack W. Parks IV
> >> >> Sr. Network Engineer
> >> >> ALLTEL Communications
> >> >> jack.w.parks at remove-me.alltel.com
> >> >> Work: 501-905-5961
> >> >> Cell: 501-680-3341
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: cisco-nsp-bounces at puck.nether.net
> >> >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Sorin
> >> >> CONSTANTINESCU
> >> >> Sent: Wednesday, November 12, 2003 1:42 PM
> >> >> To: cisco-nsp at puck.nether.net
> >> >> Subject: Re: [nsp] CEF problem on 6509 (native)
> >> >>
> >> >>
> >> >>
> >> >> Hi,
> >> >>
> >> >> I found out what the problem is (with some help from the list), but i
> >> >> don't know how i can get rid of it.
> >> >>
> >> >> The router has a mls cef entry for x.y.z.25 different from
> >> x.y.z.0/24,
> >> >> when in the routing table i have only entry, for x.y.z.0/24:
> >> >>
> >> >> r2#show mls cef x.y.z.0 255.255.255.0
> >> >>
> >> >> Index      Prefix           Mask                Adjacency
> >> >> 13429      x.y.z.0       255.255.255.0       00d0.0568.980a
> >> >> r2#show mls cef x.y.z.25 255.255.255.255
> >> >>
> >> >> Index
> >> >   Prefix           Mask                Adjacency
> >> >> 2240       x.y.z.25      255.255.255.255     00a0.d2a4.5003
> >> >> r2#
> >> >>
> >> >> This client is connected via a cable-modem. The CMTS is Cuda (router,
> >> >> not bridge).
> >> >>
> >> >> I don't get it from where does th
> >> >> is router learn that mls cef entry. The
> >> >> layer3 path is
> >> >>
> >> >> r2 --> r1 --> CUDA CMTS --> client
> >> >>
> >> >> I've even monitored CUDA's traffic for 00a0.d2a4.5003 or x.y.z.25 to
> >> see
> >> >> what packets come/go when the mls cef entry is renewed, but i haven't
> >> >> seen any.
> >> >>
> >> >> r2 does not have any interface in the vlan in which the CUDA CMTS is
> >> >> connected.
> >> >>
> >> >> I really don't know what to do next. If there's anything i forgot to
> >> >> add, please drop pe an email.
> >> >>
> >> >> Thanks!
> >> >> --
> >> >> Sorin CONSTANTINESCU
> >> >> adonay at dumnez.eu.org
> >> >> Linux Registered User #222086
> >> >>
> >> >>> On 11/11/03 2:35 AM, "Sorin CONSTANTINESCU" <adonay at dumnez.eu.org>
> >> >>> wrote:
> >> >>>
> >> >>>> Hi,
> >> >>>>
> >> >>>> One of our Cat6500 routers' CEF is acting strangely. The router
> >> >>>> wouldn't forward traffic towards x.y.z.25, but it would for
> >> x.y.z.26.
> >> >>
> >> >>>> CEF has an entry for x.y.z/24 (known by the router from BGP).
> >> >>>>
> >> >>>> If i put an ACL on a VLAN (in) with permit for x.y.z.25, traffic
> >> >>>> coming via that vlan will be routed, but only the traffic coming
> >> via
> >> >>>> that vlan.
> >> >>>>
> >> >>>> The temporary solution was to have a route for x.y.z.25.
> >> >>>>
> >> >>>> The 6509 has msfc2/sup2, and runs Version 12.1(19)E (native). I
> >> >>>> looked for CEF bugs using cisco's bugtool, but none match
> >> >>>  my case.
> >> >>>>
> >> >>>> Does anybody have a clue on how to solve this problem?
> >> >>>>
> >> >>>> Regards,
> >> >>>
> >>
> >> _______________________________________________
> >> 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/
> >>
>


More information about the cisco-nsp mailing list