کد:
http://blog.ipexpert.com/2009/11/11/ospf-type-4-lsa-the-forward-address-part-2/
PART-2
Welcome back everybody! Today we will be continuing our discussion on some of the internals of OSPF Type-4 LSAs and the forwarding-address. We will also be discussing an interesting feature known as forward-address suppression and see how it can actually dramatically change the flow of our traffic in OSPF. The diagram we will be working on is similar to the one used for part 1 of this blog, but modified to make it a bit more…interesting?
Notice that area 56 and area 65 are both NSSA. Here is a quick summary of what we are actually doing here with all this routing madness. R7 has a loopback of 7.7.7.7/32 which it only advertises into RIP. This RIP route will get redistributed into OSPF at R6 and injected into both area 56 and area 65 as a Type-7 LSA. R5 being the ABR will then convert the Type-7 LSA to a Type-5 LSA and inject it into the backbone. The fun and magic will come with the specifics and exactly what is happening behind the scenes.
The first thing we should understand is how things happen and look during normal redistribution into a regular old area – without all the NSSA area madness. To demonstrate this quickly, lets add loopback22 on R2 and redistribute it into OSPF. This should make R2 an ASBR, and we can see exactly how the LSA looks.
کد:
R2(config)#int lo22
R2(config-if)#ip add 22.22.22.22 255.255.255.255
R2(config-if)#route-map OSPF-Connected 10
R2(config-route-map)#match int lo22
R2(config-route-map)#router ospf 1
R2(config-router)#red conn sub route-map OSPF-Connected
Excellent…let’s see what that LSA looks like on R1 inside of area 12.
کد:
R1#sh ip ospf data ext 22.22.22.22
OSPF Router with ID (1.1.1.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 219
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 22.22.22.22 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0xB38C
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
OK. So what is going on here? R2 has become an ASBR. We see that R2 is the advertising router for the prefix 22.22.22.22/32 as expected. The thing we want to pay attention to here is the Forward Address. It is set to 0.0.0.0. What this means is that R1 will forward traffic for this prefix to the router that originated it – R2. Simple. Now, we will revert the config and see what happens with redistribution into a NSSA.
کد:
R2(config-router)#no redistribute conn
Now we will head over to R6 and see how things look when we redistribute RIP into the NSSAs.
کد:
R6(config-router)#router ospf 1
R6(config-router)#redistribute rip subnets
R5(config-router)#do sh ip route | i 7.7.7.7
O N2 7.7.7.7 [110/20] via 56.56.56.6, 00:00:01, FastEthernet0/0.56
R5(config-router)#do sh ip ospf data nssa 7.7.7.7
OSPF Router with ID (5.5.5.5) (Process ID 1)
Type-7 AS External Link States (Area 56)
Routing Bit Set on this LSA
LS age: 9
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 7.7.7.7 (External Network Number )
Advertising Router: 66.66.66.66
LS Seq Number: 80000002
Checksum: 0x77E0
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 6.6.6.6
External Route Tag: 0
Type-7 AS External Link States (Area 65)
LS age: 91
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 7.7.7.7 (External Network Number )
Advertising Router: 66.66.66.66
LS Seq Number: 80000001
Checksum: 0xCDD9
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 65.65.65.6
External Route Tag: 0
There are a few important things to note here. First off, we are receiving TWO NSSA Type-7 LSAs for the 7.7.7.7/32 prefix. This is normal and expected as we have two NSSA (area 56 and area 65). Notice the Type 7/5 translation is set. This means R6 is setting a bit in the LSA that instructs R5 (the ABR) to translate the NSSA Type-7 LSA into an external Type-5 LSA and inject it into the backbone. This is known as the P bit, and is set by default by the ASBR when it redistributes routes into an NSSA. We’ll also notice a significant change from the first example. The forwarding address for both Type-7 LSAs is no longer 0.0.0.0. The forward address is set to R6 in both cases. The rules for what you set the forward address to are outlined in RFC 3103. In summary, first it will choose the highest loopback that is on the ASBR and that is also being advertised into the area. If there is no loopback, it will go with the highest interface that is running OSPF and also advertised into the NSSA. This is why we see 6.6.6.6 for the first LSA and 65.65.65.6 for the second. 6.6.6.6 is a loopback on R6 and it is being advertised into NSSA 56. 65.65.65.6 is the highest available address on R6 that is participating in area 65. The question then becomes if we have two Type-7 LSAs with two different forward address values, which one gets injected into area 0? Let’s check out R2 for the answer.
کد:
R2(config-router)#do sh ip ospf data ext 7.7.7.7
OSPF Router with ID (2.2.2.2) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 875
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 7.7.7.7 (External Network Number )
Advertising Router: 5.5.5.5
LS Seq Number: 80000010
Checksum: 0x1D2C
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 6.6.6.6
External Route Tag: 0
There we have it. 6.6.6.6 won. Why? The first thing the router will do is check the metrics to those multiple forward addresses. In this case the metric will be 20 to both 6.6.6.6 and 65.65.65.6 because they are O N2 routes. Since the metric is tied, we go with lowest address. Another thing to be aware of here is that R5 is no longer just an ABR between area 0 , area 56 and area 65. It is now an ASBR as well because it is now generating Type-5 LSAs and injecting them (thats what an ASBR does by definition.) Therefore, some interesting things happen regarding our Type-4 LSA. Let’s look at R2.
کد:
R2(config-router)#do sh ip ospf data asbr
OSPF Router with ID (2.2.2.2) (Process ID 1)
Summary ASB Link States (Area 12)
LS age: 1444
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 5.5.5.5 (AS Boundary Router address)
Advertising Router: 2.2.2.2
LS Seq Number: 80000006
Checksum: 0xD00A
Length: 28
Network Mask: /0
TOS: 0 Metric: 64
Pay very close attention. The Type-4 LSA is ONLY present in area 12. There are NO Type-4 LSAs being injected into area 0. How then do routers inside of area 0 know how to get to R6 for routes like 7.7.7.7? They will go to R5 since R5 is now acting as an ASBR as well and actually is the one generating the LSAs going into area 0. Everybody in area 0 already knows how to get to R5s RID because R5 is itself part of area 0! In area 12 however, we still will need the Type-4 LSA because routers in area 12 know nothing about R5’s RID as it is in a separate area.
So far we have seen that the behavior of the forward address parameter is different depending on if you are redistributing into a normal area or a NSSA. Furthermore, we saw a little deeper into how the Type-4 LSA works. Now we will go further down the rabbit hole hehe…Since 6.6.6.6 won the battle on R5 for the right to be sent as the forward address into area 0, we should see 6.6.6.6 set as the forward address of the Type-5 external LSA on R1 and R2. Let’s check R1…
کد:
R1#sh ip ospf data ext 7.7.7.7 | i Forward
Forward Address: 6.6.6.6
Just as expected. Essentially this is saying “If you want to get to 7.7.7.7 you need to contact the ASBR over at 6.6.6.6.” In order for us to actually install the route in our routing table we need a valid intra or inter-area route for 6.6.6.6. Currently we have 6.6.6.6/32 as an inter-area route so we are golden. That means our ping traffic should go from R1 –> R2 –> R5 –> R6 –> R7
کد:
R1#ping 7.7.7.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R1#trace 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 12.12.12.2 0 msec 0 msec 0 msec
2 25.25.25.5 0 msec 0 msec 0 msec
3 56.56.56.6 4 msec 4 msec 4 msec
4 67.67.67.7 4 msec * 0 msec
So far so good! NOW…can we influence what the forward address gets set to? The answer is yes we can, and in multiple ways. We have already seen that the Type-7 LSA on R5 with the best metric to the ASBR will win the battle and be injected into the backbone. Take a look:
کد:
R5(config-router)#do sh ip ospf int brie
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo0 1 0 5.5.5.5/32 1 LOOP 0/0
Se0/2/0 1 0 25.25.25.5/24 64 P2P 1/1
Fa0/0.56 1 56 56.56.56.5/24 1 DR 1/1
Fa0/0.65 1 65 65.65.65.5/24 10 DR 1/1
R5(config-router)#do sh ip ospf border
OSPF Process 1 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 2.2.2.2 [64] via 25.25.25.2, Serial0/2/0, ABR, Area 0, SPF 17
i 66.66.66.66 [1] via 56.56.56.6, FastEthernet0/0.56, ASBR, Area 56, SPF 15
i 66.66.66.66 [10] via 65.65.65.6, FastEthernet0/0.65, ASBR, Area 65, SPF 14
Did you catch the cost difference? Fa0/0.56 has a cost of 1 while Fa0/0.65 has a cost of 10. Because Fa0/0.56 has the lower metric to get to the ASBR we advertise the forward address as whatever we learned on Fa0/0.56 (6.6.6.6). What if we change things around?
کد:
R5(config-router)#int fa0/0.56
R5(config-subif)#ip ospf cost 10
R5(config-subif)#int fa0/0.65
R5(config-subif)#ip ospf cost 1
R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward Address
Forward Address: 65.65.65.6
By simply modifying the cost of a link, we have altered where things should be heading! In this case it won’t really affect the routing path, but in certain situations it could. Are there other things we can do? Of course! The second thing we can do is this: If you make the interface on the ASBR (R6) that is facing the outside AS (RIP in this case) part of the OSPF process itself, things will change as well.
کد:
R6(config-if)#router ospf 1
R6(config-router)#pass def
R6(config-router)#no pass fa0/0.56
R6(config-router)#no pass fa0/0.65
R6(config-router)#network 67.67.67.6 0.0.0.0 area 65
What we should see at this point is that on R5 and thus R1 and R2 the forward address is now set to R6’s interface facing the RIP domain!
کد:
R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward
Forward Address: 67.67.67.6
This makes things veeeeeeerrrrry interesting! Right now, we have a route to 67.67.67.6 via R5, so things would not really be altered. What if we knew about 67.67.67.6 another way though? Let’s advertise the 67.67.67.0/24 network into OSPF on R7. Keep in mind this means that we are advertising the same prefix into two different areas at the same time – On R6 we are injecting it into area 56 and on R7 we are injecting it into area 0. This means that from the perspective of R2 we will prefer the route from R7 over VLAN 27. It is an intra-area route VS an inter-area route from area 56.
کد:
R7(config-if)#int fa0/0
R7(config-if)#ip ospf 1 area 0
Check things out on R6…
کد:
R2(config-router)#do sh ip route | i 67.67.67.0
O 67.67.67.0 [110/2] via 27.27.27.7, 02:27:31, FastEthernet1/1
Guess what? The 7.7.7.7/32 still has a forward address of 67.67.67.6. We now know about 67.67.67.6 through another path over VLAN 27. In theory, we just completely altered the path of our packets through the network! Watch this…
کد:
R1#sh ip ospf data ext 7.7.7.7 | i Forward
Forward Address: 67.67.67.6
R1#trace 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 12.12.12.2 0 msec 4 msec 0 msec
2 27.27.27.7 4 msec * 0 msec
WOW! Look at that! We are now taking the path R1 –> R2 –> R7 instead!!! Now here is the REAL kicker. There is a little known feature in OSPF known as forward-address suppression and it is specific for NSSA ABRs. Imagine what would happen if R1 and R2 had no way to reach 67.67.67.0. What would happen is we may have the LSAs in the LSDB but the route would never get put into the RIB. The forward-address suppression feature is a way around this. Essentially what it does is tell the ABR of the NSSA that is injecting the Type-5 LSAs to set the forward-address to 0.0.0.0. When the other routers get the LSA they will then forward to R5 instead of 67.67.67.6. Clearly this can COMPLETELY alter our routing path without changing ANY metrics or anything. Cool huh? Let’s see it in action.
BEFORE:
کد:
R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward
Forward Address: 67.67.67.6
R2(config-router)#do trace 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 27.27.27.7 4 msec * 0 msec
R5(config-router)#area 65 nssa translate type7 ?
suppress-fa Suppress forwarding address in translated LSAs
R5(config-router)#area 65 nssa translate type7 suppress-fa
AFTER:
کد:
R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward
Forward Address: 0.0.0.0
R2(config-router)#do trace 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 25.25.25.5 4 msec 0 msec 0 msec
2 65.65.65.6 4 msec 4 msec 4 msec
3 67.67.67.7 4 msec * 0 msec
That about does it for today guys!!! I really hope you all enjoyed the article and got something out of it! I will be talking to you all soon :P
Regards,
Joe Astorino CCIE #24347 (R&S)
Sr. Technical Instructor – IPexpert
LinkBack URL
About LinkBacks
