Re: [c-nsp] Equivalent of ip multicast boundary on N7k for blocking data packets?
On 03/06/13 21:44, Tim Stevenson wrote: At 01:08 PM 6/3/2013 Monday, Phil Mayers clamored: How can I accomplish the equivalent of the boundary on NX-OS 5.2 for N7k, given it lacks the command? Does one just use a normal ACL, and if so, are there any caveats to doing so e.g. does boundary do *other* things that a plain ACL would miss? In n7k, you must use a combination of control plane data plane filtering to get the equivalent functionality of multicast boundary. For data plane, it's nothing more than ip access-group with matches on multicast traffic. Just to say, this does all work, but it takes a few minutes to kick in - if you add the data-plane ACL then clear ip mroute, the routes just reappear. They die off a few minutes later - presumably something hardware-related. Can't say I'm loving the NX-OS CLI paradigm for this particular feature though - having to merge the unicast and multicast ACEs is a pain, absent any templating/include other ACL functionality :o( ___ 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] Equivalent of ip multicast boundary on N7k for blocking data packets?
On Jun 4, 2013, at 4:54 AM, Phil Mayers wrote: including that you don't need to write both ingress and egress ACLs. Though I suppose the latter are more flexible. Egress ACLs are generally considered to be a Bad Thing, as they allow potentially undesirable packets past the port/linecard ASICs before dropping them on egress. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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] Equivalent of ip multicast boundary on N7k for blocking data packets?
On 05/06/13 12:50, Dobbins, Roland wrote: On Jun 4, 2013, at 4:54 AM, Phil Mayers wrote: including that you don't need to write both ingress and egress ACLs. Though I suppose the latter are more flexible. Egress ACLs are generally considered to be a Bad Thing, as they allow potentially undesirable packets past the port/linecard ASICs before dropping them on egress. Well, as you say, generally. Multicast is of course a slightly different beast to unicast. TBH the egress functionality in multicast boundary (and therefore, an egress ACL on platforms that merge this into normal ACLs) is sort-of redundant - it makes more sense to prevent hosts joining the group, either via IGMP ACLs (at the edge) or PIM J/P ACLs (in the core, but this feature is absent on 6500) so that the platform doesn't ever try to emit the packets, than block them at egress data-plane. As for egress ACLs - for multicast, maybe there are circumstances where you want different data-plane filtering to control-plane, and in different ways on different egress interfaces, in which case an egress ACL works. Or different ingress/egress data-plane filtering, in which case the IOS boundary stuff is too limited. And of course in the general case, if the packets arrive labelled, maybe the ingress ACL doesn't run on that platform, so egress is your only filtering option. ...all of which argue in favour of splitting the boundary function into data-plane ingress/egress ACLs and separate control-plane IGMP/PIM join/leave ACLs. So I appear to have argued with myself and won ;o) ___ 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] Equivalent of ip multicast boundary on N7k for blocking data packets?
At 04:12 AM 6/5/2013 Wednesday, Phil Mayers remarked: On 03/06/13 21:44, Tim Stevenson wrote: At 01:08 PM 6/3/2013 Monday, Phil Mayers clamored: How can I accomplish the equivalent of the boundary on NX-OS 5.2 for N7k, given it lacks the command? Does one just use a normal ACL, and if so, are there any caveats to doing so e.g. does boundary do *other* things that a plain ACL would miss? In n7k, you must use a combination of control plane data plane filtering to get the equivalent functionality of multicast boundary. For data plane, it's nothing more than ip access-group with matches on multicast traffic. Just to say, this does all work, but it takes a few minutes to kick in - if you add the data-plane ACL then clear ip mroute, the routes just reappear. They die off a few minutes later - presumably something hardware-related. This is expected. 'clear ip mroute' on n7k clears the MRIB everything 'below' it (down to the hardware). The MRIB then immediately queries all its clients for multicast state - ie, PIM, IGMP, MSDP, which repopulates the MRIB (and thus the h/w). You can clear the state of each client with commands like clear ip pim route, clear ip igmp route etc. Can't say I'm loving the NX-OS CLI paradigm for this particular feature though - having to merge the unicast and multicast ACEs is a pain, As you can imagine, there was considerable debate about the pros/cons. Main reasons we went this way vs multicast boundary à la c6k: - clear separation of control plane vs data plane filtering - granular per-protocol filtering control - deterministic behavior across reboots (no order-dependent ACL merge) absent any templating/include other ACL functionality :o( You might be able to do some stuff with object groups here? Eg: tstevens-7010-2# sh ip access example IP access list example 10 permit udp any addrgroup multicast-ranges 20 permit ip any 1.1.1.1/32 30 deny ip any any tstevens-7010-2# sh object-group multicast-ranges IPv4 address object-group multicast-ranges 10 239.0.0.0/8 20 225.1.1.0/24 tstevens-7010-2# Note this is just a config 'convenience', TCAM consumption is based on the expansion of the ACEs in your object groups. Hope that helps, Tim 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/
[c-nsp] Equivalent of ip multicast boundary on N7k for blocking data packets?
On our 6500s, we have a standard multicast config inspired by the Cymru secure IOS template: http://www.cymru.com/Documents/secure-ios-template.html ...in our case, looking broadly like this: ip access-list standard MULTICAST-in deny 224.0.1.60 deny 224.77.0.0 0.0.255.255 deny 226.77.0.0 0.0.255.255 permit 239.192.0.0 0.3.255.255 deny 239.0.0.0 0.255.255.255 permit 224.0.0.0 15.255.255.255 int VlanXX description subnet facing some clients ... ip pim sparse-mode ip multicast boundary MULTICAST-in ip igmp access-group MULTICAST-in The two multicast/ACL commands accomplish two different things - the boundary prevents clients sending to that group, the igmp join prevents clients asking to receive from that group. This lets us block some common junk - such as Symantec Ghost (sessions trample on each other) and groups from 239/8 but not 239.192/14 - that in the past have caused masses of multicast routing entries to no real purpose. How can I accomplish the equivalent of the boundary on NX-OS 5.2 for N7k, given it lacks the command? Does one just use a normal ACL, and if so, are there any caveats to doing so e.g. does boundary do *other* things that a plain ACL would miss? It's important to note that the boundary translates into TCAM entries on 6500s i.e. it really does stop traffic forwarding, and this has proven important to us in the past: #sh tcam interface vlxx acl in ip * Global Defaults not shared Entries from Bank 0 permit ip any any Entries from Bank 1 permit ip any 239.192.0.0 0.3.255.255 deny ip any 224.77.0.0 0.0.255.255 deny ip any 226.77.0.0 0.0.255.255 deny ip any host 224.0.1.60 deny ip any 239.0.0.0 0.255.255.255 permit ip any any ___ 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] Equivalent of ip multicast boundary on N7k for blocking data packets?
At 01:08 PM 6/3/2013 Monday, Phil Mayers clamored: How can I accomplish the equivalent of the boundary on NX-OS 5.2 for N7k, given it lacks the command? Does one just use a normal ACL, and if so, are there any caveats to doing so e.g. does boundary do *other* things that a plain ACL would miss? In n7k, you must use a combination of control plane data plane filtering to get the equivalent functionality of multicast boundary. For data plane, it's nothing more than ip access-group with matches on multicast traffic. For control plane, there is independent filtering control for each protocol, ie, PIM, IGMP, MSDP, etc. Hope that helps, Tim 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] Equivalent of ip multicast boundary on N7k for blocking data packets?
On 03/06/2013 21:44, Tim Stevenson wrote: At 01:08 PM 6/3/2013 Monday, Phil Mayers clamored: How can I accomplish the equivalent of the boundary on NX-OS 5.2 for N7k, given it lacks the command? Does one just use a normal ACL, and if so, are there any caveats to doing so e.g. does boundary do *other* things that a plain ACL would miss? In n7k, you must use a combination of control plane data plane filtering to get the equivalent functionality of multicast boundary. For data plane, it's nothing more than ip access-group with matches on multicast traffic. Ok, so just use ACLs. Out of curiosity, what was the rationale for merging the unicast and multicast data-plane filtering? The IOS-style split seems to have some advantages in terms of manageability, including that you don't need to write both ingress and egress ACLs. Though I suppose the latter are more flexible. For control plane, there is independent filtering control for each protocol, ie, PIM, IGMP, MSDP, etc. Indeed. It's somewhat non-obvious to me at this time how the PIM control plane filtering interacts with data- and IGMP-driven PIM events on edge subnets, but I probably need to re-read the docs. Hope that helps, Very much so, thanks. ___ 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/
