Ethernet Fabric (VDX, CNA)

Reply
da
Occasional Contributor
da
Posts: 6
Registered: ‎01-07-2013

VDX 6730-32 IP access-lists on NOS 3.0.1

Hello, everyone

I have bumped into a weird scenario where the VDX seems to deny traffic with and IP extended ACL that should work and in fact does work for some hosts on the subnet (but not on a few others).

There are 2 VDX 6730-32 switches (one is turned off during testing so as to not interfere with test results) and they act as L3 core switches in the network - providing VRRP virtual IP for the subnets to use as default gateway. There are about 10 subnets configured on it and access in and out to and from the internet as well as to and from the networks defined in the ACLs seem to work.

The issues I am currently having with the ACLs are with regards to ACL_SERVERS_IN seq 10 stating that traffic with a source from the SERVERS subnet to a destination of the SERVERS subnet is permitted (I found that I needed this when applying the ACL inbound on the Virtual Ethernet (VE) interfaces to allow the subnet to communicate on the same L2 domain). The only issue is that, while most hosts on the SERVERS subnet is working fine and being able to reach both internet resources, resources in other VLANs (like the DMZ) a few hosts are not able to ping some hosts on the same subnet.

Example: host 172.16.12.63 cannot reach 172.16.12.41 but is able to reach internet resources, inter-VLAN resources as well as resources on the same subnet (172.16.12.0/24).

The moment I remove the IP access-group statement on the VE interface (interface ve 512) the issue is resolved, but reapplying the ACL will cause it to happen again.

This is the VDX config (edited for brevity)

ip access-list extended ACL_SERVERS_IN

  seq 10 permit ip 172.16.12.0 0.0.0.255 172.16.12.0 0.0.0.255

  seq 100 permit ip 172.16.12.0 0.0.0.255 172.16.0.0 0.0.0.255

  seq 105 permit ip 172.16.12.0 0.0.0.255 172.16.7.0 0.0.0.255

  seq 110 permit ip 172.16.12.0 0.0.0.255 172.16.9.0 0.0.0.255

  seq 115 permit ip 172.16.12.0 0.0.0.255 172.16.10.0 0.0.0.255

  seq 120 permit ip 172.16.12.0 0.0.0.255 172.16.14.0 0.0.0.255

  seq 125 permit ip 172.16.12.0 0.0.0.255 172.19.12.0 0.0.0.255

  seq 130 permit ip 172.16.12.0 0.0.0.255 192.168.49.0 0.0.0.255

  seq 900 deny ip any 10.0.0.0 0.255.255.255

  seq 901 deny ip any 172.16.0.0 0.15.255.255

  seq 902 deny ip any 192.168.0.0 0.0.255.255

  seq 1000 permit ip any any

!

ip access-list extended ACL_CLIENTS_IN

  seq 10 permit ip 172.16.14.0 0.0.0.255 172.16.14.0 0.0.0.255

  seq 100 permit ip 172.16.14.0 0.0.0.255 172.16.10.0 0.0.0.255

  seq 105 permit ip 172.16.14.0 0.0.0.255 172.16.12.0 0.0.0.255

  seq 110 permit ip 172.16.14.0 0.0.0.255 172.16.9.0 0.0.0.255

  seq 900 deny ip any 10.0.0.0 0.255.255.255

  seq 901 deny ip any 172.16.0.0 0.15.255.255

  seq 902 deny ip any 192.168.0.0 0.0.255.255

  seq 1000 permit ip any any

!

interface Vlan 512

description SERVERS

shutdown

!

interface Vlan 514

description CLIENTS

shutdown

!

!

rbridge-id 1

ip router-id 1.1.2.2

router ospf

  no rfc1583-compatibility

  area 0

  auto-cost reference-bandwidth 10000

  !

  fabric route mcast priority 120

  protocol vrrp

  !

!

interface Ve 514

  ip ospf area 0

  ip ospf cost 1

  ip ospf passive

  ip mtu 1500

  ip proxy-arp

  ip address 172.16.14.2/24

  ip access-group ACL_CLIENTS_IN in

  no shutdown

  vrrp-extended-group 1

   virtual-ip 172.16.14.1

   track tengigabitethernet 1/0/24 priority 20

   enable

   preempt-mode

   priority 120

  !

!

interface Ve 512

  ip ospf area 0

  ip ospf cost 1

  ip ospf passive

  ip mtu 1500

  ip proxy-arp

  ip address 172.16.12.2/24

  no shutdown

  vrrp-extended-group 1

   virtual-ip 172.16.12.1

   track tengigabitethernet 1/0/24 priority 20

   enable

   preempt-mode

   priority 120

Does anyone have an idea as to what the cause may be ? Also, if you need any more information I am able to supply just about whatever is needed (I think).

Thanks,

Derry N. Ambo

Contributor
gerald.krause
Posts: 20
Registered: ‎12-13-2010

Re: VDX 6730-32 IP access-lists on NOS 3.0.1

Hí Derry,

that sounds a little bit strange indeed. The first thing I don't get is why yo need ACL seq 10 because all "intra" VLAN traffic has to be Layer2-switched from the VDX and should never reach his Layer3/IP stage where your L3-ACL's come into effect (except traffic towards the VDX system IP on that interface). But I see you have "ip proxy arp" enabled on both interfaces - I would recommend to disable this feature if you do not have a *really* good reason to turn it on. This feature is often more harmful than anybody can imagine. Proxy ARP is the first thing I disable on all systems/interfaces I get my hands on. It mask/hide errors and faulty configurations on other systems like wrong IP addresses, network masks or routes and has side effects that make you go crazy ;-).

Gerald

da
Occasional Contributor
da
Posts: 6
Registered: ‎01-07-2013

Re: VDX 6730-32 IP access-lists on NOS 3.0.1

Hi, Gerald

Thanks for the heads up on the proxy-arp. I do remember tinkering with the command back in the lab stages of the deployment of the VDX cluster and experienced some issues that made me turn it back on. I just can't remember specifically what the issues were. I will try in the next service window to turn the feature off and see how it goes.

The ACL seq 10 I found necessary after applying the ACLs and seeing that the hosts on the subnet were completely cut-off from their L2 neighbours. I applied ACL seq 10 to the ACLs and everything worked again. I too thought it shouldn't reach the ACL when they are on the same VLAN.

I am seeing some strange stuff going on with ACLs on the VDX and I do suspect it may be because the ACL wasn't made to handle L3 traffic passing through the VDX, but rather L3 traffic passing TO the VDX. In fact, the network documentation for NOS 3.0.1 still states that the ACL is for VDX network management purposes - not traffic filtering between networks.

This is an excerpt from the Network OS Administrator's Guide (page 357)

The IP ACLs control the access to the switch. The policies do not control the egress and outbound management traffic initiated from the switch. The IP ACLs support IPv4 and IPv6 at the simultaneously. 

Join the Community

Get quick and easy access to valuable resource designed to help you manage your Brocade Network.