cisco design question

[afsharki2]

Let's say I have the following:

routed refers to routed interface

we want to ping between computer1 and computer2

Current design:

(computer1)----Sw1----routed----Sw2---routed---Sw3---routed----Sw4-----(computer2)

Future design:

(computer1)---Sw1----routed-----Sw2-----trunk----Sw3-----routed-----Sw4-----(computer2)

As you can see, a trunk is now attempting to be implemented between Sw2 and Sw3.  What configuration changes need to be done to make this happen? so the packets can get from comp1 to comp2.  Do we have to create a new vlan definition (svi), so that it knows to route it up to the next inerface?

I have a feeling I'm missing something really important.  Please let me know if this is not clear enough. 

[afsharki2]

I would be super confused if I saw that picture haha.  That trunk is already there, and it's not bypassing anything, it's just how the design of the network is.  I didn't have any room on the paper, so I looped it around everything else. But DS2 does have a port-channel trunk the service switch.  It's used to push all the internet-only vlans for guests that way.   those guest vlans are all defined on the firewall.

[Jon Marshall]

Okay so that is not the trunk you want to create ?

If not between which switches do you want the trunk in your diagram ?

Jon

[afsharki2]

correct.  It's not that I want to design a trunk interface or add one.    The only change that will be happening is removing the 4 routed interfaces between the core1/2 to primary and secondary voice gateways, and replacing those with the dashed lines from the services switch (VSS pair) to the primary and secondary voice gateways.  The dashed lines represent what will happen, and it's not currently there as of now.....but everything else is currently there.

What I want to do is figure out what configuration changes need to happen on DS2 (or any other switch you might think) since the 'current path' with arrows in the diagram is using routed links all the way, and the future path with the other arrows which will have to take that red trunk link on the diagram to the service switch instead of going to the core switches.  I'm confused about the fact that I think the traffic won't make it up there because that trunk configuration needs some additional configuration changes.  

That vlan 50 is defined on r1 and r2 and is HSRP'd between them for their gateway which is DS2.  

[Jon Marshall]

Right, thanks for that, it makes a lot more sense now.

So just so I understand fully, the voice gateways, do these peer with the core switches and advertise routes or are the routes for the voice gateways being advertised by the core switches themselves to DS2 ?

And the existing trunk, there is no L3 peering between DS2 and the service switch ie. it is simply a trunk that passes the guest vlans traffic to their default gateways which are defined on the firewall ?

Jon

[afsharki2]

When you say peering, are you talking about ospf peering and advertising routes?

correct, the cores and the voice gateways share routes to eachother.  

the voice gateways only know of 2 ways into our network and that is through to core 1 and core 2.  When you say do these peer with the core switches and advertise routes or are the routes for the voice gateways being advertised by the core switches themselves to DS2 ?  I'm not exactly sure what you mean.

[Jon Marshall]

Yes I mean OSPF peering and sharing routes.

So are you going to in effect move the L3 interfaces on the core switches that peer with the voice gateways to the VSS pair ie. the service switch and this is why you are asking how to route traffic over the trunk between DS2 and the service switch ?

Apologies for continually coming back with more questions but I want to fully understand this so I don't give you bad advice.

Jon

[afsharki2]

exactly!  The L3 interfaces will exactly unplug from the core1/2 side and hook into the services VSS pair.

Just like you mentioned, all I am worried about is that there is a trunk link in our new path...what configuration change needs to happen to make sure our traffic can direct itself from vlan 50, to past the voice gateways?

No worries, detail orientation can't be comprised in this job field.  I have learned that the hard way.

[Jon Marshall]

Okay, so It comes back to what I was saying earlier ie. you now need to setup an OSPF peering between DS2 and the service switch so that your routing works. To do this you need a vlan that is common to both switches. So using a new vlan and a /30 subnet you simply create the vlan on both switches, create the SVIs on both switches and then add to your OSPF configuration.

This should then mean that DS2 now sees routes to the voice gateways via the service switch and the service switch has routes to the subnets behind DS2.

The guest vlans that just use the trunk should not be affected and any traffic to the voice gateways is routed across the new vlan you have created.

I can't think of anything else at the moment but if something occurs to me I'll add it in.

Jon 

[afsharki2]

Jon, I just realized I left something HUGE out.  There is a routed interface between the services switch and the cores.  It seems that if we didn't make that configuration change that you just mentioned, the packets would take that extra hop and go up DS2 --> Cr1/2 --> service switch  

instead of ds2-->service switch

what do you recommend here?

[afsharki2]

Thank you, Jon!  So essentially, if we didn't create this new SVI on both the switches, we wouldn't be able to traverse that trunk link, correct?  So why do I keep thinking about the packets taking the native vlan?

[Jon Marshall · Accepted solution]

I'll try and answer both questions but you have removed the diagram so I'll have to do the first question from memory :)

If the service switch connects at L3 to the core switches then, assuming you setup the routing between DS2  and the service switch as discussed,  DS2 would receive routes for the voice gateways from both the core switches and the service switch.

Assuming the interconnects from DS2 are the same speed to the cores as to the service switch then DS2 should favour the routes received direct from the service switch which is what you want. In fact you could then use the cores as a backup in case the trunk failed if that is what you wanted.

If the interconnects are different speeds then the above may not apply.

If you do not create this new vlan for peering the traffic will not traverse the link because the traffic is not arriving at DS2 as L2 traffic unlike the guest vlan traffic which is. The traffic from vlan 50 is L3 traffic when it arrives at DS2.

It might help to think of it from DS2's perspective. A packet arrives from vlan 50 via the routed link. DS2 does what any L3 device does and does a route lookup on the destination IP but you don't have those routes if you don't peer with the service switch (assuming you are not still receiving those routes from the core switches).

So DS2 cannot forward the packets. The native vlan does not come into it here.

Jon

[afsharki2]

I have put the diagram back.  great explanation, thank you!   You're absolutely right about another form of redundancy, I will implement this for sure.

is all we need to do is make an SVI on ds2 and SVI on service switch.  

would it be something like this:

int vlan 75

ip add.....

ip  ospf 1 area x

Then we would hope that 

probably off topic, but in that diagram at the bottom where it shows the vlan 50s connected to the r1 and r2 switch: those vlan 50 devices should be multihomed to the r1 and r2 switches...in a bvi interface fashion.

[Jon Marshall]

For the peering  basically yes to what you say, just create vlan in the vlan database and then create the SVIs and add to OSPF configuration so pretty much like Julio's original example although you don't need to create the trunk. The vlan is purely for peering so no end clients and you just need a subnet with an IP for each end.

As for the question about the vlan 50 devices it depends what they are but you usually only connect to both switches if a server etc. ie. not for standard end user PCs etc.

You do raise an interesting point though and that is if the devices are physically connected to r1 or r2 then why run HSRP because if the switch goes the devices connected to it have no connectivity anyway. However it may be you have other switches connecting to those switches with more clients attached, I don't know and I wouldn't want to suggest there was anything wrong with what you have at the moment.

By all means ask away though if you want to discuss further.

Jon

[afsharki2]

As far as the HSRP config at the bottom, there is nothing wrong with, I was just mentioning it to make my diagram more accurate.  Nothing to worry about there.

lets call our new svi, 75 

so both the svi 75 I create on the service switch side and ds2 side have to be on the same subnet or this wouldn't work right?

I guess the question to ask is , the second that I add this svi on both sides, will the routing tables of both ds2 and service switch be shared with eachother completely?

Also, I would have to add more svi's, because I forgot to mention that there are also trunks from ds1 and ds3 to services switch.  Sorry for making matters even more confusing.  

[Jon Marshall]

Yes, has to be the same subnet.

Once you add the vlan, SVIs and update the OSPF configuration then the switches should exchange LSAs and update their routing tables. Note I am assuming all switches are in the same OSPF area. If not let me know.

I am logging off for tonight but I'll check in with this thread tomorrow if you have any more queries.

Jon