Routed vs SVI, ACL vs VACL in vmware environment

[bill.morton]

I need to allow for good traffic into my vmware environment but block bad broadcast and multicast traffic from getting in. Currently I have an SVI setup to allow for the communication but it seems to allow broadcast and multicast traffic to get to my individual VLAN interfaces despite ACL entries on the inbound SVI interfaces.

Would I be better off making a routed port uplink to the rest of the network, or should I use VACLs to block all but desirable IP traffic?

Basically I have all of the vmware networks for console, management, kernel, vmotion etc. on their own vlan and subnet with ACLs to permit only the necessary traffic into the VLAN. I have to at some point link back to the production LAN network which I don't have control over, which has a ton of broad/multicast traffic that I dont want getting into the VMware networks. Currently I just have an L2 uplink port with an SVI in the native VLAN to allow communication.

So basically I am asking for the best way to block broadcast and multicast traffic from getting into my VLANs that is coming from the production network.

What I am a bit confused by is that my ACL on the production network shows literally millions of blocks, but then the ACLs on the internally defined VLANs are also showing drops of the broadcast traffic that I though should have been all dropped by the first ACL.

[Jon Marshall]

Bill

Unless you have "ip directed broadcast" on your vlan interfaces then any broadcast/multicast traffic will be generated within those vlans and not coming from the production network. Routers and that includes L3 switches do not forward broadcasts with the proviso about directed broadcasts above.

So if you are seeing a lot of broacast/multicast traffic within your vlans the traffic should have been generated in these vlans.

Jon

[bill.morton]

Jon,

I agree that this was exactly what I was expected but not what I was seeing.

Well I must fall on my sword now because I found the problem ... and it was my fault for not double checking the default behavior / configuration of the switch.

I put a sniffer on one of the VLANs in question and started tracking down some ARP that should not have been getting in from the production side ... and I found:

#sh mac-address-table vlan 2

Vlan Mac Address Type Ports

---- ----------- -------- -----

...

2 0002.8ae6.dfaf DYNAMIC Gi1/0/24

Oh crap ... 1/0/24 is supposed to be an uplink port and not a member of the VLAN ... I bet it became a trunk ...

#sh int trunk

Port Mode Encapsulation Status Native vlan

Gi1/0/24 auto n-802.1q trunking 1

Probably forgot to specify access port in the config:

#sh run int gi1/0/24

!

interface GigabitEthernet1/0/24

description Link to Production Network

spanning-tree bpdufilter enable

end

------------

AGH! The core switch that I uplink to got upgraded a few weeks ago and someone must have enabled it to allow dynamic trunks and my uplink turned into an trunk and was allowing junk from the production VLANs into my VMware VLANs via the trunk.

:facepalm:

[Jon Marshall · Accepted solution]

Bill

No problem, these things happen. Glad you got to the bottom of it :-)

Jon

[jgreenwoodii]

Two features come to mind to solve your problem but I don't know your platforms or setup.

1st option from a layer 2 perspective you could use storm control for broadcast/multicast and limit them to the lowest possible level.

2nd option would be use protected ports ie "switchport protected" along with blocking for multicast ie "switchport block multicast" to not allow broadcast or unknown multicast between your VM environment and your the rest of your Network Infrastructure.

These options are dependant on your platform and or direction of traffic.

HTH

Jonathan