router on a stick

setup:

2501 - ios 12.3 (connected to switchport config'd as trunk) 2950 - ios 12.1 host 1 = 192.168.10.3 (connected to switchport config'd as vlan10) host 2 = 192.168.20.3 (connected to switchport config'd as vlan20)

switch: sh int trunk (verifies vlans 1, 10, 20 on port to router)

router: int e0 ip add 192.168.1.1 255.255.255.0 exit int e0.1 ip add 192.168.10.10 255.255.255.0 exit int e0.2 ip add 192.168.20.20 255.255.255.0 exit

problem: router can't ping its subint's (e0.1 & e0.2) of course, host 1 can't ping x.x.10.10 & host 2 can't ping x.x.20.20

router: sh ip int (says both subint's are up/up, but ip processing is disabled on both subint's) router can ping e0

what am i doing wrong? thanks!

Reply to
HEY!
Loading thread data ...

please post the actual port configs of both ends of the trunk

Reply to
BernieM

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.

Reply to
Brian V

bernie, not sure exactly what you want...? on switch side, mode is set to trunk, and 2950's only do dot1q.

brian, i was thinking the same thing. seems like a simple setup, but it just doesn't work on 2501.

can anyone else confirm the 2501 doesn't trunk?

i'm going to try it later on a different router. thanks guys!

Reply to
HEY!

I was expecting to see the router port config that assigns the vlan id to the subinterface but as brian's pointed out the 2501 doesn't trunk ... which explains why it's not there.

Reply to
BernieM

I thought you couldnt have an IP address for the e0 if you are using subinterfaces?

Reply to
daytime

after some research, i believe brian is right in 2501 doesn't trunk.

2600 series w/ the proper ios can though. obviously as well as others.

daytime, in this instance, you can assign an ip for e0. in fact, i could give e0, the x.x.10.10 addy and give e0.1 the x.x.20.20 addy and get rid of e0.2.

if you were doing isl, you may not want to give the major int an ip, just the subint's.

thanks all

Reply to
HEY!

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.
Reply to
daytime

Just to add I was using dot1q not ISL if I remember correctly. Would that make a difference ?

Reply to
daytime

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.

Reply to
Wayne

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

Reply to
daytime

vlan trunking, tagging packets with vlan id's and a non-tagged native vlan is supported by the OS of many devices .... routers, switches, servers or even a simple pc.

BernieM

Reply to
BernieM

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...

Interface FastEthernet0/0.20 encapsulation dot1q 20 native

Then on the switch, add another "switchport" command

Interface FastEthernet0/1 switchport trunk native vlan 20

So VLAN 20 is now the native VLAN (also called the "untagged" VLAN by some vendors that are not Cisco) on this switch to router link.

I think that's all right, I'm sure someone will correct me if I'm wrong!

Reply to
Wayne

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

Reply to
daytime

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.

BernieM

Reply to
BernieM

Forgive my ignorance but what is udld? I understand that the vlans must match on both ends-unless you were using a router-in which case the router would route betwixt vlans?

Reply to
daytime

Correct on the router, on the switch it's an extra command, not just an addition to another.

In the example, the configs would look like... (router)

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 native ip address 10.10.20.1 255.255.255.0

(switch) Interface FastEthernet0/1 description Trunk link to Router switchport trunk encapsulation dot1q switchport trunk native vlan 20 switchport mode trunk speed 100 duplex full

Reply to
Wayne

Gotcha-many thanks-does it happen often whereby you would change the default native VLAN to another VLAN? TIA

Reply to
daytime

Just a heads up on the use, or non-use, of a native vlan from a updated Cisco vlan security white paper ...

formatting link
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 [3]) should be the only rightful users of the native VLAN and their traffic should be completely isolated from any data packets.

BernieM

Reply to
BernieM

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."

formatting link

Reply to
BernieM

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.