From: Gustavo Novais (gustavo.novais@novabase.pt)
Date: Fri May 25 2007 - 18:57:41 ART
My recomendation will be that in fact the networks admin have that extra
trouble of manually configuring allowed Vlans, because, at least, when
he has problems, he can see something specific regarding which vlans are
allowed or not.
Although some of the allowed vlans may still not be present on the vlan
DB.
Does anybody know if there are alternatives to VTP client/server mode
approach in progress, besides GVRP, that don't suffer from the "oooops,
I think I plugged the lab switch on the network..." syndrome?
Because VTP transparent can really be a burden...
Gustavo Novais
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Ryan Morris
Sent: quinta-feira, 24 de Maio de 2007 19:47
To: Cisco certification
Subject: RE: Question about 802.1q trunking - Do not have any switch
near to test...
Hi Gustavo,
The trunks will permit all vlans by default. The alternative to VTP
pruning is to manually specify which vlans are allowed on the trunk
using
the interface command:
switchport trunk allowed vlan <VLANs>
If you allow only the VLANs in common this will prevent the extra
overhead
of broadcast traffic from the unnecessary vlans, but requires additional
manual labour when creating vlans compared to VTP with pruning.
Regards,
Ryan
On Thu, 24 May 2007, Gustavo Novais wrote:
> I agree with you, the problem is that I cannot change or activate
> pruning, as it is not my network.
>
> My doubt is just that I cannot find any specific info confirming that
> behaviour, as it results of not-so-good design in my opinion, but that
> happens to work.
>
> Thanks
>
> Gustavo Novais
>
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Mohammad Saeed
> Sent: quinta-feira, 24 de Maio de 2007 18:16
> To: Cisco certification
> Subject: Re: Question about 802.1q trunking - Do not have any switch
> near to test...
>
> In my opinion, as no Pruning is in place, all VLANS will be allowed on
> trunk link and flooded traffic from all VLANS will pass through the
> trunk even if the respective VLAN does not exist on the other switch.
> So, if that VLAN does not exist on the other switch traffic will
> dropped. This is where Pruning comes, if you want to let the traffic
> pass on the trunk only for the VLANS that exist on the other end,
> enable VTP pruning on both switches.
>
> By default 802.1Q trunk tag all VLANS traffic except the Native VLAN,
> so as per this rule, if traffic is flooded in VLAN 10, suppose, when
> it will cross the Dot1Q trunk it shall be tagged with the respective
> VLAN ID, VLAN 10, so that receiving switch shall be able to contain
> the traffic in the VLAN 10.
>
> Hope this helps.
>
> Regards,
>
> Mohammad Zahed Saeed
>
> On 5/24/07, Gustavo Novais <gustavo.novais@novabase.pt> wrote:
> > Hello,
> >
> >
> >
> > Lately I faced a doubt while on a customer audit, that although does
> not
> > affect performance, has left me thinking...
> >
> >
> >
> > You have two switches (lets say 3550 and 2950) in VTP mode
> transparent,
> > interconnected through a dot1q trunk, without any vlan filtering on
> the
> > trunk ports, but both switches have different vlan databases. Some
> vlans
> > in common, some not.
> >
> >
> >
> > What will happen to the flooded traffic on those trunk ports on the
> > not-in-common (nic) vlans?
> >
> >
> >
> > Sh interface trunk tells me that not-in-common vlans are STP
> forwarding
> > and are obviously allowed on the trunk.
> >
> >
> >
> > Will the flooded traffic for one of those vlans cross the patch
cable
> > (tagged), and be dropped by the other switch, who doesn't know that
> vlan
> > ID?
> >
> > Or will it simply not be forwarded over that particular link?
> >
> > Or will it be flooded through the trunks native vlan (on the
receiving
> > switch)?
> >
> >
> >
> > Any ideas/comments/links pointing to info are helpful.
> >
> >
> >
> > Thanks
> >
> >
> >
> > Gustavo Novais
> >
> > #15622
> >
> >
>
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:22 ART