You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently we needed to add a virtual router to the MOC-CORE switches for this routed network.
For this ACLs needed to be deployed for only the routable portions of the network. For Dell OS9 switches the way to do this is to make an access control list and apply it to the VRF. The problem is that when applying I get this error:
MOC-CORE-1(conf-vrf)#ip access-group nerc_routes_acl in
% Error: VRF V4 Access-list not supported on this CAM profile.
The issue is that certain CAM blocks need to be allocated for use in VRFs, and that is done with this command:
Unfortunately, this cannot be applied without rebooting the switch. This means we need to wait for a downtime to do this safely. For now, we've gotten around this issue by applying the access control on the interface itself with these rules:
ip access-list extended nerc_routes_acl
seq 40 permit tcp 10.85.0.0/22 host 10.30.9.6 eq 80
seq 45 permit tcp 10.85.0.0/22 host 10.30.9.6 eq 443
seq 50 permit tcp 10.85.0.0/22 host 10.30.9.5 eq 6443
seq 98 permit icmp any any
seq 99 deny ip any 10.30.9.0/24
seq 100 permit ip any any
We needed a blanket allow rule for DHCP packets, which we restrict with the deny rule for NERC networks.
The text was updated successfully, but these errors were encountered:
cc: @naved001
Recently we needed to add a virtual router to the MOC-CORE switches for this routed network.
For this ACLs needed to be deployed for only the routable portions of the network. For Dell OS9 switches the way to do this is to make an access control list and apply it to the VRF. The problem is that when applying I get this error:
The issue is that certain CAM blocks need to be allocated for use in VRFs, and that is done with this command:
Unfortunately, this cannot be applied without rebooting the switch. This means we need to wait for a downtime to do this safely. For now, we've gotten around this issue by applying the access control on the interface itself with these rules:
We needed a blanket allow rule for DHCP packets, which we restrict with the deny rule for NERC networks.
The text was updated successfully, but these errors were encountered: