cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2826
Views
85
Helpful
34
Replies

Vlan Routing Issue

Mokhalil82
Level 4
Level 4

Hi Guys

Please see attached simple diagram. I am in the process of replacing a 6500 switch with a 6800.I need to do this migration in stages so I have connected the new switch to the old via a trunk. Next I want to move some links across but not the svi's, so i moved the port-channel for one of the areas over which had data and voice vlans (Green switch), when connected to the new switch the devices could ping the voice and data svi's that currently sit on the old core but cannot get further than that. I cannot ping other vlans either. 

Is routing required between the old and new core? I was planning to have the new core as a L2 extension to the old during the migration but cannot turn off routing on the 6800.

 

Thanks

 

 

34 Replies 34

Reza Sharifi
Hall of Fame
Hall of Fame

Hi,

Since the new 6800 is only a layer-2 device at this time, all you need is a default route for the management vlan pointing to the SVI on the old 6500.

So, on the 6800:

ip route 0.0.0.0 0.0.0.0 <ip address of the svi>

I am assuming you are using the same vlan for management on both the 6500 and the 6800.

HTH

The 6800 is a layer 3 device, I was trying to turn off routing but there is no "no ip routing" command. So when I add a default route on the new core pointing to the old, I can then ping all IPs from the new core, but not the access devices attached to the switch we migrated over to the new core

Am I right in saying, the old core needs a route back to the networks migrated over to the new core eg ip route 192.16.10.0 255.255.255.0 192.168.30.3

So a default route to the old core from the new,  and a static route to the new core from the old for migrated networks

I won't get to try this till later so making sure it will work

Am I right in saying, the old core needs a route back to the networks migrated over to the new core eg ip route 192.16.10.0 255.255.255.0 192.168.30.3

Not if the networks that you have migrated still have their SVIs on the 6500.

If you moved the SVIs to the 6800 then yes you will.

I haven't used the 6800 but if follows the same logic as the 6500 you cannot turn off ip routing.

But if all the SVIs are still on the 6500 there is no routing from the 6800.

Jon

 

But what I have is, the access layer switches are layer 3 stacks and each stack has an uplink /30 vlan configured. So the uplink is a trunk wiith a /30 vlan running over it. All access stacks have a default route pointing to the uplink SVI on the core. So the core has 3 SVI's for each access stack, the uplink, data and voice. 

Now when I just moved physical connections over to the new core without changing the routing, most devices did not work, I say most as the odd phone still worked.

I managed to ping my gateway IP from a PC on this migrated stack but thats as far as it went. I could ping the core management IP which is why I was thinking is routing required, although I was planning to just migrate the physical links at this stage

I'm not sure I follow.

If you had a /30 and a vlan for routing from the access switch then why are the data and voice SVIs on the 6500 ie. if this was L3 from the access switch the SVIs should be on the access switches.

Can you clarify exactly what you are doing on the access switches ie. what is the point of the vlan for routing using the /30 if the data and voice vlans on the access switches have their SVIs on the 6500 ?

Jon

I totally understand what you say John, I thought the same when I looked at this network, it was setup previously by someone else and they have done exactly that. On the access stack there is only one SVI which is for the /30 uplink. the SVI's for the data and voice are on the core. Then there is one default route on the access stack pointing to the uplink SVI on the core.

This is why I think I may need to add routes here and there for the migration.

Im not sure but there is multicasting configured on the network and wrr queues on every port and qos so not sure if this setup was done because of the multicasting aspect

 

If that's the case then there should be no need for any routes to be added.

The access switch should just use the trunk for the data and voice vlans.

So on the migrated switch the trunk is used from the access switch and the 6800 should just pass through the traffic to the 6500 SVI.

It is basically all L2 until you get to the SVI on the 6500, no L3 involved.

So when you migrate a device to the switch connected to the 6800 it can ping it's own default gateway and nothing else ?

Jon

So when you migrate a device to the switch connected to the 6800 it can ping it's own default gateway and nothing else ?

Yes, so when I migrate a stack over without changing the configs, devices can only ping their own gateway and nothing else. 

So when i was consoled into the new core switch, I was not able to ping the access switches still attached to my old core, but then I just added a default route to point to the old core and suddenly i was able to ping those access switches and ping 8.8.8.8 

Okay, pinging from the switch is different from pinging from an end device.

The access switch is routing (even though it isn't if you see what I mean) so it would need to know how to get to remote networks.

The end devices though are different. For them the access switch should just L2 switch the traffic to the 6500 not L3 switch.

Are the data and voice vlans common between all access switches ie. the same IP subnet or does each access switch use a different IP subnet per vlan ?

When you migrate a switch to the new 6800 it doesn't have any connections to the 6500 ?

Just to clarify. On the access switch there are no SVIs for the clients are there ie. the SVI you talk about pinging is on the 6500 ?

Jon

The data and voice vlans are different on every stack all on different subnets. When I migrate over both connections (forming a port-channel) are migrate with no connections for that stack left on the 6500. The SVI's are still on the 6500 and not the 6800 after the ports are migrated.

I just though of something, not sure if this may be causing the 6800 to route, but the pair of 6800s are configured as a VSS pair using a L3 etherchannel for the VSL links. When I migrate a stack over I have 2 links for each stack as a port-channel, for redundancy I am plugging each link into a separate 6800. Will this mean when traffic hits the 6800 it routes it as the vsl links between the 2 are L3, although its 1 virtual switch

I saw that previous thread where it said the VSL was L3 and I didn't understand it then because the VSL needs to be capable of carrying user traffic if needed but if it is L3 I'm not sure how it does this.

How are the 6800s connected back to the 6500 ie. do you have connections from both 6800s or just one of them ?

Jon

 

By L3 for the vsl i mean on show int status the ports are showing as routed although I havent assigned any IPs to it. I done VSS on a 4500x before which showed as L2.

The 6500 is connected back using 2 links as a all vlan trunk port-channel, one to each 6800 switch, and on separate cards on the 6500

Yes. my understanding was VSL was L2 not L3.

From a client on the migrated access switch can you ping any of the other SVIs on the 6500 ?

Can you do a traceroute from the client to any other SVI IP on the 6500 ?

Is the only SVI you have on the 6800 the management SVI ?

Jon

So going back to the access layer stacks, ip routing is enabled according to sh run, the uplink to the core is a trunk with a /30 ip with svi for this uplink. The access switches then have a default route pointing to the core.

So from a client I could only ping the the gateway svi, not any other svi.

Yes the only SVI on the 6800 is the management svi, I have created mirror svi's of the 6500 and shut them all down so during migration of the svi's I can just do a no shut on them