OSPF Ninja Filtering — Hacking The Forward Address

Introduction

Hello everybody! In today’s blog, we are going to be diving deep into OSPF and discovering another very subtle way to do route filtering in a specific situation.  I call this blog OSPF “ninja filtering” because the method we are going to use is very subtle, and one would have to know exactly what they are doing to identify it.  It’s a very “stealthy” technique.  You know what that means?  It is an awesome choice for CCIE training vendors and CCIE lab proctors with regards to your troubleshooting or configuration portion of the CCIE lab exam : )

Let’s have a look at the diagram for today.  We will be building off of the diagram we used earlier when we discussed the OSPF Type 5 LSA Forward Address

As you can see, we have OSPF area 0 running between R2, R4 and R5 and we have RIP running between R4 and Cat3.  Cat3 advertises it’s Lo0 interface 33.33.33.33/32 into RIP.  R4 will do mutual redistribution between RIP and OSPF.  Before we get into our filtering, let’s just look around on R5 and make sure we do have reachability

R5#sh ip route ospf
     34.0.0.0/24 is subnetted, 1 subnets
O E2    34.34.34.0 [110/20] via 192.168.45.4, 00:00:28, Serial2/0
     33.0.0.0/32 is subnetted, 1 subnets
O E2    33.33.33.33 [110/20] via 192.168.45.4, 00:00:28, Serial2/0
O    192.168.24.0/24 [110/65] via 192.168.45.4, 00:00:28, Serial2/0
                     [110/65] via 192.168.25.2, 00:00:28, Serial2/1
R5#
R5#sh ip ospf database external 33.33.33.33

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1472
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 33.33.33.33 (External Network Number )
  Advertising Router: 192.168.45.4
  LS Seq Number: 80000001
  Checksum: 0x93ED
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

R5#
R5#ping 33.33.33.33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 33.33.33.33, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms

Great, everything works! Now, let’s break it : ) Before we do that, let’s examine a few things. In the above output, notice that the forward address of the external type 5 LSA for 33.33.33.33/32 is set to 0.0.0.0. What does this mean? This is completely normal. When an ASBR (R4) redistributes routes into OSPF it will typically set the forward address to be itself by setting this field to 0.0.0.0. This is essentially telling everybody else in the OSPF domain that “If you want to get to this external route, go through me.” Keep in mind that this “normal” behavior of setting the forward address to 0.0.0.0 assumes we are not working with an OSPF NSSA which gets a little more “interesting”. See rfc3101 for more information on the forward address with respect to a NSSA

Ninja Filtering External Routes

Now, what if for some reason we don’t actually want OSPF area 0 to see our 33.33.33.33/32 loopback route?  Don’t redistribute it? Naw, that is too easy.  Distribute-List? Sloppy. Route-Map on our RIP –> OSPF redistribution? Not today. Today, we are going to do it the ninja way.  The way that will have CCIE candidates banging their heads into the wall in a troubleshooting exam…today my friends, we will do this by mucking around with the OSPF forward address in the external LSA.  How?

First, we’ll manipulate the forward address itself.  In order to get R4 to inject the LSA with a “non-zero” forward address we need to run OSPF on the R4/Cat3 link. There are other requirements, that you can read about hereNote that the IP address on Cat3 Fa0/4 is 34.34.34.33/24.

R4(config)#router ospf 1
R4(config-router)#network 34.34.34.4 0.0.0.0 area 0
R5#sh ip ospf database external 33.33.33.33

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 27
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 33.33.33.33 (External Network Number )
  Advertising Router: 192.168.45.4
  LS Seq Number: 80000003
  Checksum: 0x2CCB
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 34.34.34.33
        External Route Tag: 0

R5#sh ip route ospf
     34.0.0.0/24 is subnetted, 1 subnets
O       34.34.34.0 [110/74] via 192.168.45.4, 00:02:54, Serial2/0
     33.0.0.0/32 is subnetted, 1 subnets
O E2    33.33.33.33 [110/20] via 192.168.45.4, 00:02:54, Serial2/0
O    192.168.24.0/24 [110/65] via 192.168.45.4, 00:02:54, Serial2/0
                     [110/65] via 192.168.25.2, 00:02:54, Serial2/1

Nice! Notice that the forward address is now Cat3, 34.34.34.33. Now, here is the ninja filtering catch here. There is a rule in OSPF that says if a router receives an LSA with a non-zero forwarding address that router needs to have either an intra or inter-area route to that forwarding address. If it doesn’t the LSA will stick around but the route will NEVER BE INJECTED INTO THE ROUTING TABLE!

So, how do we make the forward address 34.34.34.33 go away? If we redistribute 34.34.34.0/24 into OSPF instead of advertising it directly with the network command, the forward address will be set back to 0.0.0.0 so that is out. We could use a distribute-list on R5 but that is nowhere near as fun. We would have to do that same thing on every OSPF router in area 0 to filter the route entirely. Here is a stealthier way — Let’s throw 34.34.34.4 on R4 into OSPF area 1 instead. Then we will do inter-area filtering between area 0 and area 1 and prevent the 34.34.34.0/24 prefix from getting into area 0

R4(config)#ip prefix-list ninja deny 34.34.34.0/24
R4(config)#ip prefix-list ninja permit 0.0.0.0/0 le 32

R4(config)#router ospf 1
R4(config-router)#no network 34.34.34.4 0.0.0.0 area 0
R4(config-router)#network 34.34.34.4 0.0.0.0 area 1
R4(config-router)#area 0 filter-list prefix ninja in

Now let’s see R5’s LSDB again

R5#sh ip ospf database external 33.33.33.33

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

                Type-5 AS External Link States

  LS age: 177
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 33.33.33.33 (External Network Number )
  Advertising Router: 192.168.45.4
  LS Seq Number: 80000005
  Checksum: 0x28CD
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 34.34.34.33
        External Route Tag: 0

The forward address is still set to 34.34.34.33 as expected…but do we have a route for that forward address anymore?

R5#sh ip route 34.34.34.33
% Network not in table

Nope. How about a route for 33.33.33.33/32?

R5#sh ip route 33.33.33.33
% Network not in table

Nope…ninja vanish! Now, imagine you are in the lab or in a real world situation on R2 or R5. You definitely see an OSPF type 5 external LSA for your route…it is right there staring you in the face…yet you don’t have a route in your routing table. Remember to think through the process and check out the forward address!

Summary

When an OSPF router receives a type 5 external LSA with a non-zero forwarding address, the router must have an intra or inter-area route to that forwarding address.  If it doesn’t, it will never install the route into the routing table.  The characteristic of setting a zero or non-zero forward address is set on the ASBR during redistribution.  The “normal” behavior is to set a zero forward address (0.0.0.0) indicating the next hop is the ASBR itself.  However, as we have seen that can be manipulated in specific circumstances

Keep studying hard my friends!

5 Comments

Leave a Reply