[c-nsp] cisco-nsp Digest, Vol 138, Issue 10
william.roe.319@gmail.com
william.roe.319 at gmail.com
Mon May 5 18:53:42 EDT 2014
From my HTC Amaze 4G on T-Mobile. The first nationwide 4G network
----- Reply message -----
From: cisco-nsp-request at puck.nether.net
To: <cisco-nsp at 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 at 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-request at puck.nether.net
You can reach the person managing the list at
cisco-nsp-owner at 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 <Robert at CustodianDC.com>
To: Mack McBride <mack.mcbride at viawest.com>,
"'cisco-nsp at puck.nether.net'" <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] BFD bypassing CoPP on 6500
Message-ID: <9ecd5ab0609b4300a7703fc41a8f2bcf at 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: Robert at CustodianDC.com
http://www.CustodianDC.com
-----Original Message-----
From: Mack McBride [mailto:mack.mcbride at viawest.com]
Sent: 05 May 2014 16:43
To: Robert Williams; 'cisco-nsp at 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.mcbride at viawest.com | www.viawest.com | LinkedIn | Twitter | YouTube
-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Robert Williams
Sent: Sunday, May 04, 2014 10:20 AM
To: 'cisco-nsp at 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
More information about the cisco-nsp
mailing list