[c-nsp] Loop/Unreachable problem with C6500/SUP720
Lee Starnes
lee.t.starnes at gmail.com
Tue Aug 14 17:02:09 EDT 2012
I don't know if this helps, but how much ram do you have in this system and
the line cards that these VLANs are on? This type of behavior sounds like
the system is running low on memory. We saw this running on the 6500
running BGP and OSPF. Had to upgrade ram to solve the issue. Of course we
were running full tables, so...
-Lee
On Fri, Aug 10, 2012 at 10:42 AM, Tóth András <diosbejgli at gmail.com> wrote:
> Hi Sebastian,
>
> The CEF entries indeed seem to be correct. Could you do a SPAN capture
> on the 6500 interface towards the server and compare the working and
> non-working scenario? It'd be interesting to see if the packet indeed
> leaves the correct interface at all or not and how the packet headers
> look like.
>
> Additionally, if you see the packet going out, do a packet capture on
> the server to see if it arrives there, what the server is doing with
> it. I'd not be surprised if the server is just routing or bridging the
> packet back somehow. Just an idea though.
>
> If all else is unsuccessful, a TAC case might be helpful to perform
> ELAM captures to see where the packets are destined and sent out, etc.
>
> Best regards,
> Andras
>
> On Thu, Aug 9, 2012 at 11:45 AM, Sebastian Wiesinger
> <cisco-nsp at ml.karotte.org> wrote:
> > * Randy <randy_94108 at yahoo.com> [2012-08-08 21:35]:
> >> ...also curious:
> >>
> >> If there is a discrepancy between "sh ip cef <perfix>" and "sh ip
> >> cef <prefix> internal" for prefixes in question.
> >
> > Here is the working prefix:
> >
> > $ ping 10.1.66.51
> > PING 10.1.66.51 (10.1.66.51) 56(84) bytes of data.
> > 64 bytes from 10.1.66.51: icmp_req=1 ttl=60 time=3.93 ms
> > 64 bytes from 10.1.66.51: icmp_req=2 ttl=60 time=3.97 ms
> > 64 bytes from 10.1.66.51: icmp_req=3 ttl=60 time=3.98 ms
> >
> > And the bad one:
> >
> > $ ping 10.1.66.84
> > PING 10.1.66.84 (10.1.66.84) 56(84) bytes of data.
> > From 10.2.14.9 icmp_seq=1 Time to live exceeded
> > From 10.2.14.9 icmp_seq=2 Time to live exceeded
> > From 10.2.14.9 icmp_seq=3 Time to live exceeded
> >
> >
> > We start with show ip cef:
> >
> > lab-rtr1#show ip cef 10.1.66.51
> > 10.1.66.51/32
> > attached to Vlan412
> >
> > lab-rtr1#show ip cef 10.1.66.84
> > 10.1.66.84/32
> > attached to Vlan412
> >
> >
> > We go on with show ip cef internal:
> >
> > lab-rtr1#show ip cef 10.1.66.51 internal
> > 10.1.66.51/32, epoch 7, flags attached, refcount 5, per-destination
> sharing
> > sources: Adj
> > feature space:
> > NetFlow: Origin AS 0, Peer AS 0, Mask Bits 25
> > subblocks:
> > Adj source: IP adj out of Vlan412, addr 10.1.66.51 5136EEC0
> > Dependent covered prefix type adjfib cover 10.1.66.0/25
> > ifnums:
> > Vlan412(180): 10.1.66.51
> > path 5110F968, path list 5110C090, share 1/1, type adjacency prefix,
> for IPv4
> > attached to Vlan412, adjacency IP adj out of Vlan412, addr 10.1.66.51
> 5136EEC0
> > output chain: IP adj out of Vlan412, addr 10.1.66.51 5136EEC0
> >
> > lab-rtr1#show ip cef 10.1.66.84 internal
> > 10.1.66.84/32, epoch 7, flags attached, refcount 5, per-destination
> sharing
> > sources: Adj
> > feature space:
> > NetFlow: Origin AS 0, Peer AS 0, Mask Bits 25
> > subblocks:
> > Adj source: IP adj out of Vlan412, addr 10.1.66.84 5136A6C0
> > Dependent covered prefix type adjfib cover 10.1.66.0/25
> > ifnums:
> > Vlan412(180): 10.1.66.84
> > path 51110C70, path list 5110D2F8, share 1/1, type adjacency prefix,
> for IPv4
> > attached to Vlan412, adjacency IP adj out of Vlan412, addr 10.1.66.84
> 5136A6C0
> > output chain: IP adj out of Vlan412, addr 10.1.66.84 5136A6C0
> >
> >
> > And show mls cef detail / mls adjacency:
> >
> > lab-rtr1#show mls cef 10.1.66.51 detail
> >
> > Codes: M - mask entry, V - value entry, A - adjacency index, P -
> priority bit
> > D - full don't switch, m - load balancing modnumber, B - BGP
> Bucket sel
> > V0 - Vlan 0,C0 - don't comp bit 0,V1 - Vlan 1,C1 - don't comp bit
> 1
> > RVTEN - RPF Vlan table enable, RVTSEL - RPF Vlan table select
> > Format: IPV4_DA - (8 | xtag vpn pi cr recirc tos prefix)
> > Format: IPV4_SA - (9 | xtag vpn pi cr recirc prefix)
> > M(313 ): E | 1 FFF 0 0 0 0 255.255.255.255
> > V(313 ): 8 | 1 0 0 0 0 0 10.1.66.51 (A:425985 ,P:1,D:0,m:0
> ,B:0 )
> >
> > lab-rtr1#show mls cef adjacency entry 425985
> >
> > Index: 425985 smac: 0003.3245.0000, dmac: 0023.ae67.936e
> > mtu: 1518, vlan: 412, dindex: 0x0, l3rw_vld: 1
> > packets: 0, bytes: 0
> >
> > lab-rtr1#show mls cef 10.1.66.84 detail
> >
> > Codes: M - mask entry, V - value entry, A - adjacency index, P -
> priority bit
> > D - full don't switch, m - load balancing modnumber, B - BGP
> Bucket sel
> > V0 - Vlan 0,C0 - don't comp bit 0,V1 - Vlan 1,C1 - don't comp bit
> 1
> > RVTEN - RPF Vlan table enable, RVTSEL - RPF Vlan table select
> > Format: IPV4_DA - (8 | xtag vpn pi cr recirc tos prefix)
> > Format: IPV4_SA - (9 | xtag vpn pi cr recirc prefix)
> > M(345 ): E | 1 FFF 0 0 0 0 255.255.255.255
> > V(345 ): 8 | 1 0 0 0 0 0 10.1.66.84 (A:442370 ,P:1,D:0,m:0
> ,B:0 )
> >
> > lab-rtr1#show mls cef adjacency entry 442370
> >
> > Index: 442370 smac: 0003.3245.0000, dmac: 0023.ae67.936e
> > mtu: 1518, vlan: 412, dindex: 0x0, l3rw_vld: 1
> > packets: 0, bytes: 0
> >
> >
> > As far as I see, it looks OK. The problem lies somewhere deeper at the
> > hardware level.
> >
> > Regards
> >
> > Sebastian
> >
> > --
> > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
> > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
> SCYTHE.
> > -- Terry Pratchett, The Fifth Elephant
> > _______________________________________________
> > 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/
> _______________________________________________
> 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