>From my HTC Amaze 4G on T-Mobile. The first nationwide 4G network
----- Reply message -----
From: cisco-nsp-requ...@puck.nether.net
To: <cisco-nsp@puck.nether.net>
Subject: cisco-nsp Digest, Vol 138, Issue 10
Date: Mon, May 5, 2014 10:00 am
Send cisco-nsp mailing list submissions to
cisco-nsp@puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
cisco-nsp-requ...@puck.nether.net
You can reach the person managing the list at
cisco-nsp-ow...@puck.nether.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-nsp digest..."
Today's Topics:
1. Re: BFD bypassing CoPP on 6500 (Robert Williams)
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 May 2014 15:45:23 +0000
From: Robert Williams <rob...@custodiandc.com>
To: Mack McBride <mack.mcbr...@viawest.com>,
"'cisco-nsp@puck.nether.net'" <cisco-nsp@puck.nether.net>
Subject: Re: [c-nsp] BFD bypassing CoPP on 6500
Message-ID: <9ecd5ab0609b4300a7703fc41a8f2...@cdc-ex2.cdc.local>
Content-Type: text/plain; charset="utf-8"
Hi,
All cards have DFCs installed, there is a 3C on the 6708 and a 3B on the 6748.
Someone else is attempting to replicate my findings now to rule out any 'odd'
behaviour with the test rig I'm using here.
I'll update when more has been found out.
Cheers!
Robert Williams
Custodian Data Centre
Email: rob...@custodiandc.com
http://www.CustodianDC.com
-----Original Message-----
From: Mack McBride [mailto:mack.mcbr...@viawest.com]
Sent: 05 May 2014 16:43
To: Robert Williams; 'cisco-nsp@puck.nether.net'
Subject: RE: BFD bypassing CoPP on 6500
You didn't mention which line card models you were using and if dfcs are
installed.
One disadvantage of CoPP on the sup720 family is that it is dependent on the
incoming line cards to rate limit in hardware. Once it hits the RP it is
handled in software.
So if the traffic is coming in multiple ports, each port will rate limit to the
specified value independently. If you have x ports and your rate limit is y,
you are actually open to x*y traffic. I haven't had a chance to play with the
sup2T family but my understanding is this was fixed in the sup2T.
Mack McBride | Network Architect | ViaWest, Inc.
O: 720.891.2502 | mack.mcbr...@viawest.com | www.viawest.com | LinkedIn |
Twitter | YouTube
-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Robert
Williams
Sent: Sunday, May 04, 2014 10:20 AM
To: 'cisco-nsp@puck.nether.net'
Subject: [c-nsp] BFD bypassing CoPP on 6500
Hi,
I can?t seem to find any relevant documentation on this so I?m hoping someone
may know. I?ve identified that BFD traffic appears to bypass the CoPP in some
respects (platform is 6500/Sup720/15.1SY).
The relevant test config is:
class-map match-any CoPP-bfd
match access-group name V4-CoPP-bfd
ip access-list extended V4-CoPP-bfd
permit udp 10.10.0.0 0.0.255.255 gt 49151 any eq 3784 permit udp 10.10.0.0
0.0.255.255 gt 49151 any eq 3785
<within control-plane policy>
class CoPP-bfd
police 32000 100000 100000 conform-action transmit exceed-action drop
So for example, if you send 50mbit/s of BFD traffic to it, then the output of
?show policy-map control-plane input class CoPP-bfd? correctly shows that there
is 50mbit/s of traffic being matched (in hardware) and that only 32,000bps of
it is being forwarded. All looks fine, however, the CPU grinds to a halt, even
though the exceed-action is set to ?drop? so nothing more than a tiny 32,000
should get through. I?ve confirmed it is indeed all getting through as you can
see it in a CPU span session.
Also, the class-default in the control-plane policy is set to conform-action
drop as well. So how is it even getting through?
Interestingly, if you set the conform-action to drop on class CoPP-bfd then it
still hits 100% CPU. Although strangely if you _do_ set CoPP-bfd to
conform-drop then also the genuine BFD ?real? sessions suddenly stop working.
So the ?drop? feature does have some impact still, somehow?
This is in a lab setup with little else running on the boxes and I?m able to
test anything if anyone has any ideas why this is occurring.
#remote command switch show tcam interface vlan 1013 qos type2 ip
* Global Defaults shared
------------------------------------------------------
QOS Results:
A - Aggregate Policing F - Microflow Policing
M - Mark T - Trust
U - Untrust
------------------------------------------------------
MAU udp 10.10.0.0 0.0.255.255 gt 49151 any eq 3784
MAU udp 10.10.0.0 0.0.255.255 gt 49151 any eq 3785
#remote command switch show tcam interface vlan 1013 qos type2 ip detail
Interface: 1013 label: 3 lookup_type: 2
protocol: IP packet-type: 0
+-+-----+---------------+---------------+---------------+---------------+-------+---+----+-+---+--+---+---+
|T|Index| Dest Ip Addr | Source Ip Addr| DPort | SPort | TCP-F
|Pro|MRFM|X|TOS|TN|COD|F-P|
+-+-----+---------------+---------------+---------------+---------------+-------+---+----+-+---+--+---+---+
V 35925 0
_______________________________________________
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/
