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: [email protected] 
[mailto:[email protected]] 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
[email protected]
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 
[email protected].
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp

Reply via email to