Solved

static routes redundancy

Posted on 2013-10-31
42
438 Views
Last Modified: 2013-12-13
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
Comment
Question by:leblanc
  • 19
  • 10
  • 8
  • +2
42 Comments
 
LVL 18

Expert Comment

by:fgasimzade
ID: 39616043
Does your core1 knows how to route traffic to 192.168.50.0? Is there any route on it?
0
 
LVL 1

Author Comment

by:leblanc
ID: 39616557
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
 
LVL 18

Expert Comment

by:fgasimzade
ID: 39616568
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
 
LVL 26

Expert Comment

by:Soulja
ID: 39616934
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
 
LVL 1

Author Comment

by:leblanc
ID: 39617047
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
 
LVL 26

Expert Comment

by:Soulja
ID: 39617082
Have you tested connectivity to the cores from R8?
0
 
LVL 1

Author Comment

by:leblanc
ID: 39617334
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
 
LVL 26

Expert Comment

by:Soulja
ID: 39617353
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
 
LVL 1

Author Comment

by:leblanc
ID: 39617414
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
 
LVL 26

Expert Comment

by:Soulja
ID: 39617525
What is the 10.10.10.10 address?
0
 
LVL 1

Author Comment

by:leblanc
ID: 39617543
that is the connection to the FW. it is on R8 e3.
0
 
LVL 26

Expert Comment

by:Soulja
ID: 39617593
Very stange. Everything looks right. I even mocked this up in packet tracer real quick and it works flawlessly.
0
 
LVL 1

Author Comment

by:leblanc
ID: 39617609
really? Is it possible for me to see that file? because I tried in packet tracer too and it did not work.
0
 
LVL 26

Expert Comment

by:Soulja
ID: 39617628
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
 
LVL 1

Author Comment

by:leblanc
ID: 39617646
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
 
LVL 1

Author Comment

by:leblanc
ID: 39618212
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
 
LVL 26

Accepted Solution

by:
Soulja earned 56 total points
ID: 39618271
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
 
LVL 18

Assisted Solution

by:Akinsd
Akinsd earned 167 total points
ID: 39618848
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
 
LVL 1

Author Comment

by:leblanc
ID: 39618876
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
 
LVL 18

Assisted Solution

by:Akinsd
Akinsd earned 167 total points
ID: 39618881
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
 
LVL 45

Assisted Solution

by:Craig Beck
Craig Beck earned 277 total points
ID: 39624306
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
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 
LVL 1

Author Comment

by:leblanc
ID: 39624744
"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
 
LVL 45

Expert Comment

by:Craig Beck
ID: 39624768
None... as the network isn't great.
0
 
LVL 26

Expert Comment

by:Soulja
ID: 39624821
^^^^This! Exactly.
0
 
LVL 45

Expert Comment

by:Craig Beck
ID: 39624880
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
 
LVL 1

Author Comment

by:leblanc
ID: 39625073
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
 
LVL 45

Expert Comment

by:Craig Beck
ID: 39625190
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
 
LVL 1

Author Comment

by:leblanc
ID: 39625238
" 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
 
LVL 45

Assisted Solution

by:Craig Beck
Craig Beck earned 277 total points
ID: 39625349
Well... play with the timers to reduce the failover time.

Just use EIGRP with eclb for the L3 links to R8 - job done.
0
 
LVL 1

Author Comment

by:leblanc
ID: 39625610
eclb?
0
 
LVL 45

Assisted Solution

by:Craig Beck
Craig Beck earned 277 total points
ID: 39625622
0
 
LVL 1

Author Comment

by:leblanc
ID: 39625677
Got it. Thx
0
 
LVL 45

Assisted Solution

by:Craig Beck
Craig Beck earned 277 total points
ID: 39625902
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
 
LVL 1

Author Comment

by:leblanc
ID: 39626045
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
 
LVL 45

Assisted Solution

by:Craig Beck
Craig Beck earned 277 total points
ID: 39626527
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
 
LVL 1

Author Comment

by:leblanc
ID: 39627311
I see. So you will have a trunk link and a routed link between core1 and core2.
0
 
LVL 1

Author Comment

by:leblanc
ID: 39634416
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
 
LVL 18

Assisted Solution

by:Akinsd
Akinsd earned 167 total points
ID: 39634967
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
 
LVL 1

Author Comment

by:leblanc
ID: 39634979
"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
 
LVL 45

Expert Comment

by:Craig Beck
ID: 39635070
Yes, I just provided an example. Use specific routes for your actual subnets
0
 
LVL 1

Author Comment

by:leblanc
ID: 39713136
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
 
LVL 45

Expert Comment

by:Craig Beck
ID: 39716371
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

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

Meet the world's only “Transparent Cloud™” from Superb Internet Corporation. Now, you can experience firsthand a cloud platform that consistently outperforms Amazon Web Services (AWS), IBM’s Softlayer, and Microsoft’s Azure when it comes to CPU and …
When it comes to security, there are always trade-offs between security and convenience/ease of administration. This article examines some of the main pros and cons of using key authentication vs password authentication for hosting an SFTP server.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

22 Experts available now in Live!

Get 1:1 Help Now