default route question

[NetworkEngineer00237]

Hello all,

I have a question about default route functionality.  Heres my scenario:

I have 2 9500 stacks in 2 separate buildings connected via a trunk.  In stack 1, I have a vlan defined and its gateway is on this stack and the default route points to the next hop on the firewall.  In building 2, stack 2, the networks use the vlan defined on stack 1 and get their connectivity through the tunnel, to the internet as well.  Stack 2 has no default route configured.  

I am currently implementing OSPF between the 2 buildings and am going to create new networks there so they can go out to the internet through each of their respective stacks.  They currently don't do that because their gateways are in stack 1 so traffic goes over the tunnel to stack 1 and then out via its default route.  I also want each building to serve as a backup to the other for redundancy.

So I have created the ospf uplinks and a network in each 9500 stack and routing between them works good.  I want to test default route failover and am curious that if I put a default route on stack 2, will it disrupt current production traffic?  User vlans in use have their gateways on stack 1 so it wouldn't right?  Only the networks whose gateways are on stack 2?  I don't think it will but just wanted to be certain before I do anything.

[Flavio Miranda]

Hi

 First, if you really have an stack there´s no such thing stack1 and stack2. Switch in stack works as one switch and routing protocol meant to be for the whole stack.

But, in case you have two separated switches, you can add default router on the second but you increase the Administrative disctance for this second route. In this case, it will be used only if the first is not reacheble.

[NetworkEngineer00237]

Hi Flavio, thanks for your response.

They are actually 2 separate stacks, 2 switches in each stack.  And yes, I created a secondary default route with an AD of 10.  I have not configured this on stack 2 yet however as I want to make sure I don't disrupt production traffic currently.  Stack 2 does not have a default route defined at all and the vlans in use come from stack 1 where the gateways are.  Will adding a default route on stack 2 disrupt that vlan traffic?  Or will it only affect networks that are defined on stack 2?  

[Flavio Miranda]

I got it. There are actually two stacks. Nice.

 You mentioned on the original post that there is no default route on stack 2 right? Then I assume the second stack is receiving de default route from the stack 1 via OSPF. You must have a redistribute static there, right?

But yes, if you deploy a default route with higher AD, there will be no problem.

[Richard Burts · Accepted solution]

Actually setting the AD of the default on switch 2 will not change anything. If now there is no default route on switch 2, then when adding a default route on switch 2 there will be a single default route and it will be the active default route for switch 2 no matter what its AD is.

As long as devices connected on switch 2 have their default gateway as switch 1 then adding a default route on switch 2 will not have an impact on these devices. Adding a default route for switch 2 will only be used by an SVI on switch 2 or any device whose gateway is an interface on switch 2.

[NetworkEngineer00237]

Thank you Rick, that's what I was looking for.  Yes, the GW for my vlans on stack 2 are on stack 1.  I have 1 vlan in each stack that are not used in production that I have routing through ospf and want to test def route failover without interrupting production traffic.  Thanks both for the responses!

[Richard Burts]

I am glad that my explanations were helpful. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

I am thinking about this part of your response "want to test def route failover without interrupting production traffic." And I am wondering how the default route on stack 2 will work. Does stack 2 have a way to get to the firewall that does not go through stack 1? If stack 2 does have its own way to get to the firewall then a second default route could make sense. But I am not clear from your description of the environment that stack 2 does have an independent way to get to the firewall.

And as I think about default route failover I believe that there is a question that you need to think about. If vlans in stack 2 have their gateway on stack 1, and if there is some problem on stack 1, then how will you get the traffic for those vlans on stack 2 to no longer use the gateway on stack 1? The solution for this is frequently to configure HSRP on those vlans. When using HSRP then each switch would have its own IP address in the vlan and they would share a (virtual) address and that shared virtual address would be the gateway for the hosts in the vlan. With HSRP if there is a problem with the default route on stack 1 you can get the traffic to use the gateway on stack 2.

[NetworkEngineer00237]

Hi Richard,

To answer your question, the way we're setup is we have 2 buildings side by side.  Each building has its own internet circuit, fw and sd-wan appliance.  Currently, the circuit in building 2 (stack 2) is not being utilized because their data vlan gateways are in building 1 (stack 1).  I am in the process of creating new networks for that building and a routed uplink between them so I can direct their internet traffic out through their firewall instead of coming across to stack 1.  And I want each building to serve as a redundant path for the other.  Hence the backup default route question.  Its probably overkill but thats what the boss wants.....

[Richard Burts]

I have read through the discussion again and have a couple of thoughts:

- Your main question was about configuring a default route of stack 2 and whether that would disrupt the existing vlans with their gateway on stack 1. Pretty clearly configuring a default route on stack 2 would not disrupt the existing traffic flow. Then you said "want to test def route failover without interrupting production traffic." I do not see how you can test default route failover without impacting your production traffic. How would you test failover for stack 1 without taking down the default route on stack 1? And if you take down the default route on stack 1 then it certainly does impact production traffic.

- Am I correct in assuming that your current environment is using static routing? And that you are implementing OSPF to provide dynamic capabilities? Perhaps we should explore ways in which OSPF might help with default route failover? 

[NetworkEngineer00237]

Actually, I want to test default route failover on stack 2 since their production vlan gw's are on stack 1.  There is no default route on stack 2 currently.  So I want to configure one and use a non-production vlan with its gw on stack 2 to test route failover with that so as not to disrupt production traffic, if possible.

Correct, we are using static routing currently.  I am implementing static routing to avoid the potential headaches down the road as we continue to grow and expand.  If you have some suggestions, im all ears   Thanks!

[Richard Burts]

Thanks for the clarification. You could test failover on stack 2 without impacting stack 1. So perhaps the next step is to identify what failover mechanism you want to use. I can think of 4 possible mechanisms.  Perhaps someone in the community can think of others?

1) Use static default route with a floating static default route. To do this each switch would configure a primary static default route with its building firewall as the next hop and configure another static default route with the other building as the next hop and with an Administrative Distance greater than zero. The challenge in this approach is to be sure that if there is a problem with the primary static default route that it is removed from the routing table so that the floating static default route can be used. This typically depends on using IP SLA to track the primary static default route.

2) In a previous response I had suggested using HSRP. But as I think about that suggestion I realize that while HSRP can configure one switch as primary and the other as backup, it needs something to trigger the change. So the challenge is similar to 1).

3) Use OSPF between the switches. I had mentioned this possibility in a previous response. In this approach each stack would redistribute its static default route into OSPF and advertise it to the peer switch. This is essentially a variant of the approach using AD. The local static default has an attractive AD, the OSPF advertised default route has higher AD. The challenge here (as in the other suggestions) is how to be sure that in a problem situation the local static default route is removed from the local routing table.

4) Use a dynamic routing protocol on the connection of the building firewall to the ISP (usually BGP) to learn a default route. Have the building firewall advertise to the building switch its default route. Each building stack would advertise its default route to the other building. The building switch would prefer its local default route but if that route is withdrawn then it would use the default route through the other switch.

[NetworkEngineer00237]

Thanks Rick, I didn't think it would but that's why we ask our colleagues   

#1 is the option that I have been planning to use.  We have a pretty robust wan infrastructure with sd-wan with 2 circuits, 2 fw's all fully meshed for failover so I was just going to set up and ipsla to google and see what happens.  Then i'll have to test different failure scenarios and hopefully its just that simple.  I do like the redistributing the def route in ospf and I played around with that in the simulator but I think it only works if the next hop fails and that won't work for us.  I can't rem now but it was something like that.

[Richard Burts]

Thanks for the update. A floating static default route with IP SLA should work. Good luck with testing and implementing this.

[NetworkEngineer00237]

Thanks!  Appreciate all the feedback