[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 473
  • Last Modified:

static routes redundancy

If you look at my atttached diagram, my R8 has the following static route:

ip route 192.168.50.0 255.255.255.0 10.10.10.5
ip route 192.168.50.0 255.255.255.0 10.10.10.1 20 name backup_route

When I shutdown int e1/0 on core2, the traffic for 192.168.50.0 did not switch to the next hop 10.10.10.1? Can you shed a light on this? Thanks
Capture.JPG
0
leblanc
Asked:
leblanc
  • 19
  • 10
  • 8
  • +2
9 Solutions
 
fgasimzadeCommented:
Does your core1 knows how to route traffic to 192.168.50.0? Is there any route on it?
0
 
leblancAccountingAuthor Commented:
the link between core1 and core2 is a trunk. So core1 does not know how to get to 192.168.50.0 network as far as layer 3 is concerned. I think if the link between core 1 and core 2 is a layer 3 then this should work. I am just wondering if running HSRP between core 1 and core 2 will work. Thanks
0
 
fgasimzadeCommented:
If core1 does not have routes to 192.168.50.0, then your back up route will not work

You need to add routes on core pointing to 192.168.50.0

HSRP will work
0
NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

 
SouljaCommented:
Nope, no reason it shouldn't work. Must be something not configured correctly. Can you post the configs?

It doesn't matter if the cores not about how to route to those networks. As long as R8 sees that far end host go down, it will switch to the other.

Regardless, based on your diagram, both cores have the 192.168.50.0 networks as connected subnets anyway, so they do both know how to get to them.
0
 
leblancAccountingAuthor Commented:
May be you can show me what I did wrong.
The configs are very basic. When I shut down e1/0 on core2, the 3560 still has a route to 192.168.50.0 via 10.10.10.5. The link between core1 and core2 is a trunk.


3560#sh run
Building configuration...

Current configuration : 1769 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname 3560
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
no ip domain lookup
ip domain name lab.local
!
!
!
interface FastEthernet0/0
!
...
!
interface FastEthernet0/15
!
interface Ethernet1/0
 ip address 10.10.10.2 255.255.255.252
 half-duplex
!
interface Ethernet1/1
 no ip address
 shutdown
 half-duplex
!
interface Ethernet1/2
 ip address 10.10.10.6 255.255.255.252
 half-duplex
!
interface Ethernet1/3
 no ip address
 shutdown
 half-duplex
!
interface Vlan1
 no ip address
!
no ip http server
no ip http secure-server
!
ip forward-protocol nd
ip route 192.168.50.0 255.255.255.0 10.10.10.5
ip route 192.168.50.0 255.255.255.0 10.10.10.1 20
!
...
!
end
-------------------------------
core2#sh run
Building configuration...

Current configuration : 1912 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname core2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
no ip domain lookup
ip domain name lab.local
!
...
!
interface FastEthernet0/0
!
interface FastEthernet0/1
!
interface FastEthernet0/2
 switchport mode trunk
!
interface FastEthernet0/3
 switchport mode trunk
!
interface FastEthernet0/4
 description TO CORE1
 switchport mode trunk
...
!
interface FastEthernet0/15
!
interface Ethernet1/0
 ip address 10.10.10.5 255.255.255.252
 half-duplex
!
interface Vlan1
 no ip address
!
...
!
interface Vlan25
 ip address 192.168.50.2 255.255.255.0
!
no ip http server
no ip http secure-server
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.10.10.6
!
...
!
end
----------------------------------------------

3750core1#sh run
Building configuration...

Current configuration : 2074 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname 3750core1
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$FYy3$9UCciaqRURCDTcItGvgLy.
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
no ip domain lookup
ip domain name lab.local
!
!
...
!
username nac secret 5 $1$WfUB$UN53eVrPANv.wTOzAtXdj.
!
...
!
interface FastEthernet0/3
!
interface FastEthernet0/4
 description TO CORE2
 switchport mode trunk
!
...
!
interface FastEthernet0/15
!
interface Ethernet1/0
 ip address 10.10.10.1 255.255.255.252
 half-duplex
!
interface Vlan1
 no ip address
!
...
!
interface Vlan25
 ip address 192.168.50.1 255.255.255.0
!
no ip http server
no ip http secure-server
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.10.10.2
!

...
!
end
0
 
SouljaCommented:
Have you tested connectivity to the cores from R8?
0
 
leblancAccountingAuthor Commented:
R8 could not reach 192.168.50.2 when  I shut down e1/0 (10.10.10.5) on core2. It did not switch to 10.10.10.1
0
 
SouljaCommented:
I meanT not reach the 192.168.50.2, but reach the 10.10.10.5 and 10.10.10.1 while both are up.

Post your sh ip route from R8 while everything is up. Then post the output after you shut the core interface off.
0
 
leblancAccountingAuthor Commented:
3560 can ping core1 & core2 without problem.


SHOW IP ROUTE WHEN EVERYTHING IS UP:
3560#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       ...

Gateway of last resort is 10.10.10.10 to network 0.0.0.0

     10.0.0.0/30 is subnetted, 3 subnets
C       10.10.10.8 is directly connected, Ethernet1/1
C       10.10.10.0 is directly connected, Ethernet1/0
C       10.10.10.4 is directly connected, Ethernet1/2
S    192.168.50.0/24 [1/0] via 10.10.10.5
S*   0.0.0.0/0 [1/0] via 10.10.10.10

----------------------

3750core1#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       ...

Gateway of last resort is 10.10.10.2 to network 0.0.0.0

     10.0.0.0/30 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, Ethernet1/0
C    192.168.50.0/24 is directly connected, Vlan25
S*   0.0.0.0/0 [1/0] via 10.10.10.2

------------------------------
core2#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       ...

Gateway of last resort is 10.10.10.6 to network 0.0.0.0

     10.0.0.0/30 is subnetted, 1 subnets
C       10.10.10.4 is directly connected, Ethernet1/0
C    192.168.50.0/24 is directly connected, Vlan25
S*   0.0.0.0/0 [1/0] via 10.10.10.6
------------------------------------

SHOW IP ROUTE WHEN CORE2 E1/0 IS DOWN:

3560#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       ...

Gateway of last resort is 10.10.10.10 to network 0.0.0.0

     10.0.0.0/30 is subnetted, 3 subnets
C       10.10.10.8 is directly connected, Ethernet1/1
C       10.10.10.0 is directly connected, Ethernet1/0
C       10.10.10.4 is directly connected, Ethernet1/2
S    192.168.50.0/24 [1/0] via 10.10.10.5
S*   0.0.0.0/0 [1/0] via 10.10.10.10

------------------------------
3750core1#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       ...

Gateway of last resort is 10.10.10.2 to network 0.0.0.0

     10.0.0.0/30 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, Ethernet1/0
C    192.168.50.0/24 is directly connected, Vlan25
S*   0.0.0.0/0 [1/0] via 10.10.10.2

--------------------------------------
core2#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       ...

Gateway of last resort is not set

C    192.168.50.0/24 is directly connected, Vlan25
0
 
SouljaCommented:
What is the 10.10.10.10 address?
0
 
leblancAccountingAuthor Commented:
that is the connection to the FW. it is on R8 e3.
0
 
SouljaCommented:
Very stange. Everything looks right. I even mocked this up in packet tracer real quick and it works flawlessly.
0
 
leblancAccountingAuthor Commented:
really? Is it possible for me to see that file? because I tried in packet tracer too and it did not work.
0
 
SouljaCommented:
sure. You have to have the exact version though. My version is 6.0.1.0011

Just change the extension back to .pkt
redundancy.doc
0
 
leblancAccountingAuthor Commented:
I have Packettracer 5.3 installed. I have to see if I have your version. I will try it tonight. What I'd like to understand is how does the 3560 remove the next hop 10.10.10.5 from the routing table as its interface is still up. Thanks
0
 
leblancAccountingAuthor Commented:
The route did switch from 10.10.10.5 to 10.10.10.1. But I still could not ping 192.168.50.2 from the router or the 3560 when core2 interface is down (see my packet tracer file - pkt 6.0). Rename the file from doc to pkt.
redundancy-v2.doc
0
 
SouljaCommented:
This is the down side of static routing. It isn't ideal for redundancy/failover. What you  can try is put a second default route on core 2 with the next hop being 10.10.10.2 and a higher metric.

ip route 0.0.0.0 0.0.0.0 10.10.10.2 20

With its current configuration it has no routes once its default goes away. If you add the floating stated above it should know howto get back to the R8.

Dothe same for core 1 and regardless of which side fails you should have connectivity
 ip route 0.0.0.0 0.0.0.0 10.10.10.6 20
0
 
AkinsdNetwork AdministratorCommented:
Use the switches as the next hop for each other in their backup routes

on ML-SW1
ip route 0.0.0.0 0.0.0.0 192.168.50.2 20


on ML-SW2
ip route 0.0.0.0 0.0.0.0 192.168.50.1 20

See attached pkt file (rename the extenssion)

This way, you have full convergence.




You may also want to consider configuring GLBP (Preferred if IOS supports it), HSRP or VRRP (if mixing with non cisco switch - I never recommend mixing core or distribution switches when implementing redundancy (failover) eg Cisco with other models)

All the best
redundancy-v3.doc
0
 
leblancAccountingAuthor Commented:
It looks like the best thing to do is to make the connection between core1 and core2 a layer 3 because now I cannot ping 192.168.10.2. To do so I have to add ip route 0.0.0.0 0.0.0.0 192.168.1.2 20 on core1.

It is getting messy with static routes. But it you guys prove that the static routes did switch automatically. My next test will be to try with eigrp.

Thanks
0
 
AkinsdNetwork AdministratorCommented:
From the Router?
The Router only knows about 192.168.50.0 network.
You will have to add additional routes for other networks on the router.

Router-on-a-stick approach (sub-interface) would have been better in conjunction with routing protocols but you can still achieve convergence with your setup


R8(config)#ip route 192.168.1.0 255.255.255.0 10.10.10.5
R8(config)#ip route 192.168.1.0 255.255.255.0 10.10.10.1 20
R8(config)#ip route 192.168.19.0 255.255.255.0 10.10.10.1 20
R8(config)#ip route 192.168.19.0 255.255.255.0 10.10.10.5



There are advantages and disadvantages when you compare statically inserted routes and use of protocols.

Main things to consider
- Administration
- Security
- Resource Intensiveness

For big networks, you definitely want to use protocols.
Static eliminates advertisement, hence uses less resource and gives an acceptable sense of security as routes will only go to where you intend with minimal configuration.

Protocols have to advertise hence more resource intensive.
To achieve security, you will need to tighten the protocols down
You also have flexibility (redistribution etc)
redundancy-v4.doc
0
 
Craig BeckCommented:
Your problem is probably this...

You have a static route to 192.168.50.0/24 on R8 pointing to 10.10.10.5.  That's great, but you also therefore need a static route for the 10.10.10.0/30, 10.10.10.4/30 and 10.10.10.8/30 networks on the cores for when the primary interface goes down, which routes traffic to the other core.  As Soulja said, this would not be a route for each network as such, but a second default route pointing to the other core.

It's doable with statics, but this is not great and it is very messy as you've already said.  This really requires dynamic routing in order for it to work nicely.

You could do it with EIGRP quite easily, but it's not optimal in the current configuration.  You would find that some traffic is going to come back over the alternate link, then across the L2 link between the cores.  That will put an unnecessary overhead on the L2 link so it's important to ensure whichever solution you choose routes traffic efficiently across the whole network and not just at this segment.
0
 
leblancAccountingAuthor Commented:
"You could do it with EIGRP quite easily, but it's not optimal in the current configuration." So which dynamic protocol provide an optimal solution?
0
 
Craig BeckCommented:
None... as the network isn't great.
0
 
SouljaCommented:
^^^^This! Exactly.
0
 
Craig BeckCommented:
I apologize if I sounded harsh there...

Traffic will always flow over the L2 link between the cores for some traffic unless you do some tricks.  This isn't optimal - that's what I meant.

If Core1 is routing all traffic for 192.168.50.0/24 via R8 to the internet, and Core2 is routing all traffic for 192.168.50.0/24 via R8 to the internet, that's ok as long as you use a protocol such as EIGRP with equal-cost load-balancing between Core1, Core2 and R8.  But when traffic comes back from R8 to the 192.168.50.0/24 network it could go over either link if you do that - to Core1 OR Core2.  That means the traffic might take the long way round on the way back.

If the link between Core1 and Core2 is heavily used that could be a bad thing and could cause other issues.
0
 
leblancAccountingAuthor Commented:
Sure. np.
Well... With hsrp configuration, core1 is the primary outbound for the 192.168.1.0, core2 is the primary outbound traffic for 192.168.50.0. So it is going through different links.
You said that the network is not great. So how would you redesign this? I don't see any other way. You have the access layer, the core redundancy, and the WAN distribution. This is how it should be. Well... I could have the WAN distribution redundant as well but I cannot justify the spending. Thx
0
 
Craig BeckCommented:
If you have dedicated L2 segments at each core, separated via a L3 link between the cores (so VLAN100 connected to Core1 is NOT the same subnet as VLAN100 connected to Core2) then this would be easy with traditional routing.  But that's not the way it is.
With hsrp configuration, core1 is the primary outbound for the 192.168.1.0, core2 is the primary outbound traffic for 192.168.50.0. So it is going through different links.
This isn't completely achievable with HSRP if you use it only facing towards the user VLANs (it's one core or the other in an active/passive setup but only on one side), and so if you have each subnet on each side of the L2 links between the cores, sure it will always go out of the same link, but you will have traffic going across the L2 link at some point on the way back in (as well as on the way out).  This isn't optimal, and that's what I was getting at.

We already know that there's more than one way to skin the cat here but the point I was making is that you could get things working quite easily using EIGRP as this would deal with the secondary routes to each subnet - it just WON'T be optimal for traffic-path selection as unless you do some tricks the EIGRP from each core will advertise its route to the same network.  However, I didn't say it won't work.

Now, if you come back to me and say that each access-layer switch is connected to both cores, I might change my mind and say that it'll work like a dream no matter which link the traffic comes back in on. :-)
0
 
leblancAccountingAuthor Commented:
" if you come back to me and say that each access-layer switch is connected to both cores" Yes, each access switch has two connections, one to core1 and one to core2 and that is why I implement HSRP. If core1 fails, core2 will take over without the access switch knowing it (well... after 30 seconds)
0
 
Craig BeckCommented:
Well... play with the timers to reduce the failover time.

Just use EIGRP with eclb for the L3 links to R8 - job done.
0
 
leblancAccountingAuthor Commented:
eclb?
0
 
Craig BeckCommented:
0
 
leblancAccountingAuthor Commented:
Got it. Thx
0
 
Craig BeckCommented:
Ok I labbed it in GNS...

EIGRP ECLB Lab
It works fine, although you should use a dedicated L3 P2P link between the cores for routing.  You can leave the L2 link there for the HSRP on each VLAN, but you'll notice the EIGRP config uses passive interfaces, so although EIGRP distributes routes for those subnets where HSRP is running, it doesn't actually run EIGRP on those interfaces.

I've attached configs for you to look at :-)

Notice the max-paths config on the R8 router... that tells the router how many routes to install and use per destination.
EIGRP-R8.txt
EIGRP-Core1.txt
EIGRP-Core2.txt
0
 
leblancAccountingAuthor Commented:
craigbeck, you rock buddy... So it looks like you make the link between core1 and core2 a layer 3. Let me run it to see how it goes. Thanks a lot.
0
 
Craig BeckCommented:
Yep but you still need a L2 trunk between the cores too for HSRP to work for your access layer. The L3 link between the cores is just for routing incase a link to R8 goes down.
0
 
leblancAccountingAuthor Commented:
I see. So you will have a trunk link and a routed link between core1 and core2.
0
 
leblancAccountingAuthor Commented:
I did not have time to run your lab yet. But the redistribute static statement that you have in r8 is to redistribute ant static routes from the Internet switch. Correct?
the reason I ask is because in my case the Internet switch is my FW and I have several static routes pointed to the internal network.
Also, I see that under eigrp process for core1 and core2, you advertise network 192,168,0,0 and 192.168.1.0. Isn't just 192.168.0.0 is enough as it covers 192.168.1.0?

Thanks
0
 
AkinsdNetwork AdministratorCommented:
the redistribution is because you have both static routes and routing protocol (EIGRP) running. The static routes are therefore injected into EIGRP through redistribution.

The network command not only tells which interface to run the routing protocol on but also specifies which routes to advertise.
You could advertise 192.168.0.0 if you don't have any range within somewhere else. What that means is you are advertising to every router that you own the routes to every network between 192.168.0.0 to 192.168.255.255. That will cause a problem if other routers have a subnet in that range. Although, that can be fixed by tagging your routes or other means, even with route maps, but it becomes unnecessarily complex
0
 
leblancAccountingAuthor Commented:
"static routes and routing protocol (EIGRP) running" Do you mean on R8? The static route that you distribute in EIGRP is the default route to the FW next hop. Correct?

For the network 192.168.0.0. I think I should remove 192.168.0.0 and make it more specific by advertising 192.168.1.0 and 192.168.50.0 within EIGRP. Correct?
0
 
Craig BeckCommented:
Yes, I just provided an example. Use specific routes for your actual subnets
0
 
leblancAccountingAuthor Commented:
craigbeck,

I am just wondering why we need a routed link between core1 and core2. If the link between core1 and R1 goes down, eigrp will have a route to the internal network through core2. As far as the outbound traffic from one of the PC, it is all layer 2 to core1 then core2 then R1. I did not test it yet but I'd like to get your thought on it. Thanks
0
 
Craig BeckCommented:
The issue is with using a client VLAN to pass transit traffic essentially.  If you are ok with doing that then just use one of the client subnets as transit between your cores, otherwise use a dedicated link.  There can be problems with doing this though.  For example, if you use an SVI for routing but remove that client VLAN from all your trunks the SVI would go down, causing all routing between the cores to fail.

You need to send traffic to the other core only when it can't reach the internet firewall directly.  If you have a L2 link between the cores you'd still need an SVI on each core to route traffic via the other core, so it's still effectively a L3 link, so if you can - use a L3 link on dedicated ports.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 19
  • 10
  • 8
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now