In my initial OSPF Forwarding Address blog post, I described a common Forwarding Address (FA) use case (at least as preached on the Internet): two ASBRs connected to a single external subnet with route redistributing configured only on one of them.

That design is clearly broken from the reliability perspective, but are there other designs where OSPF FA might make sense?

Here’s another more convoluted design: two ASBRs are connected to the same external subnet implemented with Metro Ethernet. One ASBR has a 1 Gbps connection to the Metro Ethernet service; the other one has a 100 Mbps connection.

Fixing the errors of the previous broken design we’re running BGP on both ASBRs and redistributing BGP routes into OSPF on both of them. We have full redundancy, but suboptimal forwarding: C1 has two equal-cost paths to the external destination, while in reality, one of them has 10 times less bandwidth than the other one.

Here are the relevant parts of the OSPF topology database and IP routing table on C1:

C1#show ip ospf data external

            OSPF Router with ID (192.168.0.3) (Process ID 1)

    Type-5 AS External Link States

  LS age: 40
  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

  LS age: 25
  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.4
  LS Seq Number: 80000002
  Checksum: 0x8D64
  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

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 1
  Last update from 10.0.128.6 on GigabitEthernet0/2, 00:00:47 ago
  Routing Descriptor Blocks:
    10.0.128.6, from 192.168.0.4, 00:00:47 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:01:01 ago, via GigabitEthernet0/1
      Route metric is 1, traffic share count is 1
      Route tag 65001

Time for another MacGyver stunt:

• Enable OSPF on the (external) Metro Ethernet LAN that connects our OSPF network with a third-party router (yes, it’s a Really Bad Idea from the security perspective);
• Set OSPF costs (or bandwidth) correctly;
• Hope that ASBRs start advertising Forwarding Address in Type-5 LSA and route selection of internal OSPF routes makes sure only the faster path is used.

It actually works:

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.1 on GigabitEthernet0/1, 00:01:13 ago
  Routing Descriptor Blocks:
  * 10.0.128.1, from 192.168.0.4, 00:01:13 ago, via GigabitEthernet0/1
      Route metric is 1, traffic share count is 1
      Route tag 65001

We can also observe another interesting (as in how the **** did we ever get here) behavior:

• While both ASBRs advertised the Type-5 LSA before, after enabling OSPF on the external interface, only one of them advertises Type-5 LSA

C1#show ip ospf data external

            OSPF Router with ID (192.168.0.3) (Process ID 1)

    Type-5 AS External Link States

  LS age: 272
  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.4
  LS Seq Number: 80000003
  Checksum: 0x16CE
  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

• In our network, the Type-5 LSA is advertised by the ASBR that is never used for packet forwarding toward the external destination (I am positive there’s a section somewhere in OSPF RFC talking about higher ASBR router ID).

Hooray, we just saved the memory occupied by one Type-5 LSA, and yet again increased the complexity of the protocol.

Guess what: we didn’t need OSPF FA in the first place. The correct design would be to increase OSPF external metrics on E2 and use External Type 1 (E1) metrics so that the other OSPF routers would consider the total cost (internal + external) toward the external destinations. Alas, that’s not how real-life problems are solved (at least not in the CCIE lab).