A 2501 doesn't trunk, all you did was create sub-interfaces which are useless on a 2500. 99.9% of the time you need a router that has a 100m interface to do trunking. There were a few versions of code floating around for the 2610 which allowed you to trunk.
Thats interesting-I have completed labs involving trunking between a
1700 router and two 2900 switches and studied Frame Relay,in both cases I was told never to assign the physical interface with an IP. Could you go into more depth about this please? Many thanks-great question btw.
Giving the physical interface an address is not the best idea. It *MIGHT* take the place of the native VLAN of the link. I haven't tried this, nor do I really want to, but that's the best explanation I can come up with.
That is interesting to-I would like to know how a router interface can become a Native VLAN interface-in my limited understanding I thought that VLANs were only specific to Switches?I have my CCNA final coming up so all thoughts welcome. Happy Easter to every1-religion devoid
Every VLAN trunk link, be it switch to switch, switch to router, router to router, switch to wireless access point, whatever, has a native VLAN. The Native VLAN is the only VLAN on the link that will not have a VLAN tagged applied to the Layer 2 header. Any Layer 2 frame received on a trunk link that does not have a VLAN tag is assumed to belong to the native VLAN.
Typically on the router side you will see something like (assuming farily recent code on a router and switch) (also note, this is off the top of my head, my appologies if I miss a command or fudge a line!)...
Interface FastEthernet0/0 description Trunk link to Core Switch no ip address duplex full speed 100 ! Interface FastEthernet0/0.10 description Server VLAN encapsulation dot1q 10 ip address 10.10.10.1 255.255.255.0 ! Interface FastEthernet0/0.20 description Client VLAN encapsulation dot1q 20 ip address 10.10.20.1 255.255.255.0
Then on the switch side...
Interface FastEthernet0/1 description Trunk link to Router switchport trunk encapsulation dot1q switchport mode trunk speed 100 duplex full
In this scenario, the native VLAN has not been configured, so it defaults to VLAN 1.
To change the native VLAN on a router port, add "native" to the encapsulation command...
MAny thanks for that-in my limted knowledge I was told that VLANs were only on switches-the native part was very informative-makes a lot of sense. Am I correct in thinking that you can change the Native Vlan(as you did in your example) just by putting the ...native... command after the encap on the router and before the vlan on the switch? TIA
You need to be aware of what's using the native vlan when making changes like that because you can get yourself in trouble .... for example if you've got udld configured and change the native vlan at one end if you don't change the other end before the next udld poll one end will 'err-disable' and you've got yourself disconnected.
Just a heads up on the use, or non-use, of a native vlan from a updated Cisco vlan security white paper ...
Read the section on "Double-Encapsulated 802.1Q/Nested VLAN Attack" ...
the IEEE committee that defined 802.1Q decided that because of backward compatibility it was desirable to support the so-called native VLAN, that is to say, a VLAN that is not associated explicitly to any tag on an 802.1Q link. This VLAN is implicitly used for all the untagged traffic received on an 802.1Q capable port.
This capability is desirable because it allows 802.1Q capable ports to talk to old 802.3 ports directly by sending and receiving untagged traffic. However, in all other cases, it may be very detrimental because packets associated with the native VLAN lose their tags, for example, their identity enforcement, as well as their Class of Service (802.1p bits) when transmitted over an 802.1Q link.
For these sole reasons-loss of means of identification and loss of classification-the use of the native VLAN should be avoided. ..... Protocols like STP, DTP, and UDLD (check out ) should be the only rightful users of the native VLAN and their traffic should be completely isolated from any data packets.
unidirectional link detection ... " The UDLD protocol allows devices that are connected through fiber-optic or copper (for example, Category 5 cabling) Ethernet cables to monitor the physical configuration of the cables and detect when a unidirectional link exists. When a unidirectional link is detected, UDLD shuts down the affected port and alerts the user. Unidirectional links can cause a variety of problems, including spanning tree topology loops."