This exercise was first post by Costi Serban (http://www.costiser.ro/2014/05/10/quiz-24/). I just found my own solution to the problem that he proposed
My solution includes tracking a sla failure instead of the traditional "ip sla reachability" (up)
THE PROBLEM
CORE-A must always have internet Access even if ISP-1 goes down. This is not happening with the actual configuration. Please do the tshoot to find the answer and propose a solution
THE SOLUTION
BR-B is getting a default route from ISP-1 (EBGP), but from BR-C too (OSPF). So which one it will choose?. it chooses the route with the lower administrative distance in this case the one from ISP-1. the same applies for BR-C
BGP administrative distance = 20, OSPF administrative distance = 110
BR-B#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "bgp 65001", distance 20, metric 0, candidate default path
Tag 100, type external
Last update from 1.1.1.1 00:38:22 ago
Routing Descriptor Blocks:
* 1.1.1.1, from 1.1.1.1, 00:38:22 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 100
MPLS label: none
BR-B is advertising a default route into ospf using "default-information originate always". the same happens in BR-C
BR-B#show run | section ospf
router ospf 1
network 192.168.0.0 0.0.255.255 area 0
default-information originate always
CORE-A gets the advertisement from BR-C and install a default route in its routing table
CORE-A#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "ospf 1", distance 110, metric 1, candidate default path
Tag 1, type extern 2, forward metric 2
Last update from 192.168.15.1 on GigabitEthernet0/1, 02:11:50 ago
Routing Descriptor Blocks:
* 192.168.15.1, from 192.168.0.5, 02:11:50 ago, via GigabitEthernet0/1
Route metric is 1, traffic share count is 1
Route tag 1
The "always" means BR-B will continue telling everyone "hey guys use me as the default route" even if that's is true or not. To check this will shutdown interface in ISP-1 which faces BR-B and let's check BR-B's routing table again
BR-B#show ip route 0.0.0.0
There is no default route in the routing table, so now BR-B will receive the default route from BR-C (OSPF) right...no??. Well .., no, when you use "default-information originate always" you are telling everyone " hey guys i accept default routes from no one cause i got my own "
so CORE-A will never reach internet when BR-B lose conectivity with ISP-1
SOLUTIONS
1) The most easy solution is to remove the "always" from "default-information originate "BR-B
BR-B#show run | section ospf
network 192.168.0.0 0.0.255.255 area 0
default-information originate
This will let BR-B receive the default Gateway from BR-C and CORE-A will no lose internet connectivity because now it will go out through ISP-2
2) The solution that i propose is not the most neat but it will work too
If the conection between BR-B and ISP-1 fails, i will install a default route in BR-B so all the internet goes thorugh 192.168.12.2
I'll use SLA/TRACK to achieve this. Generally we add a static route when the track response is OK, but this time we'll add the static route when the track response is FAIL
Let's create the sla which will make ping to ISP-1 interface
BR-B#show run | section sla
ip sla 1
icmp-echo 1.1.1.1
frequency 5
ip sla schedule 1 life forever start-time now
And the track which will check the sla
BR-B#show run | section track 1
track 1 ip sla 1 reachability
Here comes the magic. Now we'll créate another track object which denies track 1
BR-B#show run | section track 2
track 2 list boolean and
object 1 not
Now we'll add a route static to BR-B routing table only if connectivity between BR-B and ISP-1 fails
ip route 0.0.0.0 0.0.0.0 192.168.12.2 track 2
That's it, make some tests with traceroute from CORE-A to 34.34.34.3 when interface in ISP-1 is down or up, and check the routing table everytime
I will upload the startup and solution files...They are in VIRL format but you can copy the configuration sections and paste them in GNS3
Please give me your feedback
No comments:
Post a Comment