From: Geert Nijs (geert.nijs@simac.be)
Date: Mon Mar 13 2006 - 18:33:32 GMT-3
Mark,
I think CDP gets wacked because one side is access port and the other is
ISL trunking.
ISL adds an encapsulation layer around a packet, and i am not sure that
he does this also for the native vlan.
I know DOT1Q trunking does not tag on the native vlan, so the other side
should be able to read the CDP and VTP messages,
but i am not sure about ISL ?
Easy to check: force the trunking mode on the nonegotiate side to DOT1Q
and check if cdp gets through. I guess it will.
Change to ISL trunking and..if it doesn't get through then ISL
encapsulates even on the native vlan.
Geert
-----Oorspronkelijk bericht-----
Van: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Namens Mark
Lasarko
Verzonden: maandag 13 maart 2006 19:24
Aan: ccielab@groupstudy.com; rguyler@shp-dayton.org
Onderwerp: RE: Trunk Modes theory
Yes, I had mentioned I was running 12.2(25)SED in my initial response.
(12.2x on the 3550's in the lab now, right?)
I was simply trying to demonstrate the status:
non-trunking vs. trunking in my post, using Geert's configs.
Nice info for the group to know; different options in different
versions, You could read a lot into that (and I am sure many will)
BTW - Anybody know why CDP would also get whacked here?
(for lack of a better term - it was weird to see, may need to span)
~M
>>> "Guyler, Rik" <rguyler@shp-dayton.org> 03/13/06 12:04 PM >>>
SW1#sh ver
Cisco Internetwork Operating System Software
IOS (tm) C3550 Software (C3550-I5Q3L2-M), Version 12.1(22)EA5, RELEASE
SOFTWARE (fc1)
SW1(config-if)#sw mod ?
access Set trunking mode to ACCESS unconditionally
dot1q-tunnel Set trunking mode to DOT1Q TUNNEL unconditionally
dynamic Set trunking mode to dynamically negotiate access or
trunk
mode
trunk Set trunking mode to TRUNK unconditionally
I don't have the "nonegotiate" option but by the description of setting
it to trunk mode, it appears that no negotiation is taking place since
it will trunk unconditionally. Does this mean no negotiation or is DTP
still being output from the switch? I interpret this to mean that the
trunk is turned on with the configured encapsulation and no DTP is being
sent over the link but I may be wrong. I didn't hook up a sniffer to
test it so if anybody can confirm this one way or the other.
Rik
________________________________
From: Mark Lasarko [mailto:mlasarko@co.ba.md.us]
Sent: Monday, March 13, 2006 11:26 AM
To: ccielab@groupstudy.com; rguyler@shp-dayton.org
Subject: RE: Trunk Modes theory
Greetings Rik,
So what happens when you add the "nonegotiate" line to sw1?
I'd be interested to hear - also what version are you running? Thanx, ~M
>>> "Guyler, Rik" <rguyler@shp-dayton.org> 03/13/06 11:16 AM >>>
Yes, a trunk gets formed. Here is the output from my switches (3550's)
that I just labbed up for you. The config is not identical to yours but
looks like it provides the same functionality:
SW1#sh run int f0/24
Building configuration...
Current configuration : 93 bytes
!
interface FastEthernet0/24
switchport trunk encapsulation isl
switchport mode trunk
end
SW1#sh int trunk
Port Mode Encapsulation Status Native vlan
Fa0/24 on isl trunking 1
Port Vlans allowed on trunk
Fa0/24 1-4094
Port Vlans allowed and active in management domain
Fa0/24 1,888
Port Vlans in spanning tree forwarding state and not pruned
Fa0/24 1,888
SW1#sh run int vlan 888
Building configuration...
Current configuration : 62 bytes
!
interface Vlan888
ip address 10.111.111.111 255.0.0.0
end
SW1#
SW2#sh run int f0/24
Building configuration...
Current configuration : 97 bytes
!
interface FastEthernet0/24
switchport mode dynamic desirable
end
SW2#sh int trunk
Port Mode Encapsulation Status Native vlan
Fa0/24 desirable n-isl trunking 1
Port Vlans allowed on trunk
Fa0/24 1-4094
Port Vlans allowed and active in management domain
Fa0/24 1,888
Port Vlans in spanning tree forwarding state and not pruned
Fa0/24 1,888
SW2#sh run int vlan 888
Building configuration...
Current configuration : 62 bytes
!
interface Vlan888
ip address 10.222.222.222 255.0.0.0
end
SW2#ping 10.111.111.111
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.111.111.111, timeout is 2 seconds:
!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4
ms SW2#sh cdp nei Capability Codes: R - Router, T - Trans Bridge, B -
Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P -
Phone
Device ID Local Intrfce Holdtme Capability Platform Port
ID
SW1 Fas 0/24 121 S I WS-C3550-2Fas
0/24
R11 Fas 0/11 139 R S I Cisco 2801Fas
0/1
R2 Fas 0/2 135 R 2500 Eth
0
R3 Fas 0/3 144 R 2500 Eth
0
R1 Fas 0/1 158 R 2500 Eth
0
SW2#
Rik
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Geert Nijs
Sent: Monday, March 13, 2006 10:21 AM
To: ccielab@groupstudy.com
Subject: Trunk Modes theory
All,
I am studying for my recertification and although i do understand the
different trunking modes, there has been a large discussion between me
and a colleague for the following specific situation:
First Situation
SW1 - Fa0/1
switchport mode trunk
switchport trunk mode isl
switchport trunk nonegotiate
SW2 - Fa0/1
swichport mode desirable
Is an ISL trunk being formed or NOT ?
Trick: nonegotiate makes the port NOT send any DTP packets.
I always thought that "desirable" NEEDED DTP packets from the other side
to form a trunk (so: ON, AUTO or DESIRABLE) So i would say: NO, their is
no trunk.
Several books and docs seem to suggest that in this case, a trunk will
be formed. I am unable to test right now. So what will happen ?
regards,
Geert Nijs
Service Engineer
CCIE #13729 <http://www.cisco.com/en/US/learning/le3/ccie/index.html>
########################################################################
####
#
########
Simac N.V. trades under the commercial name Simac ICT Belgium. This
e-mail and any attached files are confidential and may be legally
privileged. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this
communication is strictly prohibited. If you have received this
transmission in error please notify Simac immediately and then delete
this e-mail.
Simac has taken all reasonable precautions to avoid virusses in this
email. Simac does not accept liability for damage by virusses, for the
correct and complete transmission of the information, nor for any delay
or interruption of the transmission, nor for damages arising from the
use of or reliance on the information.
All e-mail messages addressed to, received or sent by Simac or Simac
employees are deemed to be professional in nature. Accordingly, the
sender or recipient of these messages agrees that they may be read by
other Simac employees than the official recipient or sender in order to
ensure the continuity of work-related activities and allow supervision
thereof.
########################################################################
####
#
########
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:38 GMT-3