Inject default route into IGP based on IP SLA response

Here’s a little trick I learned on how to inject a default route into the network only if the IP SLA probe comes back with a success response. IP SLA is a way to check reachability for a given router or layer 3 device.

Network Topology:

RouterA - RouterB - RouterC

First lets lets create an IP SLA to monitor RouterC from RouterA.

# ip sla monitor 1
# type echo protocol ipIcmpEcho 3.3.3.3
# timeout 2000
# frequency 5
# ip sla monitor schedule 1 life forever start-time now

Lets setup tracking for this IP SLA

# track 1 rtr 1

Now lets create a dummy route and make sure it is entered into the routing table if the IP SLA succeeds.

# ip route 12.12.12.12 255.255.255.255 null0 track 1

Lets create a prefix-list that matches this route

# ip prefix-list PR_CHECK_STATIC permit 12.12.12.12/32

Next we create a Route-map that looks for this static route in the routing table.

# route-map RM_CHECK_STATIC

# match ip address prefix-list PR_CHECK_STATIC

Lastly we apply it to our IGP Router process and originate a default route

# default-information originate route-map RM_CHECK_STATIC

Done!

Basically, if the IP SLA fails, then the route is never entered into the routing tables which causes the route-map to fail with the prefix lookup and the end result being that no default route is advertised into the network.

Tags: , ,

Leave a Comment

What Layer 3 MPLS is all about….

The key to understanding the general idea of how MPLS VPNs work is to focus on the control plane distinctions between PE routers and P routers. Both P and PE routers run LDP and an IGP to support unicast IP routing. However, the IGP advertises routes only for subnets inside the MPLS network, with no customer routes included. As a result, the P and PE routers can together label switch packets from the ingress PE to the egress PE.

PEs have several other duties as well, all geared toward the issue of learning customer routes and keeping track of which routes belong to which customers. PEs exchange routes with the connected CE routers from various customers, using either EBGP, RIP-2, OSPF, or EIGRP, noting which routes are learned from which customers. To keep track of the possibly overlapping prefixes, PE routers do not put the routes in the normal IP routing table—instead, PEs store those routes in separate per-customer routing tables, called VRFs. Then the PEs use IBGP to exchange these customer routes with other PEs—never advertising the routes to the P routers.

Tags:

Leave a Comment

Optimizing OSPF and BGP on EDGE Devices

Both ASBR1 and ASBR2 advertise defaults into the network, expecting to have the capability to route to the Internet through BGP-learned routes. In this case, ASBR2 is already up, fully converged. However, if ASBR1 reloads, when it comes back up, OSPF is likely to converge faster than BGP. As a result, ASBR1 will advertise its default route, and OSPF routers may send packets to ASBR1, but ASBR1 will end up discarding the packets until BGP converges.

Using the stub router feature on the ASBRs solves the problem by making them advertise infinite metric routes (cost 16,777,215) for any transit routes—either for a configured time period or until BGP convergence is complete. To do so, under router ospf, the ASBRs would use either the maxmetric router-lsa on-startup announce-time command or the max-metric router-lsa on-startup wait-for-bgp command. With the first version, the actual time period (in seconds) can be set. With the second, OSPF waits until BGP signals that convergence is complete or until 10 minutes pass, whichever comes first.

Tags: ,

Leave a Comment