[nsp] CEF problem on 6509 (native)

Sorin CONSTANTINESCU adonay at dumnez.eu.org
Fri Nov 14 16:42:00 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?

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