OSFP Forwarding Address Part II: Redistribution and filtering don’t get along very well

Hoping you all enjoyed the first part of the OSPF forwarding address saga, I’m back with the promise to make things clear regarding a nicely built redistribution case. I’m not sure if you’ve ever come across it, or ever will, but it’s interesting because it explains why we need the rules to set the forward address (if you don’t remember them, you can take a look at Part I).

Let’s see what I’m talking about. Remember the second topology from Part I? Long story short, I tried to break it. Managed to partially do it, though I am still thinking of a way to make things worse, if possible :). The following setup consists in the starting point of Part II:

ospf_2_1

Initially, R2’s and R3’s interfaces towards R0 are included in area 0, in order for them to fulfill all the conditions to set the forwarding address in their T5 LSA. The snippets below show the initial state:

R1#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa1/0           1          0               10.10.13.1/24            1        DR    1/1
Fa0/0          1          0               10.10.12.1/24            1        DR    1/1

R2#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa1/0          1        0                  10.10.20.1/24           1        BDR   1/1
Fa0/0         1        0                  10.10.12.2/24           1        BDR   1/1

R3#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0          1         0                  10.10.20.3/24         1       DR     1/1
Fa1/0           1         0                  10.10.13.3/24         1       BDR   1/1

R2#show running-config | section router ospf
router ospf 1
redistribute static subnets

R3# show running-config | section router ospf
router ospf 1
redistribute static subnets

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3               1   FULL/BDR        00:00:36    10.10.13.3      FastEthernet1/0
2.2.2.2               1   FULL/BDR        00:00:34    10.10.12.2      FastEthernet0/0

R2#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3              1   FULL/DR         00:00:38    10.10.20.3      FastEthernet1/0
1.1.1.1                1   FULL/DR         00:00:35    10.10.12.1      FastEthernet0/0

Looking at the area 0 OSPF database, we can see the following:

R1#sh ip ospf data
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         958         0x80000006 0x007619 2
2.2.2.2         2.2.2.2         337         0x8000000B 0x00EE80 2
3.3.3.3         3.3.3.3         336         0x80000010 0x00FC60 2
Net Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum
10.10.12.1      1.1.1.1         958         0x80000002 0x007C8B
10.10.13.1      1.1.1.1         1205        0x80000002 0x00A35F
10.10.20.3      3.3.3.3         336         0x80000001 0x001AD4
Type-5 AS External Link States
Link ID         ADV Router      Age         Seq#       Checksum Tag
100.100.100.100 3.3.3.3         1023        0x8000000C 0x004B85 0
200.200.200.200 3.3.3.3         1021        0x80000002 0x0055F3 0

For both of its static routes, R3 generates a T5 LSA, with FA = 10.10.20.254:

R1#sh0w ip ospf database external
OSPF Router with ID (1.1.1.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 336
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 100.100.100.100 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 8000000D
Checksum: 0x4986
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.10.20.254
External Route Tag: 0

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 336
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 200.200.200.200 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000003
Checksum: 0x53F4
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.10.20.254
External Route Tag: 0

We should see the T5 LSA for 100.100.100.100/32 generated by R2 as well. Remember why it’s missing? Because if both routers, for the same prefix, set the same forwarding address, only one will generate the T5 LSA, as we’ve already seen. So R1 sees the 2 external LSAs, for the 2 prefixes, as generated by R3.

Let’s look at R1’s routing table now:

R1#show ip route

1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        10.10.12.0/24 is directly connected, FastEthernet0/0
L        10.10.12.1/32 is directly connected, FastEthernet0/0
C        10.10.13.0/24 is directly connected, FastEthernet1/0
L        10.10.13.1/32 is directly connected, FastEthernet1/0
O        10.10.20.0/24 [110/2] via 10.10.13.3, 00:19:12, FastEthernet1/0
                                      [110/2] via 10.10.12.2, 00:18:31, FastEthernet0/0
100.0.0.0/32 is subnetted, 1 subnets
O E2     100.100.100.100 [110/20] via 10.10.13.3, 00:19:12, FastEthernet1/0
                                              [110/20] via 10.10.12.2, 00:29:58, FastEthernet0/0
200.200.200.0/32 is subnetted, 1 subnets
O E2     200.200.200.200 [110/20] via 10.10.13.3, 00:19:12, FastEthernet1/0
                                                [110/20] via 10.10.12.2, 00:29:58, FastEthernet0/0

It seems that R1’s load balancing traffic destined for both loopbacks using both ABRs, which is perfectly fine according to the RFC:

“If the forwarding address is non-zero, look up the forwarding address in the routing table. The matching routing table entry must specify an intra-area or inter-area path…” RFC 2328, section 16.4

So if R1 does ECMP for the FA, so it will do for the routes themselves. You may now think “that’s wrong because R2 does not have a static route to LoopbackY (according to our configuration)”. Well, it’s not that wrong, because R2 knows about LoopbackY from R3’s Type 5 LSA (database within an area is consistent on all routers). Indeed, R2’s routing to 200.200.200.200/32 via OSPF:

R2#show ip route

2.0.0.0/32 is subnetted, 1 subnets
C        2.2.2.2 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        10.10.12.0/24 is directly connected, FastEthernet0/0
L        10.10.12.2/32 is directly connected, FastEthernet0/0
O        10.10.13.0/24 [110/2] via 10.10.20.3, 00:29:23, FastEthernet1/0
[110/2] via 10.10.12.1, 00:30:26, FastEthernet0/0
C        10.10.20.0/24 is directly connected, FastEthernet1/0
L        10.10.20.1/32 is directly connected, FastEthernet1/0
100.0.0.0/32 is subnetted, 1 subnets
S        100.100.100.100 [1/0] via 10.10.20.254
200.200.200.0/32 is subnetted, 1 subnets
O E2     200.200.200.200 [110/20] via 10.10.20.254, 00:30:21, FastEthernet1/0

Nice thing is that the next hop for the route is actually the forwarding address in the T5 LSA, 10.10.20.254. That is because R2 sees the forwarding address as directly connected. So, all good, traffic flows as expected:

R1#traceroute 200.200.200.200 probe 10
Type escape sequence to abort.
Tracing the route to 200.200.200.200
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.12.2 32 msec
10.10.13.3 52 msec
10.10.12.2 28 msec
10.10.13.3 20 msec
10.10.12.2 32 msec
10.10.13.3 20 msec
10.10.12.2 20 msec
10.10.13.3 16 msec
10.10.12.2 16 msec
10.10.13.3 12 msec
2 10.10.20.254 64 msec 48 msec 44 msec 36 msec 32 msec 20 msec 32 msec 20 msec 32 msec 32 msec

What can we try now? Well, let’s change the area on R2’s and R3’s interfaces towards R0, from area 0 to area 1. This should only lead to the fact that 10.10.20.0/24 will be seen as an inter-area prefix, not as an intra-area prefix, but this still complies with the rules to use T5 LSAs that have the FA set (FA should be reachable via intra- or inter-area routes)

ospf_2_2

Area 0 database slightly changed, Type4 LSAs being generated for the 2 ASBRs by the 2 ABRs.

Key points here are:

  1. ABR R3 generates T4 LSA for ASBR R2 and ABR R2 generates T4 LSA for ASBR R3. That is somewhat fair, as otherwise ABR R2 would say “you can reach ASBR R2 via R2” and R3 would say the same. Cool right?
  2. Also, there is the fact that T4 LSAs are generated for both ASBRs, even though only ASBR R3 generates T5 LSAs.

R1#show ip ospf database

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

Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         137         0x80000008 0x00721B 2
2.2.2.2         2.2.2.2         145         0x8000000D 0x00F0DF 1
3.3.3.3         3.3.3.3         29          0x80000013 0x00BC03 1

Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.12.1      1.1.1.1         137         0x80000004 0x00788D
10.10.13.1      1.1.1.1         137         0x80000004 0x009F61

Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.20.0      2.2.2.2         141         0x80000001 0x007F8C
10.10.20.0      3.3.3.3         25          0x80000001 0x0061A6

Summary ASB Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
2.2.2.2         3.3.3.3         25          0x80000001 0x00CE58
3.3.3.3         2.2.2.2         25          0x80000003 0x00BA6A

Type-5 AS External Link States

Link ID                     ADV Router      Age         Seq#       Checksum Tag
100.100.100.100     3.3.3.3         29          0x8000000E 0x004787 0
200.200.200.200   3.3.3.3         28          0x80000004 0x0051F5 0

Now, another really interesting thing. Let’s say ABR R2 advertises a summary into Area 0, so instead of advertising 10.10.20.0/24, it will summarize that to 10.10.0.0/16 for example. R1 will have an O IA route to 10.10.20.0/24 via R3, and an O IA route to 10.10.0.0/16 via R2. When looking at the FA in the T5 LSA, R1 will match that against the longest match in the routing table, which is the route via R3. So, no ECMP towards the FA, no ECMP towards 100.100.100.100/32 or 200.200.200.200/32

R1#show ip route
1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
O IA     10.10.0.0/16 [110/2] via 10.10.12.2, 00:00:45, FastEthernet0/0
C        10.10.12.0/24 is directly connected, FastEthernet0/0
L        10.10.12.1/32 is directly connected, FastEthernet0/0
C        10.10.13.0/24 is directly connected, FastEthernet1/0
L        10.10.13.1/32 is directly connected, FastEthernet1/0
O IA     10.10.20.0/24 [110/2] via 10.10.13.3, 00:10:08, FastEthernet1/0
100.0.0.0/32 is subnetted, 1 subnets
O E2     100.100.100.100 [110/20] via 10.10.13.3, 00:10:03, FastEthernet1/0
200.200.200.0/32 is subnetted, 1 subnets
O E2     200.200.200.200 [110/20] via 10.10.13.3, 00:10:03, FastEthernet1/0

What if now R3 advertises the same summary into area 0 as R2, meaning 10.10.0.0/16? Well, as you can imagine, ECMP will work again.

Let’s break it now. On R2 and R3 we’ll summarize but with the not-advertise option

R2/R3(config)#router ospf 1
R2/R3(config-router)#area 1 range 10.10.0.0 255.255.0.0 not-advertise

R1 is now in trouble. No external routes, no inter-area routes. Though it has the LSAs, the routing bit is not set on either of them because it has no valid path to the FA.

R1#
1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.10.12.0/24 is directly connected, FastEthernet0/0
L        10.10.12.1/32 is directly connected, FastEthernet0/0
C        10.10.13.0/24 is directly connected, FastEthernet1/0
L        10.10.13.1/32 is directly connected, FastEthernet1/0

R1#show ip ospf database external

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

Type-5 AS External Link States

LS age: 1858
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 100.100.100.100 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000013
Checksum: 0x3D8C
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.10.20.254
External Route Tag: 0

LS age: 1858
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 200.200.200.200 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000009
Checksum: 0x47FA
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 10.10.20.254
External Route Tag: 0

If you can think of other ways to break the topology, let me know!

Cheers

Facebook Comments
Rating

2 thoughts on “OSFP Forwarding Address Part II: Redistribution and filtering don’t get along very well”

Leave a Reply to Alexandru-Horia Sîrmache Cancel reply