[c-nsp] Multiple flow-masks
Robert Williams
Robert at CustodianDC.com
Sun Dec 9 13:03:30 EST 2012
Hi Andras,
Yes that has indeed applied without error, however as you point out it does not meet with the requirements I have from the customer. In short, the customer needs a limit which is applied per IP (of his clients) to restrict inbound traffic in the direction Internet->Client. This is because downstream of us the client has several links which are only 1GB serving large numbers of his clients. I know there are several ways this could be resolved (not least of which a switch upgrade within the client's network) however they are not currently options so we are trying to come up with something for them which we can deploy ahead of their connection with us.
My understanding of the full-flow mask is that it will limit flow, only, so two transfers to the same IP will count as 2 x the limit. Which in this scenario makes it inappropriate unfortunately.
So, it looks like we will have to deploy it for IPv4 for them only; and skip IPv6, which is a shame because the client is a growing IPv6 user so I can see the problem surfacing again soon.
Interestingly, can anyone confirm that the Sup-2T can do what we are trying to do without this IPv6 oddness?
Once again, my thanks to you!
From: Tóth András [mailto:diosbejgli at gmail.com]
Sent: 09 December 2012 17:16
To: Robert Williams
Cc: cisco-nsp NSP
Subject: Re: [c-nsp] Multiple flow-masks
Hi Robert,
Thanks for the clarification. What I meant is that QoS microflow policy which needs to have full-flow mask, otherwise you might likely have a conflict with NDE. I understand that it's a requirement for you to have destination based policing.
In addition to that, if the NDE flowmask is interface-full-flow, it will not work with QoS microflow policing.
Try configuring the following:
mls flow ip interface-destination-source
mls flow ipv6 full
policy-map test-policy
class class-default
police flow mask full-flow 200000000 512000 conform-action transmit exceed-action drop
This should work but this will use full-flow mask for the QoS.
Best regards,
Andras
On Sun, Dec 9, 2012 at 4:36 PM, Robert Williams <Robert at custodiandc.com<mailto:Robert at custodiandc.com>> wrote:
Hi Andras,
Many thanks for that - sorry the outputs were misleading but I have already tried all 6 variants of the mls flow ipv6 <...> command, including "mls flow ipv6 full" - they all produce the same results, culminating in the %FM-2-FLOWMASK_CONFLICT error.
I have removed all other policies off the device to rule them out, so a clean test / demonstration of the issue is as follows:
mls commands currently set:
mls ipv6 acl compress address unicast
mls netflow interface <- (there is no non-interface version of this command)
mls nde sender
mls qos
mls flow ip interface-destination-source <- (there is no version of this command which doesn't include the 'interface' keyword for ipv4)
mls flow ipv6 full
flow commands currently set:
ip flow-export source xx
ip flow-export version 9
ip flow-export destination x.x.x.x xxxx
ip flow-top-talkers
With all the above in place, I do get the Full Flow mask as you say:
IPv6: 0 reserved none
IPv6: 1 Full Flo FM_IPV6_GUARDIAN
IPv6: 2 Null
IPv6: 3 reserved none
Plus there is a space in slot 2 - however, when I try to apply my policy:
policy-map test-policy
class class-default
police flow mask dest-only 200000000 512000 conform-action transmit exceed-action drop
interface xx
service-policy input test-policy
I still get: %FM-2-FLOWMASK_CONFLICT: Features configured on interface xx have conflicting flowmask requirements, traffic may be switched in software
My policy has to be destination based so I cannot change that, but apart from that I think I'm trying what you are describing, but my apologies if I'm still missing the point!
Cheers!
From: Tóth András [mailto:diosbejgli at gmail.com]
Sent: 09 December 2012 14:47
To: Robert Williams
Cc: cisco-nsp NSP
Subject: Re: [c-nsp] Multiple flow-masks
The outputs you pasted suggests that you're using "interface-full" flowmask. The workaround is to use "full" flowmask instead of "interface-full" as mentioned in my last email. IPv6 entries consume more TCAM space than IPv4, so comparing them should take this fact into account.
Best regards,
Andras
On Sun, Dec 9, 2012 at 2:52 PM, Robert Williams <Robert at custodiandc.com<mailto:Robert at custodiandc.com>> wrote:
Hi,
Thanks very much for that, I'll have to run through everything in that document because the tests I'm doing suggest that it 'should' work, for example:
With both my policy and the mls ipv6 flow interface-full disabled I see one entry, which is presumably because 'mls qos' is enabled:
IPv6: 1 Intf Ful FM_IPV6_QOS
IPv6: 2 Null
Then if I enable only "mls ipv6 flow interface-full", the FM_IPV6_GUARDIAN 'feature' appears:
IPv6: 1 Intf Ful FM_IPV6_GUARDIAN FM_IPV6_QOS
IPv6: 2 Null
As you can see there is still a gap for the policy to take the second flow mask and use whatever type of mask it wants.
As a test - if I disable the ipv6 flow and just enable my policy by itself, it goes in the second slot correctly - and uses the Destination Only mask:
IPv6: 1 Intf Ful FM_IPV6_QOS
IPv6: 2 Dest onl FM_IPV6_QOS
So, I was assuming that a combination of these two features would be acceptable to it, since they operate in different mask slots when enabled separately anyway I didn't see why they should collide.
I am correct as far as its operation in IPv4 goes because for v4 there is no conflict warning (and the policy works in hardware perfectly!). However, in IPv6 that does not appear to be the case.
Looks like yet another unhappy IPv6 feature on the Sup-720, unless anyone can see a way around it that I'm missing?
As an aside, does anybody know why it is called FM_IPV6_GUARDIAN instead of FM_IPV6_QOS (like in v4)? I'm wondering if this difference is the reason for its inability to combine the two masks successfully...
Cheers!
From: Tóth András [mailto:diosbejgli at gmail.com]
Sent: 08 December 2012 21:09
To: Robert Williams
Cc: cisco-nsp NSP
Subject: Re: [c-nsp] Multiple flow-masks
Hi Robert,
A few things to keep in mind.
With Release 12.2(33)SXI4 and later releases, when appropriate for the configuration of the policer, microflow policers use the interface-full flow mask, which can reduce flowmask conflicts. Releases earlier than Release 12.2(33)SXI4 use the full flow mask.
The flowmask requirements of QoS, NetFlow, and NetFlow data export (NDE) might conflict, especially if you configure microflow policing.
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html
To add to this, note the following restrictions/recommendations well:
The micro-flow policing full flow mask is compatible with NDE's flow masks that are shorter than or equal to full flow (except for destination source interface).
With any micro-flow policing partial mask an error message is displayed and either the micro-flow policer or NDE might get disabled.
Best regards,
Andras
On Sat, Dec 8, 2012 at 3:50 PM, Robert Williams <Robert at custodiandc.com<mailto:Robert at custodiandc.com>> wrote:
Hi,
Unfortunately we use Netflow for an automated system we have (it doesn't need to accurately record everything, just the highest number of flows / packets etc). So I cannot just remove it, however I have made some progress.
I've tracked it down to the problem actually being with the IPv6 netflow / masks. With all netflow removed I am able to add my policy-map in and it works. Then by adding netflow commands back in I can get everything back except the command:
mls flow ipv6 <any command>
So even if I specify:
mls flow ipv6 destination
I still get:
%FM-2-FLOWMASK_CONFLICT: Features configured on interface <name> have conflicting flowmask requirements, traffic may be switched in software
At this point in time, with my policy attached and working I'm showing:
Flowmasks: Mask# Type Features
IPv4: 0 reserved none
IPv4: 1 Intf Ful FM_QOS Intf NDE L3 Feature
IPv4: 2 Dest onl FM_QOS <--- My policy (V4)
IPv4: 3 reserved none
IPv6: 0 reserved none
IPv6: 1 Intf Ful FM_IPV6_QOS
IPv6: 2 Dest onl FM_IPV6_QOS <--- My policy (V6)
IPv6: 3 reserved none
The command "mls flow ipv6 <anything>" just plain refuses to go active in the config, so if I re-send it I get the error shown above every time.
The flowmasks are correctly showing "Intf Full" and "Dest only" in slots 1 and 2 respectively. So, why does my netflow request not attach alongside either one of them when it's looking for the same mask as is already active in those slots?
The policy itself is working correctly at this point, but I cannot enable IPv6 netflow.
Can anyone help?
Robert Williams
Backline / Operations Team
Custodian DataCentre
tel: +44 (0)1622 230382<tel:%2B44%20%280%291622%20230382>
email: Robert at CustodianDC.com<mailto:Robert at CustodianDC.com>
http://www.custodiandc.com/disclaimer.txt
Robert Williams
Backline / Operations Team
Custodian DataCentre
tel: +44 (0)1622 230382<tel:%2B44%20%280%291622%20230382>
email: Robert at CustodianDC.com<mailto:Robert at CustodianDC.com>
http://www.custodiandc.com/disclaimer.txt
Robert Williams
Backline / Operations Team
Custodian DataCentre
tel: +44 (0)1622 230382<tel:%2B44%20%280%291622%20230382>
email: Robert at CustodianDC.com<mailto:Robert at CustodianDC.com>
http://www.custodiandc.com/disclaimer.txt
Robert Williams
Backline / Operations Team
[cid:imageb9d65d.jpg at acf57610.0c8a4454]<http://www.CustodianDC.com/>
Tel:
+44 (0)1622 230 382
Email:
Robert at CustodianDC.com<mailto:support at CustodianDC.com>
Web:
www.CustodianDC.com<http://www.CustodianDC.com/>
Status:
status.CustDC.net<http://status.custdc.net/>
[cid:image9e7fb8.png at d5057fdf.12c14486]
ISO:27001 IS:567248
Click to view our email disclaimer<http://www.custodiandc.com/disclaimer.txt>
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20121209/2b2278ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageb9d65d.jpg at acf57610.0c8a4454
Type: image/jpeg
Size: 14679 bytes
Desc: imageb9d65d.jpg at acf57610.0c8a4454
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20121209/2b2278ff/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image9e7fb8.png at d5057fdf.12c14486
Type: image/png
Size: 10780 bytes
Desc: image9e7fb8.png at d5057fdf.12c14486
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20121209/2b2278ff/attachment-0001.png>
More information about the cisco-nsp
mailing list