[f-nsp] Help: Deny VLAN broadcasts

[Brashear, Jonathan]

If the SIGT code has it(it's in the RX code), you might look into the 'broadcast rate-limit' command.  It lets you put a limit on the amount of broadcast traffic that goes across each network processor, though you can't confine the rate limiting to a single VLAN afaik.

Jonathan Brashear
Strategic Business Systems, Inc.
13800 Coppermine Road, Suite 400 | Herndon, VA 20171
Corporate: 703.766.8950 | Cell: 214.850.5986 
Please visit our web site at www.sbsplanet.com

-----Original Message-----
From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Mike Lott
Sent: Thursday, January 28, 2010 1:18 AM
To: foundry-nsp
Subject: [f-nsp] Help: Deny VLAN broadcasts

Hi all

I have the following setup consisting of two ServerIronGT (with switch code  09.5.02m) in an active/active configuration in an arm configuration off the core switch in a flat 10.0.0.0/8 network (don't
ask....):


[SI01]====VLAN 1====[CORE]====VLAN 1====[SI02]
  |
             |
  |
             |
  ----------------------------VLAN 200---------------------------


The connections from SI01 and SI02 to the CORE are a trunked link of four and a member of the default VLAN (in this case VLAN 1), and the directly connected active/active high availability link between the ServerIrons in a trunked link of two and a member of VLAN 200.

On both ServerIron configurations I have the following for the active/active link:

SI01:
!
trunk switch ethe 2/5 to 2/6
 config-trunk-ind
!
server active-active-port ethe 2/5 vlan-id 200 !
vlan 200 name ACTIVE-ACTIVE by port
 untagged ethe 2/5 to 2/6
 no spanning-tree
 static-mac-address 0012.f2af.2624 ethernet 2/5 !

SI02:
!
trunk switch ethe 2/5 to 2/6
 config-trunk-ind
!
server active-active-port ethe 2/5 vlan-id 200 !
vlan 200 name ACTIVE-ACTIVE by port
 untagged ethe 2/5 to 2/6
 no spanning-tree
 static-mac-address 0012.f218.d044 ethernet 2/5 !

Now, because the VLANs are present on these switches, the trunks are allowing all VLAN traffic over them, which means that although the keepalives for the active/active link are going across the trunk in VLAN 200, they are also going across the trunk in the default VLAN, meaning that there is a lot of broadcast traffic on the LAN that is originating from the ServerIrons directly related to the keepalives.

Clearly, I want to restrict what traffic goes across the trunks, but I am unclear as to how to do this. Looking at the documentation I am a little unsure of the path to follow. What I have come up with so far are two ways: mac-filter and broadcast filter.


With "mac-filter", I can filter via ethertype (in this case it is 0x885a - classed in a tcpdump as "ethertype Unknown (0x885a)"), but only, it would appear, on incoming packets that are preparing to be switched. That means that the broadcast would have already happened...

A sample of the packet capture is as follows:

06:33:32.705766 00:12:f2:af:26:20 > 00:e0:52:00:00:00, ethertype Unknown (0x885a), length 64:
06:33:33.105679 02:12:f2:af:26:0e > 00:e0:52:00:00:00, ethertype Unknown (0x885a), length 64:
06:33:33.105802 00:12:f2:af:26:20 > 00:e0:52:00:00:00, ethertype Unknown (0x885a), length 322:

I have tried "broadcast filter" but have had no success.

ServerIron(config)# broadcast filter 1 any vlan 200 ServerIron(config-bcast-filter-id-1)# exclude-ports ethernet 2/5 to 2/6

The only other way I can think of stopping this broadcast traffic is to put a filter on inbound traffic to the CORE, but this is not really what I want to do.

Can anyone provide some guidance on this?

Thanks,

Mike
_______________________________________________
foundry-nsp mailing list
foundry-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp



The information contained in this transmission may contain privileged and confidential information. 
It is intended only for the use of the person(s) named above. If you are not the intended  
recipient, you are hereby notified that any review, dissemination, distribution or  
duplication of this communication is strictly prohibited. If you are not the intended recipient, 
please contact the sender by reply email and destroy all copies of the original message. 
To reply to our email administrator directly, please send an email to postmaster at sbsplanet.com.