One of my readers sent me an interesting NSSA question (more in a future blog post) that sent me chasing for the reasons behind the OSPF Forwarding Address (FA) field in type-5 and type-7 LSAs.
Two OSPF ASBRs are connected to the same external network, but only one of them is running the external routing protocol (BGP in my diagram) and redistributing external prefixes into OSPF. You’d want to send the traffic toward external destinations through both ASBRs, but can’t do that as only one of the ASBRs advertises the external routes.
Here are the relevant parts for E1 and E2 configuration:
interface Loopback0 description Loopback ip address 192.168.0.1 255.255.255.255 ip ospf 1 area 1 ! interface GigabitEthernet0/1 description to C1 ip address 10.0.128.1 255.255.255.252 ip ospf 1 area 1 ip ospf cost 1 ! interface GigabitEthernet0/2 description to External_LAN ip address 10.0.0.1 255.255.128.0 ! router ospf 1 redistribute bgp 65000 subnets passive-interface Loopback0 ! router bgp 65000 bgp log-neighbor-changes redistribute ospf 1 neighbor 10.0.0.2 remote-as 65001
interface Loopback0 description Loopback ip address 192.168.0.4 255.255.255.255 ip ospf 1 area 1 ! interface GigabitEthernet0/1 description to C1 ip address 10.0.128.6 255.255.255.252 ip ospf 1 area 1 ip ospf cost 1 ! router ospf 1
BGP (and redistribution into OSPF) is configured on E1 but not on E2.
And here’s the relevant part of the OSPF topology database. The prefix 192.168.0.2/32 that is advertised by X1 over EBGP is redistributed as type-5 LSA into OSPF by E1 (192.168.0.1)
C1#show ip ospf database external OSPF Router with ID (192.168.0.3) (Process ID 1) Type-5 AS External Link States LS age: 301 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 192.168.0.2 (External Network Number ) Advertising Router: 192.168.0.1 LS Seq Number: 80000001 Checksum: 0xA154 Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 1 Forward Address: 0.0.0.0 External Route Tag: 65001
If you want to reproduce the results, download the VIRL topology from my VIRL Github repository.
Enter the YAK (Yet Another Kludge) twilight zone: what if the ASBR advertises external next hop (forwarding address) in the type-5 LSA, and both ASBRs advertise the external prefix (hopefully as a stub network)? Recursive next-hop lookup would solve the problem and C1 would get two equal-cost routes toward the external destinations.
To enable this functionality E1 and E2 have to advertise the external subnet as an internal OSPF route, so we’ll add the external interface to the OSPF process on E1 and E2.
interface GigabitEthernet0/2 description to External_LAN ip ospf cost 1
You cannot make the external interface passive (= stub network). At least the recent versions of Cisco IOS do not set a forwarding address if the next-hop is on a passive interface; the external network must be a fully-functional OSPF interface. I was not able to find any relevant requirements in RFC 2328 – I probably missed something, if anyone knows more details, please write a comment.
After the configuration change the Type-5 LSA in the OSPF topology database gets the forwarding address value and C1 gets two equal-cost paths to the external destination.
C1>show ip ospf database external OSPF Router with ID (192.168.0.3) (Process ID 1) Type-5 AS External Link States LS age: 907 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 192.168.0.2 (External Network Number ) Advertising Router: 192.168.0.1 LS Seq Number: 80000001 Checksum: 0x2CBD Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 1 Forward Address: 10.0.0.2 External Route Tag: 65001
C1>show ip route 192.168.0.2 Routing entry for 192.168.0.2/32 Known via "ospf 1", distance 110, metric 1 Tag 65001, type extern 2, forward metric 2 Last update from 10.0.128.6 on GigabitEthernet0/2, 00:15:21 ago Routing Descriptor Blocks: 10.0.128.6, from 192.168.0.1, 00:15:21 ago, via GigabitEthernet0/2 Route metric is 1, traffic share count is 1 Route tag 65001 * 10.0.128.1, from 192.168.0.1, 00:15:21 ago, via GigabitEthernet0/1 Route metric is 1, traffic share count is 1 Route tag 65001
Problem solved? NO, OF COURSE NOT. You just made it worse:
- Even though it looks like everything works as expected, E1 is a single point of failure – if it crashes, you lose route redistribution, and thus connectivity to external destinations;
- The already-too-complex link-state routing protocol got another hard-to-figure-out quirk. See the passive interface gotcha above, and check all the complications T5 FA caused in OSPF route selection process (RFC 2328);
- You have to run OSPF on the external interface (at least with recent Cisco IOS releases) to make this kludge work. Not exactly the most secure design I’ve seen in my life (and please don’t even mention that you could use an ACL to filter incoming OSPF packets on the external interface before reading this blog post).
The proper design would be to run external routing protocol and route redistribution on both ASBRs (yeah, I know, the beauties of two-way redistribution), and tell everyone who complained about this deficiency of OSPF to get lost and fix his design.
Alas, that’s not how standards are made. No wonder academics are making fun of the complexities of distributed routing protocols (and backpedaling on their own ridiculous claims), and we’re continuously involved in YAK shaving exercises.
Oh, and just because we got this wonderful unnecessary knob in OSPF, debugging OSPF became even more interesting. Hooray!