Re: [c-nsp] Cat 6500 - uRPF - FIB TCAM

[Gert Doering]

Hi,

On Tue, Aug 14, 2012 at 07:50:08PM -0400, Brandon Applegate wrote:
> I know this has been mentioned over the years here and there, but I don't 
> know that I fully understand the exact behavior.  I've always read 'urpf 
> halves your tcam...'.  So this only applies to the interface on which it's 
> configured, correct ?  So for example, in a single switch with the full 
> routing table (using ipv4 for examples, and using simple even numbers 
> not counting any built-in entries):

This only applies to Sup2.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpXDS78bfsD7.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cat 6500 - uRPF - FIB TCAM

[Brandon Applegate]

Thanks to Tim - that was exactly the clarification I was looking for.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
8779 B023 7637 CEC8 C5C6 4052 664D 7E08 3CBB 1739
"SH1-0151.  This is the serial number, of our orbital gun."


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cat 6500 - uRPF - FIB TCAM

[Tim Stevenson]

At 04:50 PM 8/14/2012, Brandon Applegate vociferated:

Hello,

I know this has been mentioned over the years here and there, but I 
don't know that I fully understand the exact behavior.  I've always 
read 'urpf halves your tcam...'.



It applies only to sup2. Sup720 & later don't suffer this limitation.



  So this only applies to the interface on which it's configured, correct ?


No. If you turn on uRPF check on sup2 on any interface, the available 
FIB TCAM for IP prefixes becomes 50% of what it is without uRPF check.



So for example, in a single switch with the full routing table 
(using ipv4 for examples, and using simple even numbers not counting 
any built-in entries):


uplink 1 - 400k routes
uplink 2 - 400k routes

customer interface 1 - 2 routes
customer interface 2 - 2 routes

So this is 400,004 entries.  Adding (strict) urpf to the customer 
interfaces (not the uplinks) would make this 400,008 ?



Well this whole discussion is moot, since you're probably not using 
sup2, especially if you have 400K prefixes.



I guess I'm just unsure of if urpf is added to a single interface 
(even a customer interface with 1 or 2 prefixes) - does this have 
some 'global' effect ?



You're probably confusing the sup2 limit described above, and the 
sup720 limitation that all interfaces w/uRPF check have to be in the 
same mode (strict or loose) and last configured wins.


Tim




Thanks in advance.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
8779 B023 7637 CEC8 C5C6 4052 664D 7E08 3CBB 1739
"SH1-0151.  This is the serial number, of our orbital gun."

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/





Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Distinguished Technical Marketing Engineer, Cisco Nexus 7000
Cisco - 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.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cat 6500 - uRPF - FIB TCAM

[Blake Dunlap]

I strongly think you should read up on how CEF/dCEF work on the 6500, as
you seem to show a basic misunderstanding here.

Short version: There is 1 TCAM table with some caveats about how dCEF works
per card / spa.

-Blake

On Tue, Aug 14, 2012 at 6:50 PM, Brandon Applegate  wrote:

> Hello,
>
> I know this has been mentioned over the years here and there, but I don't
> know that I fully understand the exact behavior.  I've always read 'urpf
> halves your tcam...'.  So this only applies to the interface on which it's
> configured, correct ?  So for example, in a single switch with the full
> routing table (using ipv4 for examples, and using simple even numbers not
> counting any built-in entries):
>
> uplink 1 - 400k routes
> uplink 2 - 400k routes
>
> customer interface 1 - 2 routes
> customer interface 2 - 2 routes
>
> So this is 400,004 entries.  Adding (strict) urpf to the customer
> interfaces (not the uplinks) would make this 400,008 ?
>
> I guess I'm just unsure of if urpf is added to a single interface (even a
> customer interface with 1 or 2 prefixes) - does this have some 'global'
> effect ?
>
> Thanks in advance.
>
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 8779 B023 7637 CEC8 C5C6 4052 664D 7E08 3CBB 1739
> "SH1-0151.  This is the serial number, of our orbital gun."
>
> __**_
> cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Cat 6500 - uRPF - FIB TCAM

[Brandon Applegate]

Hello,

I know this has been mentioned over the years here and there, but I don't 
know that I fully understand the exact behavior.  I've always read 'urpf 
halves your tcam...'.  So this only applies to the interface on which it's 
configured, correct ?  So for example, in a single switch with the full 
routing table (using ipv4 for examples, and using simple even numbers 
not counting any built-in entries):


uplink 1 - 400k routes
uplink 2 - 400k routes

customer interface 1 - 2 routes
customer interface 2 - 2 routes

So this is 400,004 entries.  Adding (strict) urpf to the customer 
interfaces (not the uplinks) would make this 400,008 ?


I guess I'm just unsure of if urpf is added to a single interface (even a 
customer interface with 1 or 2 prefixes) - does this have some 'global' 
effect ?


Thanks in advance.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
8779 B023 7637 CEC8 C5C6 4052 664D 7E08 3CBB 1739
"SH1-0151.  This is the serial number, of our orbital gun."

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Loop/Unreachable problem with C6500/SUP720

[Lee Starnes]

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  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
>  wrote:
> > * Randy  [2012-08-08 21:35]:
> >> ...also curious:
> >>
> >> If there is a discrepancy between "sh ip cef " and "sh ip
> >> cef  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 00 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., 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 00 0 0 

Re: [c-nsp] (no subject)

[Engelhard M. Labiro]

What line cards are inserted ? Do you have enough power ?

On Tue, Aug 14, 2012 at 5:35 PM, Harry Hambi  wrote:

> Hi All,
> I have the following global command, diagnostic level complete. Is this
> command doing some sort of Diag on the line cards?. Also the output of
> the sh mod command is as follows:
>
>
> Mod Online Diag Status
> --- ---
>   1 Bypass
>   2 Bypass
>   3 Bypass
>   4 Bypass
>   5 Bypass
>   6 Bypass
>   7 Bypass
>   8 Bypass
>   9 Pass
>  10 Bypass
>  11 Bypass
>
> Why am I getting Bypass on a majority of line cards?, and only pass on
> mod 9?.Any info appreciated.
>
> Rgds
> Harry
>
> Harry Hambi BEng(Hons)  MIET  Rsgb
>
>
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ___
> cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] (no subject)

[Harry Hambi]

Hi All,
I have the following global command, diagnostic level complete. Is this
command doing some sort of Diag on the line cards?. Also the output of
the sh mod command is as follows:


Mod Online Diag Status
--- ---
  1 Bypass
  2 Bypass
  3 Bypass
  4 Bypass
  5 Bypass
  6 Bypass
  7 Bypass
  8 Bypass
  9 Pass
 10 Bypass
 11 Bypass

Why am I getting Bypass on a majority of line cards?, and only pass on
mod 9?.Any info appreciated.

Rgds
Harry

Harry Hambi BEng(Hons)  MIET  Rsgb


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/