Conditional OSPF default route origination based on classless IP prefixes

From CT3

Jump to: navigation, search

By Ivan Pepelnjak

Symptom The early implementations of the Conditional OSPF default route origination feature expected a route-map which referred to an IP access-list. The IP access-list was allowed to match only classful prefixes (class-A, class-B or class-C networks).
Solution A route-map used in the default-information originate route-map OSPF router configuration command can use an IP prefix list with the match ip address prefix-list name route map configuration command. The IP prefix-list can match classless IP prefixes.

Recent IOS releases, including IOS release 12.4, 15.0 and 12.2SR, support conditional OSPF default route origination based on route maps using IP prefix lists. The IP prefix-list used in the route map can match any IP prefix as long as the match is exact (the le and ge keywords are not allowed).

The Conditional OSPF default route advertisement feature recognizes only a very small subset of match conditions in the specified route map. BGP-related tests (including BGP communities and AS-path access lists) or source routing protocol tests (match source-protocol bgp) do not work.
Internal BGP routes are ignored by the Conditional OSPF default route origination feature; even though an internal BGP route is matched by the specified route map, OSPF process does not originate the default route.

Sample configuration

Router X2 is an ASBR running OSPF and BGP. It inserts default route into OSPF only when the IP prefix 172.18.64.0/18 is present in its routing table. As the 172.18.64.0/18 prefix is advertised by its BGP peer, X2 inserts a default route into OSPF only if its BGP session is operational and its BGP peer advertises the expected IP prefix.

Sample network diagram
The BGP prefix used in the conditional OSPF default route feature should be a stable prefix in the upstream ISP’s core network.

Relevant parts of router configuration

hostname X2
!
router ospf 1
 log-adjacency-changes
 default-information originate always metric 15 route-map CoreRoutes
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.1.4 remote-as 65000
 neighbor 10.0.1.4 update-source Loopback0
 neighbor 10.0.7.58 remote-as 65101
 no auto-summary
!
ip prefix-list CorePrefix seq 5 permit 172.18.64.0/18
!
route-map CoreRoutes permit 10
 match ip address prefix-list CorePrefix 

Debugging conditional OSPF default route origination

You can use the following debug commands to debug the conditional OSPF default route origination:

  • Use debug ip bgp updates access-list to track BGP updates related to the prefixes on which the OSPF default route is based;
  • Use debug ip routing access-list to track updates to the IP routing table.
  • Use debug ip ospf spf external access-list to track origination of the OSPF default route.
Always use an IP access list in these debug commands; otherwise the amount of debugging printouts might saturate the router’s CPU. Also make sure you’ve disabled console logging.

The following access-lists have to be configured on X2 to support the debugging process:

IP access lists configured on X2

X2#'''show access-list'''
Standard IP access list 95
    10 permit 172.18.64.0
Standard IP access list 96
    10 permit 0.0.0.0 

The debugging is enabled with these commands:

X2#debug ip bgp updates 95
BGP updates debugging is on for access list 95 for address family: IPv4 Unicast
X2#debug ip routing 95
IP routing debugging is on for access list 95
X2#debug ip ospf spf external 96
OSPF spf external events debugging is on for access list 96

When the external BGP neighbor advertises IP prefix 172.18.64.0/18, X2 generates the following debugging printouts:

BGP debugging printouts

58.351: BGP(0): 10.0.7.58 rcvd UPDATE w/ attr: nexthop 10.0.7.58, origin i, metric 0, path 65101 65100
58.359: BGP(0): 10.0.7.58 rcvd 172.18.64.0/18
58.363: BGP(0): Revise route installing 1 of 1 routes for 172.18.64.0/18 -> 10.0.7.58(main) to main IP table 

IP routing debugging printouts

58.371: RT: add 172.18.64.0/18 via 10.0.7.58, bgp metric [20/0] 
58.371: RT: NET-RED 172.18.64.0/18 

OSPF debugging printouts

58.407: OSPF: Schedule partial SPF - type 5 id 0.0.0.0 adv rtr 10.0.1.5
58.411: OSPF: Service partial SPF 0/1/0
58.411: OSPF process partial spfQ entry
58.411: OSPF process partial spfQ entry
58.411: OSPF process partial spfQ LSA id 0.0.0.0: mask 0.0.0.0, type 5 adv_rtr 10.0.1.5, age 0,
  seq 0x80000001 (Area dummy area)
58.415: OSPF: Start partial processing Type 5 External LSA 0.0.0.0, mask 0.0.0.0, adv 10.0.1.5,
  age 0, seq 0x80000001, metric 15, metric-type 2
58.419: OSPF process partial spfQ entry 

When the BGP prefix is revoked, the following printouts are generated:

BGP debugging printouts

55.923: BGP(0): 10.0.7.58 rcv UPDATE about 172.18.64.0/18 -- withdrawn
55.923: BGP(0): no valid path for 172.18.64.0/18
55.923: BGP(0): nettable_walker 172.18.64.0/18 no best path 

IP routing debugging printouts

55.923: RT: del 172.18.64.0/18 via 10.0.7.58, bgp metric [20/0] 
55.923: RT: delete subnet route to 172.18.64.0/18
55.923: RT: NET-RED 172.18.64.0/18 

OSPF debugging printouts

55.927: OSPF: Schedule partial SPF - type 5 id 0.0.0.0 adv rtr 10.0.1.5
55.927: OSPF: Service partial SPF 0/1/0
55.927: OSPF process partial spfQ entry
55.927: OSPF process partial spfQ entry
55.927: OSPF process partial spfQ LSA id 0.0.0.0: mask 0.0.0.0, type 5 adv_rtr 10.0.1.5,
  age 3600, seq 0x80000002 (Area dummy area)
55.927: OSPF: Start partial processing Type 5 External LSA 0.0.0.0, mask 0.0.0.0, adv 10.0.1.5,
  age 3600, seq 0x80000002, metric 16777215, metric-type 2
55.927: OSPF process partial spfQ entry 

Additional Resources  

Personal tools

CT3

Main menu