If they allow vlan 50 into your trunk port,  then THAT traffic will hit your 
switch but will get dumped by your switch if you do NOT allow vlan 50;  and I 
believe the vlan 50 packets are counted as DISCARDED frames on that port.   So 
the pipe is more congested with vlan 50 traffic. (That is packets that are 
non-unicast and unknown-unicast).

Jeff Fitzwater
Princeton University


On Sep 21, 2011, at 11:48 , null zeroroute wrote:

> I have an 8021q trunk link that permits 3 out of 20 VLAN's.  The trunk port
> permits VLAN ID's 2,3,4, and uses native VLAN 25.  The VLAN ID's in the
> local VTP domain are 5-25.  There are no other VLAN's in the switched domain
> at the location in question.  There are no other switchports in VLAN 25.
> 
> The trunk port is connected to a WAN service provider layer2 device, which
> is connected to a VPLS service.
> 
> If the service provider sends a frame onto the trunk port tagged with VLAN
> ID 50, will my trunk port accept the frame and forward it "somewhere" or
> will it drop the frame?
> 
> Note that VLAN 50 does not exist at the location in question, there are no
> ports in that VLAN.
> 
> So the question I have is... How does the "switchport trunk allowed vlan"
> command affect forwarding from an inbound perspective?
> 
> If "switchport trunk allowed vlan" doesn't prevent a VLAN tagged frame from
> being accepted into a network, is there any way to prevent a VLAN tagged
> frame from entering your network that shouldn't be?
> 
> The reason I ask is because I have a situation where the trunkport is
> accepting the frame that I assume it shouldn't, forwarding into my network,
> and a loop ensues.  That loop is a differnet issue all together I think.  My
> main question is about the behavior of "switchport trunk allowed vlan" as it
> relates to inbound and outbound forwarding.  I have no idea why VLAN's
> tagged with VLAN 50 are entering my network and getting forwarded around.  I
> know those frames are entering my network at this location because I see the
> 8021q header in wireshark.
> 
> Thanks,
> 
> --NZR
> _______________________________________________
> cisco-nsp mailing list  [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to