[f-nsp] Help: Deny VLAN broadcasts

[Mike Lott]

Hi Jonathan

Thanks for the reply and sorry for the late response. The code doesn't
have the command you suggested (not that I could see). I called the
support and the engineer suggested using VLAN tagging which makes
sense so I'll go from there.

Thanks again,

Mike

On 28 January 2010 22:14, Brashear, Jonathan <jbrashear at sbsplanet.com> wrote:
> 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.
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>