static routes redundancy

Does your core1 knows how to route traffic to 192.168.50.0? Is there any route on it?

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

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

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.

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

Have you tested connectivity to the cores from R8?

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

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.

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

What is the 10.10.10.10 address?

that is the connection to the FW. it is on R8 e3.

Very stange. Everything looks right. I even mocked this up in packet tracer real quick and it works flawlessly.

really? Is it possible for me to see that file? because I tried in packet tracer too and it did not work.

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

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

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

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

"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?

None... as the network isn't great.

^^^^This! Exactly.

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.

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

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. :-)

" 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)

eclb?

Got it. Thx

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.

I see. So you will have a trunk link and a routed link between core1 and core2.

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

"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?

Yes, I just provided an example. Use specific routes for your actual subnets

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

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.