cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1910
Views
5
Helpful
9
Replies

Only native Vlan traffic is making it over trunk

Geis77
Level 1
Level 1

First, I inherited this network. As a part of the network I have two c9200 switches, setup with trunk connections between them. Everything appears to work however I can not access the switches over the mgmt vlan (vlan 25). I can get to the switch ips on vlan 1. Everything looks good, I figure its something simple I'm missing. I included edited configs, ip route, and pings. Ideas?

9 Replies 9

andrewswanson
Level 7
Level 7

Is your management vlan 25 in the switch's vlan database's? You can check with "show vlan". If not, add it to both switches.

hth

Andy

Yep, all vlans have been added to both switches.

 

Hello,

 

How is the network set up? Is one suppossed to send network traffic through the other? Do you have a more in-depth diagram? 2 things I notice:

1. Both are EIGRP stubs (not sure if this comes into play yet)

2. You have a static route on Delmas pointing to the 25.2 network but it can't reach it...so it doesn't know where it's at. Have you tried using an exit interface instead.

If you can provide a bit more context that would help.

 

-David

I'll get a diagram together. In the meantime Delmas --Trunk--> MainCore2 --Trunk--> MainCore1 ----> Internet. MainCore 2 can connect to other switches via vlan 25 with no issue. Both MainCore2 and Delmas have egrip setup with the same network settings MainCore1 has the following setup:

router eigrp 1
network 10.0.0.0
network 172.17.0.0
network 192.168.5.0
network 192.168.90.0
eigrp stub connected summary redistributed

To make it clear all 3 devices have EIGRP stub configured? Was this always like that? Has VLAN 25 ever worked for reachability? It seems counterintuitive as a stub network is usually a dead end and not used as a transit link. I would only configure stub on the last device (DELMAS). That stub on all 3 devices is 100% affecting your routing and your path out. a Stub in EIGRP by default (connected/summary) will only advertise that...connected and summary routes. So it wont learn other EIGRP learned routes further down the path. You need more route manipulation if you want to keep those settings.

If this is a live network DO NOT MAKE THE CHANGES as it will bring adjacencies down and reconfigure routing. 

 

Hope that helps

 

-David

To my knowledge it has always been setup this way. I'll plan on removing the "eigrp stub connected summary" line from MainCore2, tonight,  should I also remove "eigrp stub connected summary redistributed" from MainCore1?

Thank you for you time!

Without knowing the whole of your topology or routing I cannot make a sound decision on that unfortunately. If MainCore1 connects to something else that relies on certain configurations it could break routing. Also just removing the stub from the middle device and not MainCore1 will probably not work. Like I said, the stub EIGRP command prevents some routes from downstream neighbors from being learned and therefore being able to access.

 

If there is no other device connecting upstream to MainCore1 (as far as EIGRP neighbors) I would remove the EIGRP stub command from all devices to form a normal adjacency first allowing correct routing to see if it works without any restrictons. Then playing around with the STUB feature only if you're familiar with it. I would first inquire to anyone you can about the configurations before making any changes though as I assume there is a reason those configurations are there (hopefully). If not then make the changes during a maintenance window and if noting comes back up....reboot to revert changes.

Hope that helps.

-David

Thank you! I'll let you know how it goes. Attached is a simple diagram. Looking at it I agree it's EGRIP that's the culprit.

I tried to change the ip route on the Delmas switch to "ip route 0.0.0.0 0.0.0.0 G1/0/24" but got the message I must specify a L3 port as the next hop. I'm concerned I'd loose connectivity if I changed it to "ip route 0.0.0.0 0.0.0.0 vlan25", not exactly local.