We are using the below simple topology for this explanation:
The client has 2 networks at the first site – 192.168.1.0/24 and 10.10.10.0/24. These are both connected to R1 and R2 (via a switch not shown) – R1 and R2 are running MHSRP, with R1 being the master of 192.168.1.254 and R2 being the master of 10.10.10.254. Both routers are the backup of each others group.
I want the link from R1 to be used for 192.168.1.0 and I want the link from R2 to be used for 10.10.10.0. I also want return traffic to take the same path. i.e. if R3 needs to send traffic to 10.10.10.0 – it needs to prefer the direct path to R2.
Another constraint is that I need convergence to be fast, therefore I’m not going to run HSRP on the WAN side of R1 and R2 and have to wait for the IGP to re-converge.
The final constraint is that I don’t want to have to use route-map’s on R3 itself. Let’s pretend there are going to be a lot more routers connected to OSPF area 0. I want to make it as simple as possible when newer routers come into the area. Therefore all this routing needs to be controlled by R1 and R2 themselves.
So far, pretty simple. So let’s get cracking!
Let’s do R1 first, this is the relevant config:
interface FastEthernet0/1 ip address 10.10.10.1 255.255.255.0 secondary ip address 192.168.1.1 255.255.255.0 standby version 2 standby 1 ip 192.168.1.254 standby 1 priority 110 standby 1 preempt standby 1 track FastEthernet0/0 50 standby 2 ip 10.10.10.254 standby 2 preempt standby 2 track FastEthernet0/0 50
And now R2:
interface FastEthernet0/1 ip address 10.10.10.2 255.255.255.0 ip address 192.168.1.2 255.255.255.0 secondary standby version 2 standby 1 ip 192.168.1.254 standby 1 preempt standby 1 track FastEthernet0/0 50 standby 2 ip 10.10.10.254 standby 2 priority 110 standby 2 preempt standby 2 track FastEthernet0/0 50
Now let’s set up OSPF. Remember that I want 192.168.1.0 traffic to go via R1 and 10.10.10.0 to go via R2. There are a number of ways of doing this.
First let’s try and set up regular OSPF with a metric:
router ospf 1 R1(config-router)#network 10.10.10.0 0.0.0.255 area 0 ? cr> R1(config-router)#network 10.10.10.0 0.0.0.255 area 0
OSPF will not allow you to specify a metric under the network command!
There is another way. Run 2 OSPF processes and redistribute with a higher metric.
router ospf 1 redistribute ospf 2 metric 50 metric-type 1 subnets network 1.1.1.0 0.0.0.255 area 0 network 192.168.1.0 0.0.0.255 area 0 ! router ospf 2 network 10.10.10.0 0.0.0.255 area 0
Let’s check R3′s routing table:
R3#sh ip route
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/0
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.50.0 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/51] via 1.1.1.1, 00:00:39, FastEthernet0/0
O 192.168.1.0/24 [110/2] via 1.1.1.1, 00:00:39, FastEthernet0/0It works, but I think its messy. We could also use route-maps which would give us a lot finer control over newer subnets that may be added (without having to run more OSPF processes)
Let’s remove that OSPF config from R1 and do the following:
router ospf 1 redistribute connected metric-type 1 subnets route-map 10_HIGH network 1.1.1.0 0.0.0.255 area 0 ! ip prefix-list 10NET seq 5 permit 10.10.10.0/24 ! route-map 10_HIGH permit 10 match ip address prefix-list 10NET set metric +100 ! route-map 10_HIGH permit 20
Now we do this on R2:
router ospf 1 redistribute connected metric-type 1 subnets route-map 192_HIGH network 1.1.1.0 0.0.0.255 area 0 ! ip prefix-list 192NET seq 5 permit 192.168.1.0/24 ! route-map 192_HIGH permit 10 match ip address prefix-list 192NET set metric +100 ! route-map 192_HIGH permit 20
This will ensure R1 redistributes the 10.10.10.0 network with a higher metric to R3, and vice-versa for R2. R3 will have a possible route in it’s database, but won’t use it until the preferred link is down/
Let’s have a look at R3′s routing table:
R3#sh ip route ospf
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/21] via 1.1.1.2, 00:00:28, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:28, FastEthernet0/0Excellent, just what we want. but do the backups work correctly? Let’s shut down R1′s interface to the customer LAN and see what happens:
R1(config)#int fa1/0 R1(config-if)#shut R1(config-if)# *Mar 1 00:34:20.711: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Active -> Init *Mar 1 00:34:20.723: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Standby -> Init *Mar 1 00:34:22.723: %LINK-5-CHANGED: Interface FastEthernet1/0, changed state to administratively down *Mar 1 00:34:23.723: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down
What does R3 see?
R3#sh ip route ospf
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/21] via 1.1.1.2, 00:00:18, FastEthernet0/0
O E1 192.168.1.0/24 [110/101] via 1.1.1.2, 00:00:18, FastEthernet0/0Both are now going via R2, which is exactly what we wanted. Let’s now reconnect R1 and disconnect R2′s WAN link:
R1(config-if)#int fa1/0 R1(config-if)#no shut R1(config-if)# *Mar 1 00:35:47.775: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Listen -> Active *Mar 1 00:35:47.859: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up *Mar 1 00:35:48.859: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
R2(config)#int fa0/0 R2(config-if)#shut R2(config-if)# *Mar 1 00:36:16.179: %TRACKING-5-STATE: 1 interface Fa0/0 line-protocol Up->Down *Mar 1 00:36:16.187: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Mar 1 00:36:16.187: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Mar 1 00:36:18.179: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down *Mar 1 00:36:18.231: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Active -> Speak *Mar 1 00:36:19.179: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
What does R3 see this time?
R3#sh ip route ospf
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/101] via 1.1.1.1, 00:00:03, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:03, FastEthernet0/0Great. Let’s just make sure it all works properly again if all links are up:
R2(config-if)#int fa0/0 R2(config-if)#no shut R2(config-if)# *Mar 1 00:37:53.291: %TRACKING-5-STATE: 1 interface Fa0/0 line-protocol Down->Up *Mar 1 00:37:54.235: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Standby -> Active *Mar 1 00:37:55.287: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up *Mar 1 00:37:56.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R3#sh ip route ospf
10.0.0.0/24 is subnetted, 1 subnets
O E1 10.10.10.0 [110/21] via 1.1.1.2, 00:00:06, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:06, FastEthernet0/0Let’s see what happens when a client is pinging a network directly connected to R3 over the 192.168.1.0 network. I’ll be using a router as a client, so it’ll be a ping flood.
R4#ping 172.16.50.1 repeat 1000
I’ll quickly shut R1′s LAN interface. Wait a bit, and then no shut it. What happens to R4′s pings?
Sending 1000, 100-byte ICMP Echos to 172.16.50.1, timeout is 2 seconds: !!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 99 percent (998/1000), round-trip min/avg/max = 1/44/160 ms
I lost only 2 pings! Once when I shut the interface, and the second when it came back up again. Pretty good!
It wont be as fast if the WAN link goes down though. R2 will take over for sending packets out, but return traffic will still go to R1. Why? Well remember R3 still thinks R1 is there. Unless they were directly connected, or you wait for OSPF to realise the peer is down, it’ll continue to send traffic that way. You can speed this up by reducing your OSPF hello timers though. This will need to be balanced on how much OSPF traffic you want going across your WAN link.
No comments:
Post a Comment