yes but I guess the question is why? What is the function of the Native
Vlan that requires it to be not dot1q encapsulated. Does Cisco just opt
for it or is there a logical reasoning behind it... spanning tree seems to
ring a bell but am not sure what about spanning tree requries it to be
dot1q encapsulation.
Nimesh.
On Fri, 28 Dec 2001 Scott.Keoseyan@BroadWing.com wrote:
> Isn't this because the native vlan traffic is not dot1q encapsulated to
> begin with?
>
> try:
>
> http://www.cisco.com/warp/public/473/27.html
>
> Scott
>
>
> -----Original Message-----
> From: Nimesh Vakharia [mailto:nvakhari@clio.rad.sunysb.edu]
> Sent: Thursday, December 27, 2001 9:40 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: Switching Advice
>
>
> While we are on this topic, I was wondernig if anyone has seen the
> following on the old version of the Cisco 65xx IOS where there was a CatOS
> and IOS for management.
>
> for eg:
>
> Lab-6500# (enable) sh trunk 2/5
>
> * - indicates vtp domain mismatch
> Port Mode Encapsulation Status Native vlan
> -------- ----------- ------------- ------------ -----------
> 2/5 nonegotiate dot1q trunking 98
>
> Port Vlans allowed on trunk
> --------
> ---------------------------------------------------------------------
> 2/5 98
>
> Port Vlans allowed and active in management domain
> --------
> ---------------------------------------------------------------------
> 2/5 98
>
> Port Vlans in spanning tree forwarding state and not pruned
> --------
> ---------------------------------------------------------------------
> 2/5 98
>
> If the 'Native vlan' and 'Vlans allowed on trunk' are the same the 802.1q
> encapsulation fails and this config does not work. I remember reading
> about this on Cisco's site but cannot recall the details. Obviously
> Murphy's Law, I cannot find that document.
> Anyone know why, it had something to do with Spanning tree running on
> Native vlan which therefore might require it to be a non trunk on that
> vlan or somethign along those lines.
>
> thanks,
>
> Nimesh.
>
> On Wed, 26 Dec 2001, dan hopkins wrote:
>
> >
> > The SANS document does only apply to 802.1q trunks between 2924XL
> switches.
> > The methodology they used is dependant on the way that 802.1q trunks tag
> > the frames. This can be spoofed in some situations.
> >
> > I am unaware of any tests that test this with ISL Trunking or any tests of
> > VLAN hopping in a single switch.
> >
> > Searching on this topic brought me to a good Doc on switching security:
> > http://www.sans.org/infosecFAQ/switchednet/switch_security.htm
> >
> > on 2001-12-26 09:02 -0500, Brian DeFeyter <bdf@gospelcom.net> wrote:
> >
> > > This sounds like it's only a concern on multiple switch setups using
> > > trunks for VLAN communication? In my example, everything is routed
> > > through one switch... probably bypassing this problem.
> > >
> > > - bdf
> > >
> >
> +++The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and destroy any copies of this
> document.+++
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:27 EDT