Re: Lacp, dot1q, SPT, native vlan and Management Vlan concepts

From: <robclav_at_gmail.com>
Date: Thu, 5 Nov 2009 08:46:32 +0000

Hi guys,

First of all thank you for your help,
As clear I have the concepts more chances to pass the TS part. Also:)
Well I did't post every test I did, so I realice that the problem seems originated at trunk negotiation(dtp) and SPT.
What I'm going to test is to disable trunk negotiation, but enabled. And also disable spt at the trunk, if without spt it works, then I will configure flex links in order to avoid bpdu's.

I'll be back will the results.
Cheers,
Robclav

BlackBerry de movistar, allm donde estis esta tu oficin@

-----Original Message-----
From: Nathan Richie <nathanr_at_boice.net>
Date: Wed, 4 Nov 2009 19:16:21
To: 'CCIE Groupstudy'<ccielab_at_groupstudy.com>
Subject: RE: Lacp, dot1q, SPT, native vlan and Management Vlan concepts
  for troubleshooting.

Cristian,

Thanks for the corrections. I appreciate you pointing out the VLAN 1 minimization. I did not mean to imply that tagging the native VLAN made an 802.1q trunk compatible with ISL, in fact I was trying to do just the opposite and state that no matter the configuration the 2 trunking protocols are incompatible. As far as best practices, I have always found them to be subjective :)

Thanks for your help!

Regards,

Nathan Richie

-----Original Message-----
From: Cristian Matei [mailto:cristian.matei_at_datanets.ro]
Sent: Wednesday, November 04, 2009 3:50 PM
To: Nathan Richie; 'CCIE Groupstudy'
Subject: RE: Lacp, dot1q, SPT, native vlan and Management Vlan concepts for troubleshooting.

Hi Nathan,

Some comments here......

        VLAN1 can be removed from trunk ports from the DATA/aka user traffic
(not control-plane like CDP,VTP,PAgP) perspective; it's called VLAN1
minimization; along with it 802.1Q IEEE BPDUs will NOT be sent as well. Also
it is NOT best practices to use VLAN1 for remote switch management, just as
it's not recommended to use VLAN1 for any data traffic (leave it for
control-plane).
        ISL is not compatible with 802.1Q regardless of the native VLAN
tagging or not configuration.

As for the problem, maybe a NORTEL guy can help it out; on the Cisco side
trunk should be manually configured and DTP turned off (Nortel doesn't run
DTP); Etherchannel should be configured with "on" mode or LACP; now for the
traffic functionality part........the native VLAN concept on Nortel side
should be checked.

Regards,
Cristian.

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Nathan Richie
Sent: Wednesday, November 04, 2009 10:11 PM
To: CCIE Groupstudy
Subject: RE: Lacp, dot1q, SPT, native vlan and Management Vlan concepts for
troubleshooting.

Rob,

Few corrections that I see:

The native VLAN really has nothing to do with management VLAN nor with
carrying the layer 2 protocols. Other than VLAN 1 is used to carry these
protocols and unless you specify differently, VLAN 1 is the native VLAN.
With 802.1q each frame is marked with the VLAN-id with the exception of the
native VLAN. The way I think about this is that the switches agree to send
VLAN-id's on each frame but if they send packets without the VLAN-id, the
other switch is to assume it is for the native VLAN. This will allow
communication if a non-802.1q device is connected to the port.
Theoretically you can choose any VLAN you want for your management network,
but it is best practice to use VLAN 1 as it cannot be pruned nor blocked on
any trunk ports, where other VLANs can.

If you use the "vlan dot1q native tag" global command, you are just telling
the switch to send the VLAN-id with packets assigned to the native VLAN.
However, this does not make the port compatible with an ISL trunk port. ISL
encapsulates the layer 2 frame with a new header which includes the VLAN-id.
I am not sure about the 2960 support or lack of support for not tagging the
native VLAN.

There is no requirement for the layer 2 switch management interface to be a
part of the native VLAN. The only requirement of a layer 2 switch
management interface is that you can only have 1 enabled at a time. So if
you create interface VLAN 100 and assign an IP address to it, interface VLAN
1 must be shutdown.

In terms of your issue, let's break it completely down. First, what are the
2 devices you are trying to connect and how many links exist between them?
Put the etherchannel aside for now and shutdown any redundant ports, leaving
only 1 interconnection. Now configure the trunk encapsulation to dot1q and
set the mode to trunk. Verify hat this is trunking port by running the
"show int trunk" command.

Post the results and then we will work on the next step.

Hope this helps.

Regards,

Nathan

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Rob
Clav
Sent: Wednesday, November 04, 2009 5:16 AM
To: CCIE Groupstudy
Subject: Lacp, dot1q, SPT, native vlan and Management Vlan concepts for
troubleshooting.

Hi folks,

I was pretty sure about this concepts in the past, but after check them
configuring a C2960 with a nortel switch I have several doubts.

Can you say if i'm wrong with any statement?

LACP.- standard dynamic protocol used to negociate links aggregation. In
order to activate it, you need to add a command, to the interfaces joinning
to a virtual interface(layer 2 or not) called port-channel. You can activate
lacp to be the expected(active), to lisen for a lacp negotiation from the
other site or to say the channel-group is on without negociation. At
port-channel virtual interface you need to configure the same that you
configure at physical int.

DOT1Q and native vlan.- standard dynamic protocol in order to allow more
than one vlan crossing the link. One of these vlans is called native because
is the one used to carry the control protocols like cdp,spt(one instance)
and so one. This one is send it untagged by default. The rest of the vlans
are send tagged. You can tag native vlan in some devices like 3750 but at
2960 you couldnt with the command "vlan dot1q native tag". The kind of
encapsulation should be choosed in some models supporting isl. Then you can
say if the trunk will be desirable, will expect the action of the other site
of the link, if will be on or the negotiation will be deactivated.

Management VLAN.- Is used at layer 2 devices to configure an IP Address in
order to manage the switch. This one could be the native vlan or not. By
default at layer 2 devices, this one must be the native as well.

SPT.- Well-known anti layer 2 loop protocol. There are several kinds like
CST, PVST, PVST+(cisco) ,RST, MST, RPVST+(cisco). The first one support only
one instance for whole spt domain, and the rest support a instance and then
a root for each vlan.

As compatible SPT I use, CST, or mst. I read at some forums that 802.1q
doesn't support PVST+ except if you use only Cisco switches.

Summary,

I have a Cisco 2960 trying to establish an etherchannel with a 801.q trunk
configuration. But it doesn't works. Obviously, I tried to break the problem
in some smaller ones. Well the main problem is that I need to change the
management vlan to other(Vlan 63) because the subnetting. And then I tried
to make the management(Vlan 63) as a native also. I tried too, using one
vlan(63) for management and other one(Vlan 1) as a native. But no positive
results.

The picture of the config is that I have vlan 63 as management and I assume
vlan 1 is the native, because you couldnt remove it.

1.-I tried to check connectivity between one link without trunk or
etherchannel config, basically acting as an access port. It works

2.-I tried to configure a trunk between them, and didn't work. In fact, I
tried several configuration, negotiating the trunk and forcing it, but
nothing.

3.-LACP seems to work fine, without 802.1q.

Well at the end of this email I realize that I have a problem with the
trunk+native vlan and SPT, but I don't know why. It's a lab environment so
I'm sure there's no third cable between them to loop it. Any idea?

Thanks in advance,

Robclav

Blogs and organic groups at http://www.ccie.net
Received on Thu Nov 05 2009 - 08:46:32 ART

This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:28 ART