cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1369
Views
0
Helpful
6
Replies

NX-OS: Deny SNMP, NTP and BGP access to SVI itself

laurent.dewilde
Level 1
Level 1

We're trying to block all SNMP, NTP and BGP access to a particular SVI. However, when using the ACL config below, only traffic through the SVI is blocked, not the traffic directly destined towards it.

So SVI VLAN901 is still responding on BGP, NTP and SNMP requests.

 

Any ideas how to deny traffic destined to an SVI itself?

 

Platform used: N9K-C93180YC-FX3

 

interface Vlan901
ip access-group filter_vlan901 in
ip access-group filter_vlan901 out

ip access-list filter_vlan901
10 deny tcp any any eq bgp
11 deny udp any any eq ntp
12 deny tcp any any eq 161
99 permit ip any any

 

Thanks a lot,

 

Laurent

1 Accepted Solution

Accepted Solutions

It seems that with this ACL you are blocking the Data plane but you want to block the control plane. I think you should use CoPP policy.

Take a look on this document and see if make sense for you.

 

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/security/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide_chapter_010001.html#con_... 

View solution in original post

6 Replies 6

It seems that with this ACL you are blocking the Data plane but you want to block the control plane. I think you should use CoPP policy.

Take a look on this document and see if make sense for you.

 

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/security/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide_chapter_010001.html#con_... 

We've implemented the CoPP policy by cloning the strict policy and adding a class map with ACLs on top of this custom CoPP policy.

It seems to indeed block the traffic arriving on the SVI specified in the ACL.

 

IP access list acl_block_bgp
10 permit tcp any gt 1024 10.200.200.2/32 eq bgp
11 permit tcp any eq bgp 10.200.200.2/32 gt 1024
20 permit tcp 10.200.200.2/32 gt 1024 any eq bgp
21 permit tcp 10.200.200.2/32 eq bgp any gt 1024

 

service-policy input copp-policy-strict-custom_copp

class-map custom-copp-class-block (match-any)
match access-group name acl_block_bgp
match access-group name acl_block_snmp

 

Thanks a lot for your help!!

 

Regards,

laurent.dewilde
Level 1
Level 1

Thanks Flavio,

 

But it appears that the minimum pps is '1' and not '0', which means that packets will still be allowed by CoPP. 

With a N7K, this is apparently possible. 

Any other way on how to block packets completely towards the CPU with a N9K?

 

Thanks a lot!

Richard Burts
Hall of Fame
Hall of Fame

I think the suggestion to use control plane is an interesting one. And given the complexity of a successful implementation using ACL perhaps is the better approach.

The suggested implementation is based on a misunderstanding of how ACL works. When you apply the ACL"in" it will process traffic from devices connected in the subnet of that interface. This would work only if the SNMP, NTP, BGP requests originate from devices in the local subnet (which seems not likely to be the case). So this ACL is not doing much good. When you apply the ACL"out" it will process traffic going from the interface to devices connected in the subnet of that interface. So that ACL is not doing any good.

It is likely that the SNMP, NTP, BGP are arriving on other interfaces of this device. If you want to prevent access to the SVI then every other interface should have entries preventing the specified protocol to the specified address (and then permitting other traffic).

HTH

Rick

laurent.dewilde
Level 1
Level 1

Thanks for your replies, guys. I'll go ahead with the CoPP option and let you know the results...