OSPF The Ultimate CCIE Enterprise and Infrastructure Exam

Citation preview

Description:  

OSPF Routing Protocol is a big topic in CCIE Enterprise exam, This workbook is written and dedicated for people and candidates who prepare the CCIE Enterprise Exam and looking for an ultimate preparation after finishing studying, looking a way to acquire additional atypical scenarios and an indepth lecture of the most important OSPF's concept related to the exam such as LSA Types and LSDB which are the core component of OSPF, path selection through regular area and non-regular area, route filtering and some advanced features such as stub router, prefix suppression, forwarding address etc...this workbook gives you the opportunity to definitely master this important topic before passing the CCIE Exam by acquiring a solid skills and learn another view of OSPF, understand what inside OSPF's behavior, what happen and why this happen, How to override a problem of suboptimal routing, routing loop or path selection using uncommon solution and atypical tricks that you will not find elsewhere.  

By traveling through the scenarios involved in the workbook and by reproducing them using the basic configuration at the top of each lab, you will be able to fully understand and master this topic with 30 practice labs explained with atypical method so that any OSPF topic in the CCIE Exam will be easy to answer.  

Goals and Methods:  

The most important goal of this book is provide candidates of CCIE Enterprise and Infrastructure Exam scenarios and Hands of Labs with high level for Exam about OSPF Routing Protocol, the method and the proposed scenarios help you to definitely master this topic before taking the exam, this is an ultimate preparation to enforce your skills and to acquire solid knownledges after attending a global preparation or in depth bootcamp, and you want to be comfortable with this big topic. This book consists of a series of practical scenarios with challenges and with explanations of the most misunderstanding OSPF's behavior, when I talk OSPF's behavior, I mean all OSPF topics related to the exams such as: LSA Types, Area Types, Network Types OSPF Path Selection, Route Filtering, Forwarding Address, Prefix Suppression, Loop-Free Alternate, Summary Routes and so on.  

After publishing my first book titled "OSPF Demystified With RFC with more than 80 labs and scenarios and awarded as one of the best ebook by BookAuthority, I conclude that Understanding OSPF behavior is very important to be efficient in the CCIE Exams for two reasons:  

To be able to troubleshoot any problem by reasoning. To be able to answer challenges that requires only one command.

 

For this purpose, this book provides you challenges where you will learn:  

How to follow some logic to detect any problem or to explain an unexpected behavior. How to fix it with some restrictions such as: you are not allowed to use cost and so on.

 

Understanding OSPF needs atypical and uncommon explanations, useful and appropriate show commands and debug commands rather than showing just routing tables or LSDB tables.  

As you read this book, you definitely get a feeling of, "This is how a feature works", "This is how to understand a behavior" and "This is how to solve a problem" which are exactly what you need for the Cisco CCIE Enterprise and Infrastructure Exams.  

How to read this book?  

This book is a series of hands of labs, and there is no relationship between them, you can start at any lab, from the last, the first or the middle, the purpose is to provide you a granularity to freely switch between topics and go to the one you need in depth lecture and understanding.  

About the Author:  

Redouane MEDDANE is 3xCCNP Collaboration, Security and Enterprise certified and he is a published author of some of the most important OSPF Protocol, Security and Collaboration books in the world titled: OSPF Demystified With RFC, Network Security All-in-one, and Dial Plan and Call Routing Demystified on CUCM, Cisco Meeting Server Deploy Implement Maintain Cisco Collaboration Conferencing. He is also a blogger at ipdemystify.com and writes articles about collaboration and security to demystify the most complex topics.                                            

Table of Content

Lab 1: OSPFv2 Link State Database LSDB In depth Exploration Lab 2: OSPFv3 Link State Database LSDB In depth Exploration Lab 3: OSPF Network Types P2P P2M and Broadcast Lab 4: OSPF Network Type P2M and Broadcast with Type-2 LSA Lab 6: Stub and Totally Stub Area Types Lab 7: NSSA Area Type In depth Exploration Lab 8: NSSA Area Type Filtering Options Lab 9: NSSA ABRs translator Condition Lab 10: Path Selection Scenario 1 Lab 11: Path Selection Scenario 2 Lab 12: Path Selection Scenario 3 Lab 13: Path Selection Scenario 4 Lab 14: Forwarding Address Scenario 1 Lab 15: Forwarding Address Scenario 2 Lab 16: Forwarding Address Scenario 3 Lab 17: Route Filtering Scenario 1 Lab 18: Route Filtering Scenario 2 Lab 19: Route Filtering Scenario 3

Lab 20: Route Filtering Scenario 4 Lab 21: OSPFv2 RFC 6860 Hiding Transit-Only Networks Lab 22: OSPFv3 RFC 6860 Hiding Transit-Only Networks Lab 23: OSPF TTL security check Lab 24: Stub router advertisement Graceful Shutdown Lab 25: OSPF Link-State Database Overload Protection Lab 26: OSPF Refresh and Flooding Reduction in Stable Topologies Lab 27: OSPF SPF Throttling Lab 28: Inter-Area Summary route lowest cost and highest cost Lab 29: OSPF Loop-Free Alternate LFA Fast Reroute FRR Lab 30: Capability Transit feature and routing loop    

Lab 1: OSPFv2 Link State Database LSDB In depth Exploration  

Note: The topology is hidden for this Lab   Understanding the LSDB of OSPF is very important to understand and master this protocol, a good analyzing of this LSDB help you to draw the topology without having any idea about the number of routers, the number of areas. the type of link and the ip addressing etc...   In this example, you receive the outputs of the show ip ospf data router and the show ip ospf data network commands of all routers and you are asked to draw the topology.   I have now the outputs of 4 fours routers: R1, R2, R3 and R4.   The first step is to identify the ABRs by looking which Type-1 LSA carry the B-bit. This bit is used and set by a router to identify itself as ABR. The ABR is the central point.   The show ip ospf database router on R3 shown that R3 is receiving two Type-1 LSAs in area 0 and two Type-1 LSAs in area 2.   In area 0 there are: -One Type-1 LSA with Advertising Router: 101.0.0.2 -One Type-1 LSA Advertising Router: 101.0.0.3   In area 2 there are: -One Type-1 LSA with Advertising Router: 101.0.0.2 -One Type-1 LSA with Advertising Router: 102.0.0.3   To identify the Type-1 LSAs self generated, in other words the Type-1 LSAs’S R3, looks the first line in the show ipospf database router output “OSPF Router with ID (101.0.0.2) (Process ID 1)”.   The line tells that the router-ID of R3 is 101.0.0.2 and since the Advertising Router field of Type-1 LSA is always the router-ID that generates this LSA, we can conclude that the Type-1 LSAs with the Advertising Router: 101.0.0.2 are the LSAs originated by R2.   Since we have identified the Type-1 LSAs of R3, we have to look the field “Area Border Router” and notice that the line is present in the self-generated LSA 1 for area 0 and area 1, this means that the B-bit is set by R3 to identify itself as ABR (B means Border). Keep in mind that since we have seen two Type-1 LSA for area 1 and area 0, this means automatically that R3 is an ABR, the Type-1 has area flooding scope and an ABR creates a separate and unique Type-1 LSA with the same Link-State ID and Advertising Router Field but they carry different informations about the prefixes and type links.  

R3#show ip ospf database router OSPF Router with ID (101.0.0.2) (Process ID 1) Router Link States (Area 0) LS age: 500 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 101.0.0.2 Advertising Router: 101.0.0.2 LS Seq Number: 80000009 Checksum: 0xEBCE Length: 48 Area Border Router----B-bit is set in Type-1 of area 0 this means R3 is an ABR Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.2.2 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 101.0.0.2 (Link Data) Router Interface address: 101.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 1 Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 406 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 101.0.0.3 Advertising Router: 101.0.0.3 LS Seq Number: 80000002 Checksum: 0x652B Length: 36 Area Border Router Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 101.0.0.2 (Link Data) Router Interface address: 101.0.0.3 Number of MTID metrics: 0 TOS 0 Metrics: 1 Router Link States (Area 2) LS age: 253 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 101.0.0.2 Advertising Router: 101.0.0.2 LS Seq Number: 80000006 Checksum: 0x6F28 Length: 48 Area Border Router----B-bit is set in Type-1 of area 2 this means R3 is an ABR Number of Links: 2 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 102.0.0.3 (Link Data) Router Interface address: 102.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 102.0.0.0 (Link Data) Network Mask: 255.255.255.0

Number of MTID metrics: 0 TOS 0 Metrics: 64 LS age: 236 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 102.0.0.3 Advertising Router: 102.0.0.3 LS Seq Number: 80000003 Checksum: 0xD3F2 Length: 60 Number of Links: 3 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.1.3 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 101.0.0.2 (Link Data) Router Interface address: 102.0.0.3 Number of MTID metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 102.0.0.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 64 R3#   The show ip ospf database router on R2 shown that R2 is receiving two Type-1 LSAs in area 0 and two Type-1 LSAs in area 1.   In area 0 there are: -One Type-1 LSA with Advertising Router: 101.0.0.2 -One Type-1 LSA Advertising Router: 101.0.0.3   In area 1 there are: -One Type-1 LSA with Advertising Router: 100.0.0.2 -One Type-1 LSA with Advertising Router: 101.0.0.3   To identify the Type-1 LSAs self generated, in other words the Type-1 LSAs’S R2, looks the first line in the show ipospf database router output “OSPF Router with ID (101.0.0.3) (Process ID 1)”.   The line tells that the router-ID of R2 is 101.0.0.3 and since the Advertising Router field of Type-1 LSA is always the router-ID that generates this LSA, we can conclude that the Type-1 LSAs with the Advertising Router: 101.0.0.3 are the LSAs originated by R2.   Since we have identified the Type-1 LSAs of R2, we have to look the field “Area Border Router” and notice that the line is present in the self-generated LSA 1 for area 0 and area 1, this means that the B-bit is set by R2 to identify itself as ABR (B means Border). Keep in mind that since we have seen two Type-1 LSA for area 1 and area 0, this means automatically that R2 is an ABR, the Type-1 has area flooding scope and an ABR creates a separate and unique Type-1 LSA with the same Link-State ID and Advertising Router Field.   R2#show ip ospf database router OSPF Router with ID (101.0.0.3) (Process ID 1) Router Link States (Area 0) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 391 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 101.0.0.2

Advertising Router: 101.0.0.2 LS Seq Number: 80000009 Checksum: 0xEBCE Length: 48 Area Border Router Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.2.2 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 101.0.0.2 (Link Data) Router Interface address: 101.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 1 LS age: 296 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 101.0.0.3 Advertising Router: 101.0.0.3 LS Seq Number: 80000002 Checksum: 0x652B Length: 36 Area Border Router----B-bit is set in Type-1 of area 0 this means R2 is an ABR Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 101.0.0.2 (Link Data) Router Interface address: 101.0.0.3 Number of MTID metrics: 0 TOS 0 Metrics: 1 Router Link States (Area 1) LS age: 208 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 100.0.0.2 Advertising Router: 100.0.0.2 LS Seq Number: 80000002 Checksum: 0x1FA2 Length: 48 Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.4.4 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 100.0.0.3 (Link Data) Router Interface address: 100.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 1 LS age: 199 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 101.0.0.3 Advertising Router: 101.0.0.3 LS Seq Number: 80000004 Checksum: 0xFEBC

Length: 48 Area Border Router----B-bit is set in Type-1 of area 1 this means R2 is an ABR Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.3.3 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 100.0.0.3 (Link Data) Router Interface address: 100.0.0.3 Number of MTID metrics: 0 TOS 0 Metrics: 1 R2#   Since R2 and R3 are identified as ABR, they can be either directly connected or not directly connected, this information is given by the Type-1 LSA by looking the Link Type.   By definition The LSA Type 1 (Router LSA) describes states of the links connected to a router in a particular area,such as its stub interfaces and links to adjacent OSPF routers and virtual links, and transit networks where a DR is elected.   The Type-1 LSA carry four Link Type as shown in the table below:   Link Type Description       Link ID 1       Point-to-point link Neighbor Router ID 2       Link to transit network Interface address of DR 3       Link to Stub network IP network number 4       Virtual Link Neighbor Router ID   By definition:   When a DR generates a Type-1 LSA, Link ID of Link Type 2 (Designated Router address) is set to IP interface address of the attached interface's DR. And the Link Data (Router Interface address) is set to its own IP interface address. In other words the Link ID is equal to the Link Data.   When a BDR or Drother generates a Type-1 LSA, the Link ID (Designated Router address) is set to IP interface address of the attached interface's DR. And Link Data (Router Interface address) is set to its own IP interface address   Below the section of the Links Type in the Type-1 LSA created by R2 and R3 in area 0:   R3 has a Link Type 3 (connected to Stub Network). A router generates an LSA Type 1 with a Type-3 link (stub network) even if it has no OSPF router neighborsfor each stub interface where OSPF is enabled. Also in the type-3 link, the mask of the subnet directly connected is listed in the Link Data (255.255.255.255)field and the Subnet number is listed in the Link ID (172.16.2.2). Also Both ABRs has Link Type 2 or Link to Transit Network, this means that the two routers R2 and R3 are connected through a segment where a DR is elected.   R3 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.2.2 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 101.0.0.2 (Link Data) Router Interface address: 101.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 1

  R2: Link connected to: a Transit Network (Link ID) Designated Router address: 101.0.0.2 (Link Data) Router Interface address: 101.0.0.3 Number of MTID metrics: 0 TOS 0 Metrics: 1   On R3 the Link Type 2 has the following information:   1-Link ID (Designated Router address) set to IP interface address of the attached interface's DR (101.0.0.2). 2-Link Data (Router Interface address) set to its own IP interface address (101.0.0.2) in the Transit Network. Of course the Link ID and the Link Data are the same IP address, so R3 is the DR!!! On R2 the Link Type 2 has the following information:   1-Link ID (Designated Router address) set to IP interface address of the attached interface's DR (101.0.0.2). 2-Link Data (Router Interface address) set to its own IP interface address (101.0.0.3) in the Transit Network. The Link ID and Link Data are not the same IP address and R2 sees the Router with IP address 101.0.0.2 (Link ID) which is R3 as a DR.   So we have R2 connected directly to R3 and an election of DR has occurred. In this segment: R2 has the IP address of 101.0.0.3. R3 has the IP address of 101.0.0.2.   To deduce the subnet of the link between R2 and R3 we should have an information of the mask, in a transit segment where a DR is elected, the subnet mask of the transit network is carried through the Type-2 LSA created by a DR.   Let’s confirm by looking the Type-2 Network LSA by searching the show ipospf database network output on R3:   The Advertising router is 101.0.0.2 is the Router-ID of R3 this means that our deduction is correct, R3 is the DR, still from this output we can see the subnet mask used in this transit link /24, so the subnet number used between R2 and R3 is 101.0.0.0/24.   R3#show ip ospf database network OSPF Router with ID (101.0.0.2) (Process ID 1) Net Link States (Area 0) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 466 Options: (No TOS-capability, DC) LS Type: Network Links Link State ID: 101.0.0.2 (address of Designated Router) Advertising Router: 101.0.0.2 LS Seq Number: 80000002 Checksum: 0x2674 Length: 32 Network Mask: /24 Attached Router: 101.0.0.2 Attached Router: 101.0.0.3 R3#   We obtain this topology:

    The Link Type 1 or point-to-point link describes the connection to the OSPF neighbor (Link ID as Neighboring Router ID). The router-ID of R2 is 101.0.0.3. The router-ID of R3 is 101.0.0.2.   What about area 1?   The Type-1 LSA’s R2 in area 1 carries two Links:   1-Link Type 3 connected to a Stub Network, the Link ID is the subnet number 172.16.3.3 and the Link Data is the Network Mask 255.255.255.255. So R2 has a stub network or a network directly connected (no OSPF neighbor).   Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.3.3 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1   2-Link Type 2 connected to a Transit Network, therefore there is a DR elected in area 1, since the Link ID and the Link Data have the same IP address in the Transit Link 100.0.0.3 so R2 is the DR.   Link connected to: a Transit Network (Link ID) Designated Router address: 100.0.0.3 (Link Data) Router Interface address: 100.0.0.3 Number of MTID metrics: 0 TOS 0 Metrics: 1   Let’s look the output of the show ipospf database network of R2:   Of course R2 has two Type-2 LSAs, the one in area 0 is already seen, let’s focus in the Type-2 LSA in area 0, we concluded already that R2 is the DR because the Link ID and Link Data carry the same IP address of the attached interface's DR R2. Note: the Link State ID of the Network LSA is the IP address of the attached interface's DR. So the Type-2 LSA in area 1 we should have the IP address 100.0.0.3 as expected!!!   Now we can deduce two pieces informations from the Type-2 LSA’s R2 in area 1: 1-The subnet mask of the transit network is /24, and since the Link State ID is 100.0.0.3 therefore the subnet of the transit segment is 100.0.0.0/24.   2-By definition the Type-2 Lists all attached routers in the same segment, the attached routers are listed with the router-ID, below R2 the DR lists itself (RID 101.0.0.3) and one router only with RID 100.0.0.2.   R2#show ip ospf database network OSPF Router with ID (101.0.0.3) (Process ID 1) Net Link States (Area 0) Routing Bit Set on this LSA in topology Base with MTID 0

LS age: 319 Options: (No TOS-capability, DC) LS Type: Network Links Link State ID: 101.0.0.2 (address of Designated Router) Advertising Router: 101.0.0.2 LS Seq Number: 80000002 Checksum: 0x2674 Length: 32 Network Mask: /24 Attached Router: 101.0.0.2 Attached Router: 101.0.0.3 Net Link States (Area 1) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 221 Options: (No TOS-capability, DC) LS Type: Network Links Link State ID: 100.0.0.3 (address of Designated Router) Advertising Router: 101.0.0.3 LS Seq Number: 80000001 Checksum: 0x1685 Length: 32 Network Mask: /24 Attached Router: 101.0.0.3 Attached Router: 100.0.0.2 R2#   We know that R2 is connected to one router in area 1 and this router has a RID 100.0.0.2, but no idea which router? and what is its IP address in the segment? And what informations it advertises to R2 in order to build a complete topology of area 1.   We obtain the following topology:  

  On R2 we can see the Type-1 LSA advertised by the neighbor router with RID 100.0.0.2 in area 1:   This Type-1 carries two Links:   1-Link connected to Transit Network and the Link Data is the IP address of this router in the transit network. The Link ID is the IP address of the DR R2 100.0.0.3.   2-Link connected to Stub Network, the subnet number is 172.16.4.4 and the mask number is 255.255.255.255.   Router Link States (Area 1) LS age: 208 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 100.0.0.2 Advertising Router: 100.0.0.2 LS Seq Number: 80000002

Checksum: 0x1FA2 Length: 48 Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.4.4 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 100.0.0.3 (Link Data) Router Interface address: 100.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 1   Now we know that the IP address of the router with RID 100.0.0.2 connected to R2 in area 1 is 100.0.0.2 and it has a stub network 172.16.4.4/32 connected directly without neighbor router.   So we have the following topology:  

  But who is the router with RID 100.0.0.2?   In the file we have the LSDB of R1 and R4, let’s look the LSDB of R1:   The show ipospf database command with all keywords (router, network, summary, asbr-summary, external or nssa-external) list always the RID of the local router where the command is executed at the beginning.   Now we know that R1 is the famous router with RID 100.0.0.2 and neighbor to R2 in area 1:   R1#show ip ospf database router OSPF Router with ID (100.0.0.2) (Process ID 1) Router Link States (Area 1)   We obtain the following topology:  

  Now what about area 2?  

Let’s see which informations are carried by the Type-1 LSA created by R3 for area 2, R3 generate a Type-1 LSA with two links. 1-A Link Type 1 or point-to-point link describing the connection to the OSPF neighbor (Link ID as Neighboring Router ID 102.0.0.3) and its own IP address (Link Data Router Interface Address 102.0.0.2). 2-Type-3 link (stub network) describing the subnet of the point-to-point interface (Link ID as the network/subnet number: 102.0.0.0) with the Network Mask (255.255.255.0).   Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 102.0.0.3 (Link Data) Router Interface address: 102.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 102.0.0.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 64   The Link Type 1 and Link Type 3 are generated by a router for its point-to-point interface, serial link for example, there is no DR election and only one OSPF neighbor.   The topology looks like this:  

  Some informations are missing. Who is the router connected to R3 in area 2? What is the IP address? And which informations are advertised by this router to R3?   In the show ipospf data router output on R3, we have seen that it is receiving a Type-1 LSA from another router in area 2 and this Type-1 LSA has the following informations and fields:   We can see below that the Advertising Router 102.0.0.3 matches the Link ID:Neighboring Router ID: 102.0.0.3seen in the Type-1 LSA‘s R3. So this Type-1 is coming from the unknown router name in the topology.   The router with RID 102.0.0.3 sees R3 101.0.0.2 as neighbor and the IP address of this router‘s interface connected to R3 is 102.0.0.3 as displayed in the link Type 1.   The second information is that this router is advertising a stub network 172.16.1.3 with mask 255.255.255.255 through Link Type 3.   LS age: 236 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 102.0.0.3 Advertising Router: 102.0.0.3 LS Seq Number: 80000003 Checksum: 0xD3F2 Length: 60 Number of Links: 3 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.1.3

(Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 101.0.0.2 (Link Data) Router Interface address: 102.0.0.3 Number of MTID metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 102.0.0.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 64     The last information about the name of this router can be seen through the show ipospf data router output of R4:   R4 has a router-ID 102.0.0.3 which matches with router-ID listed in Type-1 LSA as the advertising router:   R4#show ip ospf database router OSPF Router with ID (102.0.0.3) (Process ID 1) Router Link States (Area 2)   Finally our topology looks like this:  

                             

Lab 2: OSPFv3 Link State Database LSDB In depth Exploration  

Note: The topology is hidden for this Lab   Let's start with R1 by displaying the LSDB, R1 has information about area 1 only, it is an internal router so it originates a single Type-1 LSA, the router-id of R1 is 0.0.0.31:   R1#sh ipv os data OSPFv3 Router with ID (0.0.0.31) (Process ID 1)

ADV Router 0.0.0.31 0.0.0.32 0.0.0.34 0.0.0.35 ADV Router 0.0.0.32 0.0.0.34 ADV Router 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.35 0.0.0.35 0.0.0.35 0.0.0.35 0.0.0.35 0.0.0.35 0.0.0.35 ADV Router 0.0.0.34 0.0.0.35 ADV Router 0.0.0.31 0.0.0.32 ADV Router 0.0.0.32 0.0.0.32 0.0.0.34

Router Link States (Area 1) Age Seq# Fragment ID Link count Bits 630 0x8000000F 0 1 None 770 0x80000018 0 2 E 2010 0x80000010 0 1 B 1910 0x8000000F 0 1 B Net Link States (Area 1) Age Seq# Link ID Rtr count 770 0x80000007 3 2 1495 0x8000000A 2 3 Inter Area Prefix Link States (Area 1) Age Seq# Prefix 215 0x8000000B 2002::/64 215 0x80000008 2001::/64 2010 0x80000007 1010::/64 2010 0x80000007 2004::/64 2010 0x80000007 2005::/64 1751 0x80000007 2004:DB8::/64 1751 0x80000007 2003::/64 1910 0x8000000A 2002::/64 1910 0x8000000C 2001::/64 1910 0x80000007 1010::/64 1910 0x80000007 2004::/64 1910 0x80000007 2005::/64 1910 0x80000007 2004:DB8::/64 1910 0x80000007 2003::/64 Inter Area Router Link States (Area 1) Age Seq# Link ID Dest RtrID 2010 0x80000007 51 0.0.0.51 1910 0x80000007 51 0.0.0.51 Link (Type-8) Link States (Area 1) Age Seq# Link ID Interface 630 0x8000000A 3 Fa0/1 1275 0x8000000A 3 Fa0/1 Intra Area Prefix Link States (Area 1) Age Seq# Link ID Ref-lstype Ref-LSID 770 0x80000014 0 0x2001 0 770 0x80000007 3072 0x2002 3 2010 0x80000007 2048 0x2002 2 Type-5 AS External Link States Age Seq# Prefix 1275 0x80000008 2010::/64 69 0x80000001 1020::/64

ADV Router 0.0.0.32 0.0.0.51 R1#   The Type-1 LSA describes the Links connected to the router, there are four Links Type.   Link Type 1: Point-to-point connection to another router = Neighbor router ID Link Type 2: Connection to a transit network = DR's interface address Link Type 3: Connection to a stub network = IP network/subnet number Link Type 4: Virtual Link = Neighbor router ID   In OSPFv3, the Type-1 and Type-2 LSAs no longer carry any addressing information. They only carry a description of topology adjacencies. IPv6 prefixes are carried in a

  Type-9 and Type-8 LSAs.   Let's display the Type-1 LSA's R1.

The Link Type 2 describes the connection to a transit network where a DR is elected, "Neighbor (DR) Router ID: 0.0.0.32" represents the router ID of the DR, so 0.0.0.32 is a Designated Router in this segment.   R1#sh ipv os data router self OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Router Link States (Area 1) LS age: 256 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 0.0.0.31 LS Seq Number: 80000009 Checksum: 0x7F32 Length: 40 Number of Links: 1 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 3 Neighbor (DR) Interface ID: 3 Neighbor (DR) Router ID: 0.0.0.32 R1#     Since the 0.0.0.32 is a DR so it originates a Type-2 LSA that helps us to identify the attached routers to this segment, let's see the Type-2 LSA of 0.0.0.32, I am

  using the number (3) as a Link State ID, this is the Interface ID of the DR listed in the Type-1 LSA 's R1 above ( Neighbor (DR) Interface ID: 3):   There are two attached routers, the DR itself (0.0.0.32) and 0.0.0.31 (R1):   R1#sh ipv os data net 3 OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Net Link States (Area 1) LS age: 303 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Network Links Link State ID: 3 (Interface ID of Designated Router) Advertising Router: 0.0.0.32 LS Seq Number: 80000001 Checksum: 0x79F Length: 32 Attached Router: 0.0.0.32 Attached Router: 0.0.0.31 R1#   By definition with OSPFv2 the content of the LSA Type 2 describes the network segment listing the DR address, the attached routers, and the used subnet mask. This information is used by each router participating in OSPF to build the exact picture of the described multiaccess segment, which cannot be fully described with just LSAs Type 1.   With OSPFv3 the LSA Type 2 does not carry the used subnet mask and the DR address. There is no information of the subnet mask and the DR address, only the attached routers are carried as shown above.   To identify the prefix address used in this segment, you need to know that when running OSPFv3 in multiaccess segment, the DR generates a unique Type-2 LSA describing the attached routers and unique Type-9 LSA describing the subnet and the subnet mask used in this segment.  

In the LSDB of R1 shown above we can see that it has three Type-9 LSAs:   One Type-9 LSA originated by 0.0.0.32 with Link State ID 0 and references the Type-1 LSA. One Type-9 LSA originated by 0.0.0.32 with Link State ID 3072 and references the Type-2 LSA. One Type-9 LSA originated by 0.0.0.34 with Link State ID 2048 and references the Type-2 LSA.   The Type-9 LSA with a Link State ID 3072 is the one that we are looking since it references the Type-2 LSA and it has the 0.0.0.32 as the ADV Router.   Intra Area Prefix Link States (Area 1) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 0.0.0.32 770 0x80000014 0 0x2001 0 0.0.0.32 770 0x80000007 3072 0x2002 3 0.0.0.34 2010 0x80000007 2048 0x2002 2   Let's display the content of the Type-9 LSA’s DR 0.0.0.32 using the Link State ID 3072 keyword.   We find the following information:   -The Prefix Address: 2000::and the subnet mask (Prefix Length): 64 -Referenced Link State ID: 3 that matches the Link State ID of the Type-2 LSA's DR 0.0.0.32. -Referenced LSA Type: 2002 describes its association to the Network Type-2 LSA (or 2002).   R1#sh ipv os data prefix 3072 OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Intra Area Prefix Link States (Area 1) Routing Bit Set on this LSA LS age: 382 LS Type: Intra-Area-Prefix-LSA Link State ID: 3072 Advertising Router: 0.0.0.32 LS Seq Number: 80000001 Checksum: 0xE471 Length: 44 Referenced LSA Type: 2002 Referenced Link State ID: 3 Referenced Advertising Router: 0.0.0.32 Number of Prefixes: 1 Prefix Address: 2000:: Prefix Length: 64, Options: None, Metric: 0 R1#   Our area 1 looks like this:

  What about the topology behind the DR 0.0.0.32?   The LSDB of R1 shown that the Type-1 LSA with the ADV Routing 0.0.0.32 carries two links.   R1#sh ipv os data OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Router Link States (Area 1) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.31 630 0x8000000F 0 1 None 0.0.0.32 770 0x80000018 0 2 E 0.0.0.34 2010 0x80000010 0 1 B 0.0.0.35 1910 0x8000000F 0 1 B   Let's display the content of the Type-1 LSA 's 0.0.0.32, 0.0.0.32 is connected to two links or two transit networks where a DRs are elected, the first link is the first link or segment that we discovered, 0.0.0.32 identifies itself as a DR, the Neighbor (DR) Router ID: 0.0.0.32 is equivalent to the ADV Router 0.0.0.32, and we know already that R1 is the only router attached to that segment.   Let's focus on the second link, the link describes a connection to a transit network and DR should elected, so who is the DR in the segment located behind 0.0.0.32?   The line "Neighbor (DR) Router ID: 0.0.0.34" tells us that 0.0.0.34 is the DR:   R1#sh ipv os data router adv 0.0.0.32 OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Router Link States (Area 1) Routing Bit Set on this LSA LS age: 417 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 0.0.0.32 LS Seq Number: 80000012 Checksum: 0x6705 Length: 56 AS Boundary Router Number of Links: 2 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 3

Neighbor (DR) Interface ID: 3 Neighbor (DR) Router ID: 0.0.0.32 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 2 Neighbor (DR) Interface ID: 2 Neighbor (DR) Router ID: 0.0.0.34 R1#   We can confirm with the LSDB of R1: The Link State ID of the Type-2 LSA originated by 0.0.0.34 is 2:   Net Link States (Area 1) ADV Router Age Seq# Link ID Rtr count 0.0.0.32 770 0x80000007 3 2 0.0.0.34 1495 0x8000000A 2 3   Now how many attached routers to this segment?   Let's display the content of the Type-2 LSA originated by 0.0.0.34, I am using the Link State ID: 2 keyword of the Type-2 LSA’s 0.0.0.34.   There are three attached routers, the DR itself (0.0.0.34), a router with a RID (0.0.0.32) and a router with a RID (0.0.0.35):   R1#sh ipv os data net 2 OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Net Link States (Area 1) LS age: 1257 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Network Links Link State ID: 2 (Interface ID of Designated Router) Advertising Router: 0.0.0.34 LS Seq Number: 80000004 Checksum: 0xA1D6 Length: 36 Attached Router: 0.0.0.34 Attached Router: 0.0.0.32 Attached Router: 0.0.0.35 R1#   Now which prefix address is used in this segment between the DR 0.0.0.34, 0.0.0.32 and 0.0.0.35?   In the LSDB of R1 we can see that there is one Type-9 LSA originated by 0.0.0.34 and it's our Type-9 LSA with Link State ID 2048 and references the Type-2 LSA:   Intra Area Prefix Link States (Area 1) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 0.0.0.32 770 0x80000014 0 0x2001 0 0.0.0.32 770 0x80000007 3072 0x2002 3 0.0.0.34 2010 0x80000007 2048 0x2002 2   Let's display the content of the Intra-Area prefix's 0.0.0.34:   -The Prefix Address: 2001::and the subnet mask (Prefix Length): 64 -Referenced Link State ID: 2 that matches the Link State ID of the Type-2 LSA's DR 0.0.0.34. -Referenced LSA Type: 2002 describes its association to the Network Type-2 LSA (or 2002).   R1#sh ipv os data prefix 2048

OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Intra Area Prefix Link States (Area 1) Routing Bit Set on this LSA LS age: 14 LS Type: Intra-Area-Prefix-LSA Link State ID: 2048 Advertising Router: 0.0.0.34 LS Seq Number: 80000002 Checksum: 0x292C Length: 44 Referenced LSA Type: 2002 Referenced Link State ID: 2 Referenced Advertising Router: 0.0.0.34 Number of Prefixes: 1 Prefix Address: 2001:: Prefix Length: 64, Options: None, Metric: 0 R1#   As mentioned earlier, the Type-1 and Type-2 LSAs no longer carry any addressing information within area, the addressing information is carried by a Type-9 LSA.   From the LSDB of R1, we known that there are three Type-9 LSAs (0.0.0.32 with Link ID 0, 0.0.0.32 with Link ID 3072 and 0.0.0.34 with Link ID 2048), we have already seen the Type-9 LSA of 0.0.0.32 with Link ID 3072 and the Type-9 LSA of 0.0.0.34 with Link ID 2048. And we have some information about the prefixes located in area 1: 2000::/64 and 2001::/64.   Intra Area Prefix Link States (Area 1) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 0.0.0.32 770 0x80000014 0 0x2001 0 0.0.0.32 770 0x80000007 3072 0x2002 3 0.0.0.34 2010 0x80000007 2048 0x2002 2   What about the Type-LSA 9 originated by 0.0.0.32 with Link State ID 0 ?   You should know that This LSA type (Intra Area Prefix) provides information for two different scenario:   1) It will provide information about IPv6 address prefixes associated with a transit network by referencing a Network LSA. 2) It will provide information about IPv6 address prefixes associated with a router by referencing a Router LSA. Type 9 LSAs are only flooded within an area.   The Type-9 LSA's 0.0.0.32 with Link State ID 0 belongs to the second scenario.   Let's displays the content of this LSA: We can see the number of prefix 1 carried by this LSA and it's 2030::/64.   R1#sh ipv os data prefix 0 OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Intra Area Prefix Link States (Area 1) Routing Bit Set on this LSA LS age: 1131 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.32 LS Seq Number: 8000000E Checksum: 0x127 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0

Referenced Advertising Router: 0.0.0.32 Number of Prefixes: 1 Prefix Address: 2030:: Prefix Length: 64, Options: None, Metric: 1 R1#   Now our area 1 looks like this:

  The LSDB of R1 contains two Type-5 LSAs describing external prefixes:   The ADV Router 0.0.0.32 of the Type-5 LSA carries the prefix 2010::/64. The ADV Router 0.0.0.51 of the Type-5 LSA carries the prefix 1010::/64.   We have two ASBRs 0.0.0.32 and 0.0.0.51 in the OSPF domain.   Type-5 AS External Link States ADV Router Age Seq# Prefix 0.0.0.32 1275 0x80000008 2010::/64 0.0.0.51 69 0x80000001 1020::/64 R1#   The Area 1 receives two external information, so the routers located in this area 1 need to know who is and how to reach the ASBR that floods the external prefix.   There are two way to locate an ASBR.   Within an area, an ASBR sets the E-bit in its Type-1 LSA to inform the routers in the same area that it is an ASBR. If the ASBR is located in another area, the ABR connected to the same area creates a Type-4 LSA and floods this LSA into another area to inform the routers the presence of the famous ASBR.   From the LSDB we can see that the router 0.0.0.32 sets the E-bit in its Type-1 LSA, so the area 1 contains an ASBR which is 0.0.0.32, the prefix learned from this ASBR is 2010::/64:   R1#sh ipv os data OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Router Link States (Area 1) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.31 630 0x8000000F 0 1 None 0.0.0.32 770 0x80000018 0 2 E 0.0.0.34 2010 0x80000010 0 1 B 0.0.0.35 1910 0x8000000F 0 1 B

  What about the second ASBR 0.0.0.51?   There is no router 0.0.0.51 in the area 1 since there is no Type-1 LSA with ADV Router 0.0.0.51, obviously the ASBR 0.0.0.51 is located in another area.   The topology looks like this:  

  Let's see if there is a Type-4 LSA in the LSDB of R1.   There are two Type-4 LSAs with the Destination Router ID (DestRtrID) 0.0.0.51, it's our famous ASBR, the information of the presence of this ASBR is given by two ABRs 0.0.0.34 and 0.0.0.34, there are the routers discovered in area 1:   Inter Area Router Link States (Area 1) ADV Router Age Seq# Link ID Dest RtrID 0.0.0.34 2010 0x80000007 51 0.0.0.51 0.0.0.35 1910 0x80000007 51 0.0.0.51   To confirm, let's see again the LSDB of R1. The routers 0.0.0.34 and 0.0.0.35 set the B-bit in their Type-1 LSA to tell to 0.0.0.31 and 0.0.0.32 that they are the ABRs.   R1#sh ipv os data OSPFv3 Router with ID (0.0.0.31) (Process ID 1) Router Link States (Area 1) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.31 630 0x8000000F 0 1 None 0.0.0.32 770 0x80000018 0 2 E 0.0.0.34 2010 0x80000010 0 1 B 0.0.0.35 1910 0x8000000F 0 1 B   Now what about the information about other areas?   To get the information about other areas, R1 needs to go through the ABRs 0.0.0.34 and 0.0.0.35, the LSDB of R1 shown that additional prefixes are learned through the Type-3 LSAs.   The prefixes learned are:   -2002::/64 -2004::/64

-2005::/64 -2004:DB8::/64 -2003::/64 -1010::/64   ADV Router 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.34 0.0.0.35 0.0.0.35 0.0.0.35 0.0.0.35 0.0.0.35 0.0.0.35 0.0.0.35

Inter Area Prefix Link States (Area 1) Age Seq# Prefix 215 0x8000000B 2002::/64 215 0x80000008 2001::/64 2010 0x80000007 1010::/64 2010 0x80000007 2004::/64 2010 0x80000007 2005::/64 1751 0x80000007 2004:DB8::/64 1751 0x80000007 2003::/64 1910 0x8000000A 2002::/64 1910 0x8000000C 2001::/64 1910 0x80000007 1010::/64 1910 0x80000007 2004::/64 1910 0x80000007 2005::/64 1910 0x80000007 2004:DB8::/64 1910 0x80000007 2003::/64

  The topology looks like this:  

To get a detailed information, let's go to the ABR 0.0.0.34.   let's verify the LSDB of 0.0.0.34, there are two separate LSDB, one for area 0 and another for area 1. Let's see what happen under the LSDB for area 0.   R3#sh ipv os data OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.34 2048 0x8000000F 0 1 B 0.0.0.35 1949 0x8000000F 0 1 B 0.0.0.36 1890 0x80000012 0 2 None 0.0.0.37 67 0x8000000D 0 1 B Net Link States (Area 0) ADV Router Age Seq# Link ID Rtr count 0.0.0.35 1949 0x80000008 3 3 0.0.0.36 1890 0x80000007 2 2

ADV Router 0.0.0.34 0.0.0.34 0.0.0.35 0.0.0.35 0.0.0.37 0.0.0.37 0.0.0.37 ADV Router 0.0.0.34 0.0.0.35 0.0.0.37 ADV Router 0.0.0.34 0.0.0.35 0.0.0.36 ADV Router 0.0.0.35 0.0.0.36 0.0.0.37

Inter Area Prefix Link States (Area 0) Age Seq# Prefix 1533 0x80000009 2000::/64 1533 0x80000009 2030::/64 1434 0x8000000D 2000::/64 1434 0x8000000D 2030::/64 1096 0x80000008 2005::/64 1838 0x80000007 2004:DB8::/64 1838 0x80000007 2003::/64 Inter Area Router Link States (Area 0) Age Seq# Link ID Dest RtrID 1533 0x80000009 32 0.0.0.32 1434 0x8000000D 32 0.0.0.32 832 0x80000008 51 0.0.0.51 Link (Type-8) Link States (Area 0) Age Seq# Link ID Interface 253 0x8000000A 3 Fa0/1 1949 0x80000009 3 Fa0/1 1890 0x80000009 3 Fa0/1 Intra Area Prefix Link States (Area 0) Age Seq# Link ID Ref-lstype Ref-LSID 1949 0x80000008 3072 0x2002 3 1890 0x80000007 2048 0x2002 2 67 0x8000000C 0 0x2001 0 Router Link States (Area 1) Age Seq# Fragment ID Link count Bits

ADV Router Output omitted   The same procedure needs to be followed, let's start with a Type-1 LSA of 0.0.0.34. The Type-1 LSA's 0.0.0.34 tells that it is connected to a Transit Network and the DR is 0.0.0.35.   R3#sh ipv os data router adv self OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Router Link States (Area 0) LS age: 1195 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 0.0.0.34 LS Seq Number: 8000000A Checksum: 0xB0F8 Length: 40 Area Border Router Number of Links: 1 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 3 Neighbor (DR) Interface ID: 3 Neighbor (DR) Router ID: 0.0.0.35 Output Omitted   The DR 0.0.0.35 informs about the attached routers through its Type-2 LSA.   -The DR itself 0.0.0.35. -The router 0.0.0.34 (ABR). -The router 0.0.0.36.   R3#sh ipv os data net adv 0.0.0.35

OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Net Link States (Area 0) LS age: 1630 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Network Links Link State ID: 3 (Interface ID of Designated Router) Advertising Router: 0.0.0.35 LS Seq Number: 80000004 Checksum: 0xC9A8 Length: 36 Attached Router: 0.0.0.35 Attached Router: 0.0.0.34 Attached Router: 0.0.0.36 R3#   Now to deduce the prefix address used in this segment, we need to look at the Type-9 LSA originated by the DR 0.0.0.35. The prefix address is 2002::/64.   R3#sh ipv os data prefix adv 0.0.0.35 OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 360 LS Type: Intra-Area-Prefix-LSA Link State ID: 3072 Advertising Router: 0.0.0.35 LS Seq Number: 80000005 Checksum: 0x10CB Length: 56 Referenced LSA Type: 2002 Referenced Link State ID: 3 Referenced Advertising Router: 0.0.0.35 Number of Prefixes: 1 Prefix Address: 2002:: Prefix Length: 64, Options: None, Metric: 0 R3#   Our area 0 looks like this:  

 

From the LSDB of 0.0.0.34, we can see that 0.0.0.34 has four Type-1 LSA, the self-generated and three learned from the routers 0.0.0.35, 0.0.0.36 and 0.0.0.37.   The Type-1 LSA's 0.0.0.35 has one link, this is the link connected to Transit Network with the prefix address 2002::/64. The Type-1 LSA's 0.0.0.36 has two links. The Type-1 LSA's 0.0.0.37 has one link.   We know already that 0.0.0.35 and 0.0.0.36 shares the same segment Transit Network with 0.0.0.34. The routers 0.0.0.34 and 0.0.0.37 are not connected directly but they are in the same area 1 since 0.0.0.34 sees the Type-1 LSA's 0.0.0.37.   R3#sh ipv os data OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.34 2048 0x8000000F 0 1 B 0.0.0.35 1949 0x8000000F 0 1 B 0.0.0.36 1890 0x80000012 0 2 None 0.0.0.37 67 0x8000000D 0 1 B   The Type-1 LSA's 0.0.0.36 has two links as mentioned previously:   -Link connected to Transit Network with the prefix address 2002::/64 and the DR is 0.0.0.35 (see the previous step). -Link connected to Transit Network with DR 0.0.0.36.   R3#sh ipv os data router adv 0.0.0.36 OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Router Link States (Area 0) LS age: 101 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 0.0.0.36 LS Seq Number: 8000000F Checksum: 0xED7A Length: 56 Number of Links: 2 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 2 Neighbor (DR) Interface ID: 2 Neighbor (DR) Router ID: 0.0.0.36 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 3 Neighbor (DR) Interface ID: 3 Neighbor (DR) Router ID: 0.0.0.35 R3#   Since 0.0.0.36 is the DR, we need to find who is connected to the segment behind 0.0.0.36, let's verify the Type-2 LSA's 0.0.0.36: Of course the Type-2 LSA shows two attached routers. The DR 0.0.0.36 is attached to 0.0.0.37.   R3#sh ipv os data net adv 0.0.0.36 OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Net Link States (Area 0) LS age: 136

Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Network Links Link State ID: 2 (Interface ID of Designated Router) Advertising Router: 0.0.0.36 LS Seq Number: 80000004 Checksum: 0x6F27 Length: 32 Attached Router: 0.0.0.36 Attached Router: 0.0.0.37 R3#   Let's confirm with the Type-1 LSA of 0.0.0.37, we can see that of course 0.0.0.37 sees 0.0.0.36 as the DR (Neighbor (DR) Router ID: 0.0.0.36):   R3#sh ipv os data router adv 0.0.0.37 OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Router Link States (Area 0) Routing Bit Set on this LSA LS age: 399 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 0.0.0.37 LS Seq Number: 80000009 Checksum: 0x9612 Length: 40 Area Border Router Number of Links: 1 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 2 Neighbor (DR) Interface ID: 2 Neighbor (DR) Router ID: 0.0.0.36 R3#   The prefix of the segment shared between 0.0.0.36 and 0.0.0.37 is carried through the Type-9 LSA's 0.0.0.36 as shown below: The prefix address is 2004::/64.   R3#sh ipv os data prefix adv 0.0.0.36 OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 168 LS Type: Intra-Area-Prefix-LSA Link State ID: 2048 Advertising Router: 0.0.0.36 LS Seq Number: 80000004 Checksum: 0x71DA Length: 44 Referenced LSA Type: 2002 Referenced Link State ID: 2 Referenced Advertising Router: 0.0.0.36 Number of Prefixes: 1 Prefix Address: 2004:: Prefix Length: 64, Options: None, Metric: 0 R3#  

Now what about the prefix information within area 1 (intra-area route) ?   The intra-area prefix informations are carried through the Type-9 LSA (Intra-Area Prefix LSA). Let's verify again the LSDB of 0.0.0.34 in area 0:   The Type-9 LSAs of 0.0.0.35 and 0.0.0.36 (DRs) carry the prefixes 2002::/64 and 2004::/64 respectively as shown previously. Now what about the Type-9 LSA of 0.0.0.37?   Intra Area Prefix Link States (Area 0) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 0.0.0.35 1949 0x80000008 3072 0x2002 3 0.0.0.36 1890 0x80000007 2048 0x2002 2 0.0.0.37 67 0x8000000C 0 0x2001 0   From 0.0.0.34. Let's verify the Type-9 LSA of 0.0.0.37, the Number of Prefix carried is 1 and it's 1010::/64:   R3#sh ipv os data prefix adv 0.0.0.37 OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 614 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.37 LS Seq Number: 80000008 Checksum: 0x81D2 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.37 Number of Prefixes: 1 Prefix Address: 1010:: Prefix Length: 64, Options: None, Metric: 1 R3#   Our area 0 looks now like this:  

 

Now is there inter-area information behind 0.0.0.37? To ensure if there is another area behind 0.0.0.7, let's see the LSDB of 0.0.0.34: Of course the Type-1 LSA's 0.0.0.37 received by 0.0.0.34 has the B-bit set so 0.0.0.37 is an ABR and there is inter-area information from other areas.   R3#sh ipv os data OSPFv3 Router with ID (0.0.0.34) (Process ID 1) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.34 2048 0x8000000F 0 1 B 0.0.0.35 1949 0x8000000F 0 1 B 0.0.0.36 1890 0x80000012 0 2 None 0.0.0.37 67 0x8000000D 0 1 B   The routers 0.0.0.34 and 0.0.0.35 set the B-bit in their Type-1 LSA to tell to 0.0.0.36 and 0.0.0.37 that they are the ABRs.   Now what about the information about other areas?   To see the information about other areas, the LSDB of 0.0.0.34 shown that additional prefixes are learned through the Type-3 LSAs from the ABR 0.0.0.37.   The prefixes learned are:   -2005::/64 -2004:DB8::/64 -2003::/64   Inter Area Prefix Link States (Area 0) ADV Router Age Seq# Prefix 0.0.0.34 1533 0x80000009 2000::/64 0.0.0.34 1533 0x80000009 2030::/64 0.0.0.35 1434 0x8000000D 2000::/64 0.0.0.35 1434 0x8000000D 2030::/64 0.0.0.37 1096 0x80000008 2005::/64 0.0.0.37 1838 0x80000007 2004:DB8::/64 0.0.0.37 1838 0x80000007 2003::/64   Now the topology looks now like this:  

  So who is connected to 0.0.0.37?  

The answer is always given by the famous Type-1 LSA, the most important piece of the puzzle.   Let's go to the ABR 0.0.0.37 and display the content of the Type-1 LSA's 0.0.0.37:   Two important informations can be concluded, the ABR 0.0.0.37 is connected to area 2 and area 3. So the ABR generates two Type-1 LSAs for each area as shown below:   The Type-1 LSA for area 2 tells us that the router 0.0.0.37 is attached to a Transit Network and the DR is 0.0.0.42 (Neighbor (DR) Router ID: 0.0.0.42). The Type-1 LSA for area 3 tells us that the router 0.0.0.37 is attached to a Transit Network and the DR is 0.0.0.37 (itself) (Neighbor (DR) Router ID: 0.0.0.37).   R6#sh ipv os data router adv 0.0.0.37 OSPFv3 Router with ID (0.0.0.37) (Process ID 1) Output Omitted Router Link States (Area 2) LS age: 1165 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 0.0.0.37 LS Seq Number: 80000009 Checksum: 0x3B65 Length: 40 Area Border Router Number of Links: 1 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 3 Neighbor (DR) Interface ID: 3 Neighbor (DR) Router ID: 0.0.0.42 Router Link States (Area 3) LS age: 402 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 0.0.0.37 LS Seq Number: 80000006 Checksum: 0xF2B3 Length: 40 Area Border Router Number of Links: 1 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 4 Neighbor (DR) Interface ID: 4 Neighbor (DR) Router ID: 0.0.0.37 R6#   Since 0.0.0.42 is the DR for the segment located in area 2, let's verify the Type-2 LSA's 0.0.0.42 to identify the attached routers.   -The DR itself 0.0.0.42. -The router 0.0.0.37 (ABR). -The router 0.0.0.41.   R6#sh ipv os data net adv 0.0.0.42 OSPFv3 Router with ID (0.0.0.37) (Process ID 1) Net Link States (Area 2)

LS age: 432 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Network Links Link State ID: 3 (Interface ID of Designated Router) Advertising Router: 0.0.0.42 LS Seq Number: 80000007 Checksum: 0x64F4 Length: 36 Attached Router: 0.0.0.42 Attached Router: 0.0.0.37 Attached Router: 0.0.0.41 R6#   For this segment, to find the prefix address, let's verify the Type-9 LSA's DR 0.0.0.42. The LSDB of 0.0.0.37 displays two Type-9 LSAs originated by 0.0.0.42.   The first Type-9 LSA references the Type-1 LSA (2001). The first Type-9 LSA references the Type-2 LSA (2002).   Intra Area Prefix Link States (Area 2) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 0.0.0.42 1687 0x8000000E 0 0x2001 0 0.0.0.42 1687 0x80000009 3072 0x2002 3   The prefix address of the Transit Network (where a DR is elected) is carried in the Type-9 LSA referenced by a Type-2 LSA so the Prefix Address is 2003::/64. While the Type-9 LSA referenced by a Type-1 LSA carries the prefix 2004:DB8::/64, this is the Stub Network.   R6#sh ipv os data prefix adv 0.0.0.42 OSPFv3 Router with ID (0.0.0.37) (Process ID 1) Intra Area Prefix Link States (Area 2) Routing Bit Set on this LSA LS age: 577 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.42 LS Seq Number: 8000000C Checksum: 0xD3A8 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.42 Number of Prefixes: 1 Prefix Address: 2004:DB8:: Prefix Length: 64, Options: None, Metric: 1 Routing Bit Set on this LSA LS age: 577 LS Type: Intra-Area-Prefix-LSA Link State ID: 3072 Advertising Router: 0.0.0.42 LS Seq Number: 80000007 Checksum: 0x65D3 Length: 44 Referenced LSA Type: 2002 Referenced Link State ID: 3 Referenced Advertising Router: 0.0.0.42 Number of Prefixes: 1 Prefix Address: 2003::

Prefix Length: 64, Options: None, Metric: 0 R6#   The last attached router 0.0.0.41 does not have a stub network since there is no Type-9 LSA from this router as shown below:   R6#sh ipv os data prefix adv 0.0.0.41 OSPFv3 Router with ID (0.0.0.37) (Process ID 1) R6#   Our area 2 looks now like this:  

  The second part of the Type-1 LSA's 0.0.0.37 is the one originated for area 3. let's verify the Type-1 LSA's 0.0.0.37.   For area 3, 0.0.0.37 tells that I am connected to a Transit Network and I am the DR (Neighbor (DR) Router ID: 0.0.0.37).   R6#sh ipv os data router adv 0.0.0.37 Output Omitted Router Link States (Area 3) LS age: 402 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 0.0.0.37 LS Seq Number: 80000006 Checksum: 0xF2B3 Length: 40 Area Border Router Number of Links: 1 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 4 Neighbor (DR) Interface ID: 4 Neighbor (DR) Router ID: 0.0.0.37 R6#  

If you want to know who is attached to the DR 0.0.0.37, the Type-2 LSA's DR identifies the attached routers.   As shown below the attached routers are:   -0.0.0.37 (DR) -0.0.0.50 -0.0.0.51   R6#sh ipv os data net adv 0.0.0.37 OSPFv3 Router with ID (0.0.0.37) (Process ID 1) Net Link States (Area 3) LS age: 1141 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Network Links Link State ID: 4 (Interface ID of Designated Router) Advertising Router: 0.0.0.37 LS Seq Number: 8000000A Checksum: 0xAB9C Length: 36 Attached Router: 0.0.0.37 Attached Router: 0.0.0.50 Attached Router: 0.0.0.51 R6#   The prefix address of the Transit Network can be found from the Type-9 LSA 's DR 0.0.0.37. The LSDB of 0.0.0.37 shown only one Type-9 LSA originated by itself and it references the Type-2 LSA of the DR 0.0.0.37 (itself). No other information about prefix within area 3.   Intra Area Prefix Link States (Area 3) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 0.0.0.37 1143 0x80000008 4096 0x2002 4   Let's see the content of Type-9 LSA, it is referenced by a Type-2 LSA (2002) and carries the prefix 2005::/64, this is our Prefix Address of the Transit Network in area 3.   R6#sh ipv os data prefix adv 0.0.0.37 OSPFv3 Router with ID (0.0.0.37) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 1804 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.37 LS Seq Number: 8000000B Checksum: 0x7BD5 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.37 Number of Prefixes: 1 Prefix Address: 1010:: Prefix Length: 64, Options: None, Metric: 1 Intra Area Prefix Link States (Area 3) Routing Bit Set on this LSA LS age: 813 LS Type: Intra-Area-Prefix-LSA Link State ID: 4096

Advertising Router: 0.0.0.37 LS Seq Number: 80000008 Checksum: 0x41F9 Length: 44 Referenced LSA Type: 2002 Referenced Link State ID: 4 Referenced Advertising Router: 0.0.0.37 Number of Prefixes: 1 Prefix Address: 2005:: Prefix Length: 64, Options: None, Metric: 0 R6#   Our area 3 looks now like this:

Now is there inter-area or external information behind area 2 and area 3?   Let's look the LSDB of 0.0.0.37.   For area 2, the Type-1 LSAs of 0.0.0.41 and 0.0.0.42 didn't have any capabilities, is the router a Border router or ASBR? (Respective E-bit and B-bit), the word "None" means that the E-bit and the B-bit are not set so no area and no external prefix behind area 2, the router 0.0.0.37 has the B-bit set in its own Type-1 LSA, this is to inform area 2 that it is connected to area 0 and area 3.   Router Link States (Area 2) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.37 1885 0x8000000C 0 1 B 0.0.0.41 1745 0x8000000B 0 1 None 0.0.0.42 1687 0x8000000D 0 1 None   Now let's take a look at area 3.   -The Type-1 LSA of 0.0.0.37 has the B-bit set, we have seen that 0.0.0.37 is an ABR and for area routers located in area 3 will use this ABR to reach area 1, area 0 and area 2 discovered previously.   The Type-1 LSA of 0.0.0.50 didn't have any capabilities, so it's not an ABR neither an ASBR. But the Type-1 LSA 0.0.0.51 has the E-bit set so it is advertising external information.   Router Link States (Area 3) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.37 1143 0x80000009 0 1 B 0.0.0.50 1912 0x8000000A 0 1 None 0.0.0.51 1858 0x8000000C 0 1 E

  To know which external prefixes advertised by 0.0.0.51, let's verify again the LSDB of 0.0.0.37 and focus on the Type-5 LSAs:   The ADV Router of the second Type-5 LSA is 0.0.0.51, our ASBR identified through the Type-1 LSA and it advertises one prefix 1020::/64.     Type-5 AS External Link States ADV Router Age Seq# Prefix 0.0.0.32 1365 0x80000008 2010::/64 0.0.0.51 154 0x80000001 1020::/64 R6#   With all of the information of the LSDB we have the entire OSPF network as shown below.

  You have seen how OSPF scales by hiding topology information between areas. You noticed that in an area we have a large number of Type-1, Type-2 and Type-9 LSAs. Outside of that area there is only a single Type-3 LSA generated and regenerated by each ABR for each prefix. The LSA Type 1 (Router LSA) seems to be the most basic and simple LSA among all the LSAs OSPF, but it plays an important role to build the exact picture of OSPF topology within area, keep in mind that in OSPFv3 the Type-9 LSA should be combined with a Type-1 LSA or a Type-2 LSA to provide prefix address information.                                

Lab 3: OSPF Network Types P2P P2M and Broadcast  

  Basic configuration:   R1: interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ip ospf 1 area 0 no shut ! router ospf 1 router-id 0.0.0.1   R2: interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 0 no shut ! router ospf 1 router-id 0.0.0.2   A router originates a Type-1 LSA for each area that it belongs to. This LSA describes the collected states of the router's links to the area. The Router LSA is flooded throughout the area and does not traverse the area that it belongs to.   The Type-1 LSA describes the router's type of connections (in other words interfaces or links) to the area. Each Link Type represents the kind of attached network. Each link is also marked with its Link ID. This Link ID gives a name to the entity on the other end of the link.   Link Type Description       Link ID 1       Point-to-point link       Neighbor Router ID 2       Link to transit network       Interface address of DR 3       Link to Stub network       IP network number 4       Virtual Link       Neighbor Router ID   The Link Data field is specified for each link. This field represents 32-bits of extra information for the link. For links connected to transit network, point-to-point links and virtual link, this field specifies the IP interface address of the associated router interface (this is needed for routing table calculation). For links connected to stub network, this field specifies the stub network's IP address and the subnet mask.   R1#sh ip os ne Neighbor ID Pri State Dead Time Address Interface 0.0.0.2 0 FULL/ 00:00:38 12.0.0.2 Serial1/0 R1# R2#sh ip os nei Neighbor ID Pri State Dead Time Address Interface 0.0.0.1 0 FULL/ 00:00:37 12.0.0.1 Serial1/0 R2#  

Two routers connected via point-to-point serial link   In RFC 2328:   12.4.1.1. Describing point-to-point interfaces   For point-to-point interfaces, one or more link descriptions are added to the router-LSA as follows:   If the neighboring router is fully adjacent, add a Type 1 link (point-to-point). The Link ID should be set to the Router ID of the neighboring router. For numbered point-to-point networks, the Link Data should specify the IP interface address. For unnumbered point-to-point networks, the Link Data field should specify the interface's MIB-II [Ref8] ifIndex value. The cost should be set to the output cost of the point-to-point interface.   In addition, as long as the state of the interface is "Point-to-Point" (and regardless of the neighboring router state), a Type 3 link (stub network) should be added. There are two forms that this stub link can take:   Option 1 Assuming that the neighboring router's IP address is known, set the Link ID of the Type 3 link to the neighbor's IP address, the Link Data to the mask 0xffffffff (indicating a host route), and the cost to the interface's configured output cost.[15]   Option 2 If a subnet has been assigned to the point-topoint link, set the Link ID of the Type 3 link to the subnet's IP address, the Link Data to the subnet's mask, and the cost to the interface's configured output cost.[16]   The routers generate a Type-1 LSA with two links for each point-to-point interface. The router link (Type-1 or point-to-point link) describing the connection to the OSPF neighbor (Link ID is Neighboring Router ID) and Type3 link (stub network) describing the subnet of the point-to-point interface (Link ID is the network/subnet number).   Below the show ip os data router self command displays the Type-1 LSA's R1. Since the OSPF network type is a point to point. The Link Type 1 is the router-ID of the neighbor R2 0.0.0.2 while the Link Type 3 is the subnet number 12.0.0.0/24 used in this link.   R1#sh ip os data router self OSPF Router with ID (0.0.0.1) (Process ID 1) Router Link States (Area 0) LS age: 94 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.1 Advertising Router: 0.0.0.1 LS Seq Number: 80000004

Checksum: 0xBBC8 Length: 48 Number of Links: 2 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.2 (Link Data) Router Interface address: 12.0.0.1 Number of MTID metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 12.0.0.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 64 R1#   The Type-1 LSA originated by R2 has the same fields as the Type-1 LSA's R1, the Link Type-1 states that the neighbor has a router-ID 0.0.0.1 which is R1. The Link Type 3 is the subnet 12.0.0.0/24.   R2#sh ip os data router self OSPF Router with ID (0.0.0.2) (Process ID 1) Router Link States (Area 0) LS age: 73 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.2 Advertising Router: 0.0.0.2 LS Seq Number: 80000002 Checksum: 0xB3D0 Length: 48 Number of Links: 2 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.1 (Link Data) Router Interface address: 12.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 12.0.0.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 64 R2#   Two routers connected via a broadcast network   In RFC 2328:   12.4.1.2. Describing broadcast and NBMA interfaces   For operational broadcast and NBMA interfaces, a single link description is added to the router-LSA as follows: If the state of the interface is Waiting, add a Type 3 link (stub network) with Link ID set to the IP network number of the attached network, Link Data set to the attached network's address mask, and cost equal to the interface's configured output cost.   Else, there has been a Designated Router elected for the attached network. If the router is fully adjacent to the Designated Router, or if the router

itself is Designated Router and is fully adjacent to at least one other router, add a single Type 2 link (transit network) with Link ID set to the IP interface address of the attached network's Designated Router (which may be the router itself), Link Data set to the router's own IP interface address, and cost equal to the interface's configured output cost. Otherwise, add a link as if the interface state were Waiting (see above).   In broadcast network type, a DR must be elected. The router is fully adjacent to the DR, or the router itself is a DR and is fully adjacent to at least one another router, a single Type-2 link (link to transit network) is added to the Router LSA with Link ID set to IP interface address of the DR and Link Data set to router's own IP interface address.   R2(config)#int s1/0 R2(config-if)#ip ospf network broadcast   In this case R2 is the DR as shown by as shown by the sh ip os nei command:   R1#sh ip os nei Neighbor ID Pri State Dead Time Address Interface 0.0.0.2 1 FULL/DR 00:00:37 12.0.0.2 Serial1/0 R1# R2#sh ip os nei Neighbor ID Pri State Dead Time Address Interface 0.0.0.1 1 FULL/BDR 00:00:31 12.0.0.1 Serial1/0 R2#   Since R2 is the DR, R1 originates a Type-1 LSA with a Link Type 2 that describes a connexion to a Transit network where a DR is elected. The Link ID references the IP Address of the Designated Router. The Link Data references the IP Address of the router R1. R1#sh ip os data router self OSPF Router with ID (0.0.0.1) (Process ID 1) Router Link States (Area 0) LS age: 118 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.1 Advertising Router: 0.0.0.1 LS Seq Number: 80000006 Checksum: 0x3F92 Length: 36 Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 12.0.0.2 (Link Data) Router Interface address: 12.0.0.1 Number of MTID metrics: 0 TOS 0 Metrics: 64 R1#   While the Type-1 LSA originates by the DR R2 lists:   Both the Link ID and the Link Data reference the IP Address of the Designated Router, this means that this router is a DR.   R2#sh ip os data router self

OSPF Router with ID (0.0.0.2) (Process ID 1) Router Link States (Area 0) LS age: 60 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.2 Advertising Router: 0.0.0.2 LS Seq Number: 80000004 Checksum: 0x418F Length: 36 Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 12.0.0.2 (Link Data) Router Interface address: 12.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 64 R2#   R2#sh ip os data net OSPF Router with ID (0.0.0.2) (Process ID 1) Net Link States (Area 0) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 170 Options: (No TOS-capability, DC) LS Type: Network Links Link State ID: 12.0.0.2 (address of Designated Router) Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x522 Length: 32 Network Mask: /24 Attached Router: 0.0.0.2 Attached Router: 0.0.0.1 R2#   Note: When the adjacency is NOT formed between the two routers, a single Type-3 link is added to the Router LSA with Link ID set to the network number of the attached network and Link Data set to attached network's mask.   Two routers connected by a point-to-multipoint network   In RFC 2328:   12.4.1.4. Describing Point-to-MultiPoint interfaces   For operational Point-to-MultiPoint interfaces, one or more link descriptions are added to the router-LSA as follows:   A single Type 3 link (stub network) is added with Link ID set to the router's own IP interface address, Link Data set to the mask 0xffffffff (indicating a host route), and cost set to 0.   For each fully adjacent neighbor associated with the interface, add an additional Type 1 link (point-topoint) with Link ID set to the Router ID of the neighboring router, Link Data set to the IP interface address and cost equal to the interface's

configured output cost.   The router generates one Router LSA which contains:   a- a Type-1 point-to-point link with Link ID set to the Router ID of the fully-adjacent neighboring router and Link Data set to the IP address of this router. b- a Type-3 Stub network with Link ID set to the router's own interface IP address and Link Data set to 0xffffffff (indicating a host route).   R2(config)#int s1/0 R2(config-if)#ip os net point-to-multipoint   Let's verify the neighbor tables of R1 and R2, the adjacency is built:   R1#sh ip os ne Neighbor ID Pri State Dead Time Address Interface 0.0.0.2 0 FULL/ 00:01:56 12.0.0.2 Serial1/0 R1#   R2#sh ip os nei Neighbor ID Pri State Dead Time Address Interface 0.0.0.1 0 FULL/ 00:01:43 12.0.0.1 Serial1/0 R2#   Let's verify the Type-1 LSA of R1, the Link ID of the Type-3 is set to the R1's interface IP address 12.0.0.1; the Network Mask is /32. In OSPF point-to-multipoint the metric advertised by a router in the Link Type-3 is equal to zero, this is because the stub is a host route:   R1#sh ip os data router self OSPF Router with ID (0.0.0.1) (Process ID 1) Router Link States (Area 0) LS age: 58 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.1 Advertising Router: 0.0.0.1 LS Seq Number: 80000008 Checksum: 0x427D Length: 48 Number of Links: 2 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.2 (Link Data) Router Interface address: 12.0.0.1 Number of MTID metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 12.0.0.1 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 0 R1#   The same thing is valid for the Type-1 LSA generated by R2, the Link Type-3 is 12.0.0.2 and the metric is 0:   R2#sh ip os data router self OSPF Router with ID (0.0.0.2) (Process ID 1) Router Link States (Area 0)

LS age: 90 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.2 Advertising Router: 0.0.0.2 LS Seq Number: 80000006 Checksum: 0x506E Length: 48 Number of Links: 2 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.1 (Link Data) Router Interface address: 12.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 12.0.0.2 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 0 R2#   Finally both R1 and R2 will trigger the SPF algorithm to calculate the best cost to reach the Hosts 12.0.0.2 and 12.0.0.1 respectively, this cost is the sum of the metric listed in the Link Type-1 (64) plus the metric (0) listed in the Link Type-3:   R1#sh ip route osp | beg Gate Gateway of last resort is not set 12.0.0.0/8 is variably subnetted, 3 subnets, 2 masks O 12.0.0.2/32 [110/64] via 12.0.0.2, 00:02:15, Serial1/0 R1#   R2#sh ip route osp | beg Gate Gateway of last resort is not set 12.0.0.0/8 is variably subnetted, 3 subnets, 2 masks O 12.0.0.1/32 [110/64] via 12.0.0.1, 00:02:00, Serial1/0 R2#                                              

                 

Lab 4: OSPF Network Type P2M and Broadcast with Type-2 LSA    

    The OSPF Type-2 LSA is one of the misunderstanding LSA among all the popular LSAs in OSPF , most people learns that this kind of LSA (Type-2) is generated by DR the Designated Router in a broadcast segment, for example when two or more than two routers are connected to an ethernet link, but the famous question is why we need the Type-2 LSA to describe some special intra-area informations since there is a Type-1 LSA which has the same purpose.  

OSPFv2 Network Type Point-to-Multipoint between R1, R2, R3, R4 and R5.

In RFC 2328:   12.4.1.4. Describing Point-to-MultiPoint interfaces   For operational Point-to-MultiPoint interfaces, one or more link descriptions are added to the router-LSA as follows:   A single Type 3 link (stub network) is added with Link ID set to the router's own IP interface address, Link Data set to the mask 0xffffffff (indicating a host route), and cost set to 0.   For each fully adjacent neighbor associated with the interface, add an additional Type 1 link (point-topoint) with Link ID set to the Router ID of the neighboring router, Link Data set to the IP interface address and cost equal to the interface's configured output cost.   The router generates one Router LSA which contains:   a- Type-1 point-to-point link with Link ID set to the Router ID of the fully-adjacent neighboring router and Link Data set to the IP address of this router. b- Type-3 Stub network with Link ID set to the router's own interface IP address and Link Data set to 0xffffffff (indicating a host route).  

From the R6’s perspective, use the show ip osp data router adv 0.0.0.x command where x is 1 2 3 4 and 5 to display the Type-1 LSAs originated by R1, R2, R3, R4 and R5 respectively.   Below The Type-1 LSA advertised by R1.   R1 advertises a Type-1 LSA with Advertising Router 0.0.0.1 and 5 Links:   -Link connected to a point to point router with Link ID 0.0.0.5 and Link Data 100.1.1.5 -Link connected to a point to point router with Link ID 0.0.0.4 and Link Data 100.1.1.4 -Link connected to a point to point router with Link ID 0.0.0.3 and Link Data 100.1.1.3 -Link connected to a point to point router with Link ID 0.0.0.2 and Link Data 100.1.1.2 -Link connected to Stub Network with Link ID 100.1.1.1 and Link Data 255.255.255.255   R6#sh ip os data router adv 0.0.0.1 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 975 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.1 Advertising Router: 0.0.0.1 LS Seq Number: 80000006 Checksum: 0x7F39 Length: 84 Number of Links: 5 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.5 (Link Data) Router Interface address: 100.1.1.1 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.4 (Link Data) Router Interface address: 100.1.1.1 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.3 (Link Data) Router Interface address: 100.1.1.1 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.2 (Link Data) Router Interface address: 100.1.1.1 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: a Stub Network (Link ID) Network/subnet number: 100.1.1.1 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 0 R6#   Below The Type-1 LSA advertised by R1.   R2 advertises a Type-1 LSA with Advertising Router 0.0.0.2 and 5 Links:   -Link connected to a point to point router with Link ID 0.0.0.5 and Link Data 100.1.1.5 -Link connected to a point to point router with Link ID 0.0.0.4 and Link Data 100.1.1.4 -Link connected to a point to point router with Link ID 0.0.0.3 and Link Data 100.1.1.3

-Link connected to a point to point router with Link ID 0.0.0.1 and Link Data 100.1.1.1 -Link connected to Stub Network with Link ID 100.1.1.1 and Link Data 255.255.255.255   R6#sh ip os data router adv 0.0.0.2 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 1006 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.2 Advertising Router: 0.0.0.2 LS Seq Number: 80000006 Checksum: 0xFBB6 Length: 84 Number of Links: 5 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.5 (Link Data) Router Interface address: 100.1.1.2 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.4 (Link Data) Router Interface address: 100.1.1.2 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.3 (Link Data) Router Interface address: 100.1.1.2 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.1 (Link Data) Router Interface address: 100.1.1.2 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: a Stub Network (Link ID) Network/subnet number: 100.1.1.2 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 0 R6#   Below The Type-1 LSA advertised by R3.   R3 advertises a Type-1 LSA with Advertising Router 0.0.0.3 and 5 Links:   -Link connected to a point to point router with Link ID 0.0.0.5 and Link Data 100.1.1.5 -Link connected to a point to point router with Link ID 0.0.0.4 and Link Data 100.1.1.4 -Link connected to a point to point router with Link ID 0.0.0.2 and Link Data 100.1.1.2 -Link connected to a point to point router with Link ID 0.0.0.1 and Link Data 100.1.1.1 -Link connected to Stub Network with Link ID 100.1.1.3 and Link Data 255.255.255.255   R6#sh ip os data router adv 0.0.0.3 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 1011 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.3

Advertising Router: 0.0.0.3 LS Seq Number: 80000006 Checksum: 0x8428 Length: 84 Number of Links: 5 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.5 (Link Data) Router Interface address: 100.1.1.3 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.4 (Link Data) Router Interface address: 100.1.1.3 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.2 (Link Data) Router Interface address: 100.1.1.3 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.1 (Link Data) Router Interface address: 100.1.1.3 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: a Stub Network (Link ID) Network/subnet number: 100.1.1.3 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 0 R6#   Below The Type-1 LSA advertised by R4.   R4 advertises a Type-1 LSA with Advertising Router 0.0.0.4 and 5 Links:   -Link connected to a point to point router with Link ID 0.0.0.5 and Link Data 100.1.1.5 -Link connected to a point to point router with Link ID 0.0.0.3 and Link Data 100.1.1.3 -Link connected to a point to point router with Link ID 0.0.0.2 and Link Data 100.1.1.2 -Link connected to a point to point router with Link ID 0.0.0.1 and Link Data 100.1.1.1 -Link connected to Stub Network with Link ID 100.1.1.4 and Link Data 255.255.255.255   R6#sh ip os data router adv 0.0.0.4 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 1031 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.4 Advertising Router: 0.0.0.4 LS Seq Number: 80000005 Checksum: 0x3F68 Length: 84 Number of Links: 5 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.5 (Link Data) Router Interface address: 100.1.1.4 Number of MTID metrics: 0 TOS 0 Metrics: 10

Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.1 (Link Data) Router Interface address: 100.1.1.4 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.3 (Link Data) Router Interface address: 100.1.1.4 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.2 (Link Data) Router Interface address: 100.1.1.4 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: a Stub Network (Link ID) Network/subnet number: 100.1.1.4 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 0 R6#   Below The Type-1 LSA advertised by R5.   R5 advertises a Type-1 LSA with Advertising Router 0.0.0.5 and 6 Links:   -Link connected to a point to point router with Link ID 0.0.0.4 and Link Data 100.1.1.4 -Link connected to a point to point router with Link ID 0.0.0.3 and Link Data 100.1.1.3 -Link connected to a point to point router with Link ID 0.0.0.2 and Link Data 100.1.1.2 -Link connected to a point to point router with Link ID 0.0.0.1 and Link Data 100.1.1.1 -Link connected to Stub Network with Link ID 100.1.1.5 and Link Data 255.255.255.255 -Link connected to Transit Network with R6 as a DR.   R6#sh ip os data router adv 0.0.0.5 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 974 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.5 Advertising Router: 0.0.0.5 LS Seq Number: 80000007 Checksum: 0xE712 Length: 96 Number of Links: 6 Link connected to: a Transit Network (Link ID) Designated Router address: 65.0.0.5 (Link Data) Router Interface address: 65.0.0.5 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.1 (Link Data) Router Interface address: 100.1.1.5 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.3 (Link Data) Router Interface address: 100.1.1.5 Number of MTID metrics: 0

TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.4 (Link Data) Router Interface address: 100.1.1.5 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 0.0.0.2 (Link Data) Router Interface address: 100.1.1.5 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: a Stub Network (Link ID) Network/subnet number: 100.1.1.5 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 0 R6#   For each Stub Network, R6 calculates the best path or the shortest path to 10.1.1.1/32, 10.1.1.2/32, 10.1.1.3/32, 10.1.1.4/32 and 10.1.1.1/32.   R6#sh ip route os | be Ga Gateway of last resort is not set 100.0.0.0/32 is subnetted, 5 subnets O 100.1.1.1 [110/20] via 65.0.0.5, 00:16:37, Ethernet0/1 O 100.1.1.2 [110/20] via 65.0.0.5, 00:16:37, Ethernet0/1 O 100.1.1.3 [110/20] via 65.0.0.5, 00:16:37, Ethernet0/1 O 100.1.1.4 [110/20] via 65.0.0.5, 00:16:37, Ethernet0/1 O 100.1.1.5 [110/10] via 65.0.0.5, 00:16:37, Ethernet0/1 R6#   A point to multipoint network type overcomes the limitations of partially meshed networks by accomplishing two things. The first thing that happens is that when a LSA is received on an interface, the next-hop is changed to IP of the router LSA that the local router is connecting to.   The reason is mentioned in RFC 2328 in the following section:   16.1.1. The next hop calculation   If there is at least one intervening router in the current shortest path between the destination and the root, the destination simply inherits the set of next hops from the parent. Otherwise, there are two cases. In the first case, the parent vertex is the root (the calculating router itself). This means that the destination is either a directly connected network or directly connected router. The outgoing interface in this case is simply the OSPF interface connecting to the destination network/router. If the destination is a router which connects to the calculating router via a Point-to-MultiPoint network, the destination's next hop IP address(es) can be determined by examining the destination's router-LSA: each link pointing back to the calculating router and having a Link Data field belonging to the Point-to-MultiPoint network provides an IP address of the next hop router. If the destination is a directly connected network, or a router which connects to the calculating router via a point-to-point interface, no next hop IP address is required. If the destination is a router connected to the calculating router via a virtual

link, the setting of the next hop should be deferred until the calculation in Section 16.3.   In the second case, the parent vertex is a network that directly connects the calculating router to the destination router. The list of next hops is then determined by examining the destination's router-LSA. For each link in the router-LSA that points back to the parent network, the link's Link Data field provides the IP address of a next hop router. The outgoing interface to use can then be derived from the next hop IP address (or it can be inherited from the parent network).   From the router LSA above you can see that each router in the point to multipoint network advertises a stub network with a /32 mask. On point to multipoint segments the network is described as a collection of point to point links. With a regular point to point network the stub network is described with the actual mask of the interface that is running OSPF.   Since the point to multipoint segments the network is described as a collection of point to point links. Each router in the segment advertises a Stub Network listing the IP address with /32.   From the LSDB’s ¨perspective of R6, we can see that the total of Links received from R1, R2, R3, R4 and R5 in the Type-1 LSAs is 5+5+5+5+6=26.   For OSPFv2, the issue is that each router creates a big Type-1 LSA with a lot Links Type that lists the IP address of each router, the flooding of these big LSA Type-1 between the routers will cause a chaotic situation for the network.   For a segment with 100 routers, R6 will ge 100 Type-1 LSAs and the size of each LSAs will become huge and the LSDB of R6 also huge.          

OSPFv3 Network Type Point-to-Multipoint between R1, R2, R3, R4 and R5.

  Since in OSPFv3 the IP prefixes are no longer carried in the Type-1 LSA, instead the new LSAs, Type-8 and Type9 LSA are added to carry the IP prefixes.   So let’s verify the Type-9 LSAs   Each router (R1, R2, R3, R4 and R5) will advertise the prefix 100::x/128 , each router creates a Type-9 LSA, unlike with Type-8 LSA, this LSA 9 has an area flooding scope and a single Type-9 LSA can carry multiple prefixes.   Below the Type-9 LSA ‘s R1 listing the prefix 100::1/128.   R6#sh ipv os data prefix adv 0.0.0.1 OSPFv3 Router with ID (0.0.0.6) (Process ID 1) Intra Area Prefix Link States (Area 0) LS age: 1376 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.1 LS Seq Number: 80000001 Checksum: 0x1365 Length: 52 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.1

Number of Prefixes: 1 Prefix Address: 100::1 Prefix Length: 128, Options: LA, Metric: 0 R6#   Below the Type-9 LSA ‘s R2 listing the prefix 100::2/128.   R6#sh ipv os data prefix adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.6) (Process ID 1) Intra Area Prefix Link States (Area 0) LS age: 1381 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x3D38 Length: 52 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.2 Number of Prefixes: 1 Prefix Address: 100::2 Prefix Length: 128, Options: LA, Metric: 0 R6#   Below the Type-9 LSA ‘s R3 listing the prefix 100::3/128.   R6#sh ipv os data prefix adv 0.0.0.3 OSPFv3 Router with ID (0.0.0.6) (Process ID 1) Intra Area Prefix Link States (Area 0) LS age: 1414 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x670B Length: 52 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.3 Number of Prefixes: 1 Prefix Address: 100::3 Prefix Length: 128, Options: LA, Metric: 0 R6#   Below the Type-9 LSA ‘s R4 listing the prefix 100::4/128.   R6#sh ipv os data prefix adv 0.0.0.4 OSPFv3 Router with ID (0.0.0.6) (Process ID 1) Intra Area Prefix Link States (Area 0) LS age: 1412 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.4 LS Seq Number: 80000001 Checksum: 0x91DD Length: 52 Referenced LSA Type: 2001

Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.4 Number of Prefixes: 1 Prefix Address: 100::4 Prefix Length: 128, Options: LA, Metric: 0 R6#   Below the Type-9 LSA ‘s R5 listing the prefix 100::5/128.   R6#sh ipv os data prefix adv 0.0.0.5 OSPFv3 Router with ID (0.0.0.6) (Process ID 1) Intra Area Prefix Link States (Area 0) LS age: 1418 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.5 LS Seq Number: 80000008 Checksum: 0xADB7 Length: 52 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.5 Number of Prefixes: 1 Prefix Address: 100::5 Prefix Length: 128, Options: LA, Metric: 0 LS age: 1547 LS Type: Intra-Area-Prefix-LSA Link State ID: 4096 Advertising Router: 0.0.0.5 LS Seq Number: 80000001 Checksum: 0x73CE Length: 44 Referenced LSA Type: 2002 Referenced Link State ID: 4 Referenced Advertising Router: 0.0.0.5 Number of Prefixes: 1 Prefix Address: 65:: Prefix Length: 64, Options: None, Metric: 0 R6#   From the Type-9 LSA above you can see that each router in the point to multipoint network advertises a prefix with a /128 mask and LA bit set.   Since the point to multipoint segments the network is described as a collection of point to point links. Each router in the segment advertises a Stub Network listing the IP address with /32.   This definition is described in RFC 5340.   Section 4.4.3.9. Intra-Area-Prefix-LSAs   A router builds an intra-area-prefix-LSA to advertise prefixes for its attached stub links, looped-back interfaces, and hosts. A Router RTX would build its intra-area-prefix-LSA in the following fashion:   In order to indicate that the prefixes are to be associated with the Router RTX itself, RTX sets the Referenced LS Type to 0x2001, the Referenced Link State ID to 0, and the Referenced Advertising Router to RTX's own Router ID.  

Router RTX examines its list of interfaces to the area. If the interface is in the state Down, its prefixes are not included. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), prefixes that will be included in the intra-area-prefix-LSA for the link are skipped. However, any prefixes that would normally have the LA-bit set SHOULD be advertised independent of whether or not the interface is advertised as a transit link. If the interface type is pointto-multipoint or the interface is in the state Loopback, the global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area-prefix-LSA with the PrefixOptions LA-bit set, the PrefixLength set to 128, and the metric set to 0. Otherwise, the list of global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the interface's output cost.     Similar to OSPFv2, the routing table of R6 shown a host route to 100::1/128, 100::2/128, 100::3/128, 100::4/128 and 100::5/128.   R6#sh ipv route os | be App lA - LISP away, a - Application O 100::1/128 [110/20] via FE80::A8BB:CCFF:FE00:5010, Ethernet0/1 O 100::2/128 [110/20] via FE80::A8BB:CCFF:FE00:5010, Ethernet0/1 O 100::3/128 [110/20] via FE80::A8BB:CCFF:FE00:5010, Ethernet0/1 O 100::4/128 [110/20] via FE80::A8BB:CCFF:FE00:5010, Ethernet0/1 O 100::5/128 [110/10] via FE80::A8BB:CCFF:FE00:5010, Ethernet0/1 R6#   For OSPFv3, the issue is that each router creates a single Type-9 LSA that lists its IPv6 address, for 100 routers in the segment 100::/64, R6 will get 100 Type-9 LSA.  

OSPFv2 Network Type Broadcast between R1, R2, R3, R4 and R5.

  In RFC 2328:   12.4.1.2. Describing broadcast and NBMA interfaces   For operational broadcast and NBMA interfaces, a single link description is added to the router-LSA as follows: If the state of the interface is Waiting, add a Type 3 link (stub network) with Link ID set to the IP network number of the attached network, Link Data set to the attached network's address mask, and cost equal to the interface's configured output cost.   Else, there has been a Designated Router elected for the attached network. If the router is fully adjacent to the Designated Router, or if the router itself is Designated Router and is fully adjacent to at least one other router, add a single Type 2 link (transit network) with Link ID set to the IP

interface address of the attached network's Designated Router (which may be the router itself), Link Data set to the router's own IP interface address, and cost equal to the interface's configured output cost. Otherwise, add a link as if the interface state were Waiting (see above).   In broadcast network type, a DR must be elected. The router is fully adjacent to the DR, or the router itself is a DR and is fully adjacent to at least one another router, a single Type-2 link (link to transit network) is added to the Router LSA with Link ID set to IP interface address of the DR and Link Data set to router's own IP interface address.   Since R1 is the DR, R1 originates a Type-1 LSA with a Link Type 2 that describes a connection to a Transit network where a DR is elected. The Link ID references the IP Address of the Designated Router. The Link Data references the IP Address of the Designated Router.   R6#sh ip os data router adv 0.0.0.1 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 23 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.1 Advertising Router: 0.0.0.1 LS Seq Number: 80000028 Checksum: 0x81B0 Length: 36 Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 100.1.1.1 (Link Data) Router Interface address: 100.1.1.1 Number of MTID metrics: 0 TOS 0 Metrics: 10 R6#   R2 originates a Type-1 LSA with a Link Type 2 that describes a connection to a Transit network where a DR is elected. The Link ID references the IP Address of the Designated Router 100.1.1.1. The Link Data references the IP Address of the router R2 100.1.1.2.   R6#sh ip os data router adv 0.0.0.2 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 39 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.2 Advertising Router: 0.0.0.2 LS Seq Number: 80000023 Checksum: 0x89AA Length: 36 Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 100.1.1.1 (Link Data) Router Interface address: 100.1.1.2 Number of MTID metrics: 0 TOS 0 Metrics: 10 R6#

  R3 originates a Type-1 LSA with a Link Type 2 that describes a connection to a Transit network where a DR is elected. The Link ID references the IP Address of the Designated Router 100.1.1.1. The Link Data references the IP Address of the router R2 100.1.1.3.   R6#sh ip os data router adv 0.0.0.3 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 51 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.3 Advertising Router: 0.0.0.3 LS Seq Number: 80000023 Checksum: 0x87A9 Length: 36 Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 100.1.1.1 (Link Data) Router Interface address: 100.1.1.3 Number of MTID metrics: 0 TOS 0 Metrics: 10 R6#   R4 originates a Type-1 LSA with a Link Type 2 that describes a connection to a Transit network where a DR is elected. The Link ID references the IP Address of the Designated Router 100.1.1.1. The Link Data references the IP Address of the router R2 100.1.1.4.   R6#sh ip os data router adv 0.0.0.4 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 79 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.4 Advertising Router: 0.0.0.4 LS Seq Number: 8000001A Checksum: 0x979F Length: 36 Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 100.1.1.1 (Link Data) Router Interface address: 100.1.1.4 Number of MTID metrics: 0 TOS 0 Metrics: 10 R6#   R5 originates a Type-1 LSA with a Link Type 2 that describes a connection to a Transit network where a DR is elected. The Link ID references the IP Address of the Designated Router 100.1.1.1. The Link Data references the IP Address of the router R2 100.1.1.5.   R6#sh ip os data router adv 0.0.0.5 OSPF Router with ID (0.0.0.6) (Process ID 1) Router Link States (Area 0) LS age: 87 Options: (No TOS-capability, DC)

LS Type: Router Links Link State ID: 0.0.0.5 Advertising Router: 0.0.0.5 LS Seq Number: 8000001C Checksum: 0xE7D Length: 48 Number of Links: 2 Link connected to: a Transit Network (Link ID) Designated Router address: 65.0.0.6 (Link Data) Router Interface address: 65.0.0.5 Number of MTID metrics: 0 TOS 0 Metrics: 10 Link connected to: a Transit Network (Link ID) Designated Router address: 100.1.1.1 (Link Data) Router Interface address: 100.1.1.5 Number of MTID metrics: 0 TOS 0 Metrics: 10 R6#   The creators of OSPF have introduced the DR concepts and the Type-2 LSA, the purpose of the DR is to manage the adjacencies between the routers in the same broadcast domain, by suppressing the Link Type 1 (neighboring router) and the Link Type 3 (Subnet Number), instead each non-DR router will create the Type-1 LSA with a new Link Type 2, this Link Type 2 will identify the DR with the IP address only, now a non-DR router does not see the other non-DR routers in its Type-1 LSA, instead it sees only the DR, and the DR sees the nonDR routers through the Type-2 LSA and identifies the non-DR routers with the router-ID, also the DR is now responsible of advertising the Subnet Number 100.1.1.0/24.   Note: Since the IP prefix of the transit multi-access network is not carried in the Type-2 LSA, rather it should be computed by other routers that receive this LSA; by ANDing the IP address of the DR with the network mask,   See RFC 2328, in the following section.   A.4.3 Network-LSAs   Network-LSAs are the Type 2 LSAs. A network-LSA is originated for each broadcast and NBMA network in the area which supports two or more routers. The network-LSA is originated by the network's Designated Router. The LSA describes all routers attached to the network, including the Designated Router itself. The LSA's Link State ID field lists the IP interface address of the Designated Router.   Below the router R6 receives the Type-2 LSA from the DR R1, two important informations can be retrieved, the Attached Routers R1, R2, R3, R4 and R5, and the subnet number 100.1.1.0/24 derived by ANDing the Link State ID 100.1.1.1 with the Network Mask /24.   R6#sh ip os data net adv 0.0.0.1 OSPF Router with ID (0.0.0.6) (Process ID 1) Net Link States (Area 0) LS age: 119 Options: (No TOS-capability, DC) LS Type: Network Links Link State ID: 100.1.1.1 (address of Designated Router) Advertising Router: 0.0.0.1 LS Seq Number: 80000003 Checksum: 0xAA0A Length: 44 Network Mask: /24 Attached Router: 0.0.0.1

Attached Attached Attached Attached

Router: Router: Router: Router:

0.0.0.2 0.0.0.3 0.0.0.4 0.0.0.5

R6#   Now if we look at the routing table of R6, the host routes are now replaced by a single route with a destination 100.1.1.0.24.   R6#sh ip route osp | beg Ga Gateway of last resort is not set 100.0.0.0/24 is subnetted, 1 subnets O 100.1.1.0 [110/20] via 65.0.0.5, 00:02:11, Ethernet0/1 R6#   Finally, R6 now receives five Type-1 LSA from R1, R2, R3, R4 and R5 with a total links of 6 instead of 26 links in the Type-1 LSAs with Point to Multipoing Network Type.  

OSPFv3 Network Type Broadcast between R1, R2, R3, R4 and R5.

  By definition with OSPFv2 the content of the LSA Type 2 describes the network segment listing the DR address, the attached routers, and the used subnet mask. This information is used by each router participating in OSPF to build the exact picture of the described multiaccess segment, which cannot be fully described with just LSAs Type 1.   With OSPFv3 the LSA Type 2 does not carry the used subnet mask and the DR address. Let's verify the Network LSA Type 2 generated by the R2, we can see that there is no information of the subnet mask and the DR address, only the attached routers and the Link State ID: 2 are carried as shown by the show ospfv3 database network command:   Per RFC 5340 OSPF for IPv6   4.4.3.3. Network-LSAs   The LS type of a network-LSA is set to the value 0x2002. NetworkLSAs have area flooding scope. A network-LSA is originated for every broadcast or NBMA link with an elected Designated Router that is fully adjacent with at least one other router on the link. The network-LSA is originated by the link's Designated Router and lists all routers on the link with which it is fully adjacent.   The procedure for originating network-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.2 of [OSPFV2], with the following exceptions:   An IPv6 network-LSA's Link State ID is set to the Interface ID of the Designated Router on the link.   IPv6 network-LSAs do not contain a Network Mask. All addressing information formerly contained in the IPv4 network-LSA has now been consigned to intra-Area-Prefix-LSAs originated by the link's Designated Router.   So a router can originate multiple intra-area prefix LSAs for each router or transit network, each with a unique link-state ID. The link state ID for each intra-area prefix LSA describes its association to either the router LSA or the network LSA. The link-state ID also contains prefixes for stub and transit networks. This LSA type (Intra Area Prefix) provides information for two different scenarios:   1) It will provide information about IPv6 address prefixes associated with a transit network by referencing a Network LSA.

2) It will provide information about IPv6 address prefixes associated with a router by referencing a Router LSA. Type 9 LSAs are only flooded within an area.   Therefore when running OSPFv3 in multiaccess segment, the DR generates a unique LSA Type 2 describing the attached routers and unique LSA Type 9 describing the subnet and the subnet mask used in this segment. Because R2, R3, R4, R5 are not DR, it does not generate a Type-9 LSA, unless a prefix behind the routers are injected into OSPF in the same area.   Let's verify the Intra-area prefix LSA (Type 9) advertised by the DR R1.   We can see that this LSA Type 9 carries the following information:   -The subnet 100:: and the subnet mask (Prefix Length) /64. -Referenced Link State ID: 3 that matches the Link State ID of the Type-2 LSA. -Referenced LSA Type: 2002 describes its association to the Network LSA Type 2 (or 2002).   R6#sh ipv os data prefix adv 0.0.0.1 OSPFv3 Router with ID (0.0.0.6) (Process ID 1) Intra Area Prefix Link States (Area 0) LS age: 451 LS Type: Intra-Area-Prefix-LSA Link State ID: 3072 Advertising Router: 0.0.0.1 LS Seq Number: 80000001 Checksum: 0x9C17 Length: 44 Referenced LSA Type: 2002 Referenced Link State ID: 3 Referenced Advertising Router: 0.0.0.1 Number of Prefixes: 1 Prefix Address: 100:: Prefix Length: 64, Options: None, Metric: 0 R6#   Below we can see that the routers R2, R3, R4 and R5 do not generate a Type-9 LSA.   R6#sh ipv os data prefix adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.6) (Process ID 1) R6# R6#sh ipv os data prefix adv 0.0.0.3 OSPFv3 Router with ID (0.0.0.6) (Process ID 1) R6# R6#sh ipv os data prefix adv 0.0.0.4 OSPFv3 Router with ID (0.0.0.6) (Process ID 1) R6#   For OSPFv3, instead of injecting five Type-9 LSA for each IPv6 address s’R1, R2, R3, R4 and R5, only one Type-9 LSA is received reducing the size of the LSDB.   The routing table of R6 displays only one OSPF route to 100::/64 instead of five host routes.   R6#sh ipv route os | be App lA - LISP away, a - Application O 100::/64 [110/20] via FE80::A8BB:CCFF:FE00:5010, Ethernet0/1 R6#      

                                                                       

Lab 6: Stub and Totally Stub Area Types  

  Basic configuration of all routers:   R1: interface lo0 ip address 192.168.1.1 255.255.255.0 ipv6 address FE80::1 link-local ipv6 address 2001:DB8:CAFE:1::1/64 ! interface Serial1/1 ip address 192.168.12.1 255.255.255.0 ipv6 address FE80::1 link-local

ipv6 address 2001:DB8:CAFE:12::1/64 clock rate 64000 no shutdown   R2: interface lo0 ip address 192.168.2.1 255.255.255.0 ipv6 address FE80::2 link-local ipv6 address 2001:DB8:CAFE:2::1/64 ! interface Serial1/1 ip address 192.168.12.2 255.255.255.0 ipv6 address FE80::2 link-local ipv6 address 2001:DB8:CAFE:12::2/64 no shutdown ! interface Serial1/0 ip address 192.168.23.2 255.255.255.0 ipv6 address FE80::2 link-local ipv6 address 2001:DB8:CAFE:23::2/64 clock rate 64000 no shutdown   R3: interface lo0 ip address 192.168.3.1 255.255.255.0 ipv6 address FE80::3 link-local ipv6 address 2001:DB8:CAFE:3::1/64 ! interface Serial1/0 ip address 192.168.23.3 255.255.255.0 ipv6 address FE80::3 link-local ipv6 address 2001:DB8:CAFE:23::3/64 no shutdown ! interface Serial1/2 ip address 10.0.34.3 255.255.255.0 ipv6 address FE80::3 link-local ipv6 address 2001:DB8:FEED:34::3/64 clock rate 64000 no shutdown   R4: interface Serial1/1 ip address 10.0.34.4 255.255.255.0 ipv6 address FE80::4 link-local ipv6 address 2001:DB8:FEED:34::4/64 no shutdown ! interface lo0 ip address 10.4.4.4 255.255.255.0 ipv6 address 2001:db8:4:4::1/64 ! ipv6 route 2001:DB8:CAFE::/48 2001:DB8:FEED:34::3 ip route 192.168.0.0 255.255.0.0 10.0.34.3   OSPFv3 with the addresses family (AF) unifies OSPF configuration for both IPv4 and IPv6.

OSPFv3 with address families also combines neighbor and the LSDB tables under a single OSPF process. OSPFv3 messages are sent over IPv6 and therefore we need to enable IPv6 routing using the ipv6 unicastrouting command and the interface should have a link-local IPv6 address. To enter the IPv4 address family configuration mode we should to use the address-family ipv4 unicast command. To enter the IPv6 address family configuration mode we should to use the address-family ipv6 unicast command. OSPFv3 is enabled directly on the interfaces for both IPv4 and IPv6 AFs. Notice that it isn’t necessary to configure a different router-ID for IPv4 and IPv6 AF.   R1(config)# router ospfv3 1 R1(config-router)# address-family ipv4 unicast R1(config-router-af)# router-id 1.1.1.1 R1(config-router-af)# passive-interface lo0 R1(config-router-af)# exit-address-family R1(config-router)# address-family ipv6 unicast R1(config-router-af)# router-id 1.1.1.2 R1(config-router-af)# passive-interface lo0 R1(config-router-af)# exit-address-family R1(config-router)# exit R1(config)# interface lo0 R1(config-if)# ospfv3 1 ipv4 area 20 R1(config-if)# ospfv3 1 ipv6 area 20 R1(config-if)# exit R1(config)# interface serial 1/1 R1(config-if)# ospfv3 1 ipv4 area 20 R1(config-if)# ospfv3 1 ipv6 area 20   R2(config)# router ospfv3 1 R2(config-router)# address-family ipv4 unicast R2(config-router-af)# router-id 2.2.2.2 R2(config-router-af)# passive-interface lo0 R2(config-router-af)# exit-address-family R2(config-router)# address-family ipv6 unicast R2(config-router-af)# router-id 2.2.2.3 R2(config-router-af)# passive-interface lo0 R2(config-router-af)# exit-address-family R2(config-router)# interface serial 1/0 R2(config-if)# ospfv3 1 ipv4 area 0 R2(config-if)# ospfv3 1 ipv6 area 0 R2(config-if)# exit R2(config)# interface lo0 R2(config-if)# ospfv3 1 ipv4 area 0 R2(config-if)# ospfv3 1 ipv6 area 0 R2(config-if)# exit R2(config)# interface serial 1/1 R2(config-if)# ospfv3 1 ipv4 area 20 R2(config-if)# ospfv3 1 ipv6 area 20   R3(config)# router ospfv3 1 R3(config-router)# address-family ipv4 unicast R3(config-router-af)# router-id 3.3.3.3 R3(config-router-af)#passive-interface lo0 R3(config-router-af)# exit-address-family R3(config-router)# address-family ipv6 unicast R3(config-router-af)# router-id 3.3.3.4 R3(config-router-af)# passive-interface lo0 R3(config-router-af)# exit-address-family

R3(config-router)# exit R3(config)#interface lo0 R3(config-if)# ospfv3 1 ipv4 R3(config-if)# ospfv3 1 ipv6 R3(config-if)# exit R3(config)# interface serial R3(config-if)# ospfv3 1 ipv4 R3(config-if)# ospfv3 1 ipv6

area 0 area 0 1/0 area 0 area 0

  Use the show ospfv3 neighbor command to verify OSPFv3 neighbor adjacencies for both the IPv4 and IPv6 AFs as follow on R2:   R2#show ospfv3 neighbor OSPFv3 1 address-family ipv4 (router-id 2.2.2.2) Neighbor ID Pri State Dead Time Interface ID Interface 3.3.3.3 0 FULL/ 00:00:38 3 Serial1/0 1.1.1.1 0 FULL/ 00:00:32 4 Serial1/1 OSPFv3 1 address-family ipv6 (router-id 2.2.2.3) Neighbor ID Pri State Dead Time Interface ID Interface 3.3.3.4 0 FULL/ 00:00:38 3 Serial1/0 1.1.1.2 0 FULL/ 00:00:30 4 Serial1/1 R2#   The IPv4 and IPv6 routing tables can be displayed by using the show ip route ospfv3 and show ipv6 route ospfv3 commands. We can see that each router has all IPv4 networks and IPv6 prefixes in the OSPFv3 routing domain including those with passive interfaces.   R1#show ip route ospfv3 | beg Gate Gateway of last resort is not set O IA 192.168.2.0/24 [110/65] via 192.168.12.2, 00:00:18, Serial1/1 O IA 192.168.3.0/24 [110/129] via 192.168.12.2, 00:00:08, Serial1/1 O IA 192.168.23.0/24 [110/128] via 192.168.12.2, 00:00:33, Serial1/1 R1#   R1#show ipv6 route ospf IPv6 Routing Table - default - 8 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OI 2001:DB8:CAFE:2::/64 [110/65] via FE80::2, Serial1/1 OI 2001:DB8:CAFE:3::/64 [110/129] via FE80::2, Serial1/1 OI 2001:DB8:CAFE:23::/64 [110/128] via FE80::2, Serial1/1 R1#   R3#show ip route ospfv3 | beg Gate Gateway of last resort is not set O IA 192.168.1.0/24 [110/129] via 192.168.23.2, 00:00:58, Serial1/0 O 192.168.2.0/24 [110/65] via 192.168.23.2, 00:00:58, Serial1/0 O IA 192.168.12.0/24 [110/128] via 192.168.23.2, 00:00:58, Serial1/0 R3#  

R3#show ipv6 route ospf IPv6 Routing Table - default - 10 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OI 2001:DB8:CAFE:1::/64 [110/129] via FE80::2, Serial1/0 O 2001:DB8:CAFE:2::/64 [110/65] via FE80::2, Serial1/0 OI 2001:DB8:CAFE:12::/64 [110/128] via FE80::2, Serial1/0 R3#   Now we need to Propagate IPv4 and IPv6 default routes into OSPFv3 on the ASBR R3 in order to have the reachability to R4.   R3(config)# ip route 0.0.0.0 0.0.0.0 10.0.34.4 R3(config)# ipv6 route ::/0 2001:db8:feed:34::4 R3(config)# router ospfv3 1 R3(config-router)# address-family ipv4 unicast R3(config-router-af)# default-information originate R3(config-router-af)# exit-address-family R3(config-router)# address-family ipv6 unicast R3(config-router-af)# default-information originate R3(config-router-af)# exit-address-family   Also configure IPv4 and IPv6 static routes on the ASBR R3 toward the 10.4.4.0/24 and 2001:db8:4:4::1/64 networks of R4. Then redistribute the static routes into OSPFv3 IPv4 and IPv6 AFs using the redistribute static command in each address family configuration mode.   R3(config)# ip route 10.4.4.0 255.255.255.0 10.0.34.4 R3(config)# ipv6 route 2001:db8:4:4::/64 2001:db8:feed:34::4 R3(config)# router ospfv3 1 R3(config-router)# address-family ipv4 unicast R3(config-router-af)# redistribute static R3(config-router-af)# exit-address-family R3(config-router)# address-family ipv6 unicast R3(config-router-af)# redistribute static   Let's verify the The IPv4 and IPv6 routing tables of R1 and R2 to verify that the default route and the redistributed static route are being advertised into the OSPFv3 domain:   R1#show ip route ospfv3 | beg Gate Gateway of last resort is 192.168.12.2 to network 0.0.0.0 O*E2 0.0.0.0/0 [110/1] via 192.168.12.2, 00:04:57, Serial1/1 10.0.0.0/24 is subnetted, 1 subnets O E2 10.4.4.0 [110/20] via 192.168.12.2, 00:02:26, Serial1/1 O IA 192.168.2.0/24 [110/65] via 192.168.12.2, 00:10:31, Serial1/1 O IA 192.168.3.0/24 [110/129] via 192.168.12.2, 00:10:21, Serial1/1 O IA 192.168.23.0/24 [110/128] via 192.168.12.2, 00:10:46, Serial1/1 R1#   R1#show ipv6 route ospf IPv6 Routing Table - default - 10 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route

B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OE2 ::/0 [110/1], tag 1 via FE80::2, Serial1/1 OE2 2001:DB8:4:4::/64 [110/20] via FE80::2, Serial1/1 OI 2001:DB8:CAFE:2::/64 [110/65] via FE80::2, Serial1/1 OI 2001:DB8:CAFE:3::/64 [110/129] via FE80::2, Serial1/1 OI 2001:DB8:CAFE:23::/64 [110/128] via FE80::2, Serial1/1 R1#   R2#show ip route ospfv3 | beg Gate Gateway of last resort is 192.168.23.3 to network 0.0.0.0 O*E2 0.0.0.0/0 [110/1] via 192.168.23.3, 00:04:27, Serial1/0 10.0.0.0/24 is subnetted, 1 subnets O E2 10.4.4.0 [110/20] via 192.168.23.3, 00:01:56, Serial1/0 O 192.168.1.0/24 [110/65] via 192.168.12.1, 00:10:15, Serial1/1 O 192.168.3.0/24 [110/65] via 192.168.23.3, 00:04:32, Serial1/0 R2#   R2#show ipv6 route ospf IPv6 Routing Table - default - 11 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OE2 ::/0 [110/1], tag 1 via FE80::3, Serial1/0 OE2 2001:DB8:4:4::/64 [110/20] via FE80::3, Serial1/0 O 2001:DB8:CAFE:1::/64 [110/65] via FE80::1, Serial1/1 O 2001:DB8:CAFE:3::/64 [110/65] via FE80::3, Serial1/0 R2#   Now let's configure area 20 as a an area Stub:   R1(config)# router ospfv3 1 R1(config-router)# address-family ipv4 unicast R1(config-router-af)# area 20 stub R1(config-router-af)# exit-address-family R1(config-router)# address-family ipv6 unicast R1(config-router-af)# area 20 stub   R2(config)# router ospfv3 1 R2(config-router)# address-family ipv4 unicast R2(config-router-af)# area 20 stub R2(config-router-af)# exit-address-family

R2(config-router)# address-family ipv6 unicast R2(config-router-af)# area 20 stub   Before configuring the area 20 as a Stub let's check the LSDB of R1, we can see that R1 has two LSAs Type 5 for the default and static routes for both IPv4 and IPv6 AFs:   R1#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Router Link States (Area 20) ADV Router Age Seq# Fragment ID Link count Bits 1.1.1.1 1740 0x80000002 0 1 None 2.2.2.2 1737 0x80000002 0 1 B Inter Area Prefix Link States (Area 20) ADV Router Age Seq# Prefix 2.2.2.2 1741 0x80000001 192.168.23.0/24 2.2.2.2 988 0x80000001 192.168.2.0/24 2.2.2.2 978 0x80000001 192.168.3.0/24 Inter Area Router Link States (Area 20) ADV Router Age Seq# Link ID Dest RtrID 2.2.2.2 659 0x80000001 50529027 3.3.3.3 Link (Type-8) Link States (Area 20) ADV Router Age Seq# Link ID Interface 1.1.1.1 1006 0x80000001 10 Lo0 1.1.1.1 65 0x80000002 4 Se1/1 2.2.2.2 1741 0x80000001 4 Se1/1 Intra Area Prefix Link States (Area 20) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 1.1.1.1 1006 0x80000002 0 0x2001 0 2.2.2.2 1741 0x80000001 0 0x2001 0 Type-5 AS External Link States ADV Router Age Seq# Prefix 3.3.3.3 665 0x80000001 0.0.0.0/0 3.3.3.3 504 0x80000001 10.4.4.0/24 OSPFv3 1 address-family ipv6 (router-id 1.1.1.2) Router Link States (Area 20) ADV Router Age Seq# Fragment ID Link count Bits 1.1.1.2 1740 0x80000002 0 1 None 2.2.2.3 1736 0x80000002 0 1 B Inter Area Prefix Link States (Area 20) ADV Router Age Seq# Prefix 2.2.2.3 1741 0x80000001 2001:DB8:CAFE:23::/64 2.2.2.3 988 0x80000001 2001:DB8:CAFE:2::/64 2.2.2.3 978 0x80000001 2001:DB8:CAFE:3::/64 Inter Area Router Link States (Area 20) ADV Router Age Seq# Link ID Dest RtrID 2.2.2.3 658 0x80000001 50529028 3.3.3.4 Link (Type-8) Link States (Area 20) ADV Router Age Seq# Link ID Interface 1.1.1.2 1006 0x80000001 10 Lo0 1.1.1.2 41 0x80000002 4 Se1/1 2.2.2.3 1741 0x80000001 4 Se1/1 Intra Area Prefix Link States (Area 20) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 1.1.1.2 1006 0x80000002 0 0x2001 0 2.2.2.3 1741 0x80000001 0 0x2001 0 Type-5 AS External Link States ADV Router Age Seq# Prefix 3.3.3.4 664 0x80000001 ::/0

3.3.3.4

502

0x80000001

2001:DB8:4:4::/64

  After configuring the area 20 as a Stub, the LSDB of R1 does not contain the LSAs Type 5 for both IPv4 and IPv6 AFs as shown by the show ospfv3 database command below, instead R2 creates and propagate an LSA Type 3 default route to R1:   R1#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Router Link States (Area 20) ADV Router Age Seq# Fragment ID Link count Bits 1.1.1.1 582 0x80000004 0 1 None 2.2.2.2 342 0x80000005 0 1 B Inter Area Prefix Link States (Area 20) ADV Router Age Seq# Prefix 2.2.2.2 342 0x80000002 192.168.23.0/24 2.2.2.2 1588 0x80000001 192.168.2.0/24 2.2.2.2 1578 0x80000001 192.168.3.0/24 2.2.2.2 584 0x80000001 0.0.0.0/0 Link (Type-8) Link States (Area 20) ADV Router Age Seq# Link ID Interface 1.1.1.1 592 0x80000002 10 Lo0 1.1.1.1 592 0x80000003 4 Se1/1 2.2.2.2 342 0x80000003 4 Se1/1 Intra Area Prefix Link States (Area 20) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 1.1.1.1 1606 0x80000002 0 0x2001 0 2.2.2.2 342 0x80000002 0 0x2001 0 OSPFv3 1 address-family ipv6 (router-id 1.1.1.2) Router Link States (Area 20) ADV Router Age Seq# Fragment ID Link count Bits 1.1.1.2 391 0x80000005 0 1 None 2.2.2.3 343 0x80000005 0 1 B Inter Area Prefix Link States (Area 20) ADV Router Age Seq# Prefix 2.2.2.3 343 0x80000002 2001:DB8:CAFE:23::/64 2.2.2.3 1588 0x80000001 2001:DB8:CAFE:2::/64 2.2.2.3 1578 0x80000001 2001:DB8:CAFE:3::/64 2.2.2.3 584 0x80000001 ::/0 Link (Type-8) Link States (Area 20) ADV Router Age Seq# Link ID Interface 1.1.1.2 591 0x80000002 10 Lo0 1.1.1.2 591 0x80000003 4 Se1/1 2.2.2.3 343 0x80000003 4 Se1/1 Intra Area Prefix Link States (Area 20) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 1.1.1.2 1606 0x80000002 0 0x2001 0 2.2.2.3 343 0x80000002 0 0x2001 0   Notice that R1 still has a default route pointing toward R2 but with a different cost than it had prior to being configured in a stub area. This is not the default route propagated by the ASBR R3 earlier, but the default route injected by the ABR R2 of the stub area. R1 also does not receive any external routes, so it no longer has the 10.4.4.0/24 or the 2001:DB8:4:4::/64 networks in its IPv4 and IPv6 routing tables. Notice that the Stub router R1 continue to receive inter-area routes from the ABR R2:   R1#show ip route ospfv3 | beg Gate Gateway of last resort is 192.168.12.2 to network 0.0.0.0 O*IA 0.0.0.0/0 [110/65] via 192.168.12.2, 00:00:58, Serial1/1 O IA 192.168.2.0/24 [110/65] via 192.168.12.2, 00:00:58, Serial1/1

O IA O IA R1#

192.168.3.0/24 [110/129] via 192.168.12.2, 00:00:58, Serial1/1 192.168.23.0/24 [110/128] via 192.168.12.2, 00:00:58, Serial1/1

  R1#show ipv6 route ospf IPv6 Routing Table - default - 9 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OI ::/0 [110/65] via FE80::2, Serial1/1 OI 2001:DB8:CAFE:2::/64 [110/65] via FE80::2, Serial1/1 OI 2001:DB8:CAFE:3::/64 [110/129] via FE80::2, Serial1/1 OI 2001:DB8:CAFE:23::/64 [110/128] via FE80::2, Serial1/1 R1#   We can verify OSPFv3 informations using the show ospfv3 command on ABR R2 to see what type each area is and the number of interfaces in each area.This command displays OSPFv3 information for both AFs:   R2#show ospfv3 OSPFv3 1 address-family ipv4 Router ID 2.2.2.2 Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic It is an area border router Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Retransmission limit dc 24 non-dc 24 Number of external LSA 2. Checksum Sum 0x00C807 Number of areas in this router is 2. 1 normal 1 stub 0 nssa Graceful restart helper support enabled Reference bandwidth unit is 100 mbps RFC1583 compatibility enabled Area BACKBONE(0) Number of interfaces in this area is 2 SPF algorithm executed 6 times Number of LSA 9. Checksum Sum 0x04D331 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Area 20 Number of interfaces in this area is 1 It is a stub area Generates stub default route with cost 1

SPF algorithm executed 4 times Number of LSA 10. Checksum Sum 0x05982C Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 OSPFv3 1 address-family ipv6 Router ID 2.2.2.3 Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic It is an area border router Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Retransmission limit dc 24 non-dc 24 Number of external LSA 2. Checksum Sum 0x00C400 Number of areas in this router is 2. 1 normal 1 stub 0 nssa Graceful restart helper support enabled Reference bandwidth unit is 100 mbps RFC1583 compatibility enabled Area BACKBONE(0) Number of interfaces in this area is 2 SPF algorithm executed 6 times Number of LSA 9. Checksum Sum 0x048B13 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Area 20 Number of interfaces in this area is 1 It is a stub area Generates stub default route with cost 1 SPF algorithm executed 4 times Number of LSA 10. Checksum Sum 0x056A77 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R2#   Let's configure the area 20 as a Totally Stubby Area by adding the no-summary keyword on the ABR R2 under the router ospfv3 process, as a result the ABR allows and propagates a single LSA Type 3 default route and filters all the LSAs Type 3 reducing the routing and the LSDB tables.   R2(config)# router ospfv3 1 R2(config-router)# address-family ipv4 unicast R2(config-router-af)# area 20 stub no-summary R2(config-router-af)# exit-address-family R2(config-router)# address-family ipv6 unicast R2(config-router-af)# area 20 stub no-summary  

The LSDB of R1 shows that the Inter Area Prefix LSA 3 are filtered except the LSA Type 3 default route for both IPv4 and IPv6 AFs:   R1#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Router Link States (Area 20) ADV Router Age Seq# Fragment ID Link count Bits 1.1.1.1 1040 0x80000004 0 1 None 2.2.2.2 800 0x80000005 0 1 B Inter Area Prefix Link States (Area 20) ADV Router Age Seq# Prefix 2.2.2.2 116 0x80000002 0.0.0.0/0 Link (Type-8) Link States (Area 20) ADV Router Age Seq# Link ID Interface 1.1.1.1 1051 0x80000002 10 Lo0 1.1.1.1 1051 0x80000003 4 Se1/1 2.2.2.2 800 0x80000003 4 Se1/1 Intra Area Prefix Link States (Area 20) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 1.1.1.1 116 0x80000003 0 0x2001 0 2.2.2.2 800 0x80000002 0 0x2001 0 OSPFv3 1 address-family ipv6 (router-id 1.1.1.2) Router Link States (Area 20) ADV Router Age Seq# Fragment ID Link count Bits 1.1.1.2 850 0x80000005 0 1 None 2.2.2.3 801 0x80000005 0 1 B Inter Area Prefix Link States (Area 20) ADV Router Age Seq# Prefix 2.2.2.3 115 0x80000002 ::/0 Link (Type-8) Link States (Area 20) ADV Router Age Seq# Link ID Interface 1.1.1.2 1049 0x80000002 10 Lo0 1.1.1.2 1049 0x80000003 4 Se1/1 2.2.2.3 801 0x80000003 4 Se1/1 Intra Area Prefix Link States (Area 20) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 1.1.1.2 102 0x80000003 0 0x2001 0 2.2.2.3 801 0x80000002 0 0x2001 0 R1#   The show ip route ospfv3 and show ipv6 route ospf commands displays the IPv4 and IPv6 routing tables of R1 . Notice that both routing tables displays only a single route which the default route represented by the inter-area prefix LSA 3 and advertised by the ABR R2. There are no inter-area OSPFv3 routes and no external OSPFv3 routes which the behavior of the Totally Stubby Area.   R1#show ip route ospfv3 | beg Gate Gateway of last resort is 192.168.12.2 to network 0.0.0.0 O*IA 0.0.0.0/0 [110/65] via 192.168.12.2, 00:15:34, Serial1/1 R1# R1#show ipv6 route ospf IPv6 Routing Table - default - 6 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OI ::/0 [110/65]

via FE80::2, Serial1/1 R1#   Finally let's use the show ospfv3 command on ABR R2 to see what type each area is and the number of interfaces in each area:   R2#show ospfv3 OSPFv3 1 address-family ipv4 Router ID 2.2.2.2 Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic It is an area border router Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Retransmission limit dc 24 non-dc 24 Number of external LSA 2. Checksum Sum 0x00C807 Number of areas in this router is 2. 1 normal 1 stub 0 nssa Graceful restart helper support enabled Reference bandwidth unit is 100 mbps RFC1583 compatibility enabled Area BACKBONE(0) Number of interfaces in this area is 2 SPF algorithm executed 7 times Number of LSA 9. Checksum Sum 0x05C239 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Area 20 Number of interfaces in this area is 1 It is a stub area, no summary LSA in this area Generates stub default route with cost 1 SPF algorithm executed 5 times Number of LSA 7. Checksum Sum 0x0373DE Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 OSPFv3 1 address-family ipv6 Router ID 2.2.2.3 Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic It is an area border router Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs

Retransmission pacing timer 66 msecs Retransmission limit dc 24 non-dc 24 Number of external LSA 2. Checksum Sum 0x00C400 Number of areas in this router is 2. 1 normal 1 stub 0 nssa Graceful restart helper support enabled Reference bandwidth unit is 100 mbps RFC1583 compatibility enabled Area BACKBONE(0) Number of interfaces in this area is 2 SPF algorithm executed 7 times Number of LSA 9. Checksum Sum 0x047B1B Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Area 20 Number of interfaces in this area is 1 It is a stub area, no summary LSA in this area Generates stub default route with cost 1 SPF algorithm executed 5 times Number of LSA 7. Checksum Sum 0x0415C2 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R2#      

Lab 7: NSSA Area Type In depth Exploration    

    Basic configuration of all routers:   R1: ipv uni !

interface Loopback0 ipv6 address 1::1/64 ! interface FastEthernet0/0 ipv6 address 12::1/64 ipv6 ospf 1 area 0 ! interface FastEthernet0/1 ipv6 address 13::1/64 ipv6 ospf 1 area 0 ! ipv6 router ospf 1 router-id 0.0.0.1 redistribute connected route-map TEST ! route-map TEST permit 10 match interface Loopback0   R2: ipv uni ! interface FastEthernet0/0 ipv6 address 12::2/64 ipv6 ospf 1 area 0 no shut ! interface FastEthernet0/1 ipv6 address 24::2/64 ipv6 ospf 1 area 1 no shut ! ipv6 router ospf 1 router-id 0.0.0.2   R3: ipv uni ! interface FastEthernet0/0 ipv6 address 13::3/64 ipv6 ospf 1 area 0 no shut ! interface FastEthernet0/1 ipv6 address 34::3/64 ipv6 ospf 1 area 1 no shut ! ipv6 router ospf 1 router-id 0.0.0.3   R4: ipv uni ! interface Loopback0 ipv6 address 4::4/64 ! interface FastEthernet0/0 ipv6 address 24::4/64

ipv6 ospf 1 area 1 no shut ! interface FastEthernet0/1 ipv6 address 34::4/64 ipv6 ospf 1 area 1 no shut ! ipv6 router ospf 1 router-id 0.0.0.4 area 1 nssa redistribute connected route-map TEST ! route-map TEST permit 10 match interface Loopback0   R4 redistribute the prefix 4::/64 into OSPF, so it creates a Type-7 LSA with the P-bit set and floods this LSA into the NSSA area 1:   R4#sh ipv os data nssa self OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Type-7 AS External Link States (Area 1) LS age: 123 LS Type: AS External Link Link State ID: 1 Advertising Router: 0.0.0.4 LS Seq Number: 80000001 Checksum: 0xD6A8 Length: 52 Prefix Address: 4:: Prefix Length: 64, Options: P Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 34::4 R4#   R1 redistributes the prefix 1::/64 into OSPF. R1 creates and floods a Type-5 LSA for 1::/64.   Below the Type-5 LSA received by R2 from R1:   R2#sh ipv os data ext adv 0.0.0.1 OSPFv3 Router with ID (0.0.0.2) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 11 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.1 LS Seq Number: 80000001 Checksum: 0x6B4 Length: 36 Prefix Address: 1:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R2#  

Below the Type-5 LSA received by R3 from R1:   R3#sh ipv os data ext adv 0.0.0.1 OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 31 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.1 LS Seq Number: 80000001 Checksum: 0x6B4 Length: 36 Prefix Address: 1:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R3#   Since an NSSA area block the Type-5 LSA, the AS-External originated by R1 cannot traverse the area 1, R4 will not learn the external route to 1::/64:   R4#sh ipv route 1::/64 % Route not found R4#   The end-to-end connectivity between the loopback interfaces fails:   R4#ping 1::1 source 4::4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1::1, timeout is 2 seconds: Packet sent with a source address of 4::4 ..... Success rate is 0 percent (0/5) R4#   To reach the prefix 1::/64, R4 should have a default route. There are two ways to have a default route in an NSSA. When you configure an area as NSSA, by default the NSSA ABR does not generate a default inter-area route. In the case of a stub area or an NSSA totally stub area, the NSSA ABR does generate a default inter-area route. First method:   Default Type-7   This configuration generates a Type-7 default route. The NSSA ABR can generate a default route with or without a default route in its own routing table.   The command used in to generate an NSSA default route:   On R2 and R3:   Rx(config)#ipv6 router ospf 1 Rx(config-rtr)#area 1 nssa default-information-originate   In the Type-7 LSA there is a P-bit = (P - propagate), it is only used in type-7 LSAs to tell the ABRs to translate that type-7 LSA into a type-5 LSA. This P-bit represents a routing loop prevention mechanism.   In this case The ABRs R2 and R3 originate type-7 default route and they MUST NOT set the P-bit. When these type-7 LSAs reach other ABRs, since they don't have the P-bit, they will not be considered for SFP calculations

and will not get to the routing table.   See RFC 3101 below:   Per RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option section:   2.4 Originating Type-7 LSAs   A Type-7 default LSA for the network 0.0.0.0/0 may be originated into the NSSA by any NSSA router. The Type-7 default LSA originated by an NSSA border router must have the P-bit clear. An NSSA ASBR that is not an NSSA border router may originate a Type-7 default LSA with the P-bit set. A Type-7 default LSA may be installed by NSSA border routers if and only if its P-bit is set..   R4 knows two Default Type-7 LSAs injected by R2 and R3 with the P-bit cleared (as denoted by the line: Options: None) in the OSPF database:   R4#sh ipv os data nssa adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Type-7 AS External Link States (Area 1) Routing Bit Set on this LSA LS age: 24 LS Type: AS External Link Link State ID: 4 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x599E Length: 44 Prefix Address: :: Prefix Length: 0, Options: None Metric Type: 2 (Larger than any link state path) Metric: 1 Forward Address: 24::2 R4#   R4#sh ipv os data nssa adv 0.0.0.3 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Type-7 AS External Link States (Area 1) Routing Bit Set on this LSA LS age: 21 LS Type: AS External Link Link State ID: 3 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x38AE Length: 44 Prefix Address: :: Prefix Length: 0, Options: None Metric Type: 2 (Larger than any link state path) Metric: 1 Forward Address: 34::3 R4#   Since R4 is not an ABR, it installs two default routes in the routing table:   R4#sh ipv route ::/0 Routing entry for ::/0

Known via "ospf 1", distance 110, metric 1, type NSSA extern 2 Route count is 2/2, share count 0 Routing paths: 24::2, FastEthernet0/0 Last updated 00:00:43 ago 34::3, FastEthernet0/1 Last updated 00:00:37 ago R4#   Now we have the end to end connectivity:   R4#ping 1::1 sou lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1::1, timeout is 2 seconds: Packet sent with a source address of 4::4 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 104/124/168 ms R4#   As you can see, R3 knows the Default Type-7 LSA injected by R2 in the OSPF database, but does not put them into the routing table - as an ABR, it does not accept Type-7 LSA without P-bit, in order to avoid routing loops.   R3#sh ipv os data nssa adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Type-7 AS External Link States (Area 1) LS age: 81 LS Type: AS External Link Link State ID: 4 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x599E Length: 44 Prefix Address: :: Prefix Length: 0, Options: None Metric Type: 2 (Larger than any link state path) Metric: 1 Forward Address: 24::2 R3#   The same conclusion is valid for R2, it learns the default Type-7 LSA from R3, since the P-bit is not set, R2 does not install a default route in its routing table:   R2#sh ipv os data nssa adv 0.0.0.3 OSPFv3 Router with ID (0.0.0.2) (Process ID 1) Type-7 AS External Link States (Area 1) LS age: 93 LS Type: AS External Link Link State ID: 3 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x38AE Length: 44 Prefix Address: :: Prefix Length: 0, Options: None Metric Type: 2 (Larger than any link state path) Metric: 1 Forward Address: 34::3 R2#

  There is no entry for the default route on R2 and R3:   R2#sh ipv route ::/0 % Route not found R2#   R3#sh ipv route ::/0 % Route not found R3#   To confirm, enable the debug ipv osp spf external command on R2 and R3:   R3#debug ipv os spf ext OSPFv3 spf external events debugging is on for process 1, IPv6, Default vrf R3#   R2#debug ipv os spf ext OSPFv3 spf external events debugging is on for process 1, IPv6, Default vrf R2#   Remove the area 1 nssa default-information-originate command and reconfigure it once again:   On R2 and R3:   Rx(config)#ipv router osp 1 Rx(config-rtr)#no area 1 nssa default-information-originate   Rx(config)#ipv router osp 1 Rx(config-rtr)#area 1 nssa default-information-originate   The output of the debug command on R2 and R3 shown that they ignore the default Type-7 LSA because it is untranslatable (in other words the P-bit is cleared):   R3#debug ipv os spf ext OSPFv3 spf external events debugging is on for process 1, IPv6, Default vrf R3# *Aug 7 13:47:46.863: OSPFv3-1-IPv6 SPF : Schedule partial SPF - 0.0.0.2/5 type 2007 *Aug 7 13:47:46.867: OSPFv3-1-IPv6 SPF : Service partial SPF Type3/4:0 Type5:0 Type7:1 *Aug 7 13:47:46.867: OSPFv3-1-IPv6 EXTER: Partial ASE SPF, Prefix ::/0, Type: 2007 *Aug 7 13:47:46.867: OSPFv3-1-IPv6 EXTER: NSSA LSA 0.0.0.2/5, age 2, seq 0x80000001, metric 1, type 2, ::/0 *Aug 7 13:47:46.871: OSPFv3-1-IPv6 EXTER: ignored, untranslatable default route R3#   R2#debug ipv os spf ext OSPFv3 spf external events debugging is on for process 1, IPv6, Default vrf R2# *Aug 7 13:48:56.791: OSPFv3-1-IPv6 SPF : Schedule partial SPF - 0.0.0.3/4 type 2007 *Aug 7 13:48:56.795: OSPFv3-1-IPv6 SPF : Service partial SPF Type3/4:0 Type5:0 Type7:1 *Aug 7 13:48:56.795: OSPFv3-1-IPv6 EXTER: Partial ASE SPF, Prefix ::/0, Type: 2007 *Aug 7 13:48:56.795: OSPFv3-1-IPv6 EXTER: NSSA LSA 0.0.0.3/4, age 2, seq 0x80000001, metric 1, type 2, ::/0 *Aug 7 13:48:56.799: OSPFv3-1-IPv6 EXTER: ignored, untranslatable default route R2#   Second method:

  Default Type-3   By defining an area as a NSSA totally stub area, the NSSA ABR generates a default Inter-Area route. As mentioned previously, if the NSSA area were not defined as totally stub, then a default Inter-Area route is not generated by NSSA ABR.   This configuration generates a default Inter-Area route for a NSSA totally stub area.   On R2 and R3:   Rx(config)#ipv router osp 1 Rx(config-rtr)#area 1 nssa no-summary   Below you can see that R4 receives two Default Type-3 LSAs from R2 and R3:   R4#sh ipv os data inter-area prefix ::/0 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Inter Area Prefix Link States (Area 1) Routing Bit Set on this LSA LS age: 155 LS Type: Inter Area Prefix Links Link State ID: 5 Advertising Router: 0.0.0.2 LS Seq Number: 80000002 Checksum: 0x6DC8 Length: 28 Metric: 1 Prefix Address: :: Prefix Length: 0, Options: None Routing Bit Set on this LSA LS age: 6 LS Type: Inter Area Prefix Links Link State ID: 5 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x69CC Length: 28 Metric: 1 Prefix Address: :: Prefix Length: 0, Options: None R4#   Since R4 is not an ABR, it installs two default routes in the routing table:   R4#sh ipv route ::/0 Routing entry for ::/0 Known via "ospf 1", distance 110, metric 2, type inter area Route count is 2/2, share count 0 Routing paths: FE80::C802:1CFF:FEE8:6, FastEthernet0/0 Last updated 00:03:03 ago FE80::C803:1CFF:FE54:6, FastEthernet0/1 Last updated 00:00:24 ago R4#   By definition an ABR advertises only intra-area routes from non-backbone area to the backbone area and advertise intra-area and inter-area routes from backbone area to a non-backbone area. ABRs do not take into account in SPF calculations LSAs received from non-backbone areas.

  See the draft published in 1999 by ietf: draft-ietf-ospf-abr-behavior-00.txt (OSPF ABR Behavior Alternative Implementation and Deployment Considerations):   3.4 Changes to Summary-LSA Origination   In order to implement described policy, the paragraph 2 in section 12.4.3 of [Ref1] should be read as follows:   "... Note that only intra-area routes are advertised into the backbone, while both intra-area and inter-area routes are advertised into the other areas. Also, summary-LSAs for inter-area routes are originated if and only if these routes are associated with the backbone area (to prevent loops of summary-LSAs)."   This behavior is confirmed by the RFC 3509 Alternative Implementations of OSPF Area Border Routers published in 2003.   1.2 Motivation   In OSPF domains the area topology is restricted so that there must be a backbone area (area 0) and all other areas must have either physical or virtual connections to the backbone. The reason for this star-like topology is that OSPF inter-area routing uses the distance-vector approach and a strict area hierarchy permits avoidance of the "counting to infinity" problem. OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, allowing ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes, and limiting ABRs' SPF calculation to consider only Summary-LSAs in the backbone area's link-state database.   In this scenario, R2 generates a Type-3 LSA default route, R3 stores this Type-3 LSA in its LSDB as shown below:   R3#sh ipv osp data inter-a prefix ::/0 adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Inter Area Prefix Link States (Area 1) LS age: 247 LS Type: Inter Area Prefix Links Link State ID: 5 Advertising Router: 0.0.0.2 LS Seq Number: 80000002 Checksum: 0x6DC8 Length: 28 Metric: 1 Prefix Address: :: Prefix Length: 0, Options: None R3#   R3 generates a Type-3 LSA default route, R2 stores this Type-3 LSA in its LSDB as shown below:   R2#sh ipv osp data inter-a prefix ::/0 adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.2) (Process ID 1) Inter Area Prefix Link States (Area 1) LS age: 272 LS Type: Inter Area Prefix Links Link State ID: 5

Advertising Router: 0.0.0.2 LS Seq Number: 80000002 Checksum: 0x6DC8 Length: 28 Metric: 1 Prefix Address: :: Prefix Length: 0, Options: None R2#   Because the inter-area loop prevention mechanism described above, an ABR ignores a Type-3 LSA learned through a non-backbone area, R2 and R3 do not put the default route in the routing table:   R2#sh ipv route ::/0 % Route not found R2#   R3#sh ipv route ::/0 % Route not found R3#   To confirm, execute the debug ipv os spf inter command on R2 and R3, the output of the debug command shown that the default Type-3 LSA is ignored because it is learned through a non-backbone area:   R3#debug ipv os spf inter OSPFv3 spf inter events debugging is on for process 1, IPv6, Default vrf R3# *Aug 7 14:00:38.095: OSPFv3-1-IPv6 SPF : Changed LSA 0.0.0.2/9, type 2003, area 1 *Aug 7 14:00:38.095: OSPFv3-1-IPv6 SPF : Detect MAXAGE in LSA 0.0.0.2/9, type 2003 *Aug 7 14:00:38.095: OSPFv3-1-IPv6 SPF : Schedule partial SPF - 0.0.0.2/9 type 2003 *Aug 7 14:00:38.099: OSPFv3-1-IPv6 SPF : Changed LSA 0.0.0.2/A, type 2003, area 1 *Aug 7 14:00:38.099: OSPFv3-1-IPv6 SPF : Detect MAXAGE in LSA 0.0.0.2/A, type 2003 *Aug 7 14:00:38.103: OSPFv3-1-IPv6 SPF : Schedule partial SPF - 0.0.0.2/A type 2003 *Aug 7 14:00:38.103: OSPFv3-1-IPv6 SPF : Changed LSA 0.0.0.2/8, type 2003, area 1 R3# *Aug 7 14:00:38.107: OSPFv3-1-IPv6 SPF : SPF due to NON-MAXAGE in LSA 0.0.0.2/8, type 2003 *Aug 7 14:00:38.107: OSPFv3-1-IPv6 SPF : Schedule partial SPF - 0.0.0.2/8 type 2003 *Aug 7 14:00:38.111: OSPFv3-1-IPv6 SPF : Service partial SPF Type3/4:3 Type5:0 Type7:0 *Aug 7 14:00:38.111: OSPFv3-1-IPv6 INTER: Partial IAP SPF, area 1, Prefix ::/0 *Aug 7 14:00:38.111: OSPFv3-1-IPv6 INTER: IAP LSA 0.0.0.2/8, age 2, seq 0x80000003 (area 1) ::/0 *Aug 7 14:00:38.115: OSPFv3-1-IPv6 INTER: ignored, Non-backbone LSA R3#   R2#debug ipv ospf spf inter OSPFv3 spf inter events debugging is on for process 1, IPv6, Default vrf R2# *Aug 7 14:01:53.747: OSPFv3-1-IPv6 SPF : Changed LSA 0.0.0.3/6, type 2003, area 1 *Aug 7 14:01:53.751: OSPFv3-1-IPv6 SPF : Detect MAXAGE in LSA 0.0.0.3/6, type 2003 *Aug 7 14:01:53.751: OSPFv3-1-IPv6 SPF : Schedule partial SPF - 0.0.0.3/6 type 2003 *Aug 7 14:01:53.755: OSPFv3-1-IPv6 SPF : Changed LSA 0.0.0.3/7, type 2003, area 1 *Aug 7 14:01:53.755: OSPFv3-1-IPv6 SPF : Detect MAXAGE in LSA 0.0.0.3/7, type 2003 *Aug 7 14:01:53.755: OSPFv3-1-IPv6 SPF : Schedule partial SPF - 0.0.0.3/7 type 2003 *Aug 7 14:01:53.759: OSPFv3-1-IPv6 SPF : Schedule partial SPF - 0.0.0.3/8 type 2003 R2# *Aug 7 14:01:53.763: OSPFv3-1-IPv6 SPF : Service partial SPF Type3/4:3 Type5:0 Type7:0 *Aug 7 14:01:53.763: OSPFv3-1-IPv6 INTER: Partial IAP SPF, area 1, Prefix ::/0 *Aug 7 14:01:53.763: OSPFv3-1-IPv6 INTER: IAP LSA 0.0.0.3/8, age 2, seq 0x80000001 (area 1) ::/0

*Aug R2#

7 14:01:53.767: OSPFv3-1-IPv6 INTER:

                                       

Lab 8: NSSA Area Type Filtering Options

  R1, R2 and R3 are running OSPFv3 AF. R2 and R4 are running EIGRP. R3 and R5 are running RIPv2.   R2 redistributes between OSPF and EIGRP. R3 redistributes between OSPF and RIP. area 23 is configured as NSSA.   R1:

ignored, Non-backbone LSA

interface Serial1/0 ip address 12.0.0.1 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 0 ! router ospfv3 1 ! address-family ipv4 unicast router-id 0.0.0.1 exit-address-family   R2: interface Serial1/0 ip address 12.0.0.2 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 0 ! interface Serial1/1 ip address 23.0.0.2 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 23 ! interface Serial1/2 ip address 24.0.0.2 255.255.255.0 ! router eigrp 100 network 24.0.0.2 0.0.0.0 redistribute ospf 1 metric 1 1 1 1 1 ! router ospfv3 1 ! address-family ipv4 unicast redistribute eigrp 100 router-id 0.0.0.2 area 23 nssa exit-address-family   R3: interface Serial1/0 ip address 35.0.0.3 255.255.255.0 ! interface Serial1/1 ip address 23.0.0.3 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 23 ! router ospfv3 1 ! address-family ipv4 unicast redistribute rip router-id 0.0.0.3 area 23 nssa exit-address-family ! router rip version 2 redistribute ospfv3 1 metric 2 network 35.0.0.0

no auto-summary   R4: interface Loopback0 ip address 4.4.4.4 255.255.255.0 ! interface Loopback1 ip address 10.4.4.4 255.255.255.0 ! interface Serial1/2 ip address 24.0.0.4 255.255.255.0 ! router eigrp 100 network 4.0.0.0 network 10.0.0.0 network 24.0.0.0   R5: interface Loopback0 ip address 5.5.5.5 255.255.255.0 ! interface Loopback1 ip address 10.5.5.5 255.255.255.0 ! interface Serial1/0 ip address 35.0.0.5 255.255.255.0 ! router rip version 2 network 5.0.0.0 network 10.0.0.0 network 35.0.0.0 no auto-summary   We will focus on the subnets 4.4.4.0/24, 10.4.4.0/24, 5.5.5.0/24 and 10.5.5.0/24:   In this topology, R2 has two areas (a backbone area and a non-backbone area NSSA) therefore when injecting external prefixes:   1-R2 originates two LSAs Type 7 for the subnets 4.4.4.0/24 and 10.4.4.0/24, and floods these LSAs into NSSA. 2-R2 originates two LSAs Type 5 for the subnets 4.4.4.0/24 and 10.4.4.0/24, and floods these LSAs into backbone area.   In other words R2 originates both LSA Type 5 and 7 for the same destination (Prefix Address), to avoid a loop, OSPF uses the P-bit option as a loop prevention mechanism, the P-bit = (P - propagate) is only used in type-7 LSAs to tell the ABRs to translate that LSA Type 7 into an LSA Type 5. This P-bit represents a routing loop prevention mechanism. How the it used to prevent a loop?   In this case when the NSSA ABR (R2) originates) an LSA Type 5 and LSA Type 7 for the same destination in other words with the same Prefix Address (4.4.4.0/24 and 10.5.5.0/24), the P-bit in the LSA Type 7 must be cleared in order to prevent another NSSA ABR to translate this LSA 7 into LSA Type 5, this rule is defined in the RFC 1587 and RFC 3101:   In RFC 1587, section 3.4:   3.4 Originating Type-7 LSAs   If a router is attached to another AS and is also an NSSA area border router, it may originate a both a type-5 and a type-7 LSA for the

same network. The type-5 LSA will be flooded to the backbone (and all attached type-5 capable areas) and the type-7 will be flooded into the NSSA. If this is the case, the P-bit must be reset in the type-7 NSSA so the type-7 LSA isn't again translated into a type-5 LSA by another NSSA area border router.   In RFC 3101, section 2.4:   2.4 Originating Type-7 LSAs   When an NSSA border router originates both a Type-5 LSA and a Type-7 LSA for the same network, then the P-bit must be clear in the Type-7 LSA so that it isn't translated into a Type-5 LSA by another NSSA border router. If the border router only originates a Type-7 LSA, it may set the P-bit so that the network may be aggregated/propagated during Type-7 translation. If an NSSA's border router originates a Type-5 LSA with a forwarding address from the NSSA, it should also originate a Type-7 LSA into the NSSA.   Let's verify the LSAs Type 7 originated by R2 for the Prefix Address 4.4.4.0/24 and 10.4.4.0/24, of course, they don't have the P-bit set, The "Options: None" field means that the P-bit is cleared:   R2#show ospfv3 database nssa-external 4.4.4.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Type-7 AS External Link States (Area 23) LS age: 416 LS Type: AS External Link Link State ID: 3 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0xBEA Length: 32 Prefix Address: 4.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R2#   R2#show ospfv3 database nssa-external 10.4.4.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Type-7 AS External Link States (Area 23) LS age: 423 LS Type: AS External Link Link State ID: 4 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x43AB Length: 32 Prefix Address: 10.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R2#   Below we can see the LSAs Type 5 for the same networks originated by R2 and flooded into area 0:   R2#show ospfv3 database external 4.4.4.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2)

Type-5 AS External Link States LS age: 225 LS Type: AS External Link Link State ID: 1 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x5980 Length: 32 Prefix Address: 4.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R2#   R2#show ospfv3 database external 10.4.4.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Type-5 AS External Link States LS age: 236 LS Type: AS External Link Link State ID: 2 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x9141 Length: 32 Prefix Address: 10.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R2#   Recall that R3 is an ASBR NSSA and it is redistributing the RIP routes subnets 5.5.5.0/24 and 10.5.5.0/24 into NSSA therefore it creates two LSAs Type 7, because R3 is not an ABR, it must set the P-bit in order to allow the NSSA ABR R2 to translate these LSAs 7 into LSAs 5.   Below we can see that the "Options: P" field means that the P-bit is set in the LSAs Type 7 received by R2 from R3:   R2#show ospfv3 database nssa-external 5.5.5.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Type-7 AS External Link States (Area 23) Routing Bit Set on this LSA LS age: 513 LS Type: AS External Link Link State ID: 3 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x209D Length: 48 Prefix Address: 5.5.5.0 Prefix Length: 24, Options: P Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 23.0.0.3 R2#   R2#show ospfv3 database nssa-external 10.5.5.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Type-7 AS External Link States (Area 23)

Routing Bit Set on this LSA LS age: 518 LS Type: AS External Link Link State ID: 4 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x4D6A Length: 48 Prefix Address: 10.5.5.0 Prefix Length: 24, Options: P Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 23.0.0.3 R2#   R2 looks the "Options: P" field and finds that the P-bit is set, therefore it translates successfully these LSA 7 into LSA 5 as shown by the show ospfv3 database external 5.5.5.0 and the show ospfv3 database external 10.5.5.0 outputs:   R2#show ospfv3 database external 5.5.5.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Type-5 AS External Link States LS age: 12 LS Type: AS External Link Link State ID: 5 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0xC9A Length: 48 Prefix Address: 5.5.5.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 23.0.0.3 R2#   R2#show ospfv3 database external 10.5.5.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Type-5 AS External Link States LS age: 4 LS Type: AS External Link Link State ID: 3 Advertising Router: 0.0.0.2 LS Seq Number: 80000003 Checksum: 0x534E Length: 48 Prefix Address: 10.5.5.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 23.0.0.3 R2#   Let's verify the routing tables of R1, R2 and R3:   The EIGRP redistributed routes 4.4.4.0/24 and 10.4.4.0/24 are installed as type NSSA extern 2 routes on R3:   R3#show ip route ospfv | beg Gate

Gateway of last resort is not set 4.0.0.0/24 is subnetted, 1 subnets O N2 4.4.4.0 [110/20] via 23.0.0.2, 00:01:29, Serial1/1 10.0.0.0/24 is subnetted, 2 subnets O N2 10.4.4.0 [110/20] via 23.0.0.2, 00:01:29, Serial1/1 12.0.0.0/24 is subnetted, 1 subnets O IA 12.0.0.0 [110/128] via 23.0.0.2, 00:01:29, Serial1/1 24.0.0.0/24 is subnetted, 1 subnets O N2 24.0.0.0 [110/20] via 23.0.0.2, 00:01:29, Serial1/1 R3#   The RIP redistributed routes 5.5.5.0/24 and 10..5.50/24 are installed as type NSSA extern 2 routes on R2:   R2#show ip route ospfv | beg Gate Gateway of last resort is not set 5.0.0.0/24 is subnetted, 1 subnets O N2 5.5.5.0 [110/20] via 23.0.0.3, 00:03:39, Serial1/1 10.0.0.0/24 is subnetted, 2 subnets O N2 10.5.5.0 [110/20] via 23.0.0.3, 00:03:39, Serial1/1 35.0.0.0/24 is subnetted, 1 subnets O N2 35.0.0.0 [110/20] via 23.0.0.3, 00:03:39, Serial1/1 R2#   R1 installs all the EIGRP and RIP routes in its routing tables as type extern 2 routes:   R1#show ip route ospfv | beg Gate Gateway of last resort is not set 4.0.0.0/24 is subnetted, 1 subnets O E2 4.4.4.0 [110/20] via 12.0.0.2, 00:04:51, Serial1/0 5.0.0.0/24 is subnetted, 1 subnets O E2 5.5.5.0 [110/20] via 12.0.0.2, 00:04:45, Serial1/0 10.0.0.0/24 is subnetted, 2 subnets O E2 10.4.4.0 [110/20] via 12.0.0.2, 00:04:51, Serial1/0 O E2 10.5.5.0 [110/20] via 12.0.0.2, 00:04:45, Serial1/0 23.0.0.0/24 is subnetted, 1 subnets O IA 23.0.0.0 [110/128] via 12.0.0.2, 00:12:49, Serial1/0 24.0.0.0/24 is subnetted, 1 subnets O E2 24.0.0.0 [110/20] via 12.0.0.2, 00:04:51, Serial1/0 35.0.0.0/24 is subnetted, 1 subnets O E2 35.0.0.0 [110/20] via 12.0.0.2, 00:04:45, Serial1/0 R1#   Now if we want to keep the rip routes only inside area 23 NSSA, we should add the "nssa-only" keyword in the redistribute command on R3:   R3(config)#router ospfv 1 R3(config-router)#address-family ipv4 unicast R3(config-router-af)#redistribute rip nssa-only   The "nssa-only" keyword instructs the NSSA ASBR R3 to clear the P-bit in the LSA Type 7 so that isn't translated into LSA Type 7:   The following outputs display the LSAs Type 7 for both the Prefix Address 5.5.5.0/24 and 10.5.5.0/24, the "Options: None" field means that the P-bit is cleared:   R2#show ospfv3 data nssa-ext 5.5.5.0 | i Options|Router Advertising Router: 0.0.0.3 Prefix Length: 24, Options: None

R2#   R2#show ospfv3 data nssa-ext 10.5.5.0 | i Options|Router Advertising Router: 0.0.0.3 Prefix Length: 24, Options: None R2#   R2 has the OSPF routes (type NSSA extern 2) in its routing table:   R2#show ip route 5.5.5.0 Routing entry for 5.5.5.0/24 Known via "ospfv3 1", distance 110, metric 20, type NSSA extern 2, forward metric 64 Last update from 23.0.0.3 on Serial1/1, 00:02:59 ago Routing Descriptor Blocks: * 23.0.0.3, from 0.0.0.3, 00:02:59 ago, via Serial1/1 Route metric is 20, traffic share count is 1 R2#   R2#show ip route 10.5.5.0 Routing entry for 10.5.5.0/24 Known via "ospfv3 1", distance 110, metric 20, type NSSA extern 2, forward metric 64 Last update from 23.0.0.3 on Serial1/1, 00:03:14 ago Routing Descriptor Blocks: * 23.0.0.3, from 0.0.0.3, 00:03:14 ago, via Serial1/1 Route metric is 20, traffic share count is 1 R2#   Since the translation is turned off with the P-bit cleared. So the rip routes are not learned by the backbone router R1:   R1#show ip route 5.5.5.0 % Network not in table R1#   R1#show ip route 10.5.5.0 % Subnet not in table R1#   Now if we want to control which type 7 LSAs get translated into type 5. For example the RIP route 10.5.5.0/24 that is injected into the OSPF NSSA Area 23, You do not want this route to be advertised into the the backbone area as a Type 5 LSA. But the RIP route 5.5.5.0/24 is allowed to be flooded into the backbone area, use the summary-prefix 10.5.5.0/24 nssa-only command on the NSSA ASBR R3 in order to accomplish this:   This command instructs the ASBR to clear the P-bit in the type 7 LSA for the Prefix Address 10.5.5.0/24 only so that it is not translated into type 5 by the NSSA ABR R2:   Before doing this task let's remove the redistribute rip nssa-only command:   R3(config)#router ospfv3 1 R3(config-router)#address-family ipv4 unicast R3(config-router-af)#no redistribute rip nssa-only R3(config-router-af)#summary-prefix 10.5.5.0/24 nssa-only   Below we can see that the P-bit is set in the LSA Type 7 for the Prefix Address 5.5.5.0/24, and the P-bit is cleared in the LSA Type 7 for the Prefix Address 10.5.5.0/24:   R2#show ospfv3 data nssa-ext 5.5.5.0 | i Options|Router Advertising Router: 0.0.0.3

Prefix Length: 24, Options: P R2#   R2#show ospfv3 data nssa-ext 10.5.5.0 | i Options|Router Advertising Router: 0.0.0.3 Prefix Length: 24, Options: None R2#   R1#show ip route 5.5.5.0 Routing entry for 5.5.5.0/24 Known via "ospfv3 1", distance 110, metric 20, type extern 2, forward metric 128 Last update from 12.0.0.2 on Serial1/0, 00:04:02 ago Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:04:02 ago, via Serial1/0 Route metric is 20, traffic share count is 1 R1#   R1#show ip route 10.5.5.0 % Subnet not in table R1#   Now if we want to block LSA Type 7 generation for the Prefix Address 5.5.5.0/24, we can use the summary-prefix 5.5.5.0/24 not-advertise command, the "not-advertise" keyword prevents the creation on the LSA Type 7 for the subnet 5.5.5.0/24.   Let's remove the previous configuration:   R3(config)#router ospfv3 1 R3(config-router)#address-family ipv4 unicast R3(config-router-af)#no summary-prefix 10.5.5.0/24 nssa-only R3(config-router-af)#summary-prefix 5.5.5.0/24 not-advertise   We can see below that R3 is not advertising an LSA Type 7 for the Prefix Address 5.5.5.0/24:   R2#show ospfv3 data nssa-ext 5.5.5.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Type-7 AS External Link States (Area 23) R2#   But R3 advertises an LSA Type 7 for the Prefix Address 10.5.5.0/24:   R2#show ospfv3 data nssa-ext 10.5.5.0 | i Options|Router Advertising Router: 0.0.0.3 Prefix Length: 24, Options: P R2#   We can see below that R1 does not have any route for the Prefix Address 5.5.5.0/24 but there is an entry for the Prefix Address 10.5.5.0/24 in the routing table:   R1#show ip route 5.5.5.0 % Network not in table R1#   R1#show ip route 10.5.5.0 Routing entry for 10.5.5.0/24 Known via "ospfv3 1", distance 110, metric 20, type extern 2, forward metric 128 Last update from 12.0.0.2 on Serial1/0, 00:04:06 ago

Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:04:06 ago, via Serial1/0 Route metric is 20, traffic share count is 1 R1#   Recall that R2 is advertising two LSAs Type 7 for the Prefixes 4.4.4.0/24 and 10.4.4.0/24:   R3#show ip route ospfv3 | beg Gate Gateway of last resort is not set 4.0.0.0/24 is subnetted, 1 subnets O N2 4.4.4.0 [110/20] via 23.0.0.2, 00:06:10, Serial1/1 10.0.0.0/24 is subnetted, 2 subnets O N2 10.4.4.0 [110/20] via 23.0.0.2, 00:06:10, Serial1/1 12.0.0.0/24 is subnetted, 1 subnets O IA 12.0.0.0 [110/128] via 23.0.0.2, 00:29:03, Serial1/1 24.0.0.0/24 is subnetted, 1 subnets O N2 24.0.0.0 [110/20] via 23.0.0.2, 00:06:10, Serial1/1 R3#   Now we can prevent R2 from creating type 7 LSAs for NSSA with the area 1 nssa no-redistribution command: Note: Only configure this command on an NSSA ASBR that is also an ABR.   R2(config)#router ospfv3 1 R2(config-router)#address-family ipv4 unicast R2(config-router-af)#area 23 nssa no-redistribution   Now the routing table of R3 does not contain any type NSSA extern 2 routes:   R3#show ip route ospfv3 | beg Gate Gateway of last resort is not set 12.0.0.0/24 is subnetted, 1 subnets O IA 12.0.0.0 [110/128] via 23.0.0.2, 00:31:11, Serial1/1 R3#   To allow the reachability of the EIGRP routes, we can add the no-summary keyword as follow:   R2(config)#router ospfv3 1 R2(config-router)#address-family ipv4 unicast R2(config-router-af)#area 23 nssa no-redistribution no-summary   The area 23 nssa command blocks the Type 5 LSAs from entering the area 1, "no-redistribution" keyword blocks the Type 7 LSAs, and the "no-summary" keyword blocks type 3 and 4. Instead the routed advertises a Type 3 LSA default route as shown by the show ospfv3 database inter-area prefix 0.0.0.0 command:   R2#show ospfv3 database inter-area prefix 0.0.0.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Inter Area Prefix Link States (Area 23) LS age: 53 LS Type: Inter Area Prefix Links Link State ID: 2 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x8DAC Length: 28 Metric: 1 Prefix Address: 0.0.0.0 Prefix Length: 0, Options: None R2#

  R3#show ospfv3 database inter-area prefix OSPFv3 1 address-family ipv4 (router-id 0.0.0.3) Inter Area Prefix Link States (Area 23) Routing Bit Set on this LSA LS age: 150 LS Type: Inter Area Prefix Links Link State ID: 2 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x8DAC Length: 28 Metric: 1 Prefix Address: 0.0.0.0 Prefix Length: 0, Options: None R3#   The routing table fof R3 contains only an inter-area default route (O*IA):   R3#show ip route ospfv3 | beg Gate Gateway of last resort is 23.0.0.2 to network 0.0.0.0 O*IA 0.0.0.0/0 [110/65] via 23.0.0.2, 00:02:31, Serial1/1 R3#   Let's remove the previous command with "no-summary" keyword and we will add the "default-informationoriginate" keyword The "default-information-originate" keyword allows the ABR to advertise a Type 7 LSA default route into NSSA, the Type 5 LSAs are blocked but the Type 3 LSAs are allowed.   R2(config)#router ospfv3 1 R2(config-router)#address-family ipv4 unicast R2(config-router-af)#no area 23 nssa no-redistribution no-summary R2(config-router-af)#area 23 nssa no-redistribution default-information-originate   Now the routing table of R3 contains type NSSA extern 2 default route (O*N2) in addition the inter-area route 12.0.0.0/24 coming from the backbone area:   R3#show ip route ospfv3 | beg Gate Gateway of last resort is 23.0.0.2 to network 0.0.0.0 O*N2 0.0.0.0/0 [110/1] via 23.0.0.2, 00:01:18, Serial1/1 12.0.0.0/24 is subnetted, 1 subnets O IA 12.0.0.0 [110/128] via 23.0.0.2, 00:01:41, Serial1/1 R3#   Now if we add the "no-summary" keyword in the previous command:   R2(config)#router ospfv3 1 R2(config-router)#address-family ipv4 unicast R2(config-router-af)#area 23 nssa no-redistribution default-information-originate no-summary   With "no-summary" keyword R2 blocks the LSA Type 3 for the prefix 12.0.0.0/24, and with "default-informationoriginate" and no-summary" keyword together, R2 advertises two default routes, one carried by an LSA Type 7 and another carried by an LSA Type 3 as shown by the show ospfv3 database nssa-external 0.0.0.0 and show ospfv3 database inter-area prefix 0.0.0.0 commands:   R3#show ospfv3 database nssa-external 0.0.0.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.3) Type-7 AS External Link States (Area 23)

LS age: 177 LS Type: AS External Link Link State ID: 17 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0xBEC Length: 44 Prefix Address: 0.0.0.0 Prefix Length: 0, Options: None Metric Type: 2 (Larger than any link state path) Metric: 1 Forward Address: 23.0.0.2 R3#   R3#show ospfv3 database inter-area prefix 0.0.0.0 OSPFv3 1 address-family ipv4 (router-id 0.0.0.3) Inter Area Prefix Link States (Area 23) Routing Bit Set on this LSA LS age: 50 LS Type: Inter Area Prefix Links Link State ID: 4 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x79BE Length: 28 Metric: 1 Prefix Address: 0.0.0.0 Prefix Length: 0, Options: None R3#   The routing table of R3 shown that the inter-area default route is installed instead of the type NSSA extern 2 default route because the the order of preference for OSPF routes according to RFC 3101 and 1587, the interarea route is always preferred than a type NSSA extern 2 route:   R3#show ip route ospfv3 | beg Gate Gateway of last resort is 23.0.0.2 to network 0.0.0.0 O*IA 0.0.0.0/0 [110/65] via 23.0.0.2, 00:02:40, Serial1/1 R3#                                          

                     

Lab 9: NSSA ABRs translator Condition  

  Basic configuration of all routers:   R1: ipv uni ! interface FastEthernet0/0 ip address 123.0.0.1 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 0 no shut ! router ospfv3 1 ! address-family ipv4 unicast router-id 1.1.1.1 exit-address-family   R2: ipv uni ! interface FastEthernet0/0 ip address 123.0.0.2 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 0 no shut ! interface Serial1/0 ip address 24.0.0.2 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 1 no shut ! router ospfv3 1 ! address-family ipv4 unicast router-id 2.2.2.2 exit-address-family   R3:

ipv uni ! interface FastEthernet0/0 ip address 123.0.0.3 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 0 no shut ! interface Serial1/0 ip address 34.0.0.3 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 1 no shut ! router ospfv3 1 ! address-family ipv4 unicast router-id 3.3.3.3 exit-address-family   R4: ipv uni ! interface Loopback0 ip address 4.4.4.4 255.255.255.0 ! interface Serial1/0 ip address 24.0.0.4 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 1 no shut ! interface Serial1/1 ip address 34.0.0.4 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 1 no shut ! router ospfv3 1 router-id 4.4.4.4 ! address-family ipv4 unicast redistribute connected route-map CONNECTED area 1 nssa exit-address-family ! route-map CONNECTED permit 10 match interface Loopback0   Area 1 an NSSA. R2 and R3 are ABRs NSSA. R4 is ASBR NSSA and redistributes the prefix 4.4.4.0/24 into NSSA:   We can see below that R4 creates LSA Type 7 for the prefix 4.4.4.0/24:   R4#show ospfv3 database nssa-external OSPFv3 1 address-family ipv4 (router-id 4.4.4.4) Type-7 AS External Link States (Area 1)

LS age: 63 LS Type: AS External Link Link State ID: 1 Advertising Router: 4.4.4.4 LS Seq Number: 80000001 Checksum: 0x6148 Length: 48 Prefix Address: 4.4.4.0 Prefix Length: 24, Options: P Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 34.0.0.4 R4#   From RFC 3101, If there are multiple NSSA ABRs capable of performing Type 7-to-5 translation, the router advertising with higher Router ID is elected as the translator. The NSSA ABR that is no longer required to perform translation, flushes its Type 5 LSAs. In this case the RID of R2 is 2.2.2.2 and the RID of R3 is 3.3.3.3 thus R3 wins and performs the translation of LSA 7 into LSA5, the show ospv3 data ext command below shown the LSA Type 5 originated by R3:   R3#show ospfv3 database external OSPFv3 1 address-family ipv4 (router-id 3.3.3.3) Type-5 AS External Link States LS age: 116 LS Type: AS External Link Link State ID: 0 Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x8315 Length: 48 Prefix Address: 4.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 34.0.0.4 R3#   We can verify that R2 does not originate LSA Type 5 using the show ospfv3 database external self-originate command and it learns the LSA Type 5 from R3 as shown by the show ospfv3 database external adv 3.3.3.3 command:   R2#show ospfv3 database external self-originate OSPFv3 1 address-family ipv4 (router-id 2.2.2.2) R2# R2#show ospfv3 database external adv 3.3.3.3 OSPFv3 1 address-family ipv4 (router-id 2.2.2.2) Type-5 AS External Link States LS age: 286 LS Type: AS External Link Link State ID: 0 Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x8315 Length: 48 Prefix Address: 4.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20

Forward Address: 34.0.0.4 R2#   R3#show ospfv3 database external self-originate OSPFv3 1 address-family ipv4 (router-id 3.3.3.3) Type-5 AS External Link States LS age: 217 LS Type: AS External Link Link State ID: 0 Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x8315 Length: 48 Prefix Address: 4.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 34.0.0.4 R3#   The show ospfv3 is another way to verify which NSSA ABR is performing the translation, below the output displayed on R3 shown that it is the translator, notice line "Perform type-7/type-5 LSA translation" :   R3#show ospfv3 OSPFv3 1 address-family ipv4 Router ID 3.3.3.3 Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic It is an area border and autonomous system boundary router Redistributing External Routes from, Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Retransmission limit dc 24 non-dc 24 Number of external LSA 1. Checksum Sum 0x00791E Number of areas in this router is 2. 1 normal 0 stub 1 nssa Graceful restart helper support enabled Reference bandwidth unit is 100 mbps RFC1583 compatibility enabled Area BACKBONE(0) Number of interfaces in this area is 1 SPF algorithm executed 7 times Number of LSA 12. Checksum Sum 0x065EE8 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Area 1 Number of interfaces in this area is 1 It is a NSSA area Perform type-7/type-5 LSA translation SPF algorithm executed 10 times

Number of LSA 11. Checksum Sum 0x0551F8 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R3#   The same command show ospfv3 can be used on R2 to verify that there is no mention of the message "Perform type-7/type-5 LSA translation":   R2#show ospfv3 OSPFv3 1 address-family ipv4 Router ID 2.2.2.2 Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic It is an area border and autonomous system boundary router Redistributing External Routes from, Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Retransmission limit dc 24 non-dc 24 Number of external LSA 1. Checksum Sum 0x009704 Number of areas in this router is 2. 1 normal 0 stub 1 nssa Graceful restart helper support enabled Reference bandwidth unit is 100 mbps RFC1583 compatibility enabled Area BACKBONE(0) Number of interfaces in this area is 1 SPF algorithm executed 12 times Number of LSA 12. Checksum Sum 0x065EE8 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Area 1 Number of interfaces in this area is 1 It is a NSSA area SPF algorithm executed 17 times Number of LSA 11. Checksum Sum 0x057503 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R2#   In the outputs of the show ospfv3 command displayed above on R2 and R3, we can see that the RFC 3101 is enabled as shown by the line "Supports NSSA (compatible with RFC 3101)".   We can Configure the NSSA ABR R2 as a forced NSSA LSA 7 translator using the area 1 nssa translate type7 always command, the always keyword configures an NSSA ABR as a forced NSSA LSA 7 translator:   R2(config)#router ospfv3 1

R2(config-router)#address-family ipv4 unicast R2(config-router-af)#area 1 nssa translate type7 always   Below we can see that R2 is originating the LSA Type 5:   R2#show ospfv3 database external OSPFv3 1 address-family ipv4 (router-id 2.2.2.2) Type-5 AS External Link States LS age: 31 LS Type: AS External Link Link State ID: 2 Advertising Router: 2.2.2.2 LS Seq Number: 80000001 Checksum: 0x8D0D Length: 48 Prefix Address: 4.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 34.0.0.4 R2#   Let's confirm with the show ospfv3 command that R2 is the translator:   1-The line "Configured to translate Type-7 LSAs" tells us that R2 is configured as a forced NSSA ABR translator. 2-The line "Perform type-7/type-5 LSA translation" tells us that R2 is NSSA ABR performing the translation.   R2#show ospfv3 | incl 7 Configured to translate Type-7 LSAs Perform type-7/type-5 LSA translation R2#   RFC 5340 defines a new bit Nt bit (Nt stands for NSSA translation) in the Type-1 LSA for OSPFv3.   RFC 5340 section: A.4.3. Router-LSAs   Bit Nt When set, the router is an NSSA border router that is unconditionally translating NSSA-LSAs into AS-external-LSAs (Nt stands for NSSA translation). Note that such routers have their NSSATranslatorRole area configuration parameter set to Always. (See [NSSA].)   RFC 3101 includes also the Nt Bit explained in the following option:   Appendix B: Router-LSAs   bit Nt When set, the router is an NSSA border router that is unconditionally translating Type-7 LSAs into Type-5 LSAs (Nt stands for NSSA translation). Note that such routers have their NSSATranslatorRole area configuration parameter set to Always. (See Appendix D and Section 3.1.)   Appendix D: Configuration Parameters   NSSATranslatorRole

  Specifies whether or not an NSSA border router will unconditionally translate Type-7 LSAs into Type-5 LSAs. When it is set to Always, an NSSA border router always translates Type-7 LSAs into Type-5 LSAs regardless of the translator state of other NSSA border routers. When it is set to Candidate, an NSSA border router participates in the translator election process described in Section 3.1. The default setting is Candidate.   The LSA Type 1 originated by R2 in Area 1 shows the line "The “Unconditional NSSA translator", it indicates that the status of the NSSA ASBR router is as a forced NSSA LSA translator. This means that the Nt-Bit is set in LSA Type 1:   R2#show ospfv data router self | beg Area 1 Router Link States (Area 1) LS age: 226 Options: (N-Bit, R-bit, DC-Bit, AF-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 2.2.2.2 LS Seq Number: 80000002 Checksum: 0x8006 Length: 40 Area Border Router AS Boundary Router Unconditional NSSA translator Number of Links: 1 Link connected to: another Router (point-to-point) Link Metric: 64 Local Interface ID: 4 Neighbor Interface ID: 4 Neighbor Router ID: 4.4.4.4 R2#   By default the RFC 3101 is enabled on R2, let's enable RFC 1587 using the compatible rfc1587 command:   R2(config)#router ospfv 1 R2(config-router)#address-family ipv4 uni R2(config-router-af)#compatible rfc1587   Let's see what happen for the translation, below we can see that R3 is originating the LSA Type 5 and it is the translator:   R2#show ospfv3 database external OSPFv3 1 address-family ipv4 (router-id 2.2.2.2) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 13 LS Type: AS External Link Link State ID: 2 Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x6F27 Length: 48 Prefix Address: 4.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path)

Metric: 20 Forward Address: 34.0.0.4 R2#   Let's verify the always keyword on R2, it's clear the area 1 nssa translate type7 always command is still here:   R2#show run | s router router ospfv3 1 ! address-family ipv4 unicast router-id 2.2.2.2 compatible rfc1587 area 1 nssa translate type7 always exit-address-family R2#   Let's confirm that R3 is the translator using the show ospfv3 command:   R3#show ospfv3 | incl 7|RFC Supports NSSA (compatible with RFC 3101) Number of external LSA 1. Checksum Sum 0x006F27 RFC1583 compatibility enabled SPF algorithm executed 7 times Perform type-7/type-5 LSA translation R3#   Why R3 is the translator even though R2 is the forced NSSA ABR translator ?   Let's see the show ospfv3 command on R2, two things we can deduce from the output:   From cisco:   1-the line "Supports NSSA (compatible with RFC 1587)" Specifies that RFC 1587 is active or that the OSPFv3 NSSA area is RFC 1587 compatible. 2-the line "Configured to translate Type-7 LSAs, inactive (RFC3101 support disabled)" Specifies that the OSPFv3 NSSA area has an ABR device configured to act as a forced translator of Type 7 LSA. However, it is inactive because RFC 3101 is disabled.   As a result, because R2 is implementing the RFC 1587 and the RFC 3101 is disabled, OSPFv3 ignores the area 1 nssa translate type7 always command, and the tie breaker is the router-id:   R2#show ospfv3 OSPFv3 1 address-family ipv4 Router ID 2.2.2.2 Supports NSSA (compatible with RFC 1587) Event-log enabled, Maximum number of events: 1000, Mode: cyclic It is an area border and autonomous system boundary router Redistributing External Routes from, Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Retransmission limit dc 24 non-dc 24 Number of external LSA 1. Checksum Sum 0x006F27

Number of areas in this router is 2. 1 normal 0 stub 1 nssa Graceful restart helper support enabled Reference bandwidth unit is 100 mbps RFC1583 compatibility enabled Area BACKBONE(0) Number of interfaces in this area is 1 SPF algorithm executed 13 times Number of LSA 12. Checksum Sum 0x065EE8 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Area 1 Number of interfaces in this area is 1 It is a NSSA area Configured to translate Type-7 LSAs, inactive (RFC3101 support disabled) SPF algorithm executed 21 times Number of LSA 11. Checksum Sum 0x057105 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R2#   Let's enable RFC 1587 on R3:   R3(config)#router ospfv 1 R3(config-router)#address-family ipv4 unicast R3(config-router-af)#compatible rfc1587   The show ospfv3 command shown that R3 is the translator because it has a higher router-id:   R3#show ospfv3 | sec type-7|RFC Supports NSSA (compatible with RFC 1587) RFC1583 compatibility enabled Area BACKBONE(0) Perform type-7/type-5 LSA translation R3#   Therefore R3 originates LSA Type 5 as shown by the show ospfv3 database external command:   R3#show ospfv3 database external OSPFv3 1 address-family ipv4 (router-id 3.3.3.3) Type-5 AS External Link States LS age: 709 LS Type: AS External Link Link State ID: 2 Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x6F27 Length: 48 Prefix Address: 4.4.4.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 34.0.0.4 R3#  

Let's confirm by changing the router-id of R2 to be higher than 3.3.3.3, for example 22.22.22.22, clear the OSPFv3 process using the clear ospfv3 process command:   R2(config)#router ospfv 1 R2(config-router)#address-family ipv4 unicast R2(config-router-af)#router-id 22.22.22.22 % OSPFv3-1-IPv4: Reload or use "clear ospfv3 process" command, for this to take effect R2(config-router-af)#do clea ospfv3 pro Reset selected OSPFv3 processes? [no]: y R2(config-router-af)# *Sep 18 08:57:51.563: %OSPFv3-5-ADJCHG: Process 1, IPv4, Nbr 1.1.1.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Sep 18 08:57:51.567: %OSPFv3-5-ADJCHG: Process 1, IPv4, Nbr 3.3.3.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Sep 18 08:57:51.647: %OSPFv3-5-ADJCHG: Process 1, IPv4, Nbr 4.4.4.4 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Sep 18 08:57:52.375: %OSPFv3-5-ADJCHG: Process 1, IPv4, Nbr 4.4.4.4 on Serial1/0 from LOADING to FULL, Loading Done   Now R2 is the Translator because it has a higher router-id:   R2#show ospfv3 | incl 7|RFC Supports NSSA (compatible with RFC 1587) RFC1583 compatibility enabled Configured to translate Type-7 LSAs, inactive (RFC3101 support disabled) Perform type-7/type-5 LSA translation R2#   R3#show ospfv3 | beg Area 1 Area 1 Number of interfaces in this area is 1 It is a NSSA area SPF algorithm executed 17 times Number of LSA 11. Checksum Sum 0x049B1A Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R3#                                        

                                             

Lab 10: Path Selection Scenario 1  

    Basic configuration of all routers:   R1: interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ip ospf 1 area 0 ip ospf cost 65000 no shut ! interface FastEthernet0/1 ip address 13.0.0.1 255.255.255.0 ip ospf 1 area 2 ip os cost 1 no shut ! router ospf 1 router-id 1.1.1.1   R2: interface FastEthernet0/0

ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 0 ip os cost 1 no shut ! interface FastEthernet0/1 ip address 24.0.0.2 255.255.255.0 ip ospf 1 area 1 ip os cost 1 no shut ! router ospf 1 router-id 2.2.2.2   R3: interface FastEthernet0/0 ip address 13.0.0.3 255.255.255.0 ip ospf 1 area 2 ip os cost 1 no shut ! interface FastEthernet0/1 ip address 34.0.0.3 255.255.255.0 ip ospf 1 area 2 ip ospf cost 65000 no shut ! router ospf 1 router-id 3.3.3.3   R4: interface FastEthernet0/0 ip address 24.0.0.4 255.255.255.0 ip ospf 1 area 1 ip os cost 1 no shut ! interface FastEthernet0/1 ip address 34.0.0.4 255.255.255.0 ip ospf 1 area 2 ip ospf cost 65000 no shut ! interface FastEthernet1/0 ip address 46.0.0.4 255.255.255.0 no shut ! router eigrp 100 network 46.0.0.0 redistribute ospf 1 metric 1 1 1 1 1 ! router ospf 1 router-id 4.4.4.4 redistribute eigrp 100 subnets   R6: interface Loopback0 ip address 6.6.6.6 255.255.255.0

! interface FastEthernet0/0 ip address 46.0.0.6 255.255.255.0 no shut ! router eigrp 100 network 6.0.0.0 network 46.0.0.0   R4 is an ASBR and redistributes between OSPF and EIGRP, the EIGRP routes are redistributed with the default metric-type 2 and default metric 20 using the redistribute eigrp 100 subnets command: The cost of the Links between the OSPF routers are modified as illustrated in the topology.   Let's verify the routing table of R1. R1 installes an OE2 (external type 2) with next-hop R3 toward 6.6.6.0, therefore it prefers the path through R3 rather than the path through R2, why ?   R1#show ip route | inc 6.6.6.0 O E2 6.6.6.0 [110/20] via 13.0.0.3, 00:01:39, FastEthernet0/1 R1# R1#show ip route 6.6.6.0 Routing entry for 6.6.6.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 65001 Last update from 13.0.0.3 on FastEthernet0/1, 00:01:42 ago Routing Descriptor Blocks: * 13.0.0.3, from 4.4.4.4, 00:01:42 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1 R1#   Below we can see that R1 receives an LSA Type 5 from R4 with the Forward Address 0.0.0.0, this means that R1 will look the best path to reach the ASBR R4:   R1#show ip ospf database external 6.6.6.0 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: 254 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 6.6.6.0 (External Network Number ) Advertising Router: 4.4.4.4 LS Seq Number: 80000001 Checksum: 0x96E7 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 R1#   R1 has two paths to reach R4:   An intra-area route via R3 with a cost 65001. The cost 65001 is displayed by the show ip ospf border-routers command below. An inter-area route via R2 with a cost 2. This cost is the cummulative of the cost 1 to reach the ABR R2 as shown by the show ip ospf border-routers command and the cost 1 listed in the LSA Type 4 advertised by R2 as shown by the show ip ospf database asbr-summary adv 2.2.2.2

command (the LSA Type 4 is created by the ABR R2 to tell to R1 how to reach the ASBR R4 and it lists the cost from the ABR R2's perspective toward the ASBR R4).   R1 chooses the intra-area route rather than the inter-area route because the intra-area route is always preferred than the inter-area route regardless the cost and even if the intra-area route has a cost 65001 higher than the cost 2 of the inter-area route.   The forward metric 65001 listed in the shown ip route 6.6.6.0 command represents the metric to reach the ASBR R4 via the intra-area route through R3.   R1#show ip os border-routers OSPF Router with ID (1.1.1.1) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route i4.4.4.4 [65001] via 13.0.0.3, FastEthernet0/1, ASBR, Area 2, SPF 9 i 2.2.2.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 11 R1#   R1#show ip ospf database asbr-summary adv 2.2.2.2 OSPF Router with ID (1.1.1.1) (Process ID 1) Summary ASB Link States (Area 0) LS age: 1026 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(AS Boundary Router) Link State ID: 4.4.4.4 (AS Boundary Router address) Advertising Router: 2.2.2.2 LS Seq Number: 80000001 Checksum: 0x9092 Length: 28 Network Mask: /0 MTID: 0 Metric: 1 R1#   The traceroute issued on R1 shows that the packet goes through R3:   R1#tracer 6.6.6.6 Type escape sequence to abort. Tracing the route to 6.6.6.6 VRF info: (vrf in name/id, vrf out name/id) 1 13.0.0.3 68 msec 48 msec 56 msec 2 34.0.0.4 96 msec 96 msec 88 msec 3 46.0.0.6 96 msec 116 msec 96 msec R1#   Now let's disable the link R1--R3:   R1(config)#int fa0/1 R1(config-if)#shutdown   Let's verify the routing table about the prefix 6.6.6.0/24, R1 installs the backup path through R2 with a forward metric 2 which is the cost of the inter-area route to reach the ASBR R4:   R1#show ip route | incl 6.6.6.0 O E2 6.6.6.0 [110/20] via 12.0.0.2, 00:00:16, FastEthernet0/0 R1#   R1#show ip route 6.6.6.0

Routing entry for 6.6.6.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2 Last update from 12.0.0.2 on FastEthernet0/0, 00:00:24 ago Routing Descriptor Blocks: * 12.0.0.2, from 4.4.4.4, 00:00:24 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1 R1#   This forward metric can be seen through the show ip ospf border-routers command as shown below, notice the code I for Inter-area route and the cost 2 to reach the R4 with RID 4.4.4.4:   R1#show ip ospf border-routers OSPF Router with ID (1.1.1.1) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route I4.4.4.4 [2] via 12.0.0.2, FastEthernet0/0, ASBR, Area 0, SPF 12 i 2.2.2.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 12 R1#   Now what happen if we configure area 1 and area 2 as Not-So-Stubby-Area NSSA ?  

    Let's configure area 1 and area 2 as NSSA and verify the routing table of R1:   On R2 and R4:   Rx(config)#router os 1 Rx(config-router)#area 1 nssa   On R1, R3 and R4:   Rx(config)#router os 1 Rx(config-router)#area 2 nssa   R1 installs an OE2 route toward 6.6.6.0/24 via R2:   R1#show ip route | inc 6.6.6.0 O E2 6.6.6.0 [110/20] via 12.0.0.2, 00:00:58, FastEthernet0/0 R1#   R1#show ip route 6.6.6.0 Routing entry for 6.6.6.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2 Last update from 12.0.0.2 on FastEthernet0/0, 00:01:06 ago

Routing Descriptor Blocks: * 12.0.0.2, from 2.2.2.2, 00:01:06 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1 R1#   Why R1 is installing an OE2 route through R2 rather than an ON2 route through R3 ? R4 creates and advertises two LSAs Type 7.   An LSA Type 7 with Forward Address 24.0.0.4 (the ip address of R4's fa0/0) and floods this LSA into area 1 NSSA. The ABR R2 translates this LSA Type 7 into LSA Type 5 and copies the same Forward Address and floods this LSA Type 5 into area 0.   An LSA Type 7 with Forward Address 34.0.0.4 (the ip address of R4's Fa0/1) and floods this LSA into area 2 NSSA   R1 receives an LSA 5 from R2 via area 0 with FA 24.0.0.4 , it receives also an LSA Type 7 from R4 via area 2 with FA 34.0.0.4.   R1#show ip ospf database nssa-external 6.6.6.0 OSPF Router with ID (1.1.1.1) (Process ID 1) Type-7 AS External Link States (Area 2) LS age: 356 Options: (No TOS-capability, Type 7/5 translation, DC, Upward) LS Type: AS External Link Link State ID: 6.6.6.0 (External Network Number ) Advertising Router: 4.4.4.4 LS Seq Number: 80000001 Checksum: 0xB19C Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 34.0.0.4 External Route Tag: 0 R1#   R1#show ip ospf database external 6.6.6.0 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: 417 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 6.6.6.0 (External Network Number ) Advertising Router: 2.2.2.2 LS Seq Number: 80000001 Checksum: 0x1456 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 24.0.0.4 External Route Tag: 0 R1#   R1 looks the best path OSPF to reach the Forward Addresses 24.0.0.4 and 34.0.0.4.  

R1 finds that it has an inter-area route to reach 24.0.0.0/24 with cost 2 as shown by the show ip route 24.0.0.0 command. R1 finds also that it has an intra-area route to reach 34.0.0.0/24 with cost 65001 as shown by the show ip route 34.0.0.0 command.   R1#show ip route 24.0.0.0 Routing entry for 24.0.0.0/24, 1 known subnets O IA 24.0.0.0 [110/2] via 12.0.0.2, 00:05:39, FastEthernet0/0 R1#   R1#show ip route 34.0.0.0 Routing entry for 34.0.0.0/24, 1 known subnets O 34.0.0.0 [110/65001] via 13.0.0.3, 00:04:34, FastEthernet0/1 R1#   Since the two ospf routes (intra and inter areas routes) are pointed to different destination, it cannot prefer the intra-area route over the inter-area route, therefore R1 looks the best metric and the cost 2 of the inter-area route via R2 is better than the cost 65001 of the intra-area route via R3, as a result it prefers the OE2 route learned from R2 rather than the ON2 route learned from R4, in other words in this case intra-area and inter-area routes do not matter because they area different destinations, the traceroute shows that the packet goes through R2:   R1#traceroute 6.6.6.6 Type escape sequence to abort. Tracing the route to 6.6.6.6 VRF info: (vrf in name/id, vrf out name/id) 1 12.0.0.2 60 msec 68 msec 76 msec 2 24.0.0.4 92 msec 84 msec 100 msec 3 46.0.0.6 104 msec 112 msec 116 msec R1#   Remember that the best cost 2 of the inter-area route to 24.0.0.0/24 is displayed as forward metric 2 in the show ip route 6.6.6.0/24.   Now let's change the cost of fa0/0 interface's R1 toward R2 to 65002:   R1(config)#int fa0/0 R1(config-if)#ip ospf cost 65002   R1 finds that it has an inter-area route to reach 24.0.0.0/24 with cost 65003 as shown by the show ip route 24.0.0.0 command. R1 finds also that it has an intra-area route to reach 34.0.0.0/24 with cost 65001 as shown by the show ip route 34.0.0.0 command.   The cost 65001 of the intra-area route via R3 is better than the cost 65003 of the inter-area route via R2 and as a result R1 installs an ON2 route through R3:   R1#show ip route 24.0.0.0 Routing entry for 24.0.0.0/24, 1 known subnets O IA 24.0.0.0 [110/65003] via 12.0.0.2, 00:00:17, FastEthernet0/0 R1#   R1#show ip route 34.0.0.0 Routing entry for 34.0.0.0/24, 1 known subnets O 34.0.0.0 [110/65001] via 13.0.0.3, 00:08:32, FastEthernet0/1 R1#   The routing table of R1 displays an ON2 route, the forward metric 65001 is the cost of the intra-area route toward 34.0.0.3/24 and the packet goes through R3 as shown by the traceroute below:

  R1#show ip route | inc 6.6.6.0 O N2 6.6.6.0 [110/20] via 13.0.0.3, 00:04:06, FastEthernet0/1 R1#   R1#show ip route 6.6.6.0 Routing entry for 6.6.6.0/24 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 65001 Last update from 13.0.0.3 on FastEthernet0/1, 00:04:12 ago Routing Descriptor Blocks: * 13.0.0.3, from 4.4.4.4, 00:04:12 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1 R1#   R1#tracer 6.6.6.6 Type escape sequence to abort. Tracing the route to 6.6.6.6 VRF info: (vrf in name/id, vrf 1 13.0.0.3 368 msec 316 msec 2 34.0.0.4 324 msec 360 msec 3 46.0.0.6 104 msec 108 msec R1#

out 300 208 116

name/id) msec msec msec

  Let's change the cost of the fa0/0 interface's R1 to 65000:   R1(config)#int fa0/0 R1(config-if)#ip ospf cost 65000   R1 finds that it has an inter-area route to reach 24.0.0.0/24 with cost 65001 as shown by the show ip route 24.0.0.0 command. R1 finds also that it has an intra-area route to reach 34.0.0.0/24 with cost 65001 as shown by the show ip route 34.0.0.0 command.   R1#show ip route 24.0.0.0 Routing entry for 24.0.0.0/24, 1 known subnets O IA 24.0.0.0 [110/65001] via 12.0.0.2, 00:00:20, FastEthernet0/0 R1#   R1#show ip route 34.0.0.0 Routing entry for 34.0.0.0/24, 1 known subnets O 34.0.0.0 [110/65001] via 13.0.0.3, 00:14:28, FastEthernet0/1 R1#   Since the two ospf routes (intra-area and inter-area routes) are pointed to different destinations 24.0.0.0/24 and 34.0.0.0/24, R1 cannot prefer the intra-area route over the inter-area route. And since the Forward Addresses 24.0.0.4 and 34.0.0.4 are reachable with the same cost 65001, and because R1 is implementing the RFC 3101 as shown by the show ip ospf command, the following priorities in deciding which LSA (Type 5 or Type 7) is preferred are defined in the RFC 3101:   If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred:   1. A Type-7 LSA with the P-bit set.   2. A Type-5 LSA.  

3. The LSA with the higher router ID.   R1#show ip ospf | inc RFC Supports NSSA (compatible with RFC 3101) R1#   Conclusion R1 installs the NSSA external Type 2 route ON2 through R3 because the LSA Type 7 advertised by R4 is preferred than the LSA Type 5 advertised by R2 according to the RFC 3101:   R1#show ip route | inc 6.6.6.0 O N2 6.6.6.0 [110/20] via 13.0.0.3, 00:08:51, FastEthernet0/1 R1#   R1#show ip route 6.6.6.0 Routing entry for 6.6.6.0/24 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 65001 Last update from 13.0.0.3 on FastEthernet0/1, 00:08:55 ago Routing Descriptor Blocks: * 13.0.0.3, from 4.4.4.4, 00:08:55 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1 R1#   The traceroute confirms that the packet goes through R3:   R1#tracer 6.6.6.6 Type escape sequence to abort. Tracing the route to 6.6.6.6 VRF info: (vrf in name/id, vrf out name/id) 1 13.0.0.3 72 msec 76 msec 52 msec 2 34.0.0.4 108 msec 104 msec 72 msec 3 46.0.0.6 132 msec 136 msec 128 msec R1#   If we enable RFC 1587 with the compatible rfc1587 command, R1 should prefer the LSA Type 5 , in other words the path through R2, since the RFC 1587 says:   When a type-5 LSA and a type-7 LSA are found to have the same type and an equal distance, the following priorities apply (listed from highest to lowest) for breaking the tie.   a. Any type 5 LSA. b. A type-7 LSA with the P-bit set and the forwarding address non-zero. c. Any other type-7 LSA.   R1(config)#router ospf 1 R1(config-router)#compatible rfc1587   Let's verify that R1is now implementing RFC 1587 using the show ip ospf command:   R1#show ip ospf | inc RFC Supports NSSA (compatible with RFC 1587) R1#   Now R1 installs an OSPF external type 2 OE2 through R2, in other words R1 prefers the LSA Type 5 advertised by R2 rather than the LSA Type 7 advertised by R4:   R1#show ip route | inc 6.6.6.0

O E2 R1#

6.6.6.0 [110/20] via 12.0.0.2, 00:01:12, FastEthernet0/0

  R1#show ip route 6.6.6.0 Routing entry for 6.6.6.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 65001 Last update from 12.0.0.2 on FastEthernet0/0, 00:01:18 ago Routing Descriptor Blocks: * 12.0.0.2, from 2.2.2.2, 00:01:18 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1 R1#   The traceroute confirms that the packet goes through R2:   R1#tracer 6.6.6.6 Type escape sequence to abort. Tracing the route to 6.6.6.6 VRF info: (vrf in name/id, vrf out name/id) 1 12.0.0.2 80 msec 56 msec 20 msec 2 24.0.0.4 120 msec 80 msec 52 msec 3 46.0.0.6 120 msec 112 msec 112 msec R1#                                                                  

Lab 11: Path Selection Scenario 2  

  Basic configuration of all routers:   R1: interface FastEthernet0/0 ip address 13.0.0.1 255.255.255.0 ip ospf 1 area 0 ip ospf cost 10 no shut ! router ospf 1 router-id 1.1.1.1   R2: interface FastEthernet0/0 ip address 23.0.0.2 255.255.255.0 ip ospf 1 area 0 ip ospf cost 11 no shut ! router ospf 1 router-id 2.2.2.2   R3: interface FastEthernet0/0 ip address 13.0.0.3 255.255.255.0 ip ospf 1 area 0 ip ospf cost 10 no shut ! interface FastEthernet0/1 ip address 23.0.0.3 255.255.255.0 ip ospf 1 area 0 ip ospf cost 11 no shut ! interface FastEthernet1/0 ip address 34.0.0.3 255.255.255.0 ip ospf 1 area 1 ip ospf cost 100 no shut ! interface FastEthernet1/1

ip address 35.0.0.3 255.255.255.0 ip ospf 1 area 1 ip ospf cost 101 no shut ! interface FastEthernet2/0 ip address 36.0.0.3 255.255.255.0 ip ospf 1 area 1 ip ospf cost 102 no shut ! router ospf 1 router-id 3.3.3.3   R4: interface FastEthernet0/0 ip address 34.0.0.4 255.255.255.0 ip ospf 1 area 1 ip ospf cost 100 no shut ! interface FastEthernet0/1 ip address 47.0.0.4 255.255.255.0 no shut ! router eigrp 100 network 47.0.0.0 redistribute ospf 1 metric 1 1 1 1 1 ! router ospf 1 router-id 4.4.4.4 redistribute eigrp 100 subnets   R5: interface FastEthernet0/0 ip address 35.0.0.5 255.255.255.0 ip ospf 1 area 1 ip ospf cost 101 no shut ! interface FastEthernet0/1 ip address 57.0.0.5 255.255.255.0 no shut ! router eigrp 100 network 57.0.0.0 redistribute ospf 1 metric 1 1 1 1 1 ! router ospf 1 router-id 5.5.5.5 redistribute eigrp 100 subnets   R6: interface FastEthernet0/0 ip address 36.0.0.5 255.255.255.0 ip ospf 1 area 1 ip ospf cost 102 no shut

! interface FastEthernet0/1 ip address 67.0.0.6 255.255.255.0 no shut ! router eigrp 100 network 67.0.0.0 redistribute ospf 1 metric 1 1 1 1 1 ! router ospf 1 router-id 6.6.6.6 redistribute eigrp 100 subnets   R7: interface Loopback0 ip address 100.1.1.7 255.255.255.0 ! interface FastEthernet0/0 ip address 47.0.0.7 255.255.255.0 no shut ! interface FastEthernet0/1 ip address 57.0.0.7 255.255.255.0 no shut ! interface FastEthernet1/0 ip address 67.0.0.7 255.255.255.0 no shut ! router eigrp 100 network 100.1.1.0 network 47.0.0.0 network 57.0.0.0 network 67.0.0.0   In this topology we have three ASBRs R4, R5 and R6 and they are redistributing between OSPF and EIGRP, the metrics of the links between the routers in the OSPF domaine are configured as illustrated in the topology.   In this topology we will analyze the routing table from R3's perspective, especially the external route toward 6.6.6.0/24.   Notice that R4, R5 and R6 redistributes the EIGRP routes as external metric-type 2 with defaut metric 20 using the redistribute eigrp 100 subnets command. As a result, if we focus about the prefix 100.1.1.0/24, we can see that R3 receives three LSAs Type 5 with the FA 0.0.0.0 from three ASBRs (R4 with RID 4.4.4.4, R5 with RID 5.5.5.5 and R6 with RID 6.6.6.6):   R3#show ip ospf database ext 100.1.1.0 adv 4.4.4.4 OSPF Router with ID (3.3.3.3) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 91 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 100.1.1.0 (External Network Number ) Advertising Router: 4.4.4.4 LS Seq Number: 80000001 Checksum: 0x3FEA Length: 36 Network Mask: /24

Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 R3#   R3#show ip ospf database ext 100.1.1.0 adv 5.5.5.5 OSPF Router with ID (3.3.3.3) (Process ID 1) Type-5 AS External Link States LS age: 174 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 100.1.1.0 (External Network Number ) Advertising Router: 5.5.5.5 LS Seq Number: 80000001 Checksum: 0x2105 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 R3#   R3#show ip ospf database ext 100.1.1.0 adv 6.6.6.6 OSPF Router with ID (3.3.3.3) (Process ID 1) Type-5 AS External Link States LS age: 242 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 100.1.1.0 (External Network Number ) Advertising Router: 6.6.6.6 LS Seq Number: 80000001 Checksum: 0x31F Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 R3#   Which path or which ASBR will R3 choose to reach 100.1.1.0/24? In this case the route to 100.1.1.0/24 is redistributed with default settings (Cost 20 and Metric Type 2), R3 will see a cost of 20 to reach the external route through the ASBRs R4, R5 and R6, and then since the FA is 0.0.0.0 it will look at the best intra-area cost to reach each ASBR so therefore, it will take the path through R4. The show ip ospf border-routers below displays the cost toward each ASBR:   To reach R4 the cost is 100. To reach R5 the cost is 101. To reach R6 the cost is 102.     By default OSPF will assign a cost of 20 (regardless of its metric-type) to the redistributed routes. When the ABR receives the E2 routes, they will all have a cost of 20 for the redistributed route, now IF THE INTRA-AREA

ROUTE on the ABR TO THE ASBRs are equal, then and only then the ABR will perform an equal cost load sharing. So with E2 is the cost (20 default) plus the intra-area cost to that ASBR.   So we see the local router performs two calculations, one to see the local cost of 20 to the external route and the second one is to see what is the intra-area cost to the advertising router.   R3#show ip ospf border-routers OSPF Router with ID (3.3.3.3) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route i 4.4.4.4 [100] via 34.0.0.4, FastEthernet1/0, ASBR, Area 1, SPF 4 i 5.5.5.5 [101] via 35.0.0.5, FastEthernet1/1, ASBR, Area 1, SPF 4 i 6.6.6.6 [102] via 36.0.0.6, FastEthernet2/0, ASBR, Area 1, SPF 4 R3#   Let's verify the routing tale of R3 to see the external route Metric Type 2 through R4 and the forward metric 100 which is the cost to reach the ASBR R4 seen earlier in the show ip ospf border-routers:   R3#show ip route | incl 100.1.1.0 O E2 100.1.1.0 [110/20] via 34.0.0.4, 00:06:22, FastEthernet1/0 R3#   R3#show ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 100 Last update from 34.0.0.4 on FastEthernet1/0, 00:06:28 ago Routing Descriptor Blocks: * 34.0.0.4, from 4.4.4.4, 00:06:28 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1 R3#   The traceroute command shown that the packet goes through R4:   R3#tracer 100.1.1.1 Type escape sequence to abort. Tracing the route to 100.1.1.1 VRF info: (vrf in name/id, vrf out name/id) 1 34.0.0.4 264 msec 232 msec 60 msec 2 47.0.0.7 340 msec 332 msec 288 msec R3#   Let's change the route type of the redistribution on R6, R6 will advertise an external Metric Type 1 as follow:   R6(config)#router osp 1 R6(config-router)#redistribute eigrp 100 subnets metric-type 1   So R6 advertises an LSA Type 5 with Metric Type 1, and R4 and R5 advertises their LSA Type 5 with Metric Type 2:   R3#show ip ospf database ext 100.1.1.0 adv-router 6.6.6.6 OSPF Router with ID (3.3.3.3) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 33 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 100.1.1.0 (External Network Number )

Advertising Router: 6.6.6.6 LS Seq Number: 80000002 Checksum: 0x7D24 Length: 36 Network Mask: /24 Metric Type: 1 (Comparable directly to link state metric) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 R3#   R3#show ip ospf border-routers OSPF Router with ID (3.3.3.3) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route i 4.4.4.4 [100] via 34.0.0.4, FastEthernet1/0, ASBR, Area 1, SPF 4 i 5.5.5.5 [101] via 35.0.0.5, FastEthernet1/1, ASBR, Area 1, SPF 4 i 6.6.6.6 [102] via 36.0.0.6, FastEthernet2/0, ASBR, Area 1, SPF 4 R3#   Let's verify the routing table of R3 we can see that it installs the external Metric Type 1 through R6 toward 100.1.1.0/24: In other words, if we look at OSPF’s path selection, Type-1 are looked at before Type-2. So if one ASBR performs a Type-1 redistribution, and the other ASBRs perform a Type-2 (Default) redistribution, Type 1 will be chosen. So the OE1 route learned from R6 is always preferred that the OE2 routes learned from R4 and R5, notice the metric of the OE1 route is 122:   R3#show ip route | incl 100.1.1.0 O E1 100.1.1.0 [110/122] via 36.0.0.6, 00:03:16, FastEthernet2/0 R3#   R3#show ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 122, type extern 1 Last update from 36.0.0.6 on FastEthernet2/0, 00:03:24 ago Routing Descriptor Blocks: * 36.0.0.6, from 6.6.6.6, 00:03:24 ago, via FastEthernet2/0 Route metric is 122, traffic share count is 1 R3#   R3#tracer 100.1.1.1 Type escape sequence to abort. Tracing the route to 100.1.1.1 VRF info: (vrf in name/id, vrf out name/id) 1 36.0.0.6 88 msec 52 msec 76 msec 2 67.0.0.7 104 msec 108 msec 112 msec R3#   Per RFC 2328 OSPF Version 2   16.4. Calculating AS external routes   (6) Compare the AS external path described by the LSA with the existing paths in N's routing table entry, as follows. If the new path is preferred, it replaces the present paths in N's routing table entry. If the new path is of equal

preference, it is added to N's routing table entry's list of paths.   (a) Intra-area and inter-area paths are always preferred over AS external paths.   (b) Type 1 external paths are always preferred over type 2 external paths. When all paths are type 2 external paths, the paths with the smallest advertised type 2 metric are always preferred.   Per RFC 1583 OSPF Version 2   11.1. Routing table lookup   (3) Reduce the set of matching entries to those having the most preferential path-type (see Section 11). OSPF has a four level hierarchy of paths. Intra-area paths are the most preferred, followed in order by inter-area, type 1 external and type 2 external paths.   Now what happen if all ASBRs redistribute 100.1.1.0/24 as Metric Type 1 ?   Let's configure R4 and R5:   R4(config)#router osp 1 R4(config-router)#redistribute eigrp 100 subnets metric-type 1   R5(config)#router osp 1 R5(config-router)#redistribute eigrp 100 subnets metric-type 1   Verify the LSDB of R3:   R3#show ip ospf data ext 100.1.1.0 | s Metric Type|Adv Advertising Router: 4.4.4.4 Metric Type: 1 (Comparable directly to link state metric) Advertising Router: 5.5.5.5 Metric Type: 1 (Comparable directly to link state metric) Advertising Router: 6.6.6.6 Metric Type: 1 (Comparable directly to link state metric) R3#   The routing table of R3 shows that it installs the route through R4 because it has a lower cumulative cost. If the routes are redistributed as Metric-type 1, the result will be the same, but in this case R3 will look at the cumulative cost which is lower through R4. So in this topology with the assigned costs, E1 and E2 routes will have identical result.   To summarize the cumulative cost of each path:   Via R4 it is equal to 120. Via R5 it is equal to 121. Via R6 it is equal to 122.   R3#show ip route | inc 100.1.1.0 O E1 100.1.1.0 [110/120] via 34.0.0.4, 00:04:28, FastEthernet1/0 R3#   R3#show ip route 100.1.1.0 Routing entry for 100.1.1.0/24

Known via "ospf 1", distance 110, metric 120, type extern 1 Last update from 34.0.0.4 on FastEthernet1/0, 00:04:38 ago Routing Descriptor Blocks: * 34.0.0.4, from 4.4.4.4, 00:04:38 ago, via FastEthernet1/0 Route metric is 120, traffic share count is 1 R3#   The traceroute confirms the result:   R3#tracer 100.1.1.1 Type escape sequence to abort. Tracing the route to 100.1.1.1 VRF info: (vrf in name/id, vrf out name/id) 1 34.0.0.4 312 msec 480 msec 176 msec 2 47.0.0.7 112 msec 108 msec 112 msec R3#   Keep in mind that with default metric assigned to the external prefix 100.1.1.0/24 IF THE INTRA-AREA ROUTE ON THE ABR TO THE ASBRs R4, R5 and R6 are equal, then and only then the ABR R3 will perform an equal cost load sharing. E1 and E2 routes will have identical result.                                                          

Lab 12: Path Selection Scenario 3    

  R1 and R2 are in area 0. R2 and R4 are in area 24. R1, R3 and R4 are in area 134.   Basic configuration of all routers:   R1: ipv uni ! interface S2/0 ipv6 address 12::1/64 ipv6 enable ospfv3 1 ipv6 area 0 ! interface S2/1 ipv6 address 13::1/64 ipv6 enable ospfv3 1 ipv6 area 0 ! router ospfv3 1 ! address-family ipv6 unicast router-id 0.0.0.1 exit-address-family   R2: ipv uni ! interface S2/0 ipv6 address 12::2/64 ipv6 enable ospfv3 1 ipv6 area 0 ! interface S2/1 ipv6 address 24::2/64 ipv6 enable ospfv3 1 ipv6 area 24 ! router ospfv3 1 !

address-family ipv6 unicast router-id 0.0.0.2 exit-address-family   R3: ipv uni ! interface S2/0 ipv6 address 13::3/64 ipv6 enable ospfv3 1 ipv6 area 134 ! interface S2/1 ip address 34.0.0.3 255.255.255.0 ipv6 address 34::3/64 ipv6 enable ospfv3 1 ipv6 area 134 ! router ospfv3 1 ! address-family ipv6 unicast router-id 0.0.0.3 exit-address-family   R4: ipv uni ! interface Loopback0 ipv6 address 4::4/64 ! interface S2/0 ipv6 address 24::4/64 ipv6 enable ospfv3 1 ipv6 area 24 ! interface S2/1 ipv6 address 34::4/64 ipv6 enable ospfv3 1 ipv6 area 134 ! route-map CONNECTED permit 10 match interface Loopback0 ! router ospfv3 1 ! address-family ipv6 unicast redistribute connected route-map CONNECTED router-id 0.0.0.4 exit-address-family   R4 redistributes the prefix 4::/64 into OSPF therefore it creates a Type-5 LSA and floods it into all areas.   Let's verify the LSDB of R1, we can see that it receives the Type-5 LSA with the Advertising Router 0.0.0.4 (R4) and Prefix Address 4::   R1#show ospfv3 database external OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Type-5 AS External Link States

Routing Bit Set on this LSA LS age: 123 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.4 LS Seq Number: 80000001 Checksum: 0x189C Length: 36 Prefix Address: 4:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R1#   Since the Forward Address is not set in the Type-5 LSA, R1 looks the best path to reach the ASBR R4, R1 has two paths:   1-an intra-area route through R3. 2-an inter-area route through R2.   Since the intra-area route is always preferred over the inter-area route according to RFC 1583, the show ospf border command displays the best route with an intra-area route through R3:   R1#sh osp bor OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Codes: i - Intra-area route, I - Inter-area route i 0.0.0.2 [64] via FE80::A8BB:CCFF:FE00:200, Serial2/0, ABR, Area 0, SPF 13 i 0.0.0.4 [128] via FE80::A8BB:CCFF:FE00:300, Serial2/1, ASBR, Area 134, SPF 6 R1#   Therefore to route the traffic destined to 4::/64, R1 installs an external route (OE2) with next-hop R3:   R1#show ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:02:33 ago R1#   Let's do a traceroute from R1 to 4::4:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 10 msec 10 msec 11 msec 2 34::4 18 msec 18 msec 17 msec R1#   Let's configure area 24 as NSSA:   On R2 and R4:   Rx(config-router)#router ospfv 1 Rx(config-router)#address-family ipv6 uni Rx(config-router-af)#area 24 nssa  

Let's verify the LSDB of R4, the ASBR originates a Type-5 LSA and floods it into all area except the area 24:   R4#sh os data ex OSPFv3 1 address-family ipv6 (router-id 0.0.0.4) Type-5 AS External Link States LS age: 111 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.4 LS Seq Number: 80000002 Checksum: 0x169D Length: 36 Prefix Address: 4:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R4#   For area 24, R4 originates a Type-7 LSA, notice the P-bit is cleared by R4, R4 prevents R2 from translating the Type-7 NSSA External LSA from Area 24 to a Type-5 External LSA into Area 0.   R4#sh os data nssa OSPFv3 1 address-family ipv6 (router-id 0.0.0.4) Type-7 AS External Link States (Area 24) LS age: 152 LS Type: AS External Link Link State ID: 1 Advertising Router: 0.0.0.4 LS Seq Number: 80000001 Checksum: 0x5542 Length: 52 Prefix Address: 4:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 24::4 R4#   Why ?   This behavior is per RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option:   2.4 Originating Type-7 LSAs   NSSA AS boundary routers may only originate Type-7 LSAs into NSSAs. An NSSA internal AS boundary router must set the P-bit in the LSA header's option field of any Type-7 LSA whose network it wants advertised into the OSPF domain's full transit topology. The LSAs of these networks must have a valid non-zero forwarding address. If the P-bit is clear the LSA is not translated into a Type-5 LSA by NSSA border routers.   When an NSSA border router originates both a Type-5 LSA and a Type-7 LSA for the same network, then the P-bit must be clear in the Type-7 LSA so that it isn't translated into a Type-5 LSA by another NSSA border router.   By default R4 implements RFC 3101 as shown below:  

R4#show ospfv3 | i 3101 Supports NSSA (compatible with RFC 3101) R4#   Let's verify the LSDB of R1, R1 only learns a Type-5 LSA to 4::/64 through the regular area 134 with the Advertising Router 0.0.0.4 (R4): R1#show os data ex OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 143 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.4 LS Seq Number: 80000002 Checksum: 0x169D Length: 36 Prefix Address: 4:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R1#   Therefore, R1 only learns one path to 4::/64, which is via R3:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:02:36 ago R1#   Let's implement RFC 1587 on R4:   R4(config-router)#router ospfv 1 R4(config-router)#address-family ipv6 uni R4(config-router-af)#compatible rfc1587   Let's verify the RFC 1587:   R4#show ospfv3 | i 1587 Supports NSSA (compatible with RFC 1587) R4#   per RFC 1587 The OSPF NSSA Option:   3.4 Originating Type-7 LSAs   If a router is attached to another AS and is also an NSSA area border router, it may originate a both a type-5 and a type-7 LSA for the same network. The type-5 LSA will be flooded to the backbone (and all attached type-5 capable areas) and the type-7 will be flooded into the NSSA. If this is the case, the P-bit must be reset in the type-7 NSSA so the type-7 LSA isn't again translated into a type-5 LSA by another NSSA area border router  

Let's verify the Type-7 LSA, we can see the same behavior , the P-bit is cleared and R1 only learns the path to 4::/64 through R3:   R4#sh os data nssa | s Options Prefix Length: 64, Options: None R4#   Let's disable RFC 1587 and configure area 134 as NSSA:   On R4:   R4(config-router)#router ospfv 1 R4(config-router)#address-family ipv6 uni R4(config-router-af)#no compatible rfc1587   Verify the RFC 3101 is enabled:   R1#sh ospf | s 3101 Supports NSSA (compatible with RFC 3101) R1#   On R1, R3 and R4:   Rx(config-router)#router ospfv 1 Rx(config-router)#address-family ipv6 uni Rx(config-router-af)#area 134 nssa   R4 originates two Type-7 LSA with different Forward Address for each areas NSSA 24 and 134, both LSAs have the P-bit set, since the P-bit is set in the Type-7 LSA 's area 24, R2 translates the Type-7 NSSA External LSA from Area 24 to a Type-5 External LSA into Area 0:   R4#sh os data nss | s Forward|Options Prefix Length: 64, Options: P Forward Address: 24::4 R4#   R4#sh os data nss | s Forward|Options Prefix Length: 64, Options: P Forward Address: 34::4 R4#   Let's verify the LSDB of R1, R1 learns a Type-5 LSA from the ABR/ASBR R2 and a Type-7 LSA from the NSSA ASBR R4 for the same destination 4::/64:   R1#sh os data ex OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 63 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.2 LS Seq Number: 80000002 Checksum: 0xA3D7 Length: 52 Prefix Address: 4:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path)

Metric: 20 Forward Address: 24::4 R1#   R1#sh os data nss OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Type-7 AS External Link States (Area 134) Routing Bit Set on this LSA LS age: 67 LS Type: AS External Link Link State ID: 3 Advertising Router: 0.0.0.4 LS Seq Number: 80000002 Checksum: 0xC0BB Length: 52 Prefix Address: 4:: Prefix Length: 64, Options: P Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 34::4 R1#   R1 looks the best path OSPF to reach the Forward Addresses 24::4 and 34::4.   R1 finds that it has an inter-area route to reach 24::/64 with a cost 128 as shown by the sh ipv route | s 24:: command. R1 finds also that it has an intra-area route to reach 34::/64 with cost 128 as shown by the sh ipv route | s 34:: command.   R1#sh ipv route | s 24:: OI 24::/64 [110/128] via FE80::A8BB:CCFF:FE00:200, Serial2/0 R1#   R1#sh ipv route | s 34:: O 34::/64 [110/128] via FE80::A8BB:CCFF:FE00:300, Serial2/1 R1#   Since the two ospf routes (intra-area and inter-area routes) are pointed to different destinations 24::/64 and 34::/64, R1 cannot prefer the intra-area route over the inter-area route. And since the Forward Addresses 24::4 and 34::4 are reachable with the same cost 128, and because R1 is implementing the RFC 3101, the following priorities in deciding which LSA (Type 5 or Type 7) is preferred are defined in the RFC 3101:   If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred:   1. A Type-7 LSA with the P-bit set.   2. A Type-5 LSA.   3. The LSA with the higher router ID.   R1 installs the NSSA external Type 2 route ON2 through R3 because the LSA Type 7 advertised by R4 is preferred than the LSA Type 5 advertised by R2 according to the RFC 3101:  

R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:00:35 ago R1#   Let's execute a traceroute to see the path taken by the packet:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 10 msec 10 msec 9 msec 2 34::4 17 msec 18 msec 19 msec R1#   Let's implement RFC 1587:   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#compatible rfc1587   R1#sh osp | s 1587 Supports NSSA (compatible with RFC 1587) R1#   Since the RFC 1587 says:   When a type-5 LSA and a type-7 LSA are found to have the same type and an equal distance, the following priorities apply (listed from highest to lowest) for breaking the tie.   a. Any type 5 LSA. b. A type-7 LSA with the P-bit set and the forwarding address non-zero. c. Any other type-7 LSA.   R1 should prefer the Type-5 LSA learned from R2 , in other words the path through R2, let's verify the routing table of R1: Now R1 installs an OSPF external type 2 OE2 route through R2.   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:200, Serial2/0 Last updated 00:00:18 ago R1#   The traceroute shown that the packets go through R2:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 12::2 5 msec 9 msec 9 msec

2 24::4 19 msec 19 msec 14 msec R1#   RFC 1587 (and 3101) says the Type-5 LSA is preferred than a Type-7 LSA only if both LSAs have a same cost to the destination (the forward address):   Let's verify this rule, configure the cost 10 to R3 on R1:   R1(config)#int s2/1 R1(config-if)#ospfv cost 10   R1 has an inter-area route to reach 24::/64 with a cost 128 as shown previously. R1 has an intra-area route to reach 34::/64 with cost 74 as shown by the sh ipv route | s 34:: command.   R1#sh ipv route | s 34:: O 34::/64 [110/74] via FE80::A8BB:CCFF:FE00:300, Serial2/1 R1#   Since the cost to reach the Forward Address 34::4 of the Type-7 LSA learned via area 134 is better than the cost to reach the Forward Address 24::/4's Type-5 learned via area 0, R1 installs the ON2 route through R3:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:01:01 ago R1#   The packets go through R3 as shown by the traceroute command:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 6 msec 9 msec 10 msec 2 34::4 19 msec 17 msec 18 msec R1#   Remove the cost to R3 and disable RFC 1587 on R1:   R1(config)#int s2/1 R1(config-if)#no ospfv cost 10   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#no compatible rfc1587   Ensure that R1 is receiving a Type-5 LSA with FA 24::4 from R2 and a Type-7 LSA with P-bit set&FA 34::4 from R4:   R1#sh ospf data ext | s Forward Forward Address: 24::4 R1#   R1#sh os data nss | s Forward|Options

Prefix Length: 64, Options: P Forward Address: 34::4 R1#   Ensure that the costs to reach the Forward Addresses 24::4 and 34::4 are equal:   R1#sh ipv route 24:: | s metric Known via "ospf 1", distance 110, metric 128, type inter area R1#   R1#sh ipv route 34:: | s metric Known via "ospf 1", distance 110, metric 128, type intra area R1#   Ensure that R1 preferred the ON2 route through R3 according RFC 3101:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:00:18 ago R1#   Now let's redistribute the Type-7 LSA with a P-bit cleared using the "nssa-only" keyword in the redistribute command: The "nssa-only" keyword instructs R4 to clear the P-bit.   R4(config-router)#router ospfv 1 R4(config-router)#address-family ipv6 uni R4(config-router-af)#redistribute connected route-map IPV6 nssa-only   Verify that the P-bit is cleared, the "Options: None" field means that the P-bit is not set:   R1#sh os data nss | s Forward|Options Prefix Length: 64, Options: None Forward Address: 34::4 R1#   Let's verify the routing table of R1, it installs an ON2 route through R3, because according to RFC 3101, a Type-7 LSA with P-cleared is preferred than a Type-5 LSA:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:02:47 ago R1#   The packets go through R3 to reach 4::4:   R1#trace 4::4 Type escape sequence to abort. Tracing the route to 4::4

1 13::3 9 msec 5 msec 9 msec 2 34::4 18 msec 22 msec 13 msec R1#   Let's enable RFC 1587 on R1:   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#compatible rfc1587   Let's verify the routing table, R1 prefers the ON2 route through R3, because according to RFC 1587, a Type-7 LSA with P-cleared and Forward Address set is preferred than a Type-5 LSA:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:04:30 ago R1#   The traceroute command shown that the packet go through R3:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 10 msec 9 msec 9 msec 2 34::4 18 msec 18 msec 18 msec R1#   Disable RFC 1587 on R1 and remove the "nssa-only" keyword in the redistribute command on R4:   R1(config)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#no compatible rfc1587   R4(config-router)#router ospfv 1 R4(config-router)#address-family ipv6 uni R4(config-router-af)#no redistribute connected route-map IPV6 nssa-only   To proove this, configure the "nssa-only" keyword in the summary-prefix command:   R4(config)#router ospfv 1 R4(config-router)#address-family ipv6 uni R4(config-router-af)#summary-prefix 4::/64 nssa-only   Verify that the P-bit is cleared:   R1#sh os data nss | s Forward|Options Prefix Length: 64, Options: None Forward Address: 34::4 R1#   Verify the routing table, R1 prefers the ON2 route through R3, as mentioned previously, because with RFC 3101 enabled, a Type-7 LSA with P-bit cleared is preferred than a Type-5 LSA:  

R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:02:24 ago R1#   The packets go through R3:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 10 msec 8 msec 9 msec 2 34::4 18 msec 19 msec 18 msec R1#   Let's enable RFC 1587:   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#compatible rfc1587   R1 installs the ON2 route, as mentioned previously, because with RFC 1587, a Type-7 LSA with P-bit cleared&Forward Address set is preferred than a Type-5 LSA:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:03:30 ago R1#   Remove the summary-prefix command on R4 and disable RFC 1587 on R1:   R4(config-router)#router ospfv 1 R4(config-router)#address-family ipv6 uni R4(config-router-af)#no summary-prefix 4::/64 nssa-only   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#no compatible rfc1587   Now what happen if both the P-bit and the Forward Address are cleared?   To suppress the Forward Address 34::4, we should use the ospfv3 prefix-suppression on R4 under the serial 2/1 interface, the prefix suppression feature in OSPFv3 suppresses the prefix 34::/64 in the Type-8 and Type-9 LSAs.   Since R4 does not have another interface in NSSA area 134, it fails to select another Forward Address, as a result R4 clears the P-bit in the Type-7 LSA as shown by the console message displayed by R4:   R4(config)#int s2/1 R4(config-if)#ospfv3 prefix-suppression R4(config-if)#

*Oct 7 20:49:30.602: %OSPFv3-4-NSSA_NO_FA: OSPFv3-1-IPv6 Process lacks forwarding address for type 7 LSA 0.0.0.3 in NSSA 134 - P-bit cleared R4(config-if)#   Let's verify the Type-7 LSA originated by R4 in area 134, the P-bit is cleared and the Forward Address is not included:   R1#sh os data nssa-external OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Type-7 AS External Link States (Area 134) Routing Bit Set on this LSA LS age: 18 LS Type: AS External Link Link State ID: 3 Advertising Router: 0.0.0.4 LS Seq Number: 8000000D Checksum: 0xA71C Length: 36 Prefix Address: 4:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R1#   Verify the routing table, R1 installs an ON2 route through R3, because according to RFC 3101, a Type-7 LSA with P-bit cleared and Forward Address not set is preferred than a Type-5 LSA:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:08:44 ago R1#   The packets go through R3:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 9 msec 9 msec 11 msec 2 34::4 20 msec 18 msec 18 msec R1#   Let's enable RFC 1587:   R1(config)#router ospfv 1 R1(config-router)#add ipv6 uni R1(config-router-af)#compatible rfc1587   Verify the routing table, R1 installs an OE2 route through R3, because according to RFC 1587, a Type-5 LSA is preferred than a Type-7 LSA with P-bit cleared and Forward Address not set:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0

Routing paths: FE80::A8BB:CCFF:FE00:200, Serial2/0 Last updated 00:00:12 ago R1#   Now the packets go through R2:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 12::2 20 msec 9 msec 9 msec 2 24::4 19 msec 18 msec 17 msec R1#   Disable RFC 1587 on R1 and remove the prefix suppression feature on R4:   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#no compatible rfc1587   R4(config)#int s2/1 R4(config-if)#no ospfv3 prefix-suppression   R1#sh os data ext adv 0.0.0.2 | s Forward Forward Address: 24::4 R1#   Ensure that R1 is receiving a Type-5 LSA with FA 24::4 from R2 and a Type-7 LSA with P-bit&FA 34::4 set from R4:   R1#sh os data nss | s Forward|Options Prefix Length: 64, Options: P Forward Address: 34::4 R1#   Ensure that the costs to reach the Forward Addresses 24::4 and 34::4 are equal:   R1#sh ipv route 24:: | s metric Known via "ospf 1", distance 110, metric 128, type inter area R1#   R1#sh ipv route 34:: | s metric Known via "ospf 1", distance 110, metric 128, type intra area R1#   Ensure that RFC 3101 is enabled:   R1#sh ospfv3 | s RFC 3101 Supports NSSA (compatible with RFC 3101) R1#   Ensure that the ON2 route through R3 is installed according to RFC 3101:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0

Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:05:36 ago R1#   Configure the NSSA ABR to suppress the Forward Address when translating the Type-7 LSA learned from area 24 into Type-5 LSA:   R2(config-router)#router ospfv 1 R2(config-router)#address-family ipv6 uni R2(config-router-af)#area 24 nssa translate type7 suppress-fa   Let's verify the Type-5 LSA originated by R2, the Forward Address is not included, this means it is suppressed:   R1#sh osp data ext adv 0.0.0.2 OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 25 LS Type: AS External Link Link State ID: 4 Advertising Router: 0.0.0.2 LS Seq Number: 80000004 Checksum: 0xF5B9 Length: 36 Prefix Address: 4:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R1#   R1 receives the following Type-5 and Type-7 LSAs:   1-A Type-5 LSA from R2 with Forward Address cleared, R1 looks the best path to reach the NSSA ABR/ASBR R2. 2-A Type-7 LSA from R4 with Forward Address 34::/64, R1 looks the best OSPF path to reach 34::4.   The best path to reach R2 is through area 0 and the cost is 64:   R1#sh ospfv bord OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Codes: i - Intra-area route, I - Inter-area route i 0.0.0.2 [64] via FE80::A8BB:CCFF:FE00:200, Serial2/0, ABR/ASBR, Area 0, SPF 16 i 0.0.0.4 [128] via FE80::A8BB:CCFF:FE00:300, Serial2/1, ASBR, Area 134, SPF 13 R1#   The best path to reach the Forward Address 34::4 is an intra-area route through R3 and the cost is 128:   R1#sh ipv route 34:: Routing entry for 34::/64 Known via "ospf 1", distance 110, metric 128, type intra area Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:38:45 ago R1#  

Since the cost to reach R2 is better than the cost to reach the Forward Address 34::4, R1 installs an OE2 route through R2:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:200, Serial2/0 Last updated 00:01:30 ago R1#   The packets go through R2:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 12::2 9 msec 9 msec 9 msec 2 24::4 18 msec 13 msec 18 msec R1#   By default the routers implements the RFC 1583 which means that when multiple intra-area routes with the same cost are availables toward the same ASBR, the router installs a load balancing toward the externel prefix and if the costs are different, a router selects the lowest cost.   Let's verify that the RFC 1583 is enabled and RFC 3101 is enabled:   R1#sh ospfv3 | s RFC Supports NSSA (compatible with RFC 3101) RFC1583 compatibility enabled Area BACKBONE(0) R1#   OSPFv3 address family support for IPv6 and IPv4 is described in RFC 5340.   Per RFC 5340, the following rules indicate which paths are preferred when multiple intra-AS paths are available to ASBRs or forwarding addresses:   1-Intra-area paths using nonbackbone areas are always the most preferred. 2-The other paths, intra-area backbone paths and inter-area paths, are of equal preference.   These rules apply when the same ASBR is reachable through multiple areas. In this case the ASBR R4 is reachable through the backbone area 0 and non-backbone area 2. This feature applies only when RFC 1583 compatibility is set to disabled using the no compatibility rfc1583 command.   Let's disable RFC 1583 using the no compatible rfc1583 command on R1, in OSPFv3 when RFC 1583 is disabled, this means that RFC 5340 is enabled:   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#no compatible rfc1583   Let's verify that the RFC 1583 is disabled using the show ospfv3 command:   R1#sh ospfv3 | s RFC Supports NSSA (compatible with RFC 3101) RFC1583 compatibility disabled Area BACKBONE(0)

R1#   R1 receives a Type-5 LSA from R2 with Forward Address cleared and Type-7 LSA with Forward Address 34::4:   1-For Type-5 LSA, R1 has an intra-area route through a backbone area 0 to reach R2. 2-For Type-7 LSA, R1 has an intra-area route through a non-backbone area 134 to reach 34::4.   Since RFC 5340 says that an intra-area route through a non-backbone area is always preferred than an intraarea route through a backbone area, R1 prefers R3 to reach the prefixes 4::/64 even if the cost to reach R2 is better than the cost to reach the FA 34::4.   Let's verify the routing table, we can see that R1 is installing the path through R3 toward 4::/64 prefix:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:00:49 ago R1#   Let's confirm using the traceroute command, the packets go through R3:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 9 msec 10 msec 9 msec 2 34::4 19 msec 18 msec 15 msec R1#   On R1, enable RFC 1583 and increase the cost toward R2 to be higher than the cost to the FA 34::4:   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#compatible rfc1583   R1(config)#int s2/0 R1(config-if)#ospfv3 cost 129   The best path to reach R2 is through area 0 and the cost is 129:   R1#sh ospfv bord OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Codes: i - Intra-area route, I - Inter-area route i 0.0.0.2 [129] via FE80::A8BB:CCFF:FE00:200, Serial2/0, ABR/ASBR, Area 0, SPF 17 i 0.0.0.4 [128] via FE80::A8BB:CCFF:FE00:300, Serial2/1, ASBR, Area 134, SPF 13 R1#   The best path to reach the Forward Address 34::4 is an intra-area route through R3 (area 134) and the cost is 128:   R1#sh ipv route 34:: | s metric Known via "ospf 1", distance 110, metric 128, type intra area R1#   According to RFC 1583 when two or multiple intra-area routes with different cost are availables toward R2 and the FA 34::4, a router selects the lowest cost.

  Let's verify the routing table of R1, since the cost to reach the FA 34::4 is better than the cost to reach R2, R1 installs an ON2 route through R3:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:00:31 ago R1#   The packets go through R3:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 11 msec 10 msec 10 msec 2 34::4 18 msec 13 msec 22 msec R1#   Let's verify that the RFC 1583 and 3101 are still enabled:   R1#sh ospfv3 | s RFC Supports NSSA (compatible with RFC 3101) RFC1583 compatibility enabled Area BACKBONE(0) R1#   On R1, configure the cost 128 to R2:   R1(config)#int s2/0 R1(config-if)#ospfv3 cost 128   R1 looks the best path OSPF to reach R2 and the Forward Address 34::4.   1-R1 finds that it has an inter-area route to reach R2a cost 128 as shown by the sh osp bor command 2-R1 finds also that it has an intra-area route to reach 34::/64 with cost 128 as shown by the sh ipv route 34:: command.   R1#sh os bord OSPFv3 1 address-family ipv6 (router-id 0.0.0.1) Codes: i - Intra-area route, I - Inter-area route i 0.0.0.2 [128] via FE80::A8BB:CCFF:FE00:200, Serial2/0, ABR/ASBR, Area 0, SPF 18 i 0.0.0.4 [128] via FE80::A8BB:CCFF:FE00:300, Serial2/1, ASBR, Area 134, SPF 13 R1#   R1#sh ipv route 34:: Routing entry for 34::/64 Known via "ospf 1", distance 110, metric 128, type intra area Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:45:47 ago R1#  

Since R2 and the Forward Addresses 34::4 are reachable with the same cost 128, and because R1 is implementing the RFC 3101, the following priorities in deciding which LSA (Type 5 or Type 7) is preferred are defined in the RFC 3101:   If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred:   1. A Type-7 LSA with the P-bit set.   2. A Type-5 LSA.   3. The LSA with the higher router ID.   Let's verify the routing table, R1 installs an ON2 route through R3 because the Type-7 LSA is always preferred than a Type-5 LSA according to RFC 3101:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:05:30 ago R1#   The packets go through R3:     R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 10 msec 11 msec 8 msec 2 34::4 19 msec 19 msec 21 msec R1#   Enable RFC 1587 on R1:   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#compatible rfc1587   R1#sh osp | s 1587 Supports NSSA (compatible with RFC 1587) R1#   Verify the routing table, now R1 installs an OE2 route through R2, because a Type-5 LSA is always preferred than a Type-7 LSA according to RFC 1587:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:200, Serial2/0 Last updated 00:00:57 ago R1#

  The packets go through R2:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 12::2 11 msec 10 msec 9 msec 2 24::4 14 msec 7 msec 18 msec R1#   Since the RFC 1583 is enabled, R1 uses RFC 1587 to select the external path to reach 4::/64, Type-5 LSA in this case:   R1#sh ospf | s 1583 RFC1583 compatibility enabled Area BACKBONE(0) R1#   Let's disable RFC 1583, this means that RFC 5340 is enabled:   R1(config-router)#router ospfv 1 R1(config-router)#address-family ipv6 uni R1(config-router-af)#no compatible rfc1583   Verify that RFC 1583 is disabled:   R1#sh ospf | s 1583 RFC1583 compatibility disabled Area BACKBONE(0) R1#   Since RFC 5340 is enabled, R1 use the rule defined by the RFC 5340, an intra-area route learned through a nonbackbone area is always preferred than an intra-area route learned through a backbone

  area. RFC 1587 is ovveriden. Keep in mind that RFC 1587 states that for the same destination and equal distance, a Type-5 LSA is preferred than a Type-7 LSA, remember that a Type-5 is flooded into the backbone area and all regular areas, when this Type-5 LSA is learned through a backbone area (in our case), if you enable RFC 5340 , the rule defined by RFC 5340 overrides the rule defined by RFC 1587.   R2 is reachable through a backbone area 0 while the FA 34::4 is reachable through a non-backbone area 134, as a result R1 installs an ON2 route through R3:   R1#sh ipv route 4:: Routing entry for 4::/64 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:300, Serial2/1 Last updated 00:00:41 ago R1#   The traceroute command shown that the packets go through R3:   R1#tracer 4::4 Type escape sequence to abort. Tracing the route to 4::4 1 13::3 9 msec 7 msec 9 msec 2 34::4 18 msec 20 msec 18 msec

R1#   Keep in mind that RFC 1587 states that for the same destination and equal distance, a Type-5 LSA is preferred than a Type-7 LSA, remember that a Type-5 is flooded into the backbone area and all regular areas, when this Type-5 LSA is learned through a backbone area (in our case), if you enable RFC 5340 , the rule defined by RFC 5340 overrides the rule defined by RFC 1587. RFC 1587 is applied only if RFC 1583 is enabled.   This is not valid with RFC 3101, because it states that a Type-7 LSA is always preferred than a Type-5 LSA, and a Type-7 is only flooded into an NSSA area, in other word a non-backbone area NSSA, this rules is similar with RFC 5340 which states that an intra-area non-backbone route is always preferred than an intra-area backbone route, the only difference, RFC 3101 prefers the Type-7 LSA only if both LSAs 5 and 7 have the same cost toward the ASBRs or the Forward Address. While RFC 5340 applies its rule regardless the cost.                                                                        

Lab 13: Path Selection Scenario 4

Basic configuration.   R1: interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ip ospf 1 area 0 no shut ! router ospf 1 router-id 0.0.0.1   R2: interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 0 no shut ! interface FastEthernet0/1 ip address 23.0.0.2 255.255.255.0 ip ospf 1 area 23 no shut ! interface FastEthernet1/0 ip address 24.0.0.2 255.255.255.0 ip ospf 1 area 24 no shut ! interface FastEthernet1/1 ip address 25.0.0.2 255.255.255.0 ip ospf 1 area 25 no shut ! router ospf 1 router-id 0.0.0.2   R3: interface Loopback0 ip address 100.1.1.3 255.255.255.0 !

interface FastEthernet0/0 ip address 23.0.0.3 255.255.255.0 ip ospf 1 area 23 no shut ! router ospf 1 router-id 0.0.0.3 redistribute connected subnets route-map CONNECTED ! route-map CONNECTED permit 10 match interface Loopback0   R4: interface Loopback0 ip address 100.1.1.4 255.255.255.0 ! interface FastEthernet0/0 ip address 24.0.0.4 255.255.255.0 ip ospf 1 area 24 no shut ! router ospf 1 router-id 0.0.0.4 redistribute connected subnets route-map CONNECTED ! route-map CONNECTED permit 10 match interface Loopback0   R5: interface Loopback0 ip address 100.1.1.5 255.255.255.0 ! interface FastEthernet0/0 ip address 25.0.0.5 255.255.255.0 ip ospf 1 area 25 no shut ! router ospf 1 router-id 0.0.0.5 redistribute connected subnets route-map CONNECTED ! route-map CONNECTED permit 10 match interface Loopback0   R3, R4 and R5 redistribute the prefix 100.1.1.0/24 into OSPF, therefore the LSDB of R2 contains three Type-5 LSA, the Forward Address is set to 0.0.0.0.   R2#sh ip os data external | s Adv|Link St|Forw Type-5 AS External Link States Link State ID: 100.1.1.0 (External Network Number ) Advertising Router: 0.0.0.3 Forward Address: 0.0.0.0 Link State ID: 100.1.1.0 (External Network Number ) Advertising Router: 0.0.0.4 Forward Address: 0.0.0.0 Link State ID: 100.1.1.0 (External Network Number ) Advertising Router: 0.0.0.5 Forward Address: 0.0.0.0

R2#   To select the external route, R2 looks the best intra-area route to reach the ASBR. To find the best cost to reach the ASBRs R3, R4 and R5, use the show ip os bor command. As shown below, the metric to reach 0.0.0.3, 0.0.0.4 and 0.0.0.5 is = 1.   R2#sh ip os border-routers OSPF Router with ID (0.0.0.2) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route i 0.0.0.3 [1] via 23.0.0.3, FastEthernet0/1, ASBR, Area 23, SPF 5 i 0.0.0.5 [1] via 25.0.0.5, FastEthernet1/1, ASBR, Area 25, SPF 3 i 0.0.0.4 [1] via 24.0.0.4, FastEthernet1/0, ASBR, Area 24, SPF 6 R2#   As a result R2 load balances between R3, R4 and R5 to reach 100.1.1.0/24.   R2#sh ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 Last update from 25.0.0.5 on FastEthernet1/1, 00:03:52 ago Routing Descriptor Blocks: 25.0.0.5, from 0.0.0.5, 00:03:52 ago, via FastEthernet1/1 Route metric is 20, traffic share count is 1 24.0.0.4, from 0.0.0.4, 00:04:32 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1 * 23.0.0.3, from 0.0.0.3, 00:06:47 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1 R2#   Configure area 23 as NSSA.   R2(config)#router osp 1 R2(config-router)#area 23 nssa   R3(config)#router osp 1 R3(config-router)#area 23 nssa   For area 23 NSSA, R3 creates and advertises a Type-7 LSA to describe the external prefix 100.1.1.0/24. The Forward Address is set to a non-zero address 23.0.0.3 and The P-bit is set to allow the translation of the Type-7 into Type-5 by the ABR R2.   R2#sh ip os data nss OSPF Router with ID (0.0.0.2) (Process ID 1) Type-7 AS External Link States (Area 23) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 853 Options: (No TOS-capability, Type 7/5 translation, DC, Upward) LS Type: AS External Link Link State ID: 100.1.1.0 (External Network Number ) Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x39D9 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0

Metric: 20 Forward Address: 23.0.0.3 External Route Tag: 0 R2#   While R4 and R5 create and advertise a Type-5 LSA for regular areas 24 and 25.   R2#sh ip os data external adv 0.0.0.4 | s Link St|Forw Type-5 AS External Link States Link State ID: 100.1.1.0 (External Network Number ) Forward Address: 0.0.0.0 R2#   R2#sh ip os data external adv 0.0.0.5 | s Link St|Forw Type-5 AS External Link States Link State ID: 100.1.1.0 (External Network Number ) Forward Address: 0.0.0.0 R2#   Let's verify the routing table of R2.   We can see that R2 installs the NSSA external route through R3.   R2#sh ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 1 Last update from 23.0.0.3 on FastEthernet0/1, 00:04:34 ago Routing Descriptor Blocks: * 23.0.0.3, from 0.0.0.3, 00:04:34 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1 R2#   The reason is answered by RFC 3101 for NSSA, this RFC is published in January 2003 to replace the old RFC 1587 published in March 1994.   Section: 2.5 Calculating Type-7 AS External Routes:   If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred:   1. A Type-7 LSA with the P-bit set.   2. A Type-5 LSA.   3. The LSA with the higher router ID.   If we execute the show ip ospf command, we can see that by default R2 is running RFC 3101.   R2#sh ip os | s RFC Supports NSSA (compatible with RFC 3101) R2#   According to RFC 3101 the Type-7 LSA with the P-bit set is always preferred than a Type-5 LSA, if and only if metric of the external prefix (Default Metric is 20) and the cost toward the ASBRs or the Forward Addresses are equal. Keep in mind that the OE2 and ON2 are equivalent.   To confirm, let's redistribute the external prefix into NSSA with a metric 30 rather the default metric 20.

  R3(config-router)#router ospf 1 R3(config-router)#redistribute connected subnets route-map CONNECTED metric 30   Let's verify the Type-7 LSA's R3, the metric listed in the Type-7 LSA is 30 (the configured metric).   R2#sh ip os data nssa | i Metric Metric Type: 2 (Larger than any link state path) Metric: 30 R2#   For the the Type-5 LSAs advertised by R4 0.0.0.4 and R5 0.0.0.5, they list the default metric 20 of the OE2 route.   R2#sh ip os data ext adv 0.0.0.4 | i Metric Metric Type: 2 (Larger than any link state path) Metric: 20 R2#   R2#sh ip os data ext adv 0.0.0.5 | i Metric Metric Type: 2 (Larger than any link state path) Metric: 20 R2#   Let's verify the routing table of R2.   Since R4 and R5 advertises a better metric 20 compared with the metric 30 advertised by R3, R2 installs a load balancing through R4 and R5 to reach 100.1.1.0/24.   R2#sh ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 Last update from 24.0.0.4 on FastEthernet1/0, 00:05:15 ago Routing Descriptor Blocks: * 25.0.0.5, from 0.0.0.5, 00:05:15 ago, via FastEthernet1/1 Route metric is 20, traffic share count is 1 24.0.0.4, from 0.0.0.4, 00:05:15 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1 R2#   Remove the previous redistribute command on R3.   R3(config-router)#router ospf 1 R3(config-router)#no redistribute connected subnets route-map CONNECTED metric 30   Verify that R2 installed the NSSA external route through R3.   R2#sh ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 1 Last update from 23.0.0.3 on FastEthernet0/1, 00:00:02 ago Routing Descriptor Blocks: * 23.0.0.3, from 0.0.0.3, 00:00:02 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1 R2#   Increase the cost of R2 toward the NSSA ASBR R3.  

R2(config-if)#int fa0/1 R2(config-if)#ip os cost 2   Let's verify the router LSA created by R2 in area 23. R2 sees the router R3 with the IP address 23.0.0.3 which is the Forward Address of the Type-7 LSA's R3 and can reach it with a metric 2.   R2#sh ip os data router self-originate OSPF Router with ID (0.0.0.2) (Process ID 1) Output Omitted Router Link States (Area 23) LS age: 55 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 0.0.0.2 Advertising Router: 0.0.0.2 LS Seq Number: 80000007 Checksum: 0x5A91 Length: 36 Area Border Router AS Boundary Router Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 23.0.0.3 (Link Data) Router Interface address: 23.0.0.2 Number of MTID metrics: 0 TOS 0 Metrics: 2 Output Omitted   The show ip os bor command displays that the ASBRs R4 and R5 are reachable with a metric 1.   R2#sh ip os bor OSPF Router with ID (0.0.0.2) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route i 0.0.0.3 [2] via 23.0.0.3, FastEthernet0/1, ASBR, Area 23, SPF 11 i 0.0.0.5 [1] via 25.0.0.5, FastEthernet1/1, ASBR, Area 25, SPF 5 i 0.0.0.4 [1] via 24.0.0.4, FastEthernet1/0, ASBR, Area 24, SPF 8 R2#   The metric to reach R4 and R5 is better than the metric to reach the Forward Address 23.0.0.3, therefore R2 installs a load balancing to 100.1.1.0, the Type-5 LSAs originated by R4 and R5 are preferred than the Type-7 LSA's R3 because the metric.   Finally, a Type-7 LSA with the P-bit set is preferred than a Type-5 LSA, if and only if the metric of the external prefix (Default Metric is 20) and the cost toward the ASBRs or the Forward Addresses are equal.   Remove the previous command.   R2(config-if)#int fa0/1 R2(config-if)#no ip os cost 2   Verify that the Type-7 LSA's R3 is preferred than the Type-5 LSAs (of R4 and R5). This is because the default RFC 3101 rule implemented by R2. Since the metric of the external prefix and the cost to reach the ASBRs and the Forward Addresses are the same, the RFC 3101 rule is used as tie breaker.   R2#sh ip route 100.1.1.0

Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 1 Last update from 23.0.0.3 on FastEthernet0/1, 00:00:36 ago Routing Descriptor Blocks: * 23.0.0.3, from 0.0.0.3, 00:00:36 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1 R2#   The old RFC 1587 for NSSA published in March 1994 tells that the Type-5 LSA is always preferred than a Type-7 LSA.   3.5 Calculating Type-7 AS External Routes   When a type-5 LSA and a type-7 LSA are found to have the same type and an equal distance, the following priorities apply (listed from highest to lowest) for breaking the tie.   a. Any type 5 LSA. b. A type-7 LSA with the P-bit set and the forwarding address non-zero. c. Any other type-7 LSA.   To confirm let's implement RFC 1587 on R2.   R2(config)#router osp 1 R2(config-router)#compatible rfc1587   Verify the RFC 1587.   R2#sh ip os | s RFC Supports NSSA (compatible with RFC 1587) R2#   Verify the routing table of R2, Since the Type-5 LSAs originated by R4 and the Type-7 LSA's R3 have the same metric listed in the LSAs, and the same cost to reach the ASBRs R4&R5 and the Forward Address 23.0.0.3, the RFC 1587 rule is used as tie breaker. As a result R2 installs a load balancing through R4 and R5.   R2#sh ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 Last update from 24.0.0.4 on FastEthernet1/0, 00:00:39 ago Routing Descriptor Blocks: * 25.0.0.5, from 0.0.0.5, 00:00:39 ago, via FastEthernet1/1 Route metric is 20, traffic share count is 1 24.0.0.4, from 0.0.0.4, 00:00:39 ago, via FastEthernet1/0 Route metric is 20, traffic share count is 1 R2#   On R4 redistribute the external prefix as an OE1 route (metric-type 1).   R4(config-router)#router osp 1 R4(config-router)#redistribute connected route-map CONNECTED subnets metric-type 1   Let's verify the routing table of R2. According to the order path preference of OSPF defined in RFC 3101 and RFC 2328, an OE1 route is always preferred than an OE2 route regardless the cost.   RFC 3101:   Section: 2.5 Calculating Type-7 AS External Routes

  Preference is defined as follows:   (a) Intra-area and inter-area paths are always preferred over AS external paths. [OSPF]   (b) Type 1 external paths are always preferred over type 2 external paths. When all paths are type 2 external paths, the paths with the smallest advertised type 2 metric are always preferred. [OSPF]   (c) If the new AS external path is still indistinguishable from the current paths in N's routing table entry, and RFC1583Compatibility is set to "disabled", select the preferred paths based on the intra-AS paths to the ASBR/forwarding addresses, as specified in Section 16.4.1. Here intra-NSSA paths are equivalent to the intra-area paths of non-backbone regular OSPF areas. [NSSA]   RFC 2328:   Section: 16.4. Calculating AS external routes   (a) Intra-area and inter-area paths are always preferred over AS external paths.   (b) Type 1 external paths are always preferred over type 2 external paths. When all paths are type 2 external paths, the paths with the smallest advertised type 2 metric are always preferred.   (c) If the new AS external path is still indistinguishable from the current paths in the N's routing table entry, and RFC1583Compatibility is set to "disabled", select the preferred paths based on the intra-AS paths to the ASBR/forwarding addresses, as specified in Section 16.4.1.   As a result R1 prefers the OE1 route learned from R4 rather than the OE2 route learned from R5.   R2#sh ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 21, type extern 1 Last update from 24.0.0.4 on FastEthernet1/0, 00:00:34 ago Routing Descriptor Blocks: * 24.0.0.4, from 0.0.0.4, 00:00:34 ago, via FastEthernet1/0 Route metric is 21, traffic share count is 1 R2#   To confirm let's increase the cost toward R4.   R2(config)#int fa1/0 R2(config-if)#ip os cost 10   The sho ip os bor command shown that:  

R4 0.0.0.4 is reachable with a cost 10. R5 0.0.0.5 is reachable with a cost 1.   R2#sh ip os border-routers OSPF Router with ID (0.0.0.2) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route i 0.0.0.3 [1] via 23.0.0.3, FastEthernet0/1, ASBR, Area 23, SPF 12 i 0.0.0.5 [1] via 25.0.0.5, FastEthernet1/1, ASBR, Area 25, SPF 5 i 0.0.0.4 [10] via 24.0.0.4, FastEthernet1/0, ASBR, Area 24, SPF 9 R2#   Let's verify the routing table of R2, we can see that the OE1 via R4 is always preferred than the OE2 route via R5, even if the cost to reach R5 is better than the cost to reach R4.   R2#sh ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 1", distance 110, metric 30, type extern 1 Last update from 24.0.0.4 on FastEthernet1/0, 00:01:38 ago Routing Descriptor Blocks: * 24.0.0.4, from 0.0.0.4, 00:01:38 ago, via FastEthernet1/0 Route metric is 30, traffic share count is 1 R2#   To override this rule, we need to run different OSPF instances on R2 with R4 and R5.   First remove the previous command.   R2(config)#int fa1/0 R2(config-if)#no ip os cost 10   Configure the OSPF instance with a process ID 24 between R2 and R4.   R2(config-if)#interface FastEthernet1/0 R2(config-if)#no ip ospf 1 area 24   R2(config)#router osp 24 R2(config-router)#router-id 0.0.0.22   R2(config-router)#int fa1/0 R2(config-if)#ip ospf 24 area 24   Configure the OSPF instance with a process ID 25 between R2 and R5.   R2(config-if)#interface FastEthernet1/1 R2(config-if)#no ip ospf 1 area 25   R2(config)#router osp 25 R2(config-router)#router-id 0.0.0.222   R2(config-if)#interface FastEthernet1/1 R2(config-if)#ip osp 25 area 25   Verify the neighbor relationship on R2.   R2#sh ip os neighbor

Neighbor ID 0.0.0.5 0.0.0.4 0.0.0.1 0.0.0.3 R2#

Pri 1 1 1 1

State FULL/DR FULL/DR FULL/BDR FULL/DR

Dead Time 00:00:36 00:00:35 00:00:36 00:00:38

Address 25.0.0.5 24.0.0.4 12.0.0.1 23.0.0.3

Interface FastEthernet1/1 FastEthernet1/0 FastEthernet0/0 FastEthernet0/1

  Verify the routing table of R2, the OE1 route is still here.   R2#sh ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 24", distance 110, metric 21, type extern 1 Last update from 24.0.0.4 on FastEthernet1/0, 00:01:43 ago Routing Descriptor Blocks: * 24.0.0.4, from 0.0.0.4, 00:01:43 ago, via FastEthernet1/0 Route metric is 21, traffic share count is 1 R2#   To force the router R2 to install the OE2 route through R5, we should modify the Administrative Distance for external route of the OSPF instance process ID 24 so that the external route OE1 advertised by R4 will get an AD value higher than the default AD of the OE2 route originated by R5.   R2(config-router)#router ospf 24 R2(config-router)#distance ospf external 120   Let's verify the routing table of R2, now R2 installs the OE2 route through R5, because the AD 110 of the OE2 in the instance process ID 25 is lower than the AD 120 of the OE1 route in the instance process ID 24.   R2#sh ip route 100.1.1.0 Routing entry for 100.1.1.0/24 Known via "ospf 25", distance 110, metric 20, type extern 2, forward metric 1 Last update from 25.0.0.5 on FastEthernet1/1, 00:03:17 ago Routing Descriptor Blocks: * 25.0.0.5, from 0.0.0.5, 00:03:17 ago, via FastEthernet1/1 Route metric is 20, traffic share count is 1 R2#    

Lab 14: Forwarding Address Scenario 1  

    Basic configuration of all routers:   R1: interface FastEthernet0/0 ip address 172.16.1.1 255.255.255.0 ip ospf 1 area 0 no shut ! interface FastEthernet0/1 ip address 10.1.13.1 255.255.255.0 ip ospf 1 area 0 no shut ! ip route 192.168.1.0 255.255.255.0 ! router ospf 1 router-id 1.1.1.1 redistribute static subnets   R2: interface FastEthernet0/0 ip address 172.16.1.2 255.255.255.0 ip ospf 1 area 0 no shut ! interface FastEthernet0/1 ip address 10.1.23.2 255.255.255.0 ip ospf 1 area 0 no shut ! router ospf 1 router-id 2.2.2.2   R3: interface FastEthernet0/0 ip address 10.1.13.3 255.255.255.0 ip ospf 1 area 0 no shut

! interface FastEthernet0/1 ip address 10.1.23.3 255.255.255.0 ip ospf 1 area 0 no shut ! router ospf 1 router-id 3.3.3.3   R4: interface lo0 ip address 192.168.1.4 255.255.255.0 ! interface FastEthernet0/0 ip address 172.16.1.4 255.255.255.0 no shut ! ip route 0.0.0.0 0.0.0.0 172.16.1.1   Only R1 has a static route toward 192.168.1.0 and redistribute it into ospf as expected R2 learns this route as external E2:   A static route is configured on R1 to reach the prefix 192.168.1.0/24 and redistributed into OSPF domain.   R2 receives a Type-5 LSA with Forward Address 0.0.0.0 for the prefix 192.168.1.0/24.   R2#show ip ospf database external | include Forward Address|192.168.1.0 Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 0.0.0.0   Per RFC 1583 in the following section:   16.4. Calculating AS external routes   Call the destination described by the advertisement N. N's address is obtained by masking the advertisement's Link State ID with the network/subnet mask contained in the body of the advertisement. Look up the routing table entry for the AS boundary router (ASBR) that originated the advertisement. If no entry exists for router ASBR (i.e., ASBR is unreachable), do nothing with this advertisement and consider the next in the list. Else, this advertisement describes an AS external path to destination N. Examine the forwarding address specified in the AS external link advertisement. This indicates the IP address to which packets for the destination should be forwarded. If the forwarding address is set to 0.0.0.0, packets should be sent to the ASBR itself. Otherwise, look up the forwarding address in the routing table.[23] An intra-area or inter-area path must exist to the forwarding address. If no such path exists, do nothing with the advertisement and consider the next in the list.   Cisco routers implements by default RFC 1583, the new RFC 2328 that replaces the old RFC 1583 specifies the same logic.   Per RFC 2328 in the following section:   16.4. Calculating AS external routes

  If the forwarding address is set to 0.0.0.0, packets should be sent to the ASBR itself. Among the multiple routing table entries for the ASBR, select the preferred entry as follows. If RFC1583Compatibility is set to "disabled", prune the set of routing table entries for the ASBR as described in Section 16.4.1. In any case, among the remaining routing table entries, select the routing table entry with the least cost; when there are multiple least cost routing table entries the entry whose associated area has the largest OSPF Area ID (when considered as an unsigned 32-bit integer) is chosen.   If the forwarding address is non-zero, look up the forwarding address in the routing table.[24] The matching routing table entry must specify an intra-area or inter-area path; if no such path exists, do nothing with the LSA and consider the next in the list.   R2 lookup how to reach the ASBR R1 that originates the Type-5 LSA because the FA is set to 0.0.0.0. R1 is reachable through an intra-area route, as a result R1 installs successfully an OE2 external route to 192.168.1.0/24.   R2#show ip route | include 192.168.1.0 O E2 192.168.1.0/24 [110/20] via 10.1.23.3, 00:03:50, FastEthernet0/1   From R3’s perspective, the same logic is applied.   Below the Type-5 LSA received by R3.   R3#show ip ospf database external | include Forward Address|192.168.1.0 Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 0.0.0.0   Below the routing table of R3 with an OE2 route installed successfully.   R3#show ip route ospf O E2 192.168.1.0/24 [110/20] via 10.1.13.1, 00:00:15, FastEthernet0/0   Enable OSPF R1’s Fa0/0 interface:   R1(config-if)#ip ospf 1 area 0   Now the FA is 172.16.1.4 the ip address of R4 ,so after running fa0/0 R1 includes the FA in its LSA Type 5:   On R2 and R3 verify the Type-5 LSA advertised by the ASBR R1, the Forward Address now is set to a non-zero address 172.16.1.4.   R2#show ip ospf database external | include Forward Address|192.168.1.0 Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 172.16.1.4   R3#show ip ospf database external | include Forward Address|192.168.1.0 Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 172.16.1.4   Verify the routing table of R3, an OE2 route is installed successfully.  

R3#show ip route 192.168.1.0 Routing entry for 192.168.1.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20 Last update from 10.1.13.1 on FastEthernet0/0, 00:00:57 ago Routing Descriptor Blocks: * 10.1.13.1, from 1.1.1.1, 00:00:57 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1   On R2, verify the routing table, the OE2 route is no longer present.   R2#show ip route 192.168.1.0 % Network not in table   Why R2 loses the external route?   Per RFC 1583 in the following section, you will find the answer:   16.4. Calculating AS external routes   Else, this advertisement describes an AS external path to destination N. Examine the forwarding address specified in the AS external link advertisement. This indicates the IP address to which packets for the destination should be forwarded. If the forwarding address is set to 0.0.0.0, packets should be sent to the ASBR itself. Otherwise, look up the forwarding address in the routing table.[23] An intra-area or inter-area path must exist to the forwarding address. If no such path exists, do nothing with the advertisement and consider the next in the list.   R2#show ip ospf database external | include Forward Address|192.168.1.0 Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 172.16.1.4   R3#show ip ospf database external | include Forward Address|192.168.1.0 Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 172.16.1.4   By definition when a router receives a Type-5 LSA with a FA set to non zero in the LSA Type 5, the router lookup an intra-area route or inter-area route to reach the FA.   If we take a look at the routing table of R3, we can see an intra-area route exists to the prefix 172.16.1.0/24 therefore the Forward Address 172.16.1.4 listed in the Type-5 LSA’s R1 is reachable.   R3# show ip route 172.16.1.0 Routing entry for 172.16.1.0/24 Known via "ospf 1", distance 110, metric 20, type intra area Last update from 10.1.13.1 on FastEthernet0/0, 00:23:12 ago Routing Descriptor Blocks: * 10.1.13.1, from 1.1.1.1, 00:23:12 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1   Since the Forward Address is reachable through an OSPF route as mentioned in the RFC 1583, the OE2 external route is valid and can be installed successfully in the routing table.   R3#show ip route 192.168.1.0 Routing entry for 192.168.1.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20

Last update from 10.1.13.1 on FastEthernet0/0, 00:26:15 ago Routing Descriptor Blocks: * 10.1.13.1, from 1.1.1.1, 00:26:15 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1   From R2’s perspective, we have seen previously that the External route is no longer present in the routing table.   Let’s verify if R2 has an OSPF route to reach the Forward Address per RFC 1583 section 16.4. Calculating AS external routes.   The routing table of R2 displays a connected route to 172.16.1.0/24. Since RFC 1583 specifies that An intra-area or inter-area path must exist to the forwarding address and R1 does not have an OSPF route to reach the Forward Address, it does not know how to reach the external prefix 192.168.1.0/24, this is why the external route is no longer available.   R2(config-if)#do show ip route 172.16.1.0 Routing entry for 172.16.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via FastEthernet0/0 Route metric is 0, traffic share count is 1 The value of the forwarding address specified by the autonomous system boundary router (ASBR) can be either 0.0.0.0 or non-zero. The 0.0.0.0 address indicates that the originating router (the ASBR) is the next hop. The forwarding address is determined by these conditions: The forwarding address is set to 0.0.0.0 if the ASBR redistributes routes and OSPF is not enabled on the next hop interface for those routes. This is true in this scenario before enabling OSPF on R1’s F0/0 interface. These conditions set the forwarding address field to a non-zero address: 1. OSPF is enabled on the ASBR's next hop interface AND 2. ASBR's next hop interface is non-passive under OSPF AND 3. ASBR's next hop interface is not point-to-point AND 4. ASBR's next hop interface is not point-to-multipoint AND 5. ASBR's next hop interface address falls under the network range specified in the router ospf command. 6. Any other conditions besides these set the forwarding address to 0.0.0.0.   In this case, the F0/0 interface is not a point-to-point and a point-to-multipoint, the network type is broadcast. This is why the Forward Address is set the non-zero value.   The obvious solution, F0/0 interface should be either point-to-point or point-to-multipoint.   On R1, configure the F0/0 interface to operate in network type point-to-point.   R1(config-if)#int fa0/0 R1(config-if)#ip ospf network point-to-point   On R2, verify the Type-5 LSA advertised by the ASBR R1, the Forward Address is now 0.0.0.0 R2#show ip ospf database external | include Forward Address|192.168.1.0 Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 0.0.0.0   Since the FA is 0.0.0.0, this means, to reach the external prefix 192.168.1.0/24 ,routes the packet to the ASBR R1.   R2#show ip route | include 192.168.1.0 O E2 192.168.1.0/24 [110/20] via 10.1.23.3, 00:01:10, FastEthernet0/1   To ensure the reachablity of the Forward Address without modifying the network type.   You should remember how a router evaluates routes in the following order:   *Prefix Length - The longest-matching route is preferred first. Prefix length trumps all other route attributes.

  *Administrative Distance - In the event there are multiple routes to a destination with the same prefix length, the route learned by the protocol with the lowest administrative distance is preferred.   * Metric - In the event there are multiple routes learned by the same protocol with same prefix length, the route with the lowest metric is preferred.   Configure a secondary IP address 172.16.1.11 in Fa0/0 interface of R1 with a length prefix greater than 24:   R1(config-if)#int fa0/0 R1(config-if)#ip address 172.16.1.11 255.255.255.128 secondary   Verify the routing table of R2 using the show ip route 172.16.1.0 command. An intra-area route to reach 172.16.1.0/25 received from R1 because The longest-matching route /25 wins compared with the directly connected route with 172.16.1.0/24 :   R2(config)#do show ip route 172.16.1.0 Routing entry for 172.16.1.0/25 Known via "ospf 1", distance 110, metric 30, type intra area Last update from 10.1.23.3 on FastEthernet0/1, 00:01:01 ago Routing Descriptor Blocks: * 10.1.23.3, from 1.1.1.1, 00:01:01 ago, via FastEthernet0/1 Route metric is 30, traffic share count is 1   Because now R2 has an intra-area to reach the Forward Address 172.16.1.4 , it installs the external OE2 route   R2(config)#do show ip route 192.168.1.0 Routing entry for 192.168.1.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 30 Last update from 10.1.23.3 on FastEthernet0/1, 00:04:48 ago Routing Descriptor Blocks: * 10.1.23.3, from 1.1.1.1, 00:04:48 ago, via FastEthernet0/1 Route metric is 20, traffic share count is 1                                                      

             

Lab 15: Forwarding Address Scenario 2      

        Basic Configuration of all routers:   R1: interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ip ospf 1 area 0 no sh ! router ospf 1 router-id 0.0.0.1   R2: interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 0 no sh ! interface FastEthernet0/1 ip address 23.0.0.2 255.255.255.0 ip ospf 1 area 23 no shu ! router ospf 1 router-id 0.0.0.2 area 23 nssa   R3: interface Loopback0 ip address 3.3.3.3 255.255.255.0 ! interface FastEthernet0/0 ip address 23.0.0.3 255.255.255.0 ip ospf 1 area 23 no sh ! router ospf 1

router-id 0.0.0.3 area 23 nssa redistribute connected subnets route-map CONNECTED ! route-map CONNECTED permit 10 match interface Loopback0   Area 23 is configured as NSSA. R3 redistrbutes the prefix 3.3.3.0/24 into OSPF domain.   R2 receives a Type-7 LSA from R3 as shown below:   R2#sh ip os data nssa OSPF Router with ID (0.0.0.2) (Process ID 1) Type-7 AS External Link States (Area 23) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 3 Options: (No TOS-capability, Type 7/5 translation, DC, Upward) LS Type: AS External Link Link State ID: 3.3.3.0 (External Network Number ) Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0xFC73 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 23.0.0.3 External Route Tag: 0 R2#   The Forward Address is 23.0.0.3, per RFC 3101 section 2.4 Originating Type-7 LSAs, when an NSSA ASBR originates a Type-7 LSA, the NON-ZERO forwarding address is mandatory and the Forward Address must be set.   2.4 Originating Type-7 LSAs   NSSA AS boundary routers may only originate Type-7 LSAs into NSSAs. An NSSA internal AS boundary router must set the P-bit in the LSA header's option field of any Type-7 LSA whose network it wants advertised into the OSPF domain's full transit topology. The LSAs of these networks must have a valid non-zero forwarding address. If the P-bit is clear the LSA is not translated into a Type-5 LSA by NSSA border routers.   The P-bit in the Type-7 LSA is set so R2 is allowed to translate this LSA into a Type-7 LSA, let's verify the LSDB of R2, we can see below that the Type-7 LSA is translated into a Type-5 LSA and the Forward Address is copied as shown bythe RFC 3101.   Per RFC 3101 section 2.3 Type-7 LSAs   Type-5 LSAs that are translations of Type-7 LSAs copy the Type-7 LSAs' non-zero forwarding addresses.   R1 should receive the Type-5 LSA's R2 as shown below:   R1#sh ip os data ex OSPF Router with ID (0.0.0.1) (Process ID 1)

Type-5 AS External Link States Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 910 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 3.3.3.0 (External Network Number ) Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x97E3 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 23.0.0.3 External Route Tag: 0 R1#   Since the Forward Address is non-zero 23.0.0.3 in the Type-5 LSA, R1 look up the best inter-area route toward 23.0.0.3, and it will use this path to reach the external prefix 3.3.3.0/24. As per RFC 3101 section 2.5:   2.5 Calculating Type-7 AS External Routes   If the forwarding address is non-zero look up the forwarding address in the routing table. For a Type-5 LSA the matching routing table entry must specify an intra-area or inter-area path through a Type-5 capable area. For a Type-7 LSA the matching routing table entry must specify an intra-area path through the LSA's originating NSSA.   Now why the Forward Address must be set in the Type-7 LSA and must copied into the Type-5 LSA when an NSSA ABR performs a translation ?   In a regular areas, any internal router can see an ASBR in another area through a Type-4 LSA, to verify, let's remove the area 23 nssa command on R2 and R3:   R2(config-if)#router ospf 1 R2(config-router)#no area 23 nssa   R3(config-if)#router ospf 1 R3(config-router)#no area 23 nssa   Let's verify on R1, the show ip os border command shown that R1 sees the ASBR R3 0.0.0.3 located in area 23 through R2 12.0.0.2, R1 knows than it need to go through an Inter-area route (or a Type-4 LSA) to reach it.   R1#sh ip os border-routers OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route I 0.0.0.3 [2] via 12.0.0.2, FastEthernet0/0, ASBR, Area 0, SPF 3 i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 3 R1#   Now let's reconfigure area 23 as NSSA:   R2(config-if)#router ospf 1 R2(config-router)#area 23 nssa

  R3(config-if)#router ospf 1 R3(config-router)#area 23 nssa   Let's verify with the show ip os border command:   We can see below that the NSSA ASBR R3 0.0.0.3 is no longer present in the routers table, instead it sees only R2 as an ABR and as a pseudo ASBR (because it origintes a Type-5 LSA).   R1#sh ip os border-routers OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR/ASBR, Area 0, SPF 4 R1#   Since the router R1 does not have the visibility about the ASBR R3 in the NSSA AREA 23, without the Forward Address 23.0.0.3, R1 loses any informations about the NSSA ASBR, the Forward Address 23.0.0.3 helps R1 to have a visibility of the ASBR R3 undirectly because 23.0.0.3 belongs to R3. In a scenario where there are multiple NSSA ABRs, the absence of the Forward Address can cause a suboptimal routing. This is why the RFC 3101 states that the Forward Address is mandatory in order to perform efficient routing as shown in the section 2.3 Type-7 LSAs   Per RFC 3101 section 2.3 Type-7 LSAs   Non-zero forwarding addresses produce efficient inter-area routing to an NSSA's AS external destinations when it has multiple border routers. Also the non-zero forwarding addresses of Type-7 LSAs ease the process of their translation into Type-5 LSAs, as NSSA border routers are not required to compute them.   So since the Forward Address 23.0.0.3 is set in the Type-5 LSA, according to RFC 3101 section 2.5 Calculating Type-7 AS External Routes, R1 look up the best inter-area route to reach 23.0.0.3 in its routing table, let's verify:   R1#sh ip route 23.0.0.0 Routing entry for 23.0.0.0/24, 1 known subnets O IA 23.0.0.0 [110/2] via 12.0.0.2, 01:08:34, FastEthernet0/0 R1#   R1 has a valid inter-area route toward 23.0.0.0/24 through R2 with a cost 2, and it installs the external route to 3.3.3.0/24 successfully in its routing table:   R1#sh ip route 3.3.3.0 Routing entry for 3.3.3.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2 Last update from 12.0.0.2 on FastEthernet0/0, 00:38:46 ago Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:38:46 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1 R1#   Now the challenge is: configure R2 to filter all inter-area routes coming from area 23 using the filter-list.   First we need to identity all the inter-area routes using a prefix-list and associate the prefix-lis with filter-list:   R2(config)#ip prefix-list TEST seq 5 deny 0.0.0.0/0 le 32 R2(config)#router os 1 R2(config-router)# area 23 filter-list prefix TEST out

  Let's verify the routing table for 3.3.3.0/24. The external route is no longer present in the routing table:   R1#sh ip route 3.3.3.0 % Network not in table R1#   Let's verify the LSDB of R1, the Type-5 LSA is still there:   R1#sh ip os data ex OSPF Router with ID (0.0.0.1) (Process ID 1) Type-5 AS External Link States LS age: 1215 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 3.3.3.0 (External Network Number ) Advertising Router: 0.0.0.2 LS Seq Number: 80000002 Checksum: 0x95E4 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 23.0.0.3 External Route Tag: 0 R1#   The external route to 3.3.3.0/24 is not present in the routing table even if the Type-5 LSA is still in the LSDB, why ?   Let's verify the entry for 23.0.0.0/24:   The inter-area route to 23.0.0.0/24 is no longer present in the routing table because the Type-3 LSA filtering done previously with filter list:   R1#sh ip route 23.0.0.0 % Network not in table R1#   The reason why the external route is not present in the routing table is that the Forward Address is unreachable, R1 does not have any inter-area route to reach the Forward Address 23.0.0.3, therefore it does not install the external route to 3.3.3.0/24.   Keep in mind that if the forwarding addresses is filtered out of Area 23, R1 located in area 0 cannot reach the prefix 3.3.3.0/24 advertised in the translated Type-5 LSAs.   To solve this problem, we should suppress the forwarding address on the ABR so that the forwarding address is set to 0.0.0.0 in the translated Type-5 LSAs. A forwarding address set to 0.0.0.0 indicates that packets for the external destination should be forwarded to the advertising OSPF router, in this case, the translating NSSA ABR R2.   The OSPF Forwarding Address Suppression in Translated Type-5 LSAs feature using the area 23 nssa translate type7 suppress-fa command causes the NSSA ABR R2 to translate Type-7 LSA to Type-5 LSAs, but to use the address 0.0.0.0 for the forwarding address instead of that specified in the Type-7 LSA. This feature causes R1 to direct forwarded traffic toward 3.3.3.0/24 to the translating NSSA ABR R2.   But as specified in RFC 3101 section 2.3 Type-7 LSAs, the Forward Address produce efficient routing and avoid suboptimal route, so suppressing the Forward Address should be used carefully.

  Cisco says: Configuring this feature causes the router to be noncompliant with RFC 1587. Also, suboptimal routing might result because there might be better paths to reach the destination’s forwarding address. This feature should not be configured without careful consideration and not until the network topology is understood. Let's suppress the FA:   R2(config)#router osp 1 R2(config-router)#area 23 nssa translate type7 suppress-fa   Let's verify the Type-5 LSA originated by R2, the Forward Address now is 0.0.0.0:   R1#sh ip os data ext OSPF Router with ID (0.0.0.1) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 2 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 3.3.3.0 (External Network Number ) Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x6F26 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 R1#   The Forward Address 0.0.0.0 means that to reach the the external prefix 3.3.3.0/24, R1 will redirect the traffic to the Type-5 LSA's originator, let's verify the routing table of R1, the external route to 3.3.3.0/24 is installed successfully and the forward metric represents the cost to reach the NSSA ABR'translator R2:   R1#sh ip route 3.3.3.0 Routing entry for 3.3.3.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 Last update from 12.0.0.2 on FastEthernet0/0, 00:01:55 ago Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:01:55 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1 R1#   To confirm, let's display the show ip os bor output, the NSSA ABR R2 is reachable with a cost 1, this is the forward metric displayed in the show ip route 3.3.3.0 command:   R1#sh ip os bord OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR/ASBR, Area 0, SPF 2 R1#   Remove the previously command and use another method to suppress the FA in order to solve the problem.  

R2(config)#router osp 1 R2(config-router)#no area 23 nssa translate type7 suppress-fa   The second method to suppress the Forward Address is to aggregate the Type-7 LSA prefixes on the NSSA ABR R2 using the summary-address command, keep in mind that this command should be executed on the ASBR, and R2 is a pseudo ASBR since it is originating a Type-5 LSA, this causes R2 to generate a Type-5 LSA for the summary prefix with a Forward Address 0.0.0.0.   Per RFC 3101 , the sections Type-7 LSAs and Translating Type-7 LSAs into Type-5 LSAs explain that the FA is set to 0.0.0.0 in the translated Type-5 LSA when performing summarization on the NSSA ABR for the Type-7 LSAs.   2.3 Type-7 LSAs   Type-5 LSAs that are translations of Type-7 LSAs copy the Type-7 LSAs' non-zero forwarding addresses. Only those Type-5 LSAs that are aggregations of Type-7 LSAs may have 0.0.0.0 as a forwarding address. (See Section 3.2 for details.)   3.2 Translating Type-7 LSAs into Type-5 LSAs   The newly generated Type-5 LSA will have a link-state ID equal to the Type-7 address range's address (in the case of multiple originations of Type-5 LSAs with the same network address but different mask, the link-state ID can also have one or more of the range's "host" bits set). The advertising router field will be the router ID of this area border router. The network mask and the external route tag are set to the range's configured values. The forwarding address is set to 0.0.0.0. The path type and metric are set to the range's path type and metric as defined and computed above.   Let's configure the summary-address 3.3.3.0 255.255.255.0 command on R2:   R2(config-router)#router osp 1 R2(config-router)#summary-address 3.3.3.0 255.255.255.0   Let's verify the Type-5 LSA originated by R2, the Forward Address is set to 0.0.0.0:   R1#sh ip os data ext OSPF Router with ID (0.0.0.1) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 186 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 3.3.3.0 (External Network Number ) Advertising Router: 0.0.0.2 LS Seq Number: 80000003 Checksum: 0x6B28 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 R1#  

Let's verify the routing table of R1, now the external route is installed successfully, R1 looks the best path to reach the NSSA ABR translator, the traffic should be forwarded to the advertising OSPF router, in this case, the translating NSSA ABR R2.   R1#sh ip route 3.3.3.0 Routing entry for 3.3.3.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 Last update from 12.0.0.2 on FastEthernet0/0, 00:07:14 ago Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:07:14 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1 R1#   Using the summary-address 3.3.3.0 255.255.255.0 command on the NSSA ABR has the same effect with the area 23 nssa translate type7 suppress-fa command, it sets the Forward Address to 0.0.0.0.   When we perform a summarization of external prefixes on an NSSA ABR (which is a pseudo ASBR), the NSSA ABR must clear the FA, the FA is not copied from Type-7 LSA into Type-5 LSA. As explained in RFC 3101, it seems logic, since it is the router which performs the summarization, it should tell to other router (R1 in this case), to reach the external route, send the traffic to me.                                      

Lab 16: Forwarding Address Scenario 3      

    Basic configuration of all routers:   R1: ipv uni ! Interface Ethernet0/0 ipv6 address 21::1/64 ipv6 ospf 1 area 12 ! interface Serial 1/0 ipv6 address 12::1/64 ipv6 ospf 1 area 0 ! ipv6 router ospf 1 router-id 0.0.0.1   R2: ipv uni ! Interface Ethernet0/0 ipv6 address 21::2/64 ipv6 ospf 1 area 12 ! interface Serial 1/0 ipv6 address 12::2/64 ipv6 ospf 1 area 0 ! ipv6 router ospf 1 router-id 0.0.0.1 ! Interface Ethernet0/1 ipv6 address 23::2/64 ipv6 ospf 1 area 1 no shut ! interface Ethernet0/2 ipv6 address 32::2/64 ipv6 ospf 1 area 2 no shut ! ipv6 router ospf 1 router-id 0.0.0.2

  R3: ipv uni ! Interface Ethernet0/1 ipv6 address 23::3/64 ipv6 ospf 1 area 1 no shut ! interface Ethernet0/2 ipv6 address 32::3/64 ipv6 ospf 1 area 2 no shut ! ipv6 router ospf 1 router-id 0.0.0.3 redistribute connected route-map TEST ! route-map TEST permit 10 match interface Loopback0   R3 redistributes the external prefix 3::/64 into OSPF.   Let’s verify the LSDB of R1, we can see that it is receiving one Type-5 LSA from R3 0.0.0.3.   R1#sh ipv os data ex OSPFv3 Router with ID (0.0.0.1) (Process ID 1)       Type-5 AS External Link States LS age: 182 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x12A4 Length: 36 Prefix Address: 3:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R1#   Since the Forward Address is not set in the Type-5 LSA, R1 lookup how to reach the ASBR and it needs a Type-4 LSA because R3 is located in another area, the ABR R2 will give this information, remember that Type-4 LSA has an area flooding scope, in this topology R2 is connected to R1 through two different areas, therefore R2 creates two Type-4 LSAs for areas 0 and 12 as shown below, because the loop-prevention mechanism of inter-area routes, the ABR R1 ignores the Type-4 LSA learned through area 12 the non-backbone area, ABR expects summary and ASB-summary LSAs from Area 0 only. This means there should be at least one adjacency in FULL state built over Area 0 interface. In case if ABR has such adjacency, it will ignore summary-LSAs received over non-backbone areas. These LSAs will be installed in the database, but not used for SPF calculations. This why you see the line “LSA ignored in SPF calculation” in the Type-4 LSA learned through area 12 as shown below.   R1#sh ipv os data inter router adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.1) (Process ID 1)       Inter Area Router Link States (Area 0) Routing Bit Set on this LSA LS age: 249 Options: (V6-Bit, E-Bit, R-Bit, DC-Bit) LS Type: Inter Area Router Links Link State ID: 3

Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x39BB Length: 32 Metric: 10 Destination Router ID: 0.0.0.3       Inter Area Router Link States (Area 12) LSA ignored in SPF calculation LS age: 249 Options: (V6-Bit, E-Bit, R-Bit, DC-Bit) LS Type: Inter Area Router Links Link State ID: 3 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x39BB Length: 32 Metric: 10 Destination Router ID: 0.0.0.3 R1#   The total and best cost to reach the ASBR R3 can be displayed with the sh ipv os bord command, we can see that R1 considers the path through s1/0 as the best path to reach the ASBR R3 with a metric of 74. R1#sh ipv os bor OSPFv3 Router with ID (0.0.0.1) (Process ID 1) Codes: i - Intra-area route, I - Inter-area route I 0.0.0.3 [74] via FE80::A8BB:CCFF:FE00:2000, Serial1/0, ASBR, Area 0, SPF 5 i 0.0.0.2 [10] via FE80::A8BB:CCFF:FE00:2000, Ethernet0/0, ABR, Area 12, SPF 2 i 0.0.0.2 [64] via FE80::A8BB:CCFF:FE00:2000, Serial1/0, ABR, Area 0, SPF 5 R1#   Verify the routing table, R1 installs the path through s1/0, this suboptimal routing is caused by the loop prevention mechanism of inter-area route.   R1#sh ipv route 3:: Routing entry for 3::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:2000, Serial1/0 Last updated 00:05:24 ago R1#   The traceroute command confirms the result:   R1#tracer 3::3 Type escape sequence to abort. Tracing the route to 3::3 1 12::2 9 msec 9 msec 8 msec 2 23::3 9 msec 8 msec 10 msec R1#   This is what we call, the split-horizon mechanism. When an ABR learns a Type-3 LSA or Type-4 LSA through a non-backbone area, it ignores this LSA to prevent loop.   RFC 3509 explains OSPF ABR Behavior and split-horizon mechanism in the following section:   1.2 Motivation  

In OSPF domains the area topology is restricted so that there must be a backbone area (area 0) and all other areas must have either physical or virtual connections to the backbone. The reason for this star-like topology is that OSPF inter-area routing uses the distance-vector approach and a strict area hierarchy permits avoidance of the "counting to infinity" problem. OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, allowing ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes, and limiting ABRs' SPF calculation to consider only Summary-LSAs in the backbone area's link-state database.   The last restriction leads to a problem when an ABR has no backbone connection (in OSPF, an ABR does not need to be attached to the backbone).   To prevent the suboptimal routing and override the split-horizon rule, we need to block the Type-4 LSA so that the ABR R2 will not generate it for both area 12 and area 0, to do this configure areas 1 and 2 as NSSA:   R2(config)#ipv router os 1 R2(config-rtr)#area 1 nssa R2(config-rtr)#area 2 nssa   R3(config)#ipv router os 1 R3(config-rtr)#area 1 nssa R3(config-rtr)#area 2 nssa   Since areas 1 and 2 are configured as NSSA, R3 generates two Type-7 LSAs for areas 1 and 2 with the Forward Address 23::3 and 32::3 respectively, from the ABR R2’s perspective, to decide which Type-7 LSA, it uses the area id as the tie breaker, the largest area id will win, in this case the Type-7 LSA learned through area 2 is chosen to be translated rather than the Type-7 LSA learned through area 1, this rule is described in RFC 3101.   On R1 verify that it is receiving the Type-5 LSA with the Forward Address 32::3 from the NSSA translator R2.   R1#sh ipv os data ex OSPFv3 Router with ID (0.0.0.1) (Process ID 1)       Type-5 AS External Link States LS age: 174 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x90DF Length: 52 Prefix Address: 3:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 32::3 R1#   Verify the routing table of R1 for the prefix 3::/64, we can see that R1 is still using the slower path through the serial link to reach the external prefix.   R1#sh ipv route 3:: Routing entry for 3::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0

Routing paths: FE80::A8BB:CCFF:FE00:2000, Serial1/0 Last updated 00:00:05 ago R1#   The reason is the same one mentioned previously, R1 when it want to select the best path to reach the external prefix 3::/64, it will lookup the best inter-area route to reach the Forward Address 32::/64 listed in the Type-5 LSA, the routing table below shown that the inter-area route through the serial link is the best path to reach the Forward Address 32::3/64, because the inter-area loop prevention mechanism, the ABR R1 ignores the Type-3 LSA learned from the ABR R2 through area 12, a Type-3 LSA learned by an ABR through a non-backbone area is not considered in SPF calculation.   R1#sh ipv route os | beg App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application OE2 3::/64 [110/20] via FE80::A8BB:CCFF:FE00:2000, Serial1/0 OI 23::/64 [110/74] via FE80::A8BB:CCFF:FE00:2000, Serial1/0 OI 32::/64 [110/74] via FE80::A8BB:CCFF:FE00:2000, Serial1/0 R1#   To override this rule once again we should suppress the Forward Address, this causes the ABR NSSA R2 to translate Type-7 LSAs to Type-5 LSAs, but use the address 0.0.0.0 for the forwarding address instead of that specified in the Type-7 LSA. This causes R2 that are configured not to advertise forwarding addresses into area 0 and area 12 to direct forwarded traffic to the translating NSSA ABR R2:   R2(config-rtr)#ipv router os 1 R2(config-rtr)#area 2 nssa translate type7 suppress-fa   Verify the Type-5 LSA on R1, the Forward Address now is not set.   R1#sh ipv os data ex OSPFv3 Router with ID (0.0.0.1) (Process ID 1)       Type-5 AS External Link States LS age: 6 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.2 LS Seq Number: 80000008 Checksum: 0xAA6 Length: 36 Prefix Address: 3:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R1#   Since the FA is suppressed, R1 looks the best path to reach the NSSA ABR R2 which is also an ASBR.   There are two host intra-area routing entries for the same router-id "0.0.0.2" and with the cost 10 through area 12 and a cost 64 through area 0. the intra-area route through area 12 is better.   R1#sh ipv os bor OSPFv3 Router with ID (0.0.0.1) (Process ID 1) Codes: i - Intra-area route, I - Inter-area route i 0.0.0.2 [10] via FE80::A8BB:CCFF:FE00:2000, Ethernet0/0, ABR/ASBR, Area 12, SPF 3 i 0.0.0.2 [64] via FE80::A8BB:CCFF:FE00:2000, Serial1/0, ABR/ASBR, Area 0, SPF 6

R1#   Verify the routing table of R1, we can see that now it installs the path through area 12.   R1#sh ipv route 3:: Routing entry for 3::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:2000, Ethernet0/0 Last updated 00:01:21 ago R1#   The trace route confirms the result.   R1#tracer 3::3 Type escape sequence to abort. Tracing the route to 3::3 1 21::2 4 msec 1 msec 1 msec 2 32::3 1 msec 1 msec 1 msec R1#   Verify the connectivity.   R1#ping 3::3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3::3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/9 ms R1#   Remove the area 2 nssa translate type7 suppress-fa command and use another solution to resolve the suboptimal routing issue.   The second method to suppress the Forward Address is to aggregate the Type-7 LSA prefixes on the NSSA ABR R2 using the summary-prefix command, keep in mind that this command should be executed on the ASBR, and R2 is a pseudo ASBR since it is originating a Type-5 LSA, this causes R2 to generate a Type-5 LSA for the summary prefix 3::/64 without the Forward Address.   Per RFC 3101, the sections Type-7 LSAs and Translating Type-7 LSAs into Type-5 LSAs explain that the FA is set to zero in the translated Type-5 LSA when performing summarization on the NSSA ABR for the Type-7 LSAs.   Section: 2.3 Type-7 LSAs   Type-5 LSAs that are translations of Type-7 LSAs copy the Type-7 LSAs' non-zero forwarding addresses. Only those Type-5 LSAs that are aggregations of Type-7 LSAs may have 0.0.0.0 as a forwarding address. (See Section 3.2 for details.)   Section: 3.2 Translating Type-7 LSAs into Type-5 LSAs   The newly generated Type-5 LSA will have a link-state ID equal to the Type-7 address range's address (in the case of multiple originations of Type-5 LSAs with the same network address but different mask, the link-state ID can also have one or more of the range's "host" bits set). The advertising router field will be the router ID of this area border router. The network mask and the external route tag are set to the range's configured values. The forwarding address is set to 0.0.0.0.

The path type and metric are set to the range's path type and metric as defined and computed above.   So remove the area 2 nssa translate type7 suppress-fa command and configure the summary-prefix 3::/64 command.   R2(config-rtr)#no area 2 nssa translate type7 suppress-fa R2(config-rtr)#summary-prefix 3::/64   Let’s verify the Type-5 LSA, the Forward Address is not set.   R1#sh ipv os data ex OSPFv3 Router with ID (0.0.0.1) (Process ID 1)       Type-5 AS External Link States LS age: 6 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.2 LS Seq Number: 80000012 Checksum: 0xF5B0 Length: 36 Prefix Address: 3:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R1#   Let's verify the routing table of R1, now the external route to 3::/64 through area 12 is installed successfully, R1 looks the best path to reach the NSSA ABR translator, the traffic should be forwarded to the advertising OSPF router, in this case, the translating NSSA ABR R2 through the best intra-area route.   R1#sh ipv route 3:: Routing entry for 3::/64 Known via "ospf 1", distance 110, metric 20, type extern 2 Route count is 1/1, share count 0 Routing paths: FE80::A8BB:CCFF:FE00:2000, Ethernet0/0 Last updated 00:00:07 ago R1#   Let’s verify the connectivity to 3::/64, the ping from R1 fails.   R1#ping 3::3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3::3, timeout is 2 seconds: XXXXX                   Success rate is 0 percent (0/5) R1#   It seems that the issue is the router R2, let’s verify the routing table of R2, WAW, R2 has no longer an NSSA external routes to 3::/64 in its routing tables, instead, it has a intra-area route via null0. And according to the OSPF path selection described by RFC 1583, an intra-area route is always preferred than an external route.   RFC 1583 section:   11.1. Routing table lookup   Reduce the set of matching entries to those having the most

preferential path-type (see Section 11). OSPF has a four level hierarchy of paths. Intra-area paths are the most preferred, followed in order by inter-area, type 1 external and type 2 external paths.   R2#sh ipv rou osp | be App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application O 3::/64 [254/20] via Null0, directly connected R2#   With OSPF External and internal discard-route entries pointed to the null0 interface are installed in routing tables by default when configuring route summarization, routing loops may occur when packet is sent to a prefix which is a part of the summary but this prefix is no longer reachable, and a router that is performing summarization has a default route advertised by another router. To prevent the routing loop, a discard route is installed in the routing table of the ABR or ASBR.   If you do not want to use the external for ASBR or internal for ABR discard route, you can remove the discard route using the no discard-route command with the external or internal keyword for ABR and ASBR respectively.   Since we are using the summary-prefix command on an ASBR, remove the discard route using the external keyword.   R2(config)#ipv router os 1 R2(config-rtr)#disc R2(config-rtr)#discard-route ex R2(config-rtr)#no discard-route external   Verify the routing table of R2, the discard route is no longer present.   R2#sh ipv rou osp | be App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application ON2 3::/64 [110/20] via 32::3, Ethernet0/2 via 23::3, Ethernet0/1 R2#   The ping from R1 is now successful.   R1#ping 3::3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3::3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R1#   R1#trace 3::3 Type escape sequence to abort. Tracing the route to 3::3 1 21::2 4 msec 1 msec 0 msec 2 32::3 1 msec 0 msec 0 msec R1#          

                                     

Lab 17: Route Filtering Scenario 1    

    Basic configuration:   R1: ipv uni ! interface Loopback0 ipv6 address 1::1/64 ipv6 ospf 1 area 0 ipv6 ospf network point-to-point ! interface fa0/0 ipv6 address 13::1/64 ipv6 ospf 1 area 0 no sh ! ipv6 router ospf 1 router-id 0.0.0.1   R2: ipv uni ! interface Loopback0 ipv6 address 2::2/64 ipv6 ospf 1 area 0 ipv6 ospf network point-to-point

! interface fa0/0 ipv6 address 23::2/64 ipv6 ospf 1 area 0 no sh ! ipv6 router ospf 1 router-id 0.0.0.2   R3: ipv uni ! interface fa0/0 ipv6 address 13::3/64 ipv6 ospf 1 area 0 no sh ! interface fa0/1 ipv6 address 23::3/64 ipv6 ospf 1 area 0 no sh ! interface Serial1/0 ipv6 address 34::3/64 ipv6 ospf 1 area 1 no sh ! ipv6 router ospf 1 router-id 0.0.0.3   R3: ipv uni ! interface Loopback0 ipv6 address 4::4/64 ipv6 ospf 1 area 1 ! interface Serial1/0 ipv6 address 34::4/64 ipv6 ospf 1 area 1 no sh ! ipv6 router ospf 1 router-id 0.0.0.4   Verify the LSDB of R3, we should see two Type-9 LSAs originated by R1 (Advertising Router: 0.0.0.1) and R2 (Advertising Router: 0.0.0.2), R1 lists the prefix 1::/64, and R2 lists the prefix 2::/64.   R3#sh ipv ospf data prefix adv 0.0.0.1 OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 70 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.1 LS Seq Number: 80000003 Checksum: 0xCB4

Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.1 Number of Prefixes: 1 Prefix Address: 1:: Prefix Length: 64, Options: None, Metric: 1 R3#   R3#sh ipv ospf data prefix adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 65 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.2 LS Seq Number: 80000003 Checksum: 0x2895 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.2 Number of Prefixes: 1 Prefix Address: 2:: Prefix Length: 64, Options: None, Metric: 1 R3#   Note: In OSPFv2, the Type-1 and Type-2 LSAs combine together topology and the prefixes associated with each link. both describes a part of the topology (what is connected to whom) and the addresses being used in that part of the topology.   In OSPFv3, the Type-1 and Type-2 LSAs no longer carry any addressing information. They only carry a description of topology adjacencies. This is how Type-8 and Type-9 LSAs came to be.   Type-8 LSA (Link LSA) advertises link-local address and prefix(es) of a router to all other routers on the link. Type-9 LSA (Intra-Area-Prefix LSA) Performs one of two functions: Associates a list of IPv6 prefixes with a transit network by pointing to a Network LSA. Associates a list of IPv6 prefixes with a router by pointing to a Router LSA.   Type-8 LSAs have the link flooding scope and are never flooded beyond the receiving neighbor on the link. Type-9 LSAs have the area flooding scope and are never flooded into other areas.   Let's verify the routing table of R3, the prefixes 1::/64 and 2::/64 are installed as an intra-area routes:   R3#sh ipv route os | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 1::/64 [110/2] via FE80::C801:1BFF:FE4C:8, FastEthernet0/0 O 2::/64 [110/2] via FE80::C802:2EFF:FE1C:8, FastEthernet0/1 O 4::/64 [110/65] via FE80::C804:2FFF:FE98:8, Serial1/0 R3#   Since R4 is located in another area, the ABR R3 creates and floods two Type-3 LSAs for 1::/64 and 2::/64 prefixes, the routing table of R4 displays two inter-area routes toward 1::/64 and 2::/64:   R4#sh ipv route osp | beg OE2

OI OI OI OI

OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP 1::/64 [110/66] via FE80::C803:2FF:FEF0:8, Serial1/0 2::/64 [110/66] via FE80::C803:2FF:FEF0:8, Serial1/0 13::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 23::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0

R4#   Configure R3 so that it filters the prefixes 1::/64 and 2::/64 and they should not be installed in the routing table using the distribute-list command:   With OSPF there are some rules to be considered when using distribute-list:   The distribute-list command is used to filter routes from being installed in the routing table or redistributed into another routing protocol, it Using the distribute-list command in the inbound direction is used to filter routes to be installed in the routing table. Using the distribute-list command in the outbound direction filters only the desired redistributed routes. Meaning that is used only on ASBRs.   First, create a prefix list that denies the prefixes 1::/64 and 2::/64, all other routes should be permitted because the implicit deny in the prefix list:   R3(config)#ipv prefix-list FILTER-R3 seq 10 deny 1::/64 R3(config)#ipv prefix-list FILTER-R3 seq 11 deny 2::/64 R3(config)#ipv prefix-list FILTER-R3 seq 12 permit ::/0 le 128   Associate the prefix list created previously to the distribute-list command in the inbound direction:   R3(config-rtr)#ipv router ospf 1 R3(config-rtr)#distribute-list prefix-list FILTER-R3 in   Let's verify the routing table of R3, the prefixes 1::/64 and 2::/64 are no longer present in the routing table:   R3#sh ipv route os | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 4::/64 [110/65] via FE80::C804:2FFF:FE98:8, Serial1/0 R3#   What about R4, the routing table shown that R4 has learned the inter-area routes to 1::/64 and 2::/64, this is because with OSPF, the distribute list does not filter LSAs:   R4#sh ipv route osp | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OI 1::/64 [110/66] via FE80::C803:2FF:FEF0:8, Serial1/0 OI 2::/64 [110/66] via FE80::C803:2FF:FEF0:8, Serial1/0 OI 13::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 OI 23::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 R4#   Let's verify the LSDB of R3, the Type-9 LSAs of R1 and R2 are still there. There was no effect on the LSDB:

  R3#sh ipv os data prefix adv 0.0.0.1 OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 450 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.1 LS Seq Number: 80000003 Checksum: 0xCB4 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.1 Number of Prefixes: 1 Prefix Address: 1:: Prefix Length: 64, Options: None, Metric: 1 R3#   R3#sh ipv os data prefix adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 446 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.2 LS Seq Number: 80000003 Checksum: 0x2895 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.2 Number of Prefixes: 1 Prefix Address: 2:: Prefix Length: 64, Options: None, Metric: 1 R3#   This is why R4 is still receiving the Type-3 LSAs for 1::/64 and 2::/64 from the ABR R3 as shown below:   R4#sh ipv os data inter-area prefix 1::/64 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Routing Bit Set on this LSA LS age: 483 LS Type: Inter Area Prefix Links Link State ID: 9 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x25C2 Length: 36 Metric: 2 Prefix Address: 1:: Prefix Length: 64, Options: None R4#   R4#sh ipv os data inter-area prefix 2::/64 OSPFv3 Router with ID (0.0.0.4) (Process ID 1)

Routing Bit Set on this LSA LS age: 476 LS Type: Inter Area Prefix Links Link State ID: 10 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x27BE Length: 36 Metric: 2 Prefix Address: 2:: Prefix Length: 64, Options: None R4#   R4 has two inter-area routes toward 1::/64 and 2::/64, but no reachability:   R4#ping 1::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1::1, timeout is 2 seconds: UUUUU Success rate is 0 percent (0/5) R4#   R4#ping 2::2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2::2, timeout is 2 seconds: UUUUU Success rate is 0 percent (0/5) R4#   Configure R4 so that it filters the prefixes 1::/64 and 2::/64 and they should not be installed in the routing table using the distribute-list command:   R4(config)#ipv prefix-list FILTER-R4 seq 10 deny 1::/64 R4(config)#ipv prefix-list FILTER-R4 seq 11 deny 2::/64 R4(config)#ipv prefix-list FILTER-R4 seq 12 permit ::/0 le 128 R4(config)#ipv router ospf 1 R4(config-rtr)#distribute-list prefix-list FILTER-R4 in   The Type-3 LSAs for 1::/64 and 2::/64 are still int the LSDB as shown below:   R4#sh ipv os data inter-area prefix 1::/64 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Routing Bit Set on this LSA LS age: 766 LS Type: Inter Area Prefix Links Link State ID: 9 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x25C2 Length: 36 Metric: 2 Prefix Address: 1:: Prefix Length: 64, Options: None R4#   R4#sh ipv os data inter-area prefix 2::/64 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Routing Bit Set on this LSA

LS age: 759 LS Type: Inter Area Prefix Links Link State ID: 10 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x27BE Length: 36 Metric: 2 Prefix Address: 2:: Prefix Length: 64, Options: None R4#   Let's verify the routing table of R4, the prefixes 1::/64 and 2::/64 are no longer present in the routing table:   R4#sh ipv route os | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OI 13::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 OI 23::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 R4#   Since there is no routes, the ping command shown "No valid route for destination":   R4#ping 1::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1::1, timeout is 2 seconds: % No valid route for destination Success rate is 0 percent (0/1) R4#   R4#ping 2::2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2::2, timeout is 2 seconds: % No valid route for destination Success rate is 0 percent (0/1) R4#   Remove the distribute-list command on R3 and R4.   R3(config-rtr)#ipv router ospf 1 R3(config-rtr)#no distribute-list prefix-list FILTER-R3 in   R4(config)#ipv router ospf 1 R4(config-rtr)#no distribute-list prefix-list FILTER-R4 in   Verify the routing table of R3 and R4 once again:   R3#sh ipv route os | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 1::/64 [110/2] via FE80::C801:1BFF:FE4C:8, FastEthernet0/0 O 2::/64 [110/2] via FE80::C802:2EFF:FE1C:8, FastEthernet0/1 O 4::/64 [110/65] via FE80::C804:2FFF:FE98:8, Serial1/0 R3#

  R4#sh ipv route osp | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OI 1::/64 [110/66] via FE80::C803:2FF:FEF0:8, Serial1/0 OI 2::/64 [110/66] via FE80::C803:2FF:FEF0:8, Serial1/0 OI 13::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 OI 23::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 R4#   Configure R4 so that it does not install an inter-area routes in the routing neither a Type-3 LSAs in the LSDB for 1::/64 and 2::/64 using the area filter-list or area range commands.   Note The ABR Type 3 link-state advertisement (LSA) Filtering allows ABR to filter type 3 LSAs between different OSPF areas using the area filter-list command. The ABR Type 3 LSA filtering with filter-list allows only specified prefixes to be sent from one area to another area and restricts all other prefixes. This type of area filtering can be applied out of a specific OSPF area, into a specific OSPF area, or into and out of the same OSPF areas at the same time.   With IOS 15.2, it seems OSPFv3 does not support the area filter-list command as shown below:   R3(config)#ipv router osp 1 R3(config-rtr)#area 0 ? authentication Enable authentication encryption Enable encryption no-transit Do not use this router to transit data range Summarize routes matching address/mask (border routers only) R3(config-rtr)#   This feature is available with OSPFv2 as shown below:   R3(config)#router osp 1 R3(config-router)#area 0 ? authentication Enable authentication capability Enable area specific capability default-cost Set the summary default-cost of a NSSA/stub area filter-list Filter networks between OSPF areas nssa Specify a NSSA area range Summarize routes matching address/mask (border routers only) sham-link Define a sham link and its parameters stub Specify a stub area R3(config-router)#   Let's use the area range command.   OSPF offers two methods of route summarization: Summarization of internal routes performed on the ABRs using the area range command. Summarization of external routes performed on the ASBRs using the summary-address command.   The area range command has some interesting parameters to remove the summarization.   The parameters "not-advertise" sets the address range status to DoNotAdvertise. The Type 3 summary LSA is suppressed, and the component networks remain hidden from other networks.   From Cisco, the interaction between the area filter-list and area range command is explained in the following section:

  With this feature enabled in the "in" direction, all type 3 LSAs originated by the ABR to this area, based on information from all other areas, are filtered by the prefix-list. Type 3 LSAs that were originated as a result of the area-range command in another area are treated like any other type 3 LSA that was originated individually. Any prefix that does not match an entry in the prefix list is implicitly denied.   With this feature enabled in the "out" direction, all type 3 LSAs advertised by the ABR, based on information from this area to all other areas, are filtered by the prefix list. If the area-range command has been configured for this area, type 3 LSAs that correspond to the area-range are sent to all other areas, only if there is at least one prefix in the area range that matches an entry in the prefix list.   If all specific prefixes are denied by the prefix list, type 3 LSAs that correspond to the area-range command will not be sent to any other area. Prefixes that are not permitted by the prefix list are implicitly denied.   On R3 let's configure area range command for the prefixes 1::/64 and 2::/64 with "not-advertise" keyword:   R3(config-rtr)#ipv router osp 1 R3(config-rtr)#area 0 range 1::/64 not-advertise R3(config-rtr)#area 0 range 2::/64 not-advertise   Verify that the area range command is configured using the sh ipv osp command:   R3#sh ipv ospf | s ranges|Area Area BACKBONE(0) Area ranges are 1::/64 Passive DoNotAdvertise 2::/64 Passive DoNotAdvertise Area 1 R3#   The ABR R3 that performs the Type 3 link-state advertisement (LSA) Filtering has the intra-area route in the routting table:   R3#do sh ipv route os | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 1::/64 [110/2] via FE80::C801:1BFF:FE4C:8, FastEthernet0/0 O 2::/64 [110/2] via FE80::C802:2EFF:FE1C:8, FastEthernet0/1 O 4::/64 [110/65] via FE80::C804:2FFF:FE98:8, Serial1/0 R3(config-rtr)#   Let's verify the LSDB of R4, since the "not-advertise" keyword is added to the area range command, it instructs R3 not to generate a Type-3 LSAs for 1::/64 and 2::/64, as a result, the Type-3 LSA for these prefixes are no longer in the LSDB of R4:   R4#sh ipv os data inter-area prefix 1::/64 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) R4#   R4#sh ipv os data inter-area prefix 2::/64 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) R4#   The routing table of R4 shown that there no inter-area routes to 1::/64 and 2::/64:   R4#sh ipv route os | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP

OI OI

13::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 23::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0

R4#   Remove the area range with the "not-advertise" keyword:   R3(config)#ipv router osp 1 R3(config-rtr)#no area 0 range 1::/64 not-advertise R3(config-rtr)#no area 0 range 2::/64 not-advertise   As mentioned previously, The area range command has some interesting parameters to remove the summarization. Let's take a look at the cost parameters   The parameters "cost" is the metric for this summary route, which is used during OSPF SPF calculation to determine the shortest paths to the destination. The value can be 0 to 16,777,214.   The idea here is to set the cost in the area range command with maximum metric so that when R4 calculates the total cost to 1::/64 and 4::/64, it finds a value greater than 16777215.   Why the value 16777215 ?   When a router generated a Type-3 LSA or even a Type-5 LSA with the max-age set (3600 seconds). These LSAs with max age set are discarded and the metric is set to 16777215. This is the maximum metric for routes in the OSPF database in decimal. A route with a metric higher than 16777215 is inaccessible therefore is discarded from the OSPF database. This metric is also known as LSInfinity. Setting the metric to 16777215 will force the OSPF process to remove the LSA from the LSDB. LSinfinity means "unreachable".   R3(config-rtr)#ipv6 router ospf 1 R3(config-rtr)#area 0 range 1::/64 cost ? Advertised metric for this range R3(config-rtr)#   RFC 1583 and RFC 2328 describes the value of LSInfinity for Summary and External LSAs as a 24-bit binary value.   RFC 1583 section B. Architectural Constants:   LSInfinity The metric value indicating that the destination described by a link state advertisement is unreachable. Used in summary link advertisements and AS external link advertisements as an alternative to premature aging (see Section 14.1). It is defined to be the 24-bit binary value of all ones: 0xffffff.   RFC 2328 section B. Architectural Constants:   LSInfinity The metric value indicating that the destination described by an LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as an alternative to premature aging (see Section 14.1). It is defined to be the 24-bit binary value of all ones: 0xffffff   The value 24-bit is only valids for external and summary LSAs. However when reading RFC 2328 and RFC 1583, they didn’t mention LSInfinity for Router LSAs.   Let's configure area 0 range with a cost 16777214, this is the maximum metric we can set when summarizing inter-area route:  

R3(config)#ipv6 router ospf 1 R3(config-rtr)#area 0 range 1::/64 cost 16777214 R3(config-rtr)#area 0 range 2::/64 cost 16777214   Let's verify the LSDB of R4, receives the Type-3 LSA for 1::/64 and 2::/64 with a metric 16777214:   R4#sh ipv osp data inter-area prefix 1::/64 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Routing Bit Set on this LSA LS age: 83 LS Type: Inter Area Prefix Links Link State ID: 11 Advertising Router: 0.0.0.3 LS Seq Number: 80000006 Checksum: 0xF4EE Length: 36 Metric: 16777214 Prefix Address: 1:: Prefix Length: 64, Options: None R4#   R4#sh ipv osp data inter-area prefix 2::/64 OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Routing Bit Set on this LSA LS age: 82 LS Type: Inter Area Prefix Links Link State ID: 12 Advertising Router: 0.0.0.3 LS Seq Number: 80000008 Checksum: 0xF2EC Length: 36 Metric: 16777214 Prefix Address: 2:: Prefix Length: 64, Options: None R4#   When R4 calculates the total cost to reach 1::/64 and 2::/64 it adds the cost to reach the ABR R3 listed in the show ipv osp command to the cost listed in the Type-3 LSA = 64+16777214 = 16777278.   R4#sh ipv os bor OSPFv3 Router with ID (0.0.0.4) (Process ID 1) Codes: i - Intra-area route, I - Inter-area route i 0.0.0.3 [64] via FE80::C803:2FF:FEF0:8, Serial1/0, ABR, Area 1, SPF 7 R4#   Since the value 16777278 exceeds the LSInfinity 16777215, R4 considers the routes to 1::/64 and 2::/64 are unreachable and it will never install the inter-area routes:   R4#sh ipv route osp | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP OI 13::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 OI 23::/64 [110/65] via FE80::C803:2FF:FEF0:8, Serial1/0 R4#   As mentioned previously with distribute list feature, when using the distribute-list command in the outbound direction, this feature filters only the desired redistributed routes. Meaning that is used only on ASBRs.

  Let's try to filter 1::/64 and 2::/64 on R1 and R2 respectivelly in the outbound direction:   R1(config)#ipv6 prefix-list FILTER-R1 seq 10 deny 1::/64 R1(config)#ipv6 prefix-list FILTER-R1 seq 12 permit ::/0 le 128   R1(config-rtr)#ipv router osp 1 R1(config-rtr)#distribute-list prefix-list FILTER-R1 out ospf 1   R2(config)#ipv6 prefix-list FILTER-R2 seq 10 deny 2::/64 R2(config)#ipv6 prefix-list FILTER-R2 seq 11 permit ::/0 le 128   R2(config-rtr)#ipv router osp 1 R2(config-rtr)#distribute-list prefix-list FILTER-R2 out ospf 1   Verify the routing table of R3 and R4, the prefixes 1::/64 and 2::/64 are installed successfully because R1 and R2 are ASBRs to perform outbound filtering with distribute list:   R3#sh ipv route os | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 1::/64 [110/2] via FE80::C801:1BFF:FE4C:8, FastEthernet0/0 O 2::/64 [110/2] via FE80::C802:2EFF:FE1C:8, FastEthernet0/1 O 4::/64 [110/65] via FE80::C804:2FFF:FE98:8, Serial1/0 R3#   The Type-9 LSAs of R1 and R2 are still in the LSDB of R3:   R3#sh ipv ospf data prefix adv 0.0.0.1 OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 38 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.1 LS Seq Number: 80000007 Checksum: 0x4B8 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.1 Number of Prefixes: 1 Prefix Address: 1:: Prefix Length: 64, Options: None, Metric: 1 R3#   R3#sh ipv ospf data prefix adv 0.0.0.2 OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 47 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.2

LS Seq Number: 80000007 Checksum: 0x2099 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.2 Number of Prefixes: 1 Prefix Address: 2:: Prefix Length: 64, Options: None, Metric: 1 R3#   Configure R4 as an ASBR. The loopback 0 interface has already an IPv6 address 4::4/64. Remove the ipv6 ospf 1 area 1 command. Configure a second IPv6 address 44::4/64.   R4(config)#interface Loopback0 R4(config-if)#no ipv6 ospf 1 area 1 R4(config-if)#ipv add 44::4/64   Verification:   R4#sh run int lo0 Building configuration... Current configuration : 87 bytes ! interface Loopback0 no ip address ipv6 address 4::4/64 ipv6 address 44::4/64 end R4#   Redistribute the prefixes 4::/64 and 44::/64 into OSPF.   R4(config)#route-map CONNECTED permi R4(config-route-map)#match interfa R4(config-route-map)#match interface lo0   R4(config)#ipv router osp 1 R4(config-rtr)#redistribute connected route-map CONNECTED   Verify that R3 is receiving two Type-5 LSAs for 4::/64 and 44::/64:   R3#sh ipv os data | beg Type-5 Type-5 AS External Link States ADV Router Age Seq# Prefix 0.0.0.4 65 0x80000001 4::/64 0.0.0.4 65 0x80000001 44::/64 R3#   Verify the routing tables of R1, R2 and R3, two external route OE2 to 4::/64 and 44::/64 are installed:   R3#sh ipv route osp | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 1::/64 [110/2] via FE80::C801:27FF:FE90:8, FastEthernet0/0 O 2::/64 [110/2]

via FE80::C802:9FF:FE74:8, FastEthernet0/1 OE2 4::/64 [110/20] via FE80::C804:16FF:FE08:8, Serial1/0 OE2 44::/64 [110/20] via FE80::C804:16FF:FE08:8, Serial1/0 R3#   R1#sh ipv route osp | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 2::/64 [110/3] via FE80::C803:11FF:FE20:8, FastEthernet0/0 OE2 4::/64 [110/20] via FE80::C803:11FF:FE20:8, FastEthernet0/0 O 23::/64 [110/2] via FE80::C803:11FF:FE20:8, FastEthernet0/0 OI 34::/64 [110/65] via FE80::C803:11FF:FE20:8, FastEthernet0/0 OE2 44::/64 [110/20] via FE80::C803:11FF:FE20:8, FastEthernet0/0 R1#   R2#sh ipv route osp | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 1::/64 [110/3] via FE80::C803:11FF:FE20:6, FastEthernet0/0 OE2 4::/64 [110/20] via FE80::C803:11FF:FE20:6, FastEthernet0/0 O 13::/64 [110/2] via FE80::C803:11FF:FE20:6, FastEthernet0/0 OI 34::/64 [110/65] via FE80::C803:11FF:FE20:6, FastEthernet0/0 OE2 44::/64 [110/20] via FE80::C803:11FF:FE20:6, FastEthernet0/0 R2#   Configure R4 to block the prefix 44::/64 when performing redistributing using the distribute-list command, only the prefix 4::/64 is allowed:   Creates a prefix list that matches and denies the prefix 44::/64 and permit all other prefixes:   R4(config)#ipv6 prefix-list FILTER-R4 seq 10 deny 44::/64 R4(config)#ipv6 prefix-list FILTER-R4 seq 11 permit ::/0 le 128   The distribute-list command has some parameters when we apply it in the outbound direction, we need to specify the source of the updates (CONNECTED in this case) advertised from connected into OSPF:   R4(config)#ipv router osp 1 R4(config-rtr)#distribute-list prefix-list FILTER-R4 out ? bgp Border Gateway Protocol (BGP) connected Connected Routes eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) isis ISO IS-IS lisp Locator ID Separation Protocol (LISP) ospf Open Shortest Path First (OSPF) rip IPv6 Routing Information Protocol (RIPv6) static Static Routes R4(config-rtr)# R4(config-rtr)#distribute-list prefix-list FILTER-R4 out connected

  Let's enable the debug ip ospf lsa-generation command:   R4#debug ipv6 ospf lsa-generation OSPFv3 lsa generation debugging is on for process 1, IPv6, Default vrf R4#   Immediately after applying the distribute list, R4 generated a Type-5 LSA with the max-age set (3600 seconds). Remember, LSAs with max age set are discarded. Also, note the metric was set to 16777215. This is the maximum metric for routes in the OSPF database in decimal as mentioned by RFC 1583 and RFC 2328. A route with this metric is inaccessible therefore is discarded from the OSPF database. This metric is also known as LSInfinity.   R4(config-rtr)# *Jan 7 13:03:59.667: OSPFv3-1-IPv6 LSGEN: Schedule Router LSA area: 1, flag: Change *Jan 7 13:04:00.167: OSPFv3-1-IPv6 LSGEN: Suppress unchanged router LSA, area: 1 *Jan 7 13:04:00.671: OSPFv3-1-IPv6 LSGEN: Generate external LSA 44::/64, type 4005, age 3600, metric 16777215, tag 0, metric-type 2, seq 0x80000002 *Jan 7 13:04:00.671: OSPFv3-1-IPv6 LSGEN: Insert LSA 5 adv_rtr 0.0.0.4, type 0x4005 in maxage R4(config-rtr)# *Jan 7 13:04:03.299: OSPFv3-1-IPv6 LSGEN: free check failed 0 0 0 0 0 0 *Jan 7 13:04:03.303: OSPFv3-1-IPv6 LSGEN: Insert LSA 5 adv_rtr 0.0.0.4, type 0x4005 in maxage R4(config-rtr)# *Jan 7 13:04:10.675: OSPFv3-1-IPv6 LSGEN: Service_maxage: Trying to delete MAXAGE LSA *Jan 7 13:04:10.675: OSPFv3-1-IPv6 LSGEN: processing 0.0.0.4/5, type 4005 R4(config-rtr)#   Let's verify the LSDB of R3, the Type-5 LSA for 44:/64 is no longer in the database:   R3#sh ipv os data | beg Type-5 Type-5 AS External Link States ADV Router Age Seq# Prefix 0.0.0.4 467 0x80000001 4::/64 R3#   Verify the routing tables of R1, R2 and R3, the external route to 44::/64 diseappers:   R3#sh ipv route osp | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 1::/64 [110/2] via FE80::C801:27FF:FE90:8, FastEthernet0/0 O 2::/64 [110/2] via FE80::C802:9FF:FE74:8, FastEthernet0/1 OE2 4::/64 [110/20] via FE80::C804:16FF:FE08:8, Serial1/0 R3#   R1#sh ipv route osp | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 2::/64 [110/3] via FE80::C803:11FF:FE20:8, FastEthernet0/0 OE2 4::/64 [110/20] via FE80::C803:11FF:FE20:8, FastEthernet0/0 O 23::/64 [110/2] via FE80::C803:11FF:FE20:8, FastEthernet0/0 OI 34::/64 [110/65]

via FE80::C803:11FF:FE20:8, FastEthernet0/0 R1#   R2#sh ipv route osp | beg OE2 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 1::/64 [110/3] via FE80::C803:11FF:FE20:6, FastEthernet0/0 OE2 4::/64 [110/20] via FE80::C803:11FF:FE20:6, FastEthernet0/0 O 13::/64 [110/2] via FE80::C803:11FF:FE20:6, FastEthernet0/0 OI 34::/64 [110/65] via FE80::C803:11FF:FE20:6, FastEthernet0/0 R2#                                                  

Lab 18: Route Filtering Scenario 2

Basic configuration of all routers. Make sure R3 is the DR for area 0 and area 2.   R1: interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ip ospf 1 area 1

no shutd ! router ospf 1 router-id 0.0.0.1   R2: interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 1 no shutd ! interface FastEthernet0/1 ip address 23.0.0.2 255.255.255.0 ip ospf 1 area 0 no shutd ! router ospf 1 router-id 0.0.0.2   R3: interface FastEthernet0/0 ip address 34.0.0.3 255.255.255.0 ip ospf 1 area 2 no shutd ! interface FastEthernet0/1 ip address 23.0.0.3 255.255.255.0 ip ospf 1 area 0 no shutd ! router ospf 1 router-id 0.0.0.3 area 2 nssa   R4: interface Loopback0 ip address 4.4.4.4 255.255.255.0 ! interface FastEthernet0/0 ip address 34.0.0.4 255.255.255.0 ip ospf 1 area 2 no shutd ! router ospf 1 router-id 0.0.0.4 area 2 nssa redistribute connected subnets route-map CONNECTED ! route-map CONNECTED permit 10 match interface Loopback0 Loopback1   Let's verify the LSDB of R1, there is a Type-5 LSA for the prefix 4.4.4.0/24 and the Forward Address is 34.0.0.4, the Type-5 LSA is originated by the NSSA ABR R3 after translating the Type-7 LSA advertised by R4:   R1#show ip os data ext | s Link State|Forward|Adv Type-5 AS External Link States Link State ID: 4.4.4.0 (External Network Number ) Advertising Router: 0.0.0.3

Forward Address: 34.0.0.4 R1#   Let's verify the routing table of R1 to see the external route to 4.4.4.0/24:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 4.0.0.0/24 is subnetted, 1 subnets O E2 4.4.4.0 [110/20] via 12.0.0.2, 00:00:18, FastEthernet0/0 23.0.0.0/24 is subnetted, 1 subnets O IA 23.0.0.0 [110/2] via 12.0.0.2, 00:09:33, FastEthernet0/0 34.0.0.0/24 is subnetted, 1 subnets O IA 34.0.0.0 [110/3] via 12.0.0.2, 00:08:42, FastEthernet0/0 R1#   Challenge: filter the external route 4.4.4.0/24 in the routing table of R1 with only one command:  

Solution-1:

  Per RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option   2.2 Type-7 Address Ranges   NSSA border routers may be configured with Type-7 address ranges. Each Type-7 address range is defined as an [address,mask] pair. Many separate Type-7 networks may fall into a single Type-7 address range, just as a subnetted network is composed of many separate subnets. NSSA border routers may aggregate Type-7 routes by advertising a single Type-5 LSA for each Type-7 address range. The Type-5 LSA resulting from a Type-7 address range match will be distributed to all Type-5 capable areas. Section 3.2 details how Type-5 LSAs are generated from Type-7 address ranges.   A Type-7 address range includes the following configurable items.   An [address,mask] pair.   A status indication of either Advertise or DoNotAdvertise.   An external route tag.   On R4 use the following command, the "not-advertise" keyword instructs the ASBR R4 so that it does not generate Type-7 LSA for the prefix 4.4.4.0/24:   R4(config)#router ospf 1 R4(config-router)#summary-address 4.4.4.0 255.255.255.0 not-advertise   Let's verify the LSDB of R1, no Type-5 LSA:   R1#show ip os data ext OSPF Router with ID (0.0.0.1) (Process ID 1) R1#   Let's verify the routing table of R1, no external route:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 23.0.0.0/24 is subnetted, 1 subnets

O IA O IA R1#

23.0.0.0 [110/2] via 12.0.0.2, 00:11:32, FastEthernet0/0 34.0.0.0/24 is subnetted, 1 subnets 34.0.0.0 [110/3] via 12.0.0.2, 00:10:41, FastEthernet0/0

 

Solution-2:   Remove the previous solution and configure R3 with the summary-address 4.4.4.0 255.255.255.0 not-advertise command, the "not-advertise" keyword instructs R3 so that it does not generate Type-5 LSA for the prefix 4.4.4.0/24, in other words, it does not translate the Type-7 LSA received from R4:   R4(config)#router ospf 1 R4(config-router)#no summary-address 4.4.4.0 255.255.255.0 not-advertise   R3(config)#router ospf 1 R3(config-router)#summary-address 4.4.4.0 255.255.255.0 not-advertise   Let's verify the LSDB of R1, no Type-5 LSA:   R1#show ip ospf datab ext OSPF Router with ID (0.0.0.1) (Process ID 1) R1#   Let's verify the routing table of R1, no external route:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 23.0.0.0/24 is subnetted, 1 subnets O IA 23.0.0.0 [110/2] via 12.0.0.2, 00:58:27, FastEthernet0/0 34.0.0.0/24 is subnetted, 1 subnets O IA 34.0.0.0 [110/3] via 12.0.0.2, 00:29:21, FastEthernet0/0 R1#  

Solution-3:

  Per RFC 1583 OSPF Version 2   12.4.3. Summary links   The one remaining case is an intra-area route to a network. This means that the network is contained in one of the router's directly attached areas. In general, this information must be condensed before appearing in summary link advertisements. Remember that an area has been defined as a list of address ranges, each range consisting of an [address,mask] pair and a status indication of either Advertise or DoNotAdvertise. At most a single Type 3 advertisement is made for each range. When the range's status indicates Advertise, a Type 3 advertisement is generated with Link State ID equal to the range's address (if necessary, the Link State ID can also have one or more of the range's "host" bits set; see Appendix F for details) and cost equal to the smallest cost of any of the component networks. When the range's status indicates DoNotAdvertise, the Type 3 advertisement is suppressed and the component networks remain hidden from other areas.

  Per RFC 2328 OSPF Version 2   12.4.3. Summary-LSAs   The one remaining case is an intra-area route to a network. This means that the network is contained in one of the router's directly attached areas. In general, this information must be condensed before appearing in summary-LSAs. Remember that an area has a configured list of address ranges, each range consisting of an [address,mask] pair and a status indication of either Advertise or DoNotAdvertise. At most a single Type 3 summary-LSA is originated for each range. When the range's status indicates Advertise, a Type 3 summary-LSA is generated with Link State ID equal to the range's address (if necessary, the Link State ID can also have one or more of the range's "host" bits set; see Appendix E for details) and cost equal to the largest cost of any of the component networks. When the range's status indicates DoNotAdvertise, the Type 3 summary-LSA is suppressed and the component networks remain hidden from other areas.   Remove the previous solution and configure R3 to filter the Type-3 LSA for the prefix 34.0.0.0/24, the "notadvertise" keyword under the area 2 range command instructs the ABR R3 so that it does not generate Type-3 LSA for the prefix 34.0.0.0/24 and blocks the inter-area route to be flooded into area 0:   R3(config)#router ospf 1 R3(config-router)#no summary-address 4.4.4.0 255.255.255.0 not-advertise R3(config-router)#area 2 range 34.0.0.0 255.255.255.0 not-advertise   Let's verify the LSDB of R1, there is still a Type-5 LSA for the prefix 4.4.4.0/24 but no Type-3 LSA for the prefix 34.0.0.0/24:   R1#show ip os data ext | s Link State|Forward|Adv Type-5 AS External Link States Link State ID: 4.4.4.0 (External Network Number ) Advertising Router: 0.0.0.3 Forward Address: 34.0.0.4 R1#   R1#show ip ospf data summary 34.0.0.0 OSPF Router with ID (0.0.0.1) (Process ID 1) R1#   Let's verify the routing table of R1, since R1 does not have any OSPF route (inter-area) to reach the Forward Address 34.0.0.4, it fails to install the external route:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 23.0.0.0/24 is subnetted, 1 subnets O IA 23.0.0.0 [110/2] via 12.0.0.2, 00:14:31, FastEthernet0/0 R1#  

Solution-4:  

RFC 1583 and RFC 2328 describes the value of LSInfinity for Summary and External LSAs as a 24-bit binary value.   RFC 1583 section B. Architectural Constants:   LSInfinity The metric value indicating that the destination described by a link state advertisement is unreachable. Used in summary link advertisements and AS external link advertisements as an alternative to premature aging (see Section 14.1). It is defined to be the 24-bit binary value of all ones: 0xffffff.   RFC 2328 section B. Architectural Constants:   LSInfinity The metric value indicating that the destination described by an LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as an alternative to premature aging (see Section 14.1). It is defined to be the 24-bit binary value of all ones: 0xffffff   Remove the previous solution and configure R3 to advertise Type-3 Summary LSA for the prefix 34.0.0.0/24 with a metric 16777214:   R3(config)#router ospf 1 R3(config-router)#no area 2 range 34.0.0.0 255.255.255.0 not-advertise R3(config-router)#area 2 range 34.0.0.0 255.255.255.0 cost 16777214   R1 receives the Type-3 LSA with a metric 16777214, then it add its cost 1 toward R3 and the maximum metric of the inter-area route to 34.0.0.0/24 is 16777215, therefore R1 puts this inter-area route as a non-valid route.   Let's verify the LSDB of R1, the Type-5 LSA is still present but no Type-3 LSA for the prefix 34.0.0.0/24:   R1#show ip os data ext | s Link State|Forward|Adv Type-5 AS External Link States Link State ID: 4.4.4.0 (External Network Number ) Advertising Router: 0.0.0.3 Forward Address: 34.0.0.4 R1#   R1#show ip ospf data summary 34.0.0.0 OSPF Router with ID (0.0.0.1) (Process ID 1) R1#   Let's verify the routing table of R1, since there is no reachablity to the Forward Address 34.0.0.4, no external route to 4.4.4.0/24:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 23.0.0.0/24 is subnetted, 1 subnets O IA 23.0.0.0 [110/2] via 12.0.0.2, 00:20:43, FastEthernet0/0 R1#  

Solution-5:

  Per RFC 6860 Hiding Transit-Only Networks in OSPF   2.2.2. Hiding Broadcast Networks  

2.2.2.1. Sending Network-LSA   A special subnet mask value of 255.255.255.255 MUST be used in the network-LSA to hide a transit-only broadcast network. While a broadcast network connects more than routers, using 255.255.255.255 will not hide an access broadcast network accidentally. As there is no change of the Link State ID, the two-way connectivity check would proceed normally.   Make sure that R3 is the DR and Verify the Type-2 LSA created by the DR R3 in area 2, by definition the Type-2 LSA lists all attached routers in the segment where a DR/BDR are elected and also it carries the network number of the segment, in this cas the Type-2 LSA lists the network 34.0.0.0/24 with subnet mask /24:   R3#show ip ospf database network | beg Area 2 Net Link States (Area 2) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 8 Options: (No TOS-capability, DC) LS Type: Network Links Link State ID: 34.0.0.3 (address of Designated Router) Advertising Router: 0.0.0.3 LS Seq Number: 80000005 Checksum: 0xA759 Length: 32 Network Mask: /24 Attached Router: 0.0.0.3 Attached Router: 0.0.0.4 R3#   Remove the previous solution and configure ospf prefix-suppression feature on fa0/0's R3, the ip ospf prefixsuppression command instructs R3 to remove the network number carried by its Type-2 LSA , in other words it does not generate Type-3 LSA for 34.0.0.0/24:   R3(config)#router ospf 1 R3(config-router)#no area 2 range 34.0.0.0 255.255.255.0 cost 16777214 R3(config-router)#int fa0/0 R3(config-if)#ip ospf prefix-suppression   Let's verify the Type-2 LSA of R3 in area 2, the Network Mask /32 means that the prefix 34.0.0.0/24 is suppressed because the prefix suppression feature:   R3#show ip ospf database network | beg Area 2 Net Link States (Area 2) LS age: 30 Options: (No TOS-capability, DC) LS Type: Network Links Link State ID: 34.0.0.3 (address of Designated Router) Advertising Router: 0.0.0.3 LS Seq Number: 80000004 Checksum: 0xA958 Length: 32 Network Mask: /32 Attached Router: 0.0.0.3 Attached Router: 0.0.0.4 R3#   Let's verify the LSDB of R1, no Type-5 LSA to 4.4.4.0/24 and no Type-3 LSA for 34.0.0.0/24:  

R1#show ip os data ext OSPF Router with ID (0.0.0.1) (Process ID 1) R1# R1#show ip ospf data summary 34.0.0.0 OSPF Router with ID (0.0.0.1) (Process ID 1) R1#   Let's verify the routing table of R1, no external route to 4.4.4.0/24:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 23.0.0.0/24 is subnetted, 1 subnets O IA 23.0.0.0 [110/2] via 12.0.0.2, 00:23:58, FastEthernet0/0 R1#                                                                

Lab 19: Route Filtering Scenario 3  

  Basic configuration of all routers:   R1: interface FastEthernet0/0 ip address 10.1.1.1 255.255.255.0 ip ospf 1 area 2 no shut ! interface Serial1/1 ip address 10.0.12.1 255.255.255.252 ip ospf 1 area 2 no shut ! interface Serial1/0 ip address 10.0.13.1 255.255.255.252 ip ospf 1 area 3 no shut ! router ospf 1 router-id 1.1.1.1   R2: interface FastEthernet0/0 ip address 10.2.2.2 255.255.255.0 ip ospf 1 area 2 no shut ! interface Serial1/1 ip address 10.0.12.2 255.255.255.252 ip ospf 1 area 2 no shut !

interface Serial1/0 ip address 10.0.23.1 255.255.255.252 ip ospf 1 area 0 no shut ! router ospf 1 router-id 2.2.2.2   R3: interface FastEthernet0/0 ip address 10.3.3.3 255.255.255.0 ip ospf 1 area 0 no shut ! interface Serial1/0 ip address 10.0.13.2 255.255.255.252 ip ospf 1 area 3 no shut ! interface Serial1/1 ip address 10.0.23.2 255.255.255.0 ip ospf 1 area 0 no shut ! interface Serial1/2 ip address 10.0.34.1 255.255.255.252 ip ospf 1 area 4 no shut ! router ospf 1 router-id 3.3.3.3 area 4 nssa   R4: interface FastEthernet0/0 ip address 10.4.4.4 255.255.255.0 ip ospf 1 area 4 no shut ! interface Serial1/1 ip address 10.0.34.2 255.255.255.0 ip ospf 1 area 2 no shut ! router ospf 1 router-id 1.1.1.1 area 4 nssa   Configure the routers as illustrated in the topology: Configure area 4 as NSSA:   Let's verify the OSPF neighbor relationship:   R1#show ip ospf neighbor Neighbor ID Pri State Dead Time 2.2.2.2 0 FULL/ 00:00:30 3.3.3.3 0 FULL/ 00:00:33 R1#

Address 10.0.12.2 10.0.13.2

Interface Serial1/1 Serial1/0

R3#show ip ospf neighbor Neighbor ID Pri State 2.2.2.2 0 FULL/ 1.1.1.1 0 FULL/ 4.4.4.4 0 FULL/ R3#

-

Dead Time 00:00:32 00:00:31 00:00:39

Address 10.0.23.1 10.0.13.1 10.0.34.2

Interface Serial1/1 Serial1/0 Serial1/2

  R4 redistributes the following static routes as Type 1 External routes:   R4: ip route 192.168.1.0 255.255.255.255 10.4.4.254 ip route 192.168.2.0 255.255.255.255 10.4.4.254 ! router ospf 1 redistribute static subnets metric-type 1   R4 creates and advertises two LSAs Type 7 to the prefixes 192.168.1.0/24 and 192.168.2.0/24, because the nexthop is configured in the static routes, R4 uses this next-hop 10.4.4.254 as the Forward Address:   R4#show ip ospf database nssa-external OSPF Router with ID (4.4.4.4) (Process ID 1) Type-7 AS External Link States (Area 4) LS age: 23 Options: (No TOS-capability, Type 7/5 translation, DC, Upward) LS Type: AS External Link Link State ID: 192.168.1.0 (External Network Number ) Advertising Router: 4.4.4.4 LS Seq Number: 80000001 Checksum: 0x5F2C Length: 36 Network Mask: /32 Metric Type: 1 (Comparable directly to link state metric) MTID: 0 Metric: 20 Forward Address: 10.4.4.254 External Route Tag: 0 LS age: 23 Options: (No TOS-capability, Type 7/5 translation, DC, Upward) LS Type: AS External Link Link State ID: 192.168.2.0 (External Network Number ) Advertising Router: 4.4.4.4 LS Seq Number: 80000001 Checksum: 0x5436 Length: 36 Network Mask: /32 Metric Type: 1 (Comparable directly to link state metric) MTID: 0 Metric: 20 Forward Address: 10.4.4.254 External Route Tag: 0 R4#   The ABR R3 translates these LSAs Type 7 into LSAs Type 5 and copies the Forward Address and floods into all areas, as a result R3 became an ASBR:   R3#show ip ospf database external OSPF Router with ID (3.3.3.3) (Process ID 1) Type-5 AS External Link States

LS age: 100 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 192.168.1.0 (External Network Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x1287 Length: 36 Network Mask: /32 Metric Type: 1 (Comparable directly to MTID: 0 Metric: 20 Forward Address: 10.4.4.254 External Route Tag: 0 LS age: 100 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 192.168.2.0 (External Network Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x791 Length: 36 Network Mask: /32 Metric Type: 1 (Comparable directly to MTID: 0 Metric: 20 Forward Address: 10.4.4.254 External Route Tag: 0 R3#

Number )

link state metric)

Number )

link state metric)

  The internal router R1 receives the LSAs 5 from R3:   R1#show 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: 167 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 192.168.1.0 (External Network Number ) Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x1287 Length: 36 Network Mask: /32 Metric Type: 1 (Comparable directly to link state metric) MTID: 0 Metric: 20 Forward Address: 10.4.4.254 External Route Tag: 0 Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 167 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 192.168.2.0 (External Network Number ) Advertising Router: 3.3.3.3 LS Seq Number: 80000001 Checksum: 0x791

Length: 36 Network Mask: /32 Metric Type: 1 (Comparable directly to link state metric) MTID: 0 Metric: 20 Forward Address: 10.4.4.254 External Route Tag: 0 R1#   Now the challenge is to configure OSPF domain so that the forward address in the Type 5 LSAs indicates that traffic should be sent to R3 in other words the ASBR because it is originating the LSA 5. In other words, the forward address of the Type 5 LSAs will be set to 0.0.0.0 meaning traffic should be forwarded to the ASBR R3. We will use the area 4 nssa translate type7 suppress-fa command to tell to the ABR R3 to suppress the FA:   R3: router ospf 1 area 4 nssa translate type7 suppress-fa   Let's verify the result; Even if the FA is set in the LSAs Type 7, R3 removes it when translating or creating the LSA Type 5:   R3#show ip ospf database nssa-external | inc Forward Address|Link State ID Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 10.4.4.254 Link State ID: 192.168.2.0 (External Network Number ) Forward Address: 10.4.4.254 R3#   R3#show ip ospf database external | inc Forward Address|Link State ID Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 0.0.0.0 Link State ID: 192.168.2.0 (External Network Number ) Forward Address: 0.0.0.0 R3#   R1#show ip ospf database external | inc Forward Address|Link State ID Link State ID: 192.168.1.0 (External Network Number ) Forward Address: 0.0.0.0 Link State ID: 192.168.2.0 (External Network Number ) Forward Address: 0.0.0.0 R1#   The forward address of 0.0.0.0 indicates that the traffic should be sent to the ASBR. By default, R3 will be designated ASBR because it translates the Type 7 LSAs to Type 5 LSAs, which are then flooded throughout the OSPF domain.   We can verify that the Type 4 LSA for the ASBR exists using theshow ip ospf database asbr-summary command:   R1#show ip ospf database asbr-summary OSPF Router with ID (1.1.1.1) (Process ID 1) Summary ASB Link States (Area 2) LS age: 1215 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(AS Boundary Router) Link State ID: 3.3.3.3 (AS Boundary Router address) Advertising Router: 2.2.2.2

LS Seq Number: 80000001 Checksum: 0x37B0 Length: 28 Network Mask: /0 MTID: 0 Metric: 64 R1#   Now let's configure a Loopback0 interface on R1 with the IP address 100.1.1.1/32 then redistribute this prefix into OSPF using default metric type and metric:   R1: interface loopback 0 ip address 100.1.1.1 255.255.255.255 ! router ospf 1 redistribute connected subnets   R1 creates an LSA Type 5 for the prefix 100.1.1.1/32 and floods this LSA into all areas except of the area 4 NSSA. Simply because by default, a Type 5 LSA has a domain-flooding scope and it is not advertised into stub or NSSA areas. As a result of this default behavior, all other routers in the network will have an LSA for this subnet, except for R4.   Let's take an example R3: It receives successfully the LSA 5:   R3#show ip ospf database external 100.1.1.1 OSPF Router with ID (3.3.3.3) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 41 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 100.1.1.1 (External Network Number ) Advertising Router: 1.1.1.1 LS Seq Number: 80000001 Checksum: 0x8FA5 Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 R3#   And it installs successfully an external route to 100.1.1.1/32 and can reach it:   R3#show ip route 100.1.1.1 Routing entry for 100.1.1.1/32 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64 Last update from 10.0.13.1 on Serial1/0, 00:02:02 ago Routing Descriptor Blocks: * 10.0.13.1, from 1.1.1.1, 00:02:02 ago, via Serial1/0 Route metric is 20, traffic share count is 1 R3#   R4 does not have the LSA Type 5 in its LSDB because the LSA 5 is not flooded in NSSA area 4:  

R4#show ip ospf database external 100.1.1.1 OSPF Router with ID (4.4.4.4) (Process ID 1) R4#   R4#show ip ospf database OSPF Router with ID (4.4.4.4) (Process ID 1) Router Link States (Area 4) Link ID ADV Router Age Seq# Checksum 3.3.3.3 3.3.3.3 1813 0x80000004 0x000812 4.4.4.4 4.4.4.4 1616 0x80000003 0x006D86 Summary Net Link States (Area 4) Link ID ADV Router Age Seq# Checksum 10.0.12.0 3.3.3.3 103 0x80000003 0x00BCD8 10.0.13.0 3.3.3.3 103 0x80000003 0x002FA5 10.0.23.0 3.3.3.3 103 0x80000003 0x00C00A 10.1.1.0 3.3.3.3 103 0x80000003 0x004655 10.2.2.0 3.3.3.3 103 0x80000003 0x00AC2D 10.3.3.0 3.3.3.3 103 0x80000003 0x001305 Type-7 AS External Link States (Area 4) Link ID ADV Router Age Seq# Checksum 192.168.1.0 4.4.4.4 1616 0x80000001 0x005F2C 192.168.2.0 4.4.4.4 1616 0x80000001 0x005436 R4#

Link count 2 3

Tag 0 0

  As a result R4 does not have a route to 100.1.1.1/32 and cannot reach 100.1.1.1 IP address as shown by the ping:   R4#show ip route 100.1.1.1 % Network not in table R4#   R4#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks O IA 10.0.12.0/30 [110/192] via 10.0.34.1, 00:30:42, Serial1/1 O IA 10.0.13.0/30 [110/128] via 10.0.34.1, 00:30:42, Serial1/1 O IA 10.0.23.0/30 [110/128] via 10.0.34.1, 00:30:42, Serial1/1 O IA 10.1.1.0/24 [110/193] via 10.0.34.1, 00:30:42, Serial1/1 O IA 10.2.2.0/24 [110/129] via 10.0.34.1, 00:30:42, Serial1/1 O IA 10.3.3.0/24 [110/65] via 10.0.34.1, 00:30:42, Serial1/1 R4#   R4#ping 100.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R4#   Because the Type 5 LSA will not be flooded into area 4, we need to configure the ABR R3 to advertise a default route to R4. This is done by using the default-information-originate keyword on R3:   R3: router ospf 1 area 4 nssa default-information-originate   Following this configuration, the LSDB on R4 shows that it receives an LSA Type 7 default route from R3:  

R4#show ip ospf database OSPF Router with ID (4.4.4.4) (Process ID 1) Router Link States (Area 4) Link ID ADV Router Age Seq# Checksum 3.3.3.3 3.3.3.3 1672 0x80000004 0x000812 4.4.4.4 4.4.4.4 1476 0x80000003 0x006D86 Summary Net Link States (Area 4) Link ID ADV Router Age Seq# Checksum 10.0.12.0 3.3.3.3 1834 0x80000002 0x00BED7 10.0.13.0 3.3.3.3 1834 0x80000002 0x0031A4 10.0.23.0 3.3.3.3 1834 0x80000002 0x00C209 10.1.1.0 3.3.3.3 1834 0x80000002 0x004854 10.2.2.0 3.3.3.3 1834 0x80000002 0x00AE2C 10.3.3.0 3.3.3.3 1834 0x80000002 0x001504 Type-7 AS External Link States (Area 4) Link ID ADV Router Age Seq# Checksum 0.0.0.0 3.3.3.3 8 0x80000001 0x00B2F2 192.168.1.0 4.4.4.4 1475 0x80000001 0x005F2C 192.168.2.0 4.4.4.4 1475 0x80000001 0x005436 R4#

Link count 2 3

Tag 0 0 0

  And R4 installs a O*N2 default route in its routing table:   R4#show ip route ospf | beg Gate Gateway of last resort is 10.0.34.1 to network 0.0.0.0 O*N2 0.0.0.0/0 [110/1] via 10.0.34.1, 00:01:29, Serial1/1 10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks O IA 10.0.12.0/30 [110/192] via 10.0.34.1, 00:29:08, Serial1/1 O IA 10.0.13.0/30 [110/128] via 10.0.34.1, 00:29:08, Serial1/1 O IA 10.0.23.0/30 [110/128] via 10.0.34.1, 00:29:08, Serial1/1 O IA 10.1.1.0/24 [110/193] via 10.0.34.1, 00:29:08, Serial1/1 O IA 10.2.2.0/24 [110/129] via 10.0.34.1, 00:29:08, Serial1/1 O IA 10.3.3.0/24 [110/65] via 10.0.34.1, 00:29:08, Serial1/1 R4#   Now the ping to 100.1.1.1 passes successfully:   R4#ping 100.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 100/122/148 ms R4#   The purpose is to configure OSPF so that the 10.3.3.0/24'R3 the 10.4.4.0/24'R4 are not advertised to any other area. However, ensure that R1 and R2 are still able to ping 150.3.3.3 as well as 150.4.4.4.   Before doing the filtering route let's verify the routing tables of R1 and R2 to confirme that they have both two OSPF routes to 10.3.3.0/24 and 10.4.4.0/24 prefixes:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 11 subnets, 3 masks O IA 10.0.23.0/30 [110/128] via 10.0.13.2, 00:10:29, Serial1/0 [110/128] via 10.0.12.2, 00:37:58, Serial1/1 O IA 10.0.34.0/30 [110/128] via 10.0.13.2, 00:10:29, Serial1/0 O 10.2.2.0/24 [110/65] via 10.0.12.2, 00:38:18, Serial1/1

O IA O IA O E1 O E1 R1#

10.3.3.0/24 10.4.4.0/24 192.168.1.0/32 192.168.1.0 192.168.2.0/32 192.168.2.0

[110/65] via 10.0.13.2, 00:10:29, Serial1/0 [110/129] via 10.0.13.2, 00:10:29, Serial1/0 is subnetted, 1 subnets [110/84] via 10.0.13.2, 00:13:02, Serial1/0 is subnetted, 1 subnets [110/84] via 10.0.13.2, 00:13:02, Serial1/0

  R2#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 11 subnets, 3 masks O IA 10.0.13.0/30 [110/128] via 10.0.23.2, 00:38:25, Serial1/0 O IA 10.0.34.0/30 [110/128] via 10.0.23.2, 00:38:01, Serial1/0 O 10.1.1.0/24 [110/65] via 10.0.12.1, 00:39:30, Serial1/1 O 10.3.3.0/24 [110/65] via 10.0.23.2, 00:38:34, Serial1/0 O IA 10.4.4.0/24 [110/129] via 10.0.23.2, 00:34:20, Serial1/0 100.0.0.0/32 is subnetted, 1 subnets O E2 100.1.1.1 [110/20] via 10.0.12.1, 00:11:50, Serial1/1 192.168.1.0/32 is subnetted, 1 subnets O E1 192.168.1.0 [110/84] via 10.0.23.2, 00:14:23, Serial1/0 192.168.2.0/32 is subnetted, 1 subnets O E1 192.168.2.0 [110/84] via 10.0.23.2, 00:14:23, Serial1/0 R2#   To do this challenge we use the area range command and not-advertise keyword:   R2: router ospf 1 area 0 range 10.3.3.0 255.255.255.0 not-advertise   R3: router ospf 1 area 0 range 10.3.3.0 255.255.255.0 not-advertise area 4 range 10.4.4.0 255.255.255.0 not-advertise   R1 does not have an OSPF routes to 10.3.3.0/24 and 10.4.4.0/24 prefixes:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks O IA 10.0.23.0/30 [110/128] via 10.0.13.2, 00:14:51, Serial1/0 [110/128] via 10.0.12.2, 00:42:20, Serial1/1 O IA 10.0.34.0/30 [110/128] via 10.0.13.2, 00:14:51, Serial1/0 O 10.2.2.0/24 [110/65] via 10.0.12.2, 00:42:40, Serial1/1 192.168.1.0/32 is subnetted, 1 subnets O E1 192.168.1.0 [110/84] via 10.0.13.2, 00:17:24, Serial1/0 192.168.2.0/32 is subnetted, 1 subnets O E1 192.168.2.0 [110/84] via 10.0.13.2, 00:17:24, Serial1/0 R1#   R2 does not an OSPF route to the prefix 10.4.4.0/24 but the 10.3.3.0/24 prefix will show up in R2's routing table because this router also resides in area 0 along with R3. The configuration of the area range command on R2 and R3 prevents this from being advertised outside of area 0 to any other area.   R2#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks O IA 10.0.13.0/30 [110/128] via 10.0.23.2, 00:01:04, Serial1/0

O IA O O O E2 O E1 O E1 R2#

10.0.34.0/30 [110/128] via 10.0.23.2, 00:01:04, Serial1/0 10.1.1.0/24 [110/65] via 10.0.12.1, 00:01:04, Serial1/1 10.3.3.0/24 [110/65] via 10.0.23.2, 00:01:04, Serial1/0 100.0.0.0/32 is subnetted, 1 subnets 100.1.1.1 [110/20] via 10.0.12.1, 00:01:04, Serial1/1 192.168.1.0/32 is subnetted, 1 subnets 192.168.1.0 [110/84] via 10.0.23.2, 00:01:04, Serial1/0 192.168.2.0/32 is subnetted, 1 subnets 192.168.2.0 [110/84] via 10.0.23.2, 00:01:04, Serial1/0

  To ensure that R1 and R2 can still able to ping both the 10.3.3.0/24 and 10.4.4.0/24 pefixes, we need to advertise a default route via OSPF on R3 using the default-information originate always command:   R3: router ospf 1 default-information originate always   R1 and R2 receive a default routes from R3 as shown by the following output:   R1#show ip route ospf | beg Gate Gateway of last resort is 10.0.13.2 to network 0.0.0.0 O*E2 0.0.0.0/0 [110/1] via 10.0.13.2, 00:00:12, Serial1/0 10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks O IA 10.0.23.0/30 [110/128] via 10.0.13.2, 00:17:05, Serial1/0 [110/128] via 10.0.12.2, 00:44:34, Serial1/1 O IA 10.0.34.0/30 [110/128] via 10.0.13.2, 00:17:05, Serial1/0 O 10.2.2.0/24 [110/65] via 10.0.12.2, 00:44:54, Serial1/1 192.168.1.0/32 is subnetted, 1 subnets O E1 192.168.1.0 [110/84] via 10.0.13.2, 00:19:38, Serial1/0 192.168.2.0/32 is subnetted, 1 subnets O E1 192.168.2.0 [110/84] via 10.0.13.2, 00:19:38, Serial1/0 R1#   R2#show ip route ospf | beg Gate Gateway of last resort is 10.0.23.2 to network 0.0.0.0 O*E2 0.0.0.0/0 [110/1] via 10.0.23.2, 00:00:52, Serial1/0 10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks O IA 10.0.13.0/30 [110/128] via 10.0.23.2, 00:03:14, Serial1/0 O IA 10.0.34.0/30 [110/128] via 10.0.23.2, 00:03:14, Serial1/0 O 10.1.1.0/24 [110/65] via 10.0.12.1, 00:03:14, Serial1/1 O 10.3.3.0/24 [110/65] via 10.0.23.2, 00:03:14, Serial1/0 100.0.0.0/32 is subnetted, 1 subnets O E2 100.1.1.1 [110/20] via 10.0.12.1, 00:03:14, Serial1/1 192.168.1.0/32 is subnetted, 1 subnets O E1 192.168.1.0 [110/84] via 10.0.23.2, 00:03:14, Serial1/0 192.168.2.0/32 is subnetted, 1 subnets O E1 192.168.2.0 [110/84] via 10.0.23.2, 00:03:14, Serial1/0 R2#   Now R1 and R2 can ping the prefixes 10.3.3.0/24 and 10.4.4.0/24:   R1#ping 10.3.3.3 source fastEthernet 0/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds: Packet sent with a source address of 10.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 72/114/136 ms

R1# R1#ping 10.4.4.4 source fastEthernet 0/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds: Packet sent with a source address of 10.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 96/132/176 ms R1#   R2#ping 10.3.3.3 source fastEthernet 0/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds: Packet sent with a source address of 10.2.2.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/110/200 ms R2# R2#ping 10.4.4.4 source fastEthernet 0/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds: Packet sent with a source address of 10.2.2.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 88/109/132 ms R2#   The challenge now is to configure OSPF so that the 10.1.1.0/24 and 10.2.2.0/24 prefixes are not advertised only to area 3 but they should still be advertised to other areas. Let's use the area filter-list command on R1 and R3 to prevent the LSAs Type 3 for the 10.1.1.0/24 and 10.2.2.0/24 prefixes from being advertised into area 3.   Let's verify the LSDB of R1 ans R3 prior to any filtering:   R1#show ip ospf database summary 10.1.1.0 OSPF Router with ID (1.1.1.1) (Process ID 1) Summary Net Link States (Area 3) LS age: 1262 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.1.1.0 (summary Network Number) Advertising Router: 3.3.3.3 LS Seq Number: 80000002 Checksum: 0xA2FF Length: 28 Network Mask: /24 MTID: 0 Metric: 129 R1# R1#show ip ospf database summary 10.2.2.0 OSPF Router with ID (1.1.1.1) (Process ID 1) Summary Net Link States (Area 3) LS age: 1268 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.2.2.0 (summary Network Number) Advertising Router: 3.3.3.3 LS Seq Number: 80000002 Checksum: 0x9D7 Length: 28 Network Mask: /24 MTID: 0 Metric: 65

R1#   R1#show ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 2) Link ID ADV Router Age Seq# Checksum 1.1.1.1 1.1.1.1 1011 0x80000005 0x00083F 2.2.2.2 2.2.2.2 954 0x80000004 0x0093AE Summary Net Link States (Area 2) Link ID ADV Router Age Seq# Checksum 10.0.13.0 2.2.2.2 954 0x80000002 0x002C73 10.0.23.0 2.2.2.2 954 0x80000002 0x003B9A 10.0.34.0 2.2.2.2 954 0x80000002 0x004446 Summary ASB Link States (Area 2) Link ID ADV Router Age Seq# Checksum 3.3.3.3 2.2.2.2 954 0x80000002 0x0035B1 Router Link States (Area 3) Link ID ADV Router Age Seq# Checksum 1.1.1.1 1.1.1.1 1011 0x80000004 0x000956 3.3.3.3 3.3.3.3 902 0x80000004 0x003D18 Summary Net Link States (Area 3) Link ID ADV Router Age Seq# Checksum 10.0.12.0 3.3.3.3 902 0x80000002 0x001983 10.0.23.0 3.3.3.3 902 0x80000002 0x001DB4 10.0.34.0 3.3.3.3 902 0x80000002 0x00A323 10.1.1.0 3.3.3.3 902 0x80000002 0x00A2FF 10.2.2.0 3.3.3.3 902 0x80000002 0x0009D7 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum 0.0.0.0 3.3.3.3 235 0x80000001 0x00E0C5 100.1.1.1 1.1.1.1 1251 0x80000001 0x008FA5 192.168.1.0 3.3.3.3 1401 0x80000004 0x004760 192.168.2.0 3.3.3.3 1401 0x80000004 0x003C6A R1#   R3#show ip ospf database OSPF Router with ID (3.3.3.3) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum 2.2.2.2 2.2.2.2 1091 0x80000003 0x001134 3.3.3.3 3.3.3.3 1038 0x80000005 0x002FEB Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.0.12.0 2.2.2.2 1091 0x80000002 0x00B42C 10.0.13.0 3.3.3.3 1038 0x80000002 0x008B50 10.0.34.0 3.3.3.3 1038 0x80000002 0x00A323 10.1.1.0 2.2.2.2 1091 0x80000002 0x003EA8 10.2.2.0 2.2.2.2 1091 0x80000002 0x00A480 Summary ASB Link States (Area 0) Link ID ADV Router Age Seq# Checksum 1.1.1.1 2.2.2.2 1384 0x80000001 0x00935C 1.1.1.1 3.3.3.3 1383 0x80000001 0x007576 Router Link States (Area 3) Link ID ADV Router Age Seq# Checksum 1.1.1.1 1.1.1.1 1149 0x80000004 0x000956 3.3.3.3 3.3.3.3 1038 0x80000004 0x003D18 Summary Net Link States (Area 3) Link ID ADV Router Age Seq# Checksum

Link count 3 3

Link count 2 2

Tag 1 0 0 0

Link count 2 3

Link count 2 2

10.0.12.0 10.0.23.0 10.0.34.0 10.1.1.0 10.2.2.0 Link ID 3.3.3.3 4.4.4.4 Link ID 10.0.12.0 10.0.13.0 10.0.23.0 10.1.1.0 10.2.2.0 Link ID 0.0.0.0 192.168.1.0 192.168.2.0

3.3.3.3 1038 0x80000002 0x001983 3.3.3.3 1038 0x80000002 0x001DB4 3.3.3.3 1038 0x80000002 0x00A323 3.3.3.3 1038 0x80000002 0x00A2FF 3.3.3.3 1038 0x80000002 0x0009D7 Router Link States (Area 4) ADV Router Age Seq# Checksum 3.3.3.3 789 0x80000005 0x000613 4.4.4.4 714 0x80000004 0x006B87 Summary Net Link States (Area 4) ADV Router Age Seq# Checksum 3.3.3.3 1038 0x80000003 0x00BCD8 3.3.3.3 1038 0x80000003 0x002FA5 3.3.3.3 1038 0x80000003 0x00C00A 3.3.3.3 1038 0x80000003 0x004655 3.3.3.3 1038 0x80000003 0x00AC2D Type-7 AS External Link States (Area 4) ADV Router Age Seq# Checksum 3.3.3.3 833 0x80000001 0x00B2F2 4.4.4.4 714 0x80000002 0x005D2D 4.4.4.4 714 0x80000002 0x005237 Type-5 AS External Link States ADV Router Age Seq# Checksum 3.3.3.3 372 0x80000001 0x00E0C5 1.1.1.1 1389 0x80000001 0x008FA5 3.3.3.3 1537 0x80000004 0x004760 3.3.3.3 1537 0x80000004 0x003C6A

Link ID 0.0.0.0 100.1.1.1 192.168.1.0 192.168.2.0 R3#   R3#show ip ospf data summary 10.1.1.0 OSPF Router with ID (3.3.3.3) (Process ID 1) Summary Net Link States (Area 0) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 1362 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.1.1.0 (summary Network Number) Advertising Router: 2.2.2.2 LS Seq Number: 80000002 Checksum: 0x3EA8 Length: 28 Network Mask: /24 MTID: 0 Metric: 65 Summary Net Link States (Area 3) LS age: 1308 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.1.1.0 (summary Network Number) Advertising Router: 3.3.3.3 LS Seq Number: 80000002 Checksum: 0xA2FF Length: 28 Network Mask: /24 MTID: 0 Metric: 129 Summary Net Link States (Area 4) LS age: 1308 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network)

Link count 2 3

Tag 0 0 0 Tag 1 0 0 0

Link State ID: 10.1.1.0 (summary Network Number) Advertising Router: 3.3.3.3 LS Seq Number: 80000003 Checksum: 0x4655 Length: 28 Network Mask: /24 MTID: 0 Metric: 129 R3#   R3#show ip ospf data summary 10.2.2.0 OSPF Router with ID (3.3.3.3) (Process ID 1) Summary Net Link States (Area 0) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 1390 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.2.2.0 (summary Network Number) Advertising Router: 2.2.2.2 LS Seq Number: 80000002 Checksum: 0xA480 Length: 28 Network Mask: /24 MTID: 0 Metric: 1 Summary Net Link States (Area 3) LS age: 1337 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.2.2.0 (summary Network Number) Advertising Router: 3.3.3.3 LS Seq Number: 80000002 Checksum: 0x9D7 Length: 28 Network Mask: /24 MTID: 0 Metric: 65 Summary Net Link States (Area 4) LS age: 1337 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.2.2.0 (summary Network Number) Advertising Router: 3.3.3.3 LS Seq Number: 80000003 Checksum: 0xAC2D Length: 28 Network Mask: /24 MTID: 0 Metric: 65 R3#   Let's configure filtering:   R1: ip prefix-list FILTER seq ip prefix-list FILTER seq ip prefix-list FILTER seq ! router ospf 1 area 1 filter-list prefix   R3:

5 deny 10.1.1.0/24 10 deny 10.2.2.0/24 15 permit 0.0.0.0/0 le 32 FILTER in

ip prefix-list FILTER seq ip prefix-list FILTER seq ip prefix-list FILTER seq ! router ospf 1 area 1 filter-list prefix

5 deny 10.1.1.0/24 10 deny 10.2.2.0/24 15 permit 0.0.0.0/0 le 32 FILTER in

  Now let's verify the LSDB of R1 and R3: We can see now that the LSAs Type 3 for the 10.1.1.0/24 and 10.2.2.0/24 prefixes are not installed in the LSDBs of R1 and R3 as shown by the different commands displayed below:   R1#show ip ospf database summary 10.1.1.0 OSPF Router with ID (1.1.1.1) (Process ID 1) R1# R1#show ip ospf database summary 10.2.2.0 OSPF Router with ID (1.1.1.1) (Process ID 1) R1#   R1#show ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 2) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 229 0x80000006 0x000640 3 2.2.2.2 2.2.2.2 1800 0x80000004 0x0093AE 3 Summary Net Link States (Area 2) Link ID ADV Router Age Seq# Checksum 10.0.13.0 2.2.2.2 215 0x80000004 0x002875 10.0.23.0 2.2.2.2 1800 0x80000002 0x003B9A 10.0.34.0 2.2.2.2 215 0x80000004 0x004048 Summary ASB Link States (Area 2) Link ID ADV Router Age Seq# Checksum 3.3.3.3 2.2.2.2 216 0x80000004 0x0031B3 Router Link States (Area 3) Link ID ADV Router Age Seq# Checksum Link count 1.1.1.1 1.1.1.1 229 0x80000005 0x000757 2 3.3.3.3 3.3.3.3 220 0x80000005 0x003B19 2 Summary Net Link States (Area 3) Link ID ADV Router Age Seq# Checksum 10.0.12.0 3.3.3.3 215 0x80000001 0x001B82 10.0.23.0 3.3.3.3 210 0x80000003 0x001BB5 10.0.34.0 3.3.3.3 210 0x80000003 0x00A124 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 0.0.0.0 3.3.3.3 220 0x80000001 0x00E0C5 1 100.1.1.1 1.1.1.1 229 0x80000002 0x008DA6 0 192.168.1.0 3.3.3.3 210 0x80000001 0x004D5D 0 192.168.2.0 3.3.3.3 210 0x80000001 0x004267 0 R1#   R3#show ip ospf database OSPF Router with ID (3.3.3.3) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 2.2.2.2 2.2.2.2 1858 0x80000003 0x001134 2 3.3.3.3 3.3.3.3 278 0x80000006 0x002DEC 3 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.0.12.0 2.2.2.2 1858 0x80000002 0x00B42C

10.0.13.0 10.0.34.0 10.1.1.0 10.2.2.0 Link ID 1.1.1.1 1.1.1.1 Link ID 1.1.1.1 3.3.3.3 Link ID 10.0.12.0 10.0.23.0 10.0.34.0 Link ID 3.3.3.3 4.4.4.4 Link ID 10.0.12.0 10.0.13.0 10.0.23.0 10.1.1.0 10.2.2.0 Link ID 0.0.0.0 192.168.1.0 192.168.2.0

3.3.3.3 273 0x80000001 0x008D4F 3.3.3.3 273 0x80000001 0x00A522 2.2.2.2 284 0x80000004 0x003AAA 2.2.2.2 1858 0x80000002 0x00A480 Summary ASB Link States (Area 0) ADV Router Age Seq# Checksum 2.2.2.2 124 0x80000004 0x008D5F 3.3.3.3 273 0x80000001 0x007576 Router Link States (Area 3) ADV Router Age Seq# Checksum 1.1.1.1 289 0x80000005 0x000757 3.3.3.3 278 0x80000005 0x003B19 Summary Net Link States (Area 3) ADV Router Age Seq# Checksum 3.3.3.3 273 0x80000001 0x001B82 3.3.3.3 268 0x80000003 0x001BB5 3.3.3.3 268 0x80000003 0x00A124 Router Link States (Area 4) ADV Router Age Seq# Checksum 3.3.3.3 278 0x80000006 0x000414 4.4.4.4 1481 0x80000004 0x006B87 Summary Net Link States (Area 4) ADV Router Age Seq# Checksum 3.3.3.3 268 0x80000004 0x00BAD9 3.3.3.3 268 0x80000004 0x002DA6 3.3.3.3 268 0x80000004 0x00BE0B 3.3.3.3 268 0x80000007 0x003E59 3.3.3.3 268 0x80000004 0x00AA2E Type-7 AS External Link States (Area 4) ADV Router Age Seq# Checksum 3.3.3.3 278 0x80000002 0x00B0F3 4.4.4.4 1481 0x80000002 0x005D2D 4.4.4.4 1481 0x80000002 0x005237 Type-5 AS External Link States ADV Router Age Seq# Checksum 3.3.3.3 278 0x80000001 0x00E0C5 1.1.1.1 289 0x80000002 0x008DA6 3.3.3.3 268 0x80000001 0x004D5D 3.3.3.3 268 0x80000001 0x004267

Link ID 0.0.0.0 100.1.1.1 192.168.1.0 192.168.2.0 R3#   R3#show ip ospf database summary 10.1.1.0 OSPF Router with ID (3.3.3.3) (Process ID 1) Summary Net Link States (Area 0) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 383 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.1.1.0 (summary Network Number) Advertising Router: 2.2.2.2 LS Seq Number: 80000004 Checksum: 0x3AAA Length: 28 Network Mask: /24 MTID: 0 Metric: 65 Summary Net Link States (Area 4) LS age: 367 Options: (No TOS-capability, DC, Upward)

Link count 2 2

Link count 2 3

Tag 0 0 0 Tag 1 0 0 0

LS Type: Summary Links(Network) Link State ID: 10.1.1.0 (summary Network Number) Advertising Router: 3.3.3.3 LS Seq Number: 80000007 Checksum: 0x3E59 Length: 28 Network Mask: /24 MTID: 0 Metric: 129 R3#   R3#show ip ospf database summary 10.2.2.0 OSPF Router with ID (3.3.3.3) (Process ID 1) Summary Net Link States (Area 0) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 1964 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.2.2.0 (summary Network Number) Advertising Router: 2.2.2.2 LS Seq Number: 80000002 Checksum: 0xA480 Length: 28 Network Mask: /24 MTID: 0 Metric: 1 Summary Net Link States (Area 4) LS age: 374 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 10.2.2.0 (summary Network Number) Advertising Router: 3.3.3.3 LS Seq Number: 80000004 Checksum: 0xAA2E Length: 28 Network Mask: /24 MTID: 0 Metric: 65 R3#                                        

Lab 20: Route Filtering Scenario 4  

  Basic configuration:   R1: ipv uni ! interface Loopback0 ipv6 address 1::1/64 ipv6 ospf 1 area 0 ! interface Loopback1 no ip address ipv6 address 11::1/64 ipv6 ospf 1 area 0 ! interface Loopback2 ipv6 address 111::1/64 ipv6 ospf 1 area 0 ! interface Ethernet0/0 ipv6 address 12::1/64 ipv6 ospf 1 area 0 no shut ! interface Ethernet0/1 ipv6 address 13::1/64 ipv6 ospf 1 area 0 no shu ! ipv6 router ospf 1 router-id 0.0.0.1   R2: ipv uni

! interface Ethernet0/0 ipv6 address 12::2/64 ipv6 ospf 1 area 0 no shut ! interface Serial1/0 ipv6 address 24::2/64 ipv6 ospf 1 area 24 no shut ! ipv6 router ospf 1 router-id 0.0.0.2   R3: ipv uni ! interface Ethernet0/0 ipv6 address 13::3/64 ipv6 ospf 1 area 0 no shut ! interface Serial1/0 ipv6 address 35::3/64 ipv6 ospf 1 area 35 no shut ! ipv6 router ospf 1 router-id 0.0.0.3   R4: ipv uni ! interface Loopback0 ipv6 address 4::4/64 ipv6 ospf 1 area 24 ! interface Loopback1 ipv6 address 44::4/64 ipv6 ospf 1 area 24 ! interface Loopback2 ipv6 address 444::4/64 ipv6 ospf 1 area 24 ! interface Ethernet0/0 ipv6 address 45::4/64 no shut ! interface Serial1/0 ipv6 address 24::4/64 ipv6 ospf 1 area 24 no shut ! ipv6 router ospf 1 router-id 0.0.0.4   R5:

ipv uni ! interface Loopback0 ipv6 address 5::5/64 ipv6 ospf 1 area 35 ! interface Loopback1 ipv6 address 55::5/64 ipv6 ospf 1 area 35 ! interface Loopback2 ipv6 address 555::5/64 ipv6 ospf 1 area 35 ! interface Ethernet0/0 ipv6 address 45::5/64 no shut ! interface Serial1/0 ipv6 address 35::5/64 ipv6 ospf 1 area 35 no shutd ! ipv6 router ospf 1 router-id 0.0.0.5   Configure R4 and R5 to redistribute the ethernet interfaces e0/0 into OSPF with the default parameters:   R4(config)#route-map TEST per R4(config-route-map)#match int s1/0 R4(config-route-map)#ipv router osp 1 R4(config-rtr)#redist connected route-ma TEST   R5(config)#route-map TEST per R5(config-route-map)#match int s1/0 R5(config-route-map)#ipv router osp 1 R5(config-rtr)#redistr connected route-map TEST   Verify the routing table of R1, you should see 8 inter-area routes including the loopback interfaces of R4 and R5, and an external route OE2 toward 45::/64.   R1#sh ipv route osp | be App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application OI 4::4/128 [110/74] via FE80::A8BB:CCFF:FE00:200, Ethernet0/0 OI 5::5/128 [110/74] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1 OI 24::/64 [110/74] via FE80::A8BB:CCFF:FE00:200, Ethernet0/0 OI 35::/64 [110/74] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1 OI 44::4/128 [110/74] via FE80::A8BB:CCFF:FE00:200, Ethernet0/0 OE2 45::/64 [110/20] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1 via FE80::A8BB:CCFF:FE00:200, Ethernet0/0 OI 55::5/128 [110/74] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1

OI OI

444::4/128 [110/74] via FE80::A8BB:CCFF:FE00:200, Ethernet0/0 555::5/128 [110/74] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1

R1#   Note: R1 installs a load balancing toward 45::/64 because the Type-5 LSAs originated by R4 and R5 do not include a non-zero Forward Address, with OSPFV3, by default the F-bit is not set for the Forward Address, therefore R1 will compare the cost to reach the ASBR R4 with the cost to reach the ASBR R5, to see this cost, use the show ipv osp bor command.   R1#sh ipv os bord OSPFv3 Router with ID (0.0.0.1) (Process ID 1) Codes: i - Intra-area route, I - Inter-area route i 0.0.0.3 [10] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1, ABR, Area 0, SPF 10 i 0.0.0.2 [10] via FE80::A8BB:CCFF:FE00:200, Ethernet0/0, ABR, Area 0, SPF 10 I 0.0.0.5 [74] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1, ASBR, Area 0, SPF 13 I 0.0.0.4 [74] via FE80::A8BB:CCFF:FE00:200, Ethernet0/0, ASBR, Area 0, SPF 13 R1#   Configure R2 and R3 so that the inter-area routes will be blocked out the backbone area 0. R1 should not see these inter-area route. use different methods on R2 and R3.   On R, we can use the filter-list, Configure a prefix-list to match any prefix.   R2(config)#ipv prefix-list TYPE-3 deny 0::0/0 le 128   Associate the prefix-list with the area 24 filter-list command in the out direction.   R2(config-rtr)#ipv router osp 1 R2(config-rtr)#area 24 filter-list prefix TYPE-3 out   Verify the routing table of R1, the inter-area routes advertised by R2 are filtered because only Type-3 LSAs that originate from an ABR are filtered. This why you still see the inter-area routes advertised by R3.   R1#sh ipv route osp | beg App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application OI 5::5/128 [110/74] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1 OI 35::/64 [110/74] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1 OE2 45::/64 [110/20] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1 via FE80::A8BB:CCFF:FE00:200, Ethernet0/0 OI 55::5/128 [110/74] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1 OI 555::5/128 [110/74] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1 R1#   Perform the same configuration on R3.   R3(config-if)#ipv prefix-list TYPE-3 deny 0::0/0 le 128 R3(config)#ipv router osp 1 R3(config-rtr)#area 35 filter-list prefix TYPE-3 out   Verify the routing table of R1, all inter-area routes are now filtered, only external routes are installed.

  R1#sh ipv route osp | beg App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application OE2 45::/64 [110/20] via FE80::A8BB:CCFF:FE00:200, Ethernet0/0 via FE80::A8BB:CCFF:FE00:300, Ethernet0/1 R1#   Now verify the routing table of R4 and R5, the inter-area routes originated from the backbone areas are installed.   R4#sh ipv route osp | beg App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application OI 1::1/128 [110/74] via FE80::A8BB:CCFF:FE00:200, Serial1/0 OI 11::1/128 [110/74] via FE80::A8BB:CCFF:FE00:200, Serial1/0 OI 12::/64 [110/74] via FE80::A8BB:CCFF:FE00:200, Serial1/0 OI 13::/64 [110/84] via FE80::A8BB:CCFF:FE00:200, Serial1/0 OI 111::1/128 [110/74] via FE80::A8BB:CCFF:FE00:200, Serial1/0 R4#   R5#sh ipv route osp | beg App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application OI 1::1/128 [110/74] via FE80::A8BB:CCFF:FE00:300, Serial1/0 OI 11::1/128 [110/74] via FE80::A8BB:CCFF:FE00:300, Serial1/0 OI 12::/64 [110/84] via FE80::A8BB:CCFF:FE00:300, Serial1/0 OI 13::/64 [110/74] via FE80::A8BB:CCFF:FE00:300, Serial1/0 OI 111::1/128 [110/74] via FE80::A8BB:CCFF:FE00:300, Serial1/0 R5#   Prevent the Type-3 LSAs originated from the backbone area to enter the areas 24 and 35 so that R4 and R5 will not see these inter-area routes but they can reach these prefixes using a single default route.   Since we have an external information injected into both areas 24 and 35 we cannot use the Totally Stubby area type, the Stub area block the Type-5 LSA, the Totally no-so-Stubby area is the area type that can prevent or block the Type-3 LSA while it allows the external information to be injected into this area.   Configure areas 24 and 35 as a Totally NSSA.   R2(config)#ipv router osp 1 R2(config-rtr)#area 24 nssa no-summary   R4(config)#ipv router osp 1 R4(config-rtr)#area 24 nssa   R3(config)#ipv router osp 1 R3(config-rtr)#area 35 nssa no-summary   R5(config)#ipv router osp 1

R5(config-rtr)#area 35 nssa   Verify the routing tables of R4 and R5, all inter-area routes are filtered and a single default inter-area route is installed.   R4#sh ipv route osp | beg App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application OI ::/0 [110/65] via FE80::A8BB:CCFF:FE00:200, Serial1/0 R4#   R5#sh ipv route osp | beg App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application OI ::/0 [110/65] via FE80::A8BB:CCFF:FE00:300, Serial1/0 R5#   Now verify the routing table of R1. Notice the external routes OE2 to 45::/64 is not installed. Why?   R1#sh ipv route os IPv6 Routing Table - default - 11 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, la - LISP alt lr - LISP site-registrations, ld - LISP dyn-eid, a - Application R1#   Let's verify the LSDB, remember we configured areas 24 and 35 as NSSA, so R4 and R5 will originate a Type-7 LSA for 45::/64, the ABRs R2 and R3 will convert these Type-7 LSAs into a Type-5 LSAs respectively.   R1 receives one Type-5 LSA from R2 0.0.0.2 and another Type-5 LSA from R3 0.0.0.3, the Type-5 LSAs are present in the LSDB.   R1#sh ipv os data ext OSPFv3 Router with ID (0.0.0.1) (Process ID 1) Type-5 AS External Link States LS age: 481 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x3229 Length: 52 Prefix Address: 45:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 4::4 LS age: 461 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x62F5

Length: 52 Prefix Address: 45:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 5::5 R1#   So why R1 do not install the external routes in the routing table even if the Type-5 LSAs are present in the LSDB.   Let's execute the debug ipv osp spf external command and clear the OSPF process on R1.   R1#debug ipv ospf spf external OSPFv3 SPF external debugging is on for process 1, IPv6, Default vrf R1#   R1#clear ipv ospf pro Reset selected OSPFv3 processes? [no]: y R1#   We can see from the debug output, that R1 receives a Type-5 LSAs from R2 0.0.0.2 and R3 0.0.0.3, but it failed to find route to Forwarding Address 4::4 for the Type-5 LSA's R2 and to the Forwarding Address 5::5 for the Type-5 LSA's R3, when the Forward Address is unreachable, a router cannot install the external route in the routing table, because the internal path used to reach the Forward Address is the one that is used by a router to reach the external route.   Note: In the show ipv osp data ext command executed previously on R1, you can see that the Forward Address the Type-5 LSAs originated by R2 and R3 are 4::4 and 5::5 respectively.   Since the Forward Addresses 4::4 and 5::5 area reachable previously through an inter-area routes and the interarea routes are filtered in the previous task using the filter-list feature, R1 will get an issue for the external route, this is why R1 fails to install the external route to 45::/64.   R1# *Jan 21 10:21:44.859: %OSPFv3-5-ADJCHG: Process 1, Nbr 0.0.0.3 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached *Jan 21 10:21:44.859: %OSPFv3-5-ADJCHG: Process 1, Nbr 0.0.0.2 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Jan 21 10:21:44.868: OSPFv3-1-IPv6 SPF : Partial SPF - LSA 4005/0/0.0.0.2, Intra/Inter SPF already scheduled *Jan 21 10:21:44.868: OSPFv3-1-IPv6 SPF : Partial SPF - LSA 4005/0/0.0.0.3, Intra/Inter SPF already scheduled R1# *Jan 21 10:21:44.868: %OSPFv3-5-ADJCHG: Process 1, Nbr 0.0.0.3 on Ethernet0/1 from LOADING to FULL, Loading Done *Jan 21 10:21:44.868: %OSPFv3-5-ADJCHG: Process 1, Nbr 0.0.0.2 on Ethernet0/0 from LOADING to FULL, Loading Done R1# *Jan 21 10:21:49.869: OSPFv3-1-IPv6 MON : Begin SPF at 7452.282, process time 170ms *Jan 21 10:21:49.869: OSPFv3-1-IPv6 EXTER: External SPF in area ASE *Jan 21 10:21:49.869: OSPFv3-1-IPv6 EXTER: LSA 4005/0/0.0.0.2, age 692, seq 0x80000001, prefix 45::/64 (area ASE) metric 20 *Jan 21 10:21:49.869: OSPFv3-1-IPv6 EXTER: Failed to find route to forwarding address *Jan 21 10:21:49.869: OSPFv3-1-IPv6 EXTER: Add unreachable forward address 4::4, allowed types Intra and Inter, to watched queue *Jan 21 10:21:49.870: OSPFv3-1-IPv6 EXTER: LSA 4005/0/0.0.0.3, age 671, seq 0x80000001, prefix 45::/64 (area ASE) metric 20 R1# *Jan 21 10:21:49.870: OSPFv3-1-IPv6 EXTER: Failed to find route to forwarding address

*Jan 21 10:21:49.870: OSPFv3-1-IPv6 Intra and Inter, to watched queue *Jan 21 10:21:49.870: OSPFv3-1-IPv6 *Jan 21 10:21:49.870: OSPFv3-1-IPv6 *Jan 21 10:21:49.870: OSPFv3-1-IPv6 *Jan 21 10:21:49.870: OSPFv3-1-IPv6 *Jan 21 10:21:49.870: OSPFv3-1-IPv6 *Jan 21 10:21:49.870: OSPFv3-1-IPv6 R1# *Jan 21 10:21:59.873: OSPFv3-1-IPv6 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 prefix 45::/64 (area ASE) metric 20 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 Intra and Inter, to watched queue *Jan 21 10:21:59.873: OSPFv3-1-IPv6 prefix 45::/64 (area ASE) metric 20 R1# *Jan 21 10:21:59.873: OSPFv3-1-IPv6 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 Intra and Inter, to watched queue *Jan 21 10:21:59.873: OSPFv3-1-IPv6 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 *Jan 21 10:21:59.873: OSPFv3-1-IPv6 R1#

EXTER: Add unreachable forward address 5::5, allowed types EXTER: EXTER: EXTER: EXTER: EXTER: MON :

External SPF in area 0 AS external route sync for AS external route sync for AS external route sync for AS external route sync for End SPF at 7452.283, Total

area ASE area ASE area 0 area 0 elapsed time 0ms

MON : Begin SPF at 7462.286, process time 171ms EXTER: External SPF in area ASE EXTER: LSA 4005/0/0.0.0.2, age 702, seq 0x80000001, EXTER: Failed to find route to forwarding address EXTER: Add unreachable forward address 4::4, allowed types EXTER:

LSA 4005/0/0.0.0.3, age 681, seq 0x80000001,

EXTER: Failed to find route to forwarding address EXTER: Add unreachable forward address 5::5, allowed types EXTER: EXTER: EXTER: EXTER: EXTER: MON :

External SPF in area 0 AS external route sync for AS external route sync for AS external route sync for AS external route sync for End SPF at 7462.286, Total

area ASE area ASE area 0 area 0 elapsed time 0ms

  To solve this issue, we need to suppress the FA on R2 and R3.   R2(config)#ipv router osp 1 R2(config-rtr)#area 24 nssa translate type7 suppress-fa   R3(config)#ipv router osp 1 R3(config-rtr)#area 35 nssa translate type7 suppress-fa   Verify the routing table of R1, we can see only one external route is installed in the routing table through R1, this is because R1 learns only the Type-5 LSA's R2, R3 didn't translate the Type-7 LSA created by R5:   R1#sh ipv route os | beg App lr - LISP site-registrations, ld - LISP dyn-eid, a - Application OE2 45::/64 [110/20] via FE80::A8BB:CCFF:FE00:200, Ethernet0/0 R1#   Now why R3 didn't translate the Type-7 LSA of R5 even if the P-bit is set?   Let's verify the routing table of R3, we can see after executing the area 24 nssa translate type7 suppress-fa command on R2 and the area 35 nssa translate type7 suppress-fa command on R3, R3 receives one Type-5 LSA from R2 without Forward Address and one Type-7 LSA from R5 with the FA 5::5.   R3#sh ipv route os | s 45 OE2 45::/64 [110/20] via FE80::A8BB:CCFF:FE00:110, Ethernet0/0 R3#  

R3#sh ipv os data ext OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Type-5 AS External Link States LS age: 155 LS Type: AS External Link Link State ID: 1 Advertising Router: 0.0.0.2 LS Seq Number: 80000002 Checksum: 0x274C Length: 36 Prefix Address: 45:: Prefix Length: 64, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R3#   R3#sh ipv os data nssa OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Type-7 AS External Link States (Area 35) LS age: 938 LS Type: AS External Link Link State ID: 1 Advertising Router: 0.0.0.5 LS Seq Number: 80000002 Checksum: 0x501A Length: 52 Prefix Address: 45:: Prefix Length: 64, Options: P Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 5::5 R3#   To select the best LSA, R3 lookup the best cost to reach the ABR translator R2 and the FA 5::5, then it compares these metrics.   The best cost to reach the ASBR/ABR R2 is 20 through R1 and the best cost to reach the FA 5::5 is 64 through R5, 20 is lower than 64, therefore R3 prefers the Type-5 LSA rather the Type-7 LSA because the lowest cost. So because R3 has received a better Type-5 LSA, it will never translate the Type-7 LSA received from R5, as a result R3 installs an external route to 45::5 through R1, and R1 will never learn the Type-5 LSA from R3, an NSSA ABR cannot translate a Type-7 LSA if a corresponding ON2 route is not present in the routing table even if the Type-7 LSA exists in the LSDB:   R3#sh ipv os bord OSPFv3 Router with ID (0.0.0.3) (Process ID 1) Codes: i - Intra-area route, I - Inter-area route i 0.0.0.2 [20] via FE80::A8BB:CCFF:FE00:110, Ethernet0/0, ABR/ASBR, Area 0, SPF 26 i 0.0.0.5 [64] via FE80::A8BB:CCFF:FE00:500, Serial1/0, ASBR, Area 35, SPF 18 R3#   Now the challenge how to force both ABRs R2 and R3 to translate the Type-7 LSAs received from R4 and R5 respectively so that R1 will install a load balancing toward 45::/64?   If you read and compare the RFC 1583 and RFC 5340, you will find some differences in term of path selection. RFC 1583 which is the default RFC implemented by the cisco routers says that to select the best path, if the type of the route is the same, for example between two intra-area routes, the cost is always the tie breaker regardless the area where the intra-area route are learned, backbone or non-backbone areas.   From RFC 1583 Section 16.4.6

  Otherwise, compare the cost of this new AS external path to the ones present in the table. Type 1 external paths are always shorter than type 2 external paths. Type 1 external paths are compared by looking at the sum of the distance to the forwarding address and the advertised type 1 metric (X+Y). Type 2 external paths are compared by looking at the advertised type 2 metrics, and then if necessary, the distance to the forwarding addresses.   If the new path is shorter, it replaces the present paths in the routing table entry. If the new path is the same cost, it is added to the routing table entry's list of paths.   As per RFC 1583, the path selection is based solely on cost.   The RFC 5340 adds a new rule, this rule says an intra-area route learned through a non-backbone area is always the most preferred, rather an intra-area route learned through a backbone area, regardless the cost.   In the previous case, R3 has an intra-area route through a backbone area with a cost 20 to reach the ASBR/ABR R2 and an intra-area route through a non-backbone area with a cost 64 to reach the FA 35.0.0.5, and according to the RFC 1583, the cost is the tie breaker, the cost 20 wins over the cost 64.   To ensure that R3 will translate the Type-7 LSA's R5, we will tell to R3 to prefer the intra-area route to 5::5 through the non-backbone area, making the Type-7 LSA's R4 better than the Type-5 LSA's R2, as a result R3 can translate the Type-7 LSA.   To do this we need to disable RFC 1583 on R3, disabling RFC 1583 means the RFC 5340 is enabled.   Note we need to disable RFC 1583 on both R2 and R3.   Verify that R3 is implementing RFC 1583 by default.   R3#sh ipv ospf | s RFC Supports NSSA (compatible with RFC 3101) Supports Database Exchange Summary List Optimization (RFC 5243) RFC1583 compatibility enabled Area BACKBONE(0) R3#   On R2 and R3, configure the no compatible RFC1583 command:   Rx(config)#ipv router osp 1 Rx(config-rtr)#no compatible rfc1583   Verify that RFC 1583 is disabled on R3.   R3#sh ipv ospf | s RFC Supports NSSA (compatible with RFC 3101) Supports Database Exchange Summary List Optimization (RFC 5243) RFC1583 compatibility disabled Area BACKBONE(0) R3#   Verify the routing table of R1, we can see that a load balancing is installed through R2 and R3:   R1#sh ipv route | s 45:: OE2 45::/64 [110/20] via FE80::A8BB:CCFF:FE00:300, Ethernet0/1

via FE80::A8BB:CCFF:FE00:200, Ethernet0/0 R1#                                          

Lab 21: OSPFv2 RFC 6860 Hiding Transit-Only Networks  

  Basic configuration of all routers:   R1: interface Loopback0 ip address 172.16.10.1 255.255.255.0 secondary ip address 172.16.1.1 255.255.255.0 ip ospf 1 area 0 ! interface FastEthernet0/0 ip address 192.168.123.1 255.255.255.0 ip ospf 1 area 0 no shutdown

! interface FastEthernet0/1 ip address 10.10.10.1 255.255.255.0 secondary ip address 10.1.1.1 255.255.255.0 ip ospf 1 area 0 no shutdown ! router ospf 1 router-id 1.1.1.1   R2: interface FastEthernet0/0 ip address 192.168.123.2 255.255.255.0 ip ospf 1 area 0 no shutdown ! router ospf 1 router-id 2.2.2.2   R3: interface FastEthernet0/0 ip address 192.168.123.3 255.255.255.0 ip ospf 1 area 0 no shutdown ! router ospf 1 router-id 3.3.3.3   Let's verify the neighbor relationship:   R1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/BDR 00:00:39 192.168.123.2 FastEthernet0/0 3.3.3.3 1 FULL/DR 00:00:37 192.168.123.3 FastEthernet0/0 R1#   Let's verify the routing table of R2 and R3: Both routers install the OSPF routes advertised by R1:   R2#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/24 is subnetted, 2 subnets O 10.1.1.0 [110/2] via 192.168.123.1, 00:11:35, FastEthernet0/0 O 10.10.10.0 [110/2] via 192.168.123.1, 00:00:31, FastEthernet0/0 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks O 172.16.1.1/32 [110/2] via 192.168.123.1, 00:11:35, FastEthernet0/0 O 172.16.10.0/24 [110/2] via 192.168.123.1, 00:00:17, FastEthernet0/0 R2#   R3#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/24 is subnetted, 2 subnets O 10.1.1.0 [110/2] via 192.168.123.1, 00:12:28, FastEthernet0/0 O 10.10.10.0 [110/2] via 192.168.123.1, 00:00:53, FastEthernet0/0 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks O 172.16.1.1/32 [110/2] via 192.168.123.1, 00:12:28, FastEthernet0/0 O 172.16.10.0/24 [110/2] via 192.168.123.1, 00:00:38, FastEthernet0/0 R3#

  Let's verify the LSDB of R1: We can see that R1 has three LSA Type 1. -One LSA 1 created by itself with the Link ID: 1.1.1.1 and ADV Router: 1.1.1.1 -An LSA 1 advertised by R2 with the Link ID: 2.2.2.2 and ADV Router: 2.2.2.2 -An LSA 1 advertised by R3 with the Link ID: 3.3.3.3 and ADV Router: 3.3.3.3   Also R1 is receiving an LSA Type 2 from the DR R3 with the ADV Router: 3.3.3.3 and the Link: 192.168.123.3 which is the ip address of the DR in order to describe all attached routers because the multiaccess network.   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 91 0x8000000A 0x00A5BA 5 2.2.2.2 2.2.2.2 767 0x80000002 0x00E270 1 3.3.3.3 3.3.3.3 805 0x80000005 0x009EA8 1 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 192.168.123.3 3.3.3.3 767 0x80000002 0x004ADE R1#   Let's see the Router LSA Type 1 created by R1 in details: The LSA Type 1 carries informations about the intra-area prefixes 172.16.1.1/32, 172.16.10.0/24, 10.1.1.0/24 and 10.10.10.0/24 and because there are no routers connected, they are displayed: Link connected to: a Stub Network. The last section describes a Link connected to a transit Network because the election of a DR R3. Notice that The Number of Links is 5   R1#show ip ospf database router self-originate OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 110 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 1.1.1.1 Advertising Router: 1.1.1.1 LS Seq Number: 8000000A Checksum: 0xA5BA Length: 84 Number of Links: 5 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.1.1 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.10.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.1.1.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.10.10.0 (Link Data) Network Mask: 255.255.255.0

Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.123.3 (Link Data) Router Interface address: 192.168.123.1 Number of MTID metrics: 0 TOS 0 Metrics: 1 R1#   The prefix-suppression feature can be enabled globally under the OSPF process or under an interface. By default all prefixes are advertised. When this feature is configured under the OSPF process, the following types of networks are not suppressed:   -Loopbacks -Secondary address -Passive interfaces   Let's configure the prefix-suppression on R1 under OSPF and launch the debug ip ospf lsa-generation:   R1#debub ip ospf lsa-generation OSPF summary lsa generation debugging is on R1#   R1(config)#router ospf 1 R1(config-router)#prefix-suppression   R1(config-router)# *Dec 21 09:06:04.043: OSPF-1 LSGEN: Scheduling network LSA on FastEthernet0/1 *Dec 21 09:06:04.043: OSPF-1 LSGEN: Scheduling rtr LSA for area 0 *Dec 21 09:06:04.543: OSPF-1 LSGEN: No full nbrs on intf FastEthernet0/1 to build Net LSA *Dec 21 09:06:04.543: OSPF-1 LSGEN: Suppressing 10.1.1.0/24 from router LSA *Dec 21 09:06:04.547: OSPF-1 LSGEN: Build router LSA for area 0, router ID 1.1.1.1, seq 0x8000000B R1(config-router)#   Let's see the router LSA generated by R1: We can see that the primary prefix 10.1.1.0/24 of fa0/1 interface is suppressed and not carried in the router LSA 1 but the loopback and secondaries networks 172.16.1.1/32, 172.16.10.0/24 and 10.10.10.0/24 respectivelt are not filtered because the prefix-suppression rule: Notice that The Number of Links is 4   R1#show ip ospf database router self-originate OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 39 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 1.1.1.1 Advertising Router: 1.1.1.1 LS Seq Number: 8000000B Checksum: 0xA72 Length: 72 Number of Links: 4 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.1.1 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1

Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.10.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.10.10.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.123.3 (Link Data) Router Interface address: 192.168.123.1 Number of MTID metrics: 0 TOS 0 Metrics: 1 R1#   As a result R2 and R3 does not install the intra-area route toward the prefix 10.1.1.0/24 as shown by the routing tables:   R2#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/24 is subnetted, 1 subnets O 10.10.10.0 [110/2] via 192.168.123.1, 00:28:25, FastEthernet0/0 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks O 172.16.1.1/32 [110/2] via 192.168.123.1, 00:39:29, FastEthernet0/0 O 172.16.10.0/24 [110/2] via 192.168.123.1, 00:28:11, FastEthernet0/0 R2#   R3#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/24 is subnetted, 1 subnets O 10.10.10.0 [110/2] via 192.168.123.1, 00:29:21, FastEthernet0/0 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks O 172.16.1.1/32 [110/2] via 192.168.123.1, 00:40:56, FastEthernet0/0 O 172.16.10.0/24 [110/2] via 192.168.123.1, 00:29:06, FastEthernet0/0 R3#   Now let's configure passive-interface on Fa0/1 interface:   R1(config)#router ospf 1 R1(config-router)#passive-interface fastEthernet 0/1   Let's verify the router LSA of R1: The prefix 10.1.1.0/24 is now included and carried in the router LSA because the prefix-suppression feature does not suppress the network interface configured with passive-interface command: Notice that The Number of Links is 5   R1#show ip ospf database router self-originate OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 35 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 1.1.1.1 Advertising Router: 1.1.1.1 LS Seq Number: 8000000C Checksum: 0xA1BC

Length: 84 Number of Links: 5 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.1.1 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.10.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.1.1.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.10.10.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.123.3 (Link Data) Router Interface address: 192.168.123.1 Number of MTID metrics: 0 TOS 0 Metrics: 1 R1#   As a result the prefix 10.1.1.0/24 is installed in the routing tables of R2 and R3:   R2#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/24 is subnetted, 2 subnets O 10.1.1.0 [110/2] via 192.168.123.1, 00:03:45, FastEthernet0/0 O 10.10.10.0 [110/2] via 192.168.123.1, 00:34:00, FastEthernet0/0 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks O 172.16.1.1/32 [110/2] via 192.168.123.1, 00:45:04, FastEthernet0/0 O 172.16.10.0/24 [110/2] via 192.168.123.1, 00:33:46, FastEthernet0/0 R2#   R3#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/24 is subnetted, 2 subnets O 10.1.1.0 [110/2] via 192.168.123.1, 00:04:34, FastEthernet0/0 O 10.10.10.0 [110/2] via 192.168.123.1, 00:34:50, FastEthernet0/0 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks O 172.16.1.1/32 [110/2] via 192.168.123.1, 00:46:25, FastEthernet0/0 O 172.16.10.0/24 [110/2] via 192.168.123.1, 00:34:35, FastEthernet0/0 R3#   Let's configure prefix suppression directly on an interface, which only suppresses the specific network. First let's remove the prefix-suppression command and apply it to the loopback interface.   R1#debug ip ospf lsa-generation OSPF LSA generation debugging is on R1#  

R1(config)#router ospf 1 R1(config-router)#no prefix-suppression R1(config-router)#int lo 0 R1(config-if)#ip ospf prefix-suppression   R1(config-if)# *Dec 21 09:33:43.667: OSPF-1 LSGEN: Scheduling rtr LSA for area 0 *Dec 21 09:33:44.171: OSPF-1 LSGEN: Suppressing 172.16.1.1/32 from router LSA *Dec 21 09:33:44.171: OSPF-1 LSGEN: Build router LSA for area 0, router ID 1.1.1.1, seq 0x8000000F R1(config-if)#   Now only the primary prefix 172.16.1.1/32 of the loopback interface gets suppressed: The Number of Links is 4   R1#show ip ospf database router self-originate OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 12 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 1.1.1.1 Advertising Router: 1.1.1.1 LS Seq Number: 8000000D Checksum: 0x50DC Length: 72 Number of Links: 4 Link connected to: a Stub Network (Link ID) Network/subnet number: 172.16.10.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.1.1.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.10.10.0 (Link Data) Network Mask: 255.255.255.0 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.123.3 (Link Data) Router Interface address: 192.168.123.1 Number of MTID metrics: 0 TOS 0 Metrics: 1 R1#   As a result the prefix 172.16.1.1/32 is not installed in the routing tables of R2 and R3:   R2#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/24 is subnetted, 2 subnets O 10.1.1.0 [110/2] via 192.168.123.1, 00:10:28, FastEthernet0/0 O 10.10.10.0 [110/2] via 192.168.123.1, 00:40:43, FastEthernet0/0 172.16.0.0/24 is subnetted, 1 subnets O 172.16.10.0 [110/2] via 192.168.123.1, 00:40:29, FastEthernet0/0

R2#   R3#show ip route ospf | beg Gate Gateway of last resort is not set 10.0.0.0/24 is subnetted, 2 subnets O 10.1.1.0 [110/2] via 192.168.123.1, 00:10:47, FastEthernet0/0 O 10.10.10.0 [110/2] via 192.168.123.1, 00:41:03, FastEthernet0/0 172.16.0.0/24 is subnetted, 1 subnets O 172.16.10.0 [110/2] via 192.168.123.1, 00:40:48, FastEthernet0/0 R3#                                                                

Lab 22: OSPFv3 RFC 6860 Hiding Transit-Only Networks  

    Basic configuration of all routers:  

R1: ipv un ! int lo0 ip add 1.1.1.1 255.255.255.0 ipv add 1::1/64 ipv6 enable ospfv3 1 ipv6 area 0 ospfv3 1 ipv4 area 0 ospfv3 network point-to-point ! interface G0/0 ip address 12.0.0.1 255.255.255.0 ipv6 address 12::1/64 ipv6 enable ospfv3 1 ipv6 area 12 ospfv3 1 ipv4 area 12 no shut ! router ospfv3 1 ! address-family ipv4 unicast router-id 0.0.0.1 exit-address-family ! address-family ipv6 unicast router-id 0.0.0.11 exit-address-family   R2: ipv un ! interface G0/0 ip address 12.0.0.2 255.255.255.0 ipv6 address 12::2/64 ipv6 enable ospfv3 1 ipv6 area 0 ospfv3 1 ipv4 area 0 no shut ! interface G0/1 ip address 23.0.0.2 255.255.255.0 ipv6 address 23::2/64 ipv6 enable ospfv3 1 ipv6 area 1 ospfv3 1 ipv4 area 1 no shut ! router ospfv3 1 ! address-family ipv4 unicast router-id 0.0.0.2 exit-address-family ! address-family ipv6 unicast router-id 0.0.0.22 exit-address-family  

R3: ipv un ! interface G0/0 ip address 23.0.0.3 255.255.255.0 ipv6 address 23::3/64 ipv6 enable ospfv3 1 ipv6 area 1 ospfv3 1 ipv4 area 1 no shut ! router ospfv3 1 ! address-family ipv4 unicast router-id 0.0.0.3 exit-address-family ! address-family ipv6 unicast router-id 0.0.0.33 exit-address-family   By definition, In OSPFv3, the Type-1 and 2 LSAs no longer carry any addressing information. They only carry a description of topology adjacencies. This is how type 8 and 9 LSAs came to carry the prefix informations. Rememeber with OSPFv2, the prefix suppression suppresses the subnet carried in the Type-1 and 2 LSA.   So how this feature works with OSPFv3?   Per RFC 6860 Hiding Transit-Only Networks in OSPF   3. Hiding IPv6 Transit-Only Networks in OSPFv3   In [OSPFv3], addressing semantics have been removed from the OSPF protocol packets and the main LSA types, leaving a network-protocolindependent core.   More specifically, router-LSAs and network-LSAs no longer contain network addresses but simply express topology information. Instead, two new LSA types, link-LSA and intra-area-prefix-LSA, have been introduced. A link-LSA associates a list of IPv6 addresses to a link and has local-link flooding scope, and an intra-area-prefix-LSA either associates a list of IPv6 addresses with a router by referencing a router-LSA or associates a list of IPv6 addresses with a broadcast/NBMA network by referencing a network-LSA. In the latter case, the prefixes in the link-LSAs from adjacent neighbors are copied into the intra-area-prefix-LSA by the Designated Router.   To hide a transit-only network in [OSPFv3], the IPv6 address prefixes are omitted from the router-LSA. Consequently, when a Designated Router builds an intra-area-prefix-LSA referencing a network-LSA, these IPv6 address prefixes will be omitted.   In addition, when a router builds an intra-area-prefix-LSA that is referencing a router-LSA, the associated IPv6 address prefixes from the transit-only network MUST also be omitted from the intra-areaprefix-LSA.   3.1. Hiding AF-Enabled Transit-Only Networks in OSPFv3   [OSPF-AF] supports multiple Address Families (AFs) by mapping each AF

to a separate Instance ID and OSPFv3 instance.   In the meantime, each prefix advertised in OSPFv3 has a prefix length field [OSPFv3], which facilitates advertising prefixes of different lengths in different AFs. The existing LSAs defined in [OSPFv3] are used for prefix advertising, and there is no need to define new LSAs.   In other words, as link-LSAs and intra-area-prefix-LSAs are still being used, the same mechanism explained in Section 3 can be used to hide those AF-enabled transit-only networks as well.   Let's verify the IPv4 and IPv6 routing table of R3:   R3#show ip route ospfv | beg Gate Gateway of last resort is not set 1.0.0.0/24 is subnetted, 1 subnets O IA 1.1.1.0 [110/3] via 23.0.0.2, 00:02:44, GigabitEthernet0/0 12.0.0.0/24 is subnetted, 1 subnets O IA 12.0.0.0 [110/2] via 23.0.0.2, 00:02:44, GigabitEthernet0/0 R3#   R3#show ipv route ospf IPv6 Routing Table - default - 5 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2 IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application OI 1::/64 [110/3] via FE80::F60F:1BFF:FE06:E2C1, GigabitEthernet0/0 OI 12::/64 [110/2] via FE80::F60F:1BFF:FE06:E2C1, GigabitEthernet0/0 R3#   Since in OSPFv3 the IP prefixes are no longer carried in the Type-1 LSA, instead the new LSAs, Type-8 and Type9 LSA come to carry the IP prefixes: By default, for each prefix connected, a router creates a single Type-8 LSA to carry it and this LSA has a link flooding scope (not area scope), in other words, it is not flooded beyond the receiving neighbor similar to broadcast:   For IPv4 Address Family. Since R1 has two IP prefixes connected, it creates two separates Type-8 LSA for each link (Loopback and Fa0/0): Type-8 LSA for the link loopback carries 1.1.1.0/24 (Number of Prefixes: 1). Type-8 LSA for link fa0/0 carries 12.0.0.0/24 (Number of Prefixes: 1).   R1#show ospfv3 ipv4 data link self OSPFv3 1 address-family ipv4 (router-id 0.0.0.1) Link (Type-8) Link States (Area 0) LS age: 105 Options: (E-Bit, R-Bit, DC-Bit, AF-Bit) LS Type: Link-LSA (Interface: Loopback0) Link State ID: 18 (Interface ID) Advertising Router: 0.0.0.1 LS Seq Number: 80000001 Checksum: 0x15C5 Length: 52 Router Priority: 1

Link Local Address: 1.1.1.1 Number of Prefixes: 1 Prefix Address: 1.1.1.0 Prefix Length: 24, Options: None LS age: 96 Options: (E-Bit, R-Bit, DC-Bit, AF-Bit) LS Type: Link-LSA (Interface: GigabitEthernet0/0) Link State ID: 3 (Interface ID) Advertising Router: 0.0.0.1 LS Seq Number: 80000002 Checksum: 0xFADB Length: 52 Router Priority: 1 Link Local Address: 12.0.0.1 Number of Prefixes: 1 Prefix Address: 12.0.0.0 Prefix Length: 24, Options: None R1#   R1#show ospfv3 ipv4 data link self | s Prefix Number of Prefixes: 1 Prefix Address: 1.1.1.0 Prefix Length: 24, Options: None Number of Prefixes: 1 Prefix Address: 12.0.0.0 Prefix Length: 24, Options: None R1#   For IPv6 Address Family. Since R1 has two IP prefixes connected, it creates two separates Type-8 LSA for each link (Loopback and Fa0/0): Type-8 LSA for the link loopback carries 1::/64 (Number of Prefixes: 1). Type-8 LSA for link fa0/0 carries 12::/64 (Number of Prefixes: 1).   R1#show ospfv3 ipv6 data link self OSPFv3 1 address-family ipv6 (router-id 0.0.0.11) Link (Type-8) Link States (Area 0) LS age: 405 Options: (V6-Bit, E-Bit, R-Bit, DC-Bit) LS Type: Link-LSA (Interface: Loopback0) Link State ID: 18 (Interface ID) Advertising Router: 0.0.0.11 LS Seq Number: 80000001 Checksum: 0x4D0E Length: 56 Router Priority: 1 Link Local Address: FE80::1205:CAFF:FE29:6560 Number of Prefixes: 1 Prefix Address: 1:: Prefix Length: 64, Options: None LS age: 396 Options: (V6-Bit, E-Bit, R-Bit, DC-Bit) LS Type: Link-LSA (Interface: GigabitEthernet0/0) Link State ID: 3 (Interface ID) Advertising Router: 0.0.0.11 LS Seq Number: 80000003 Checksum: 0x255 Length: 56

Router Priority: 1 Link Local Address: FE80::1205:CAFF:FE29:6560 Number of Prefixes: 1 Prefix Address: 12:: Prefix Length: 64, Options: None R1#   R1#show ospfv3 ipv6 data link self | s Prefix Number of Prefixes: 1 Prefix Address: 1:: Prefix Length: 64, Options: None Number of Prefixes: 1 Prefix Address: 12:: Prefix Length: 64, Options: None R1#   For IPv4 Address Family. To advertise the prefix 1.1.1.0/24 to R2, it creates a Type-9 LSA, unlike with Type-8 LSA this LSA has an area flooding scope and a single Type-9 LSA can carry multiple prefixes: Below the IP prefixe 1.1.1.0/24 is carried by the Type-9 LSA's R1:   R1#show ospfv3 ipv4 database prefix self-originate OSPFv3 1 address-family ipv4 (router-id 0.0.0.1) Intra Area Prefix Link States (Area 0) LS age: 6 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 0.0.0.1 LS Seq Number: 80000004 Checksum: 0xCF1A Length: 40 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.1 Number of Prefixes: 1 Prefix Address: 1.1.1.0 Prefix Length: 24, Options: None, Metric: 1 R1#   R1#show ospfv3 ipv4 database prefix self | s Prefix Intra Area Prefix Link States (Area 0) LS Type: Intra-Area-Prefix-LSA Number of Prefixes: 1 Prefix Address: 1.1.1.0 Prefix Length: 24, Options: None, Metric: 1 R1#   For IPv6 Address Family. To advertise the prefix 1::/64 to R2, it creates a Type-9 LSA, unlike with Type-8 LSA this LSA has an area flooding scope and a single Type-9 LSA can carry multiple prefixes: Below the IP prefixe 1::/64 is carried by the Type-9 LSA's R1:   R1#show ospfv3 ipv6 database prefix self-originate OSPFv3 1 address-family ipv6 (router-id 0.0.0.11) Intra Area Prefix Link States (Area 0) LS age: 273 LS Type: Intra-Area-Prefix-LSA Link State ID: 0

Advertising Router: 0.0.0.11 LS Seq Number: 80000004 Checksum: 0x5A51 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 0.0.0.11 Number of Prefixes: 1 Prefix Address: 1:: Prefix Length: 64, Options: None, Metric: 1 R1#   R1#show ospfv3 ipv6 database prefix self | s Prefix Intra Area Prefix Link States (Area 0) LS Type: Intra-Area-Prefix-LSA Number of Prefixes: 1 Prefix Address: 1:: Prefix Length: 64, Options: None, Metric: 1 R1#   Let's enable prefix suppression feature on loopback of R1:   R1(config)#int lo0 R1(config-if)#ospfv3 prefix-suppression   Let's verify the Type-8 LSA for IPv4 and IPv6 Address Families, the prefixes 1.1.1.0/24 and 1::/64 are suppressed in the Type-8 LSAs for the link lo0 as mentioned by the Number of Prefixes: 0:   R1#show ospfv3 ipv4 data link self | s Prefix Number of Prefixes: 0 Number of Prefixes: 1 Prefix Address: 12.0.0.0 Prefix Length: 24, Options: None R1#   R1#show ospfv3 ipv6 data link self | s Prefix Number of Prefixes: 0 Number of Prefixes: 1 Prefix Address: 12:: Prefix Length: 64, Options: None R1#   Since R1 does not have any prefixes that belong to another link except the link fa0/0, it does not generate a Type-9 LSA for both IPv4 and IPv6 Address Families as shown below:   R1#show ospfv3 ipv4 database prefix self OSPFv3 1 address-family ipv4 (router-id 0.0.0.1) R1#   R1#show ospfv3 ipv6 database prefix self OSPFv3 1 address-family ipv6 (router-id 0.0.0.11) R1#   Since the prefixes 1.1.1.1.0/24 and 1::/64 are not included in the Type-8 LSA's R1, no route in the IPv4 and IPv6 routing tables of R3:   R3#show ip route ospfv | beg Gate

Gateway of last resort is not set 12.0.0.0/24 is subnetted, 1 subnets O IA 12.0.0.0 [110/2] via 23.0.0.2, 00:16:40, GigabitEthernet0/0 R3#   R3#show ipv route ospf IPv6 Routing Table - default - 4 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2 IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application OI 12::/64 [110/2] via FE80::F60F:1BFF:FE06:E2C1, GigabitEthernet0/0 R3#   Now what about the filtering of the prefix 12.0.0.0/24 ?   First let's verify that R2 is the DR for the segments 12.0.0.0/24 and 12::/64 for both IPv4 and IPv6 Address Families:   R2#show ospfv3 interface g0/0 | inc Designated Router Designated Router (ID) 0.0.0.2, local address FE80::F60F:1BFF:FE06:E2C0 Adjacent with neighbor 0.0.0.1 (Backup Designated Router) Designated Router (ID) 0.0.0.22, local address FE80::F60F:1BFF:FE06:E2C0 Adjacent with neighbor 0.0.0.11 (Backup Designated Router) R2#   By definition with OSPFv2 the content of the LSA Type 2 describes the network segment listing the DR address, the attached routers, and the used subnet mask. This information is used by each router participating in OSPF to build the exact picture of the described multiaccess segment, which cannot be fully described with just LSAs Type 1.   With OSPFv3 the Type-2 LSA does not carry the used subnet mask and the DR address. Let's verify the Network LSA Type 2 generated by the R2 for both IPv4 and IPv6 Address Families, we can see that there is no information about the subnet mask /24 and /64 and the DR address (12.0.0.2 and 12::2), only the attached routers and the Link State ID are carried as shown by the show ospfv3 database network command:   R2#show ospfv3 database network self-originate OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Net Link States (Area 0) LS age: 910 Options: (E-Bit, R-Bit, DC-Bit, AF-Bit) LS Type: Network Links Link State ID: 3 (Interface ID of Designated Router) Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0xE719 Length: 32 Attached Router: 0.0.0.2 Attached Router: 0.0.0.1 OSPFv3 1 address-family ipv6 (router-id 0.0.0.22) Net Link States (Area 0) LS age: 910 Options: (V6-Bit, E-Bit, R-Bit, DC-Bit) LS Type: Network Links Link State ID: 3 (Interface ID of Designated Router) Advertising Router: 0.0.0.22

LS Seq Number: 80000001 Checksum: 0xC509 Length: 32 Attached Router: 0.0.0.22 Attached Router: 0.0.0.11 R2#   Since the creators of OSPFv3 decided to remove the subnet mask in the Type-2 LSA, a router can originate multiple intra-area prefix LSAs for each router or transit network, each with a unique link-state ID. The link state ID for each intra-area prefix LSA describes its association to either the router LSA or the network LSA. The linkstate ID also contains prefixes for stub and transit networks. This LSA type (Intra Area Prefix) provides information for two different scenarios:   1) It will provide information about IPv6 address prefixes associated with a transit network by referencing a Network LSA. 2) It will provide information about IPv6 address prefixes associated with a router by referencing a Router LSA. Type 9 LSAs are only flooded within an area.   Let's verify the Intra-area prefix LSA (Type 9) advertised by the DR R2: We can see that the Type-9 LSAs carries the following information:   For IPv4 Address Family:   -the subnet 12.0.0.0 and the subnet mask (Prefix Length) /24 -Referenced Link State ID: 2 that matches the Link State ID of the LSA Type 2. -Referenced LSA Type: 2002 describes its association to the Network LSA Type 2 (or 2002).   For IPv6 Address Family:   -the subnet 12::/64 and the subnet mask (Prefix Length) /64 -Referenced Link State ID: 3 that matches the Link State ID of the Type-2 LSA -Referenced LSA Type: 2002 describes its association to the Network LSA Type 2 (or 2002).   R2#show ospfv3 database prefix self-originate OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Intra Area Prefix Link States (Area 0) LS age: 51 LS Type: Intra-Area-Prefix-LSA Link State ID: 3072 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x14BE Length: 40 Referenced LSA Type: 2002 Referenced Link State ID: 3 Referenced Advertising Router: 0.0.0.2 Number of Prefixes: 1 Prefix Address: 12.0.0.0 Prefix Length: 24, Options: None, Metric: 0 OSPFv3 1 address-family ipv6 (router-id 0.0.0.22) Intra Area Prefix Link States (Area 0) LS age: 51 LS Type: Intra-Area-Prefix-LSA Link State ID: 3072 Advertising Router: 0.0.0.22 LS Seq Number: 80000001 Checksum: 0x9BDC Length: 44 Referenced LSA Type: 2002 Referenced Link State ID: 3

Referenced Advertising Router: 0.0.0.22 Number of Prefixes: 1 Prefix Address: 12:: Prefix Length: 64, Options: None, Metric: 0 R2#   R2#show ospfv3 database prefix self | inc Prefix Intra Area Prefix Link States (Area 0) LS Type: Intra-Area-Prefix-LSA Number of Prefixes: 1 Prefix Address: 12.0.0.0 Prefix Length: 24, Options: None, Metric: 0 Intra Area Prefix Link States (Area 0) LS Type: Intra-Area-Prefix-LSA Number of Prefixes: 1 Prefix Address: 12:: Prefix Length: 64, Options: None, Metric: 0 R2#   Let's enable prefix suppression on g0/0's R2   R2(config)#int g0/0 R2(config-if)#ospfv3 prefix-suppression   Let's verify the Type-9 LSAs for both IPv4 and IPv6 Address Families: The show ospfv3 database prefix self-originate output shown that the prefixes of the transit network 12.0.0.0/24 and 12::/64 are not suppressed:   R2#show ospfv3 database prefix self-originate OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Intra Area Prefix Link States (Area 0) LS age: 136 LS Type: Intra-Area-Prefix-LSA Link State ID: 3072 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0x14BE Length: 40 Referenced LSA Type: 2002 Referenced Link State ID: 3 Referenced Advertising Router: 0.0.0.2 Number of Prefixes: 1 Prefix Address: 12.0.0.0 Prefix Length: 24, Options: None, Metric: 0 OSPFv3 1 address-family ipv6 (router-id 0.0.0.22) Intra Area Prefix Link States (Area 0) LS age: 136 LS Type: Intra-Area-Prefix-LSA Link State ID: 3072 Advertising Router: 0.0.0.22 LS Seq Number: 80000001 Checksum: 0x9BDC Length: 44 Referenced LSA Type: 2002 Referenced Link State ID: 3 Referenced Advertising Router: 0.0.0.22 Number of Prefixes: 1 Prefix Address: 12::

Prefix Length: 64, Options: None, Metric: 0 R2#   R2#show ospfv3 database prefix self | inc Prefix Intra Area Prefix Link States (Area 0) LS Type: Intra-Area-Prefix-LSA Number of Prefixes: 1 Prefix Address: 12.0.0.0 Prefix Length: 24, Options: None, Metric: 0 Intra Area Prefix Link States (Area 0) LS Type: Intra-Area-Prefix-LSA Number of Prefixes: 1 Prefix Address: 12:: Prefix Length: 64, Options: None, Metric: 0 R2#   Let's verify the Type-8-LSA's R1: We can see that R1 advertises a Type-8 LSAs for IPv4 and IPv6 Address Families describing and including the prefixes 12.0.0.0/24 and 12::/64:   R2#show ospfv3 ipv4 database link adv 0.0.0.1 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Link (Type-8) Link States (Area 0) LS age: 271 Options: (E-Bit, R-Bit, DC-Bit, AF-Bit) LS Type: Link-LSA (Interface: GigabitEthernet0/0) Link State ID: 3 (Interface ID) Advertising Router: 0.0.0.1 LS Seq Number: 80000005 Checksum: 0xF4DE Length: 52 Router Priority: 1 Link Local Address: 12.0.0.1 Number of Prefixes: 1 Prefix Address: 12.0.0.0 Prefix Length: 24, Options: None Link (Type-8) Link States (Area 1) R2#   R2#show ospfv3 ipv6 database link adv 0.0.0.11 OSPFv3 1 address-family ipv6 (router-id 0.0.0.22) Link (Type-8) Link States (Area 0) LS age: 280 Options: (V6-Bit, E-Bit, R-Bit, DC-Bit) LS Type: Link-LSA (Interface: GigabitEthernet0/0) Link State ID: 3 (Interface ID) Advertising Router: 0.0.0.11 LS Seq Number: 80000006 Checksum: 0xFB58 Length: 56 Router Priority: 1 Link Local Address: FE80::1205:CAFF:FE29:6560 Number of Prefixes: 1 Prefix Address: 12:: Prefix Length: 64, Options: None Link (Type-8) Link States (Area 1) R2#  

R2#show ospfv3 ipv4 data link adv 0.0.0.1 | s Prefix Number of Prefixes: 1 Prefix Address: 12.0.0.0 Prefix Length: 24, Options: None R2#   R2#show ospfv3 ipv6 data link adv 0.0.0.11 | s Prefix Number of Prefixes: 1 Prefix Address: 12:: Prefix Length: 64, Options: None R2#   Since R2 is getting the information about the prefixes 12.0.0.0/24 and 12::/64 through Type-8 LSA, R2 creates a Type-9 LSAs for these prefixes et advertises them as Type-3 LSAs into area 1 to R3, even if the interface G0/0 of R2 is configured with prefix suppression feature:   R3#show ip route ospfv | beg Gate Gateway of last resort is not set 12.0.0.0/24 is subnetted, 1 subnets O IA 12.0.0.0 [110/2] via 23.0.0.2, 00:07:42, GigabitEthernet0/0 R3#   R3#show ipv route ospf IPv6 Routing Table - default - 4 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2 IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application OI 12::/64 [110/2] via FE80::F60F:1BFF:FE06:E2C1, GigabitEthernet0/0 R3#   To ensure so that R2 will never generate or will never include the prefixes 12.0.0.0/24 and 12::/64 in its Type-9 LSA, we should tell to R1 to suppress these prefixes in the Type-8 LSAs generated by R1:   Let's enable prefix suppression in G0/0's R1:   R1(config-if)#int g0/0 R1(config-if)#ospfv3 prefix-suppression   Let's verify the Type-8 LSA advertised by R1 for both IPv4 and IPv6 Address Families:   For IPv6 there is no prefix 12::/64 in the Type-9 LSA's R1 as mentioned by the Number of Prefixes: 0:   R2#show ospfv3 ipv6 data link adv 0.0.0.11 | s Prefix Number of Prefixes: 0 R2#   For IPv4 there is no prefix 12.0.0.0/24 in the Type-9 LSA's R1 as mentioned by the Number of Prefixes: 0:   R2#show ospfv3 ipv4 data link adv 0.0.0.1 | s Prefix Number of Prefixes: 0 R2#  

Since R2 will not get any information from R1 about the prefixes 12.0.0.0/24 and 12::/64, it will never generate a Type-9 LSAs or it will never include these prefixes in its Type-9 LSA as shown by the show ospfv3 database prefix self command:   R2#show ospfv3 database prefix self OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) OSPFv3 1 address-family ipv6 (router-id 0.0.0.22) R2#   The routing tables for both IPv4 and IPv6 of R3 displays no routes to the prefixes 12.0.0.0/24 and 12::/64:   R3#show ip route 12.0.0.0 % Network not in table R3#   R3#show ipv route 12:: % Route not found R3#                                      

Lab 23: OSPF TTL security check  

  Basic configuration:   R1: interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ip ospf 1 area 0 no shut !

router ospf 1 router-id 0.0.0.1   R2: interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 0 no shut ! router ospf 1 router-id 0.0.0.2   The OSPF TTL security check feature is a mechanism that protects OSPF against remote attacks. When you enable this feature, OSPF will send packets with a TTL of 255 and drops any packets with a TTL that are smaller than a configured threshold. By default, once the TTL security feature is enabled it will only accept packets with a TTL of 255. Since routing process decrements the TTL by one, this means that only OSPF packets from directly connected devices will be accepted.   6. Security Considerations   Implementations have a number of options in minimizing the potential denial-of-service impact of OSPF cryptographic authentication. The Generalized TTL Security Mechanism (GTSM) [RFC5082] might be appropriate for OSPF packets except for those traversing virtual links. Using this mechanism requires support of the sender; new OSPF cryptographic authentication could specify this behavior if desired. Alternatively, implementations can limit the source addresses from which they accept packets. Non-Hello packets need only be accepted from existing neighbors. If a system is under attack, Hello packets from existing neighbors could be prioritized over Hello packets from new neighbors. These mechanisms can be considered to limit the potential impact of denial-of-service attacks on the cryptographic authentication mechanism itself.   By default, all OSPF packets have a TTL of 1 as you can see in the packet capture below for the OSPF packets generated by R1 and R2:  

 

  When TTL security check is enabled, OSPF will only accept packets with a certain TTL value, 255 by default. When it receives packets with a lower TTL, they will be discarded.   Let’s see the topology, R1 and R2 are running OSPF.   Verify the neighbor relationship:   R1#sh ip os ne Neighbor ID Pri State Dead Time Address Interface 0.0.0.2 1 FULL/DR 00:00:37 12.0.0.2 FastEthernet0/0 R1#   R2#sh ip os ne Neighbor ID Pri State Dead Time Address Interface 0.0.0.1 1 FULL/BDR 00:00:39 12.0.0.1 FastEthernet0/0 R2#   Let's enable the TTL security feature globally on R2:   R2(config-router)#router osp 1 R2(config-router)#ttl-security all-interfaces   Note: You can also enable TTL security check on the interface level with the ip ospf ttl-security command.   Verify the neighbor relationship on R1, the state of the adjacency is INIT:   R1#sh ip os ne Neighbor ID Pri State Dead Time Address Interface 0.0.0.2 1 INIT/DROTHER 00:00:31 12.0.0.2 FastEthernet0/0 R1#   To verify is the TTL security check feature is enabled, use the sh ip os command:   R2#sh ip os Routing Process "ospf 1" with ID 0.0.0.2 Start time: 00:06:13.312, Time elapsed: 00:15:56.312 Supports only single TOS(TOS0) routes Supports opaque LSA Supports Link-local Signaling (LLS) Supports area transit capability Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs

Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Incremental-SPF disabled Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 0. Checksum Sum 0x000000 Number of opaque AS LSA 0. Checksum Sum 0x000000 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Number of areas transit capable is 0 External flood list length 0 IETF NSF helper support enabled Cisco NSF helper support enabled Reference bandwidth unit is 100 mbps Strict TTL checking enabled Area BACKBONE(0) (Inactive) Number of interfaces in this area is 1 Area has no authentication SPF algorithm last executed 00:03:31.028 ago SPF algorithm executed 1 times Area ranges are Number of LSA 1. Checksum Sum 0x002FF2 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R2#   R2#sh ip os | s TTL Strict TTL checking enabled Area BACKBONE(0) (Inactive) Number of interfaces in this area is 1 R2#   As soon as you enable this on one router, R2 in this case, the neighbor adjacency with R1 will drop once the dead timer expires. Why? We can see the reason from the debug ip os adj output.   On the console of R2, you will see the following message:   R2#debug ip os adj OSPF adjacency debugging is on R2# *Aug 21 09:23:45.359: OSPF-1 ADJ Fa0/0: Drop packet from 12.0.0.1 with TTL: 1 R2# *Aug 21 09:23:54.759: OSPF-1 ADJ Fa0/0: Drop packet from 12.0.0.1 with TTL: 1 R2#   Here’s a packet capture of R2’s OSPF packet where you can see the new TTL value:  

  R2 will now only accept packets with a TTL of 255 and since R1 is sending OSPF packets with a TTL of 1, they are discarded. Let’s enable TTL security on R1 as well:   R1(config)#router osp 1 R1(config-router)#ttl-security all-interfaces   Here’s a packet capture of R1’s OSPF packet with the new TTL value:  

  The OSPF neighbor adjacency will recover and both R1 and R2 are now sending OSPF packets with a TTL of 255 to each other:   R1#sh ip os neighbor Neighbor ID Pri State Dead Time Address Interface 0.0.0.2 1 FULL/DR 00:00:39 12.0.0.2 FastEthernet0/0 R1#   Above you can see that the TTL is now 255. Since this is the highest value possible for the TTL field, it is impossible for a remote attacker to send a spoofed unicast OSPF packet to R1, preventing a remote attack like this.   The TTL security check is not applied to virtual links or sham links by default. If you want to use this, then you can use the area virtual-link ttl-security or area sham-link ttl-security commands.                

                   

Lab 24: Stub router advertisement Graceful Shutdown    

  Basic configuration:   R1: ipv uni ! interface FastEthernet0/0 ipv6 address 2012:12::1/64 ipv6 ospf 1 area 0 no shut ! interface FastEthernet1/0 ipv6 address 2013:13::1/64 ipv6 ospf 1 area 0 no shut ! ipv6 router ospf 1 router-id 1.1.1.1   R2: ipv uni ! interface FastEthernet0/0 ipv6 address 2012:12::2/64 ipv6 ospf 1 area 0 no shut ! interface FastEthernet1/0 ipv6 address 2023:23::2/64 ipv6 ospf 1 area 0 no shut ! ipv6 router ospf 1 router-id 2.2.2.2

  R3: ipv uni ! interface Loopback0 no ip address ipv6 address 2000:3333::3/64 ipv6 ospf 1 area 0 ipv6 ospf network point-to-point ! interface FastEthernet0/0 ipv6 address 2023:23::3/64 ipv6 ospf 1 area 0 no shut ! interface FastEthernet1/0 ipv6 address 2013:13::3/64 ipv6 ospf 1 area 0 no shut ! ipv6 router ospf 1 router-id 3.3.3.3   The max-metric router-lsa command is useful when you want to power down a router which is used to forward a Data Traffic for maintenace, for example upgrade a new IOS but you want to keep the network still available for the users, without this feature, if this router is powered down, the rest of routers should wait for the dead timer to expire , and re-run SPF algorithm in order to calculate others routes which are reachable through this router in the past, in this case a lot packets will be dropped when OSPF is re-converging. this is undesirable.   To avoid this issue we can enable graceful shutdown feature by using the max-metric router-lsa command on R3 , as a result it is forced to advertise its LSA Type 1 with an infinite metric 65535 and ensure other routers to use other LSAs Type 1 stored it their LSDB.   RFC 6987 says:   1. Introduction   In some situations, it may be advantageous to inform routers in a network not to use a specific router as a transit point but to still route to it. Possible situations include the following:   o The router is in a critical condition (for example, has a very high CPU load or does not have enough memory to store all Link State Advertisements (LSAs) or build the routing table).   o Graceful introduction and removal of the router to/from the network.   o Other (administrative or traffic engineering) reasons.   2. Solutions   To address both problems, router X announces its router-LSA to the neighbors with the cost of all non-stub links (links of the types other than 3) being set to MaxLinkMetric (defined in Section 3).   Before configuring this feature let's verify the LSA Type 1 (Router LSA) and the LSA Type 9 (intra-area prefix LSA) of R3. You need to know that with OSPFv3 , the Stub Prefix or network are carried in the LSA Type 9 which is new in OSPFv3, this LSA Type 9 includes also the metric of the interface which connects this prefix.

  The metric listed in the LSA Type 1 is 1 and the metric listed in the LSA Type 9 for the stub network 2000:3333::/64 (loopback interface of R3) is 1 as shown by the following output:   R1#show ipv6 ospf database router adv-router 3.3.3.3 OSPFv3 Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 78 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 3.3.3.3 LS Seq Number: 80000003 Checksum: 0xAB1B Length: 56 Number of Links: 2 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 3 Neighbor (DR) Interface ID: 3 Neighbor (DR) Router ID: 1.1.1.1 Link connected to: a Transit Network Link Metric: 1 Local Interface ID: 2 Neighbor (DR) Interface ID: 3 Neighbor (DR) Router ID: 2.2.2.2 R1#   R1#show ipv6 ospf database prefix adv-router 3.3.3.3 OSPFv3 Router with ID (1.1.1.1) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 549 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 3.3.3.3 LS Seq Number: 80000005 Checksum: 0x24FE Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 3.3.3.3 Number of Prefixes: 1 Prefix Address: 2000:3333:: Prefix Length: 64, Options: None, Metric: 1 R1#   Let's configure the max-metric router-lsa command: The command changed the metric listed in the LSA Type 1 advertised by R3 but it does not have effect in the LSA Type 9 as shown by the following outputs:   R3(config)#ipv6 router ospf 1 R3(config-rtr)#max-metric router-lsa R3(config-rtr)#   The command changed the metric listed in the LSA Type 1 advertised by R3 but it does not have effect in the LSA Type 9 as shown by the show ipv6 ospf database router adv-router 3.3.3.3 and the show ipv6 ospf database prefix adv-router 3.3.3.3 commands respectively:

  R1#show ipv6 ospf database router adv-router 3.3.3.3 OSPFv3 Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 244 Options: (V6-Bit, E-Bit, R-bit, DC-Bit) LS Type: Router Links Link State ID: 0 Advertising Router: 3.3.3.3 LS Seq Number: 80000004 Checksum: 0x8542 Length: 56 Number of Links: 2 Link connected to: a Transit Network Link Metric: 65535 Local Interface ID: 3 Neighbor (DR) Interface ID: 3 Neighbor (DR) Router ID: 1.1.1.1 Link connected to: a Transit Network Link Metric: 65535 Local Interface ID: 2 Neighbor (DR) Interface ID: 3 Neighbor (DR) Router ID: 2.2.2.2 R1#   R1#show ipv6 ospf database prefix adv-router 3.3.3.3 OSPFv3 Router with ID (1.1.1.1) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 14 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 3.3.3.3 LS Seq Number: 80000007 Checksum: 0x2001 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 3.3.3.3 Number of Prefixes: 1 Prefix Address: 2000:3333:: Prefix Length: 64, Options: None, Metric: 1 R1#   To force the router to set the metric of the LSA Type 9 to an unfinite metric we need to add the stub-prefix-lsa keyword as follow:   As a result the metric of the LSA Type 9 is now set to 65535 :   R3(config)#ipv6 router ospf 1 R3(config-rtr)#max-metric router-lsa ? external-lsa Override external-lsa metric with max-metric value inter-area-lsas Override inter-area-lsas metric with max-metric value on-startup Set maximum metric temporarily after reboot stub-prefix-lsa Set maximum metric for stub links in prefix LSAs

R3(config-rtr)#max-metric router-lsa stub-prefix-lsa R3(config-rtr)#

  R1#show ipv6 ospf database prefix adv-router 3.3.3.3 OSPFv3 Router with ID (1.1.1.1) (Process ID 1) Intra Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 109 LS Type: Intra-Area-Prefix-LSA Link State ID: 0 Advertising Router: 3.3.3.3 LS Seq Number: 80000006 Checksum: 0x1013 Length: 44 Referenced LSA Type: 2001 Referenced Link State ID: 0 Referenced Advertising Router: 3.3.3.3 Number of Prefixes: 1 Prefix Address: 2000:3333:: Prefix Length: 64, Options: None, Metric: 65535 R1#   The value of LSInfinity is defined in RFC 6987 for OSPF Stub Router Advertisement in the following section:   3. Maximum Link Metric   Section 2 refers to the cost of all non-stub links as MaxLinkMetric, which is a new fixed architectural value introduced in this document.   MaxLinkMetric The metric value indicating that a router-LSA link (see Section 2) should not be used for transit traffic. It is defined to be the 16-bit binary value of all ones: 0xffff.   Below the routing table of R1 and the metric now is 65536 (65535+1) to 2000:3333::/64 prefix:   R1#show ipv6 route ospf IPv6 Routing Table - default - 7 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP O 2000:3333::/64 [110/65536] via FE80::C803:1EFF:FEEC:1C, FastEthernet1/0 O 2023:23::/64 [110/2] via FE80::C802:10FF:FE4C:0, FastEthernet0/0 R1# R1#show ipv6 route 2000:3333::/64 Routing entry for 2000:3333::/64 Known via "ospf 1", distance 110, metric 65536, type intra area Route count is 1/1, share count 0 Routing paths: FE80::C803:1EFF:FEEC:1C, FastEthernet1/0 Last updated 00:16:08 ago R1#   To verify if the max-metric router-lsa is enabled, let's use the show ipv6 ospf command and notice the lines highlighted:  

R3#show ipv6 ospf Routing Process "ospfv3 1" with ID 3.3.3.3 Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic Originating router-LSAs with maximum metric Condition: always, State: active Advertise stub links with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Retransmission limit dc 24 non-dc 24 Number of external LSA 0. Checksum Sum 0x000000 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Graceful restart helper support enabled Reference bandwidth unit is 100 mbps RFC1583 compatibility enabled Area BACKBONE(0) Number of interfaces in this area is 3 SPF algorithm executed 12 times Number of LSA 15. Checksum Sum 0x05F749 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R3#                          

Lab 25: OSPF Link-State Database Overload Protection

Basic configuration of R1 and R2:   R1(config)#int fa0/0 R1(config-if)#ip add 10.0.12.1 255.255.255.252 R1(config-if)#ipv enable R1(config-if)#no shutdown R1(config-if)#ospfv3 1 ipv4 area 0 R1(config)#router ospfv3 1 R1(config-router)#address-family ipv4 unicast R1(config-router-af)#router-id 1.1.1.1   R2(config)#int fa0/0 R2(config-if)#ip add 10.0.12.2 255.255.255.252 R2(config-if)#ipv enable R2(config-if)#no shutdown R2(config-if)#ospfv3 1 ipv4 area 0 R2(config-if)#int lo1 R2(config-if)#ip add 2.2.2.1 255.255.255.255 R2(config-if)#ipv enable R2(config-if)#ospfv3 1 ipv4 area 1 R2(config-if)#int lo2 R2(config-if)#ip add 2.2.2.2 255.255.255.255 R2(config-if)#ipv enable R2(config-if)#ospfv3 1 ipv4 area 1 R2(config)#router ospfv3 1 R2(config-router)#address-family ipv4 unicast R2(config-router-af)#router-id 2.2.2.2   Verify the neighbor relationship:   R1#show ospfv3 neighbor OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Neighbor ID Pri State Dead Time Interface ID 2.2.2.2 1 FULL/DR 00:00:36 2 R1#   Verify the LSDB of R1: We can see that R2 sent 6 LSAs to R1:   1 Router LSA Type 1 1 Network LSA Type 2 (Because R2 is the DR) 2 Inter-Area Prefix LSAs Type 3 1 Link LSA Type 8

Interface FastEthernet0/0

1 Intra-Area LSA Type 9   Total of non self-generated LSAs is 6   R1#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 1.1.1.1 276 0x80000003 0 1 None 2.2.2.2 277 0x80000007 0 1 B Net Link States (Area 0) ADV Router Age Seq# Link ID Rtr count 2.2.2.2 281 0x80000001 2 2 Inter Area Prefix Link States (Area 0) ADV Router Age Seq# Prefix 2.2.2.2 336 0x80000001 2.2.2.1/32 2.2.2.2 336 0x80000001 2.2.2.2/32 Link (Type-8) Link States (Area 0) ADV Router Age Seq# Link ID Interface 1.1.1.1 276 0x80000002 2 Fa0/0 2.2.2.2 1412 0x80000001 2 Fa0/0 Intra Area Prefix Link States (Area 0) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 2.2.2.2 282 0x80000001 2048 0x2002 2 R1#   The show ospfv3 database database-summary command displays the total of LSAs installed in the LSDB which is 8 including the self-generated LSAs which is 2:   R1#show ospfv3 database database-summary OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Area 0 database summary LSA Type Count Delete Maxage Router 2 0 0 Network 1 0 0 Link 2 0 0 Prefix 1 0 0 Inter-area Prefix 2 0 0 Inter-area Router 0 0 0 Type-7 External 0 0 0 Unknown 0 0 0 Subtotal 8 0 0 Process 1 database summary LSA Type Count Delete Maxage Router 2 0 0 Network 1 0 0 Link 2 0 0 Prefix 1 0 0 Inter-area Prefix 2 0 0 Inter-area Router 0 0 0 Type-7 External 0 0 0 Unknown 0 0 0 Type-5 Ext 0 0 0 Unknown AS 0 0 0 Total 8 0 0 R1#  

Let's configure R1 to limit the number of non self-generated LSAs and if the threshold 50 percent of this number is reached, a warning message will be displayed:   R1(config-if)#router ospfv3 1 R1(config-router)#address-family ipv4 unicast R1(config-router-af)#max-lsa 14 50 warning-only   Let's advertise one Inter-Area Prefix LSA Type 3:   R2(config-if)#int lo3 R2(config-if)#ip add 2.2.2.3 255.255.255.255 R2(config-if)#ipv enable R2(config-if)#ospfv3 1 ipv4 area 1   We can see that R1 generates a warning message because the threshold of 7 non self-generated LSAs is reached:   R1# *Jul 7 03:35:12.211: %OSPFv3-4-MAX_LSA_THR: OSPFv3-1-IPv4 Threshold for maximum number of non self-generated LSA has been reached - 7 LSAs R1#   Let's verify the LSDB of R1, there are 7 LSAs sent by R2:   R1#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 1.1.1.1 432 0x80000003 0 1 None 2.2.2.2 438 0x80000003 0 1 B Net Link States (Area 0) ADV Router Age Seq# Link ID Rtr count 2.2.2.2 438 0x80000001 2 2 Inter Area Prefix Link States (Area 0) ADV Router Age Seq# Prefix 2.2.2.2 482 0x80000001 2.2.2.1/32 2.2.2.2 464 0x80000001 2.2.2.2/32 2.2.2.2 196 0x80000001 2.2.2.3/32 Link (Type-8) Link States (Area 0) ADV Router Age Seq# Link ID Interface 1.1.1.1 432 0x80000002 2 Fa0/0 2.2.2.2 556 0x80000001 2 Fa0/0 Intra Area Prefix Link States (Area 0) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 2.2.2.2 438 0x80000001 2048 0x2002 2 R1#   The total of LSAs installed in the LSDB is 9 = 7+2 as shown by the show ospfv3 database database-summary command:   R1#show ospfv3 database database-summary OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Area 0 database summary LSA Type Count Delete Maxage Router 2 0 0 Network 1 0 0 Link 2 0 0 Prefix 1 0 0

Inter-area Prefix 3 Inter-area Router 0 Type-7 External 0 Unknown 0 Subtotal 9 Process 1 database summary LSA Type Count Router 2 Network 1 Link 2 Prefix 1 Inter-area Prefix 3 Inter-area Router 0 Type-7 External 0 Unknown 0 Type-5 Ext 0 Unknown AS 0 Total 9 R1#

0 0 0 0 0

0 0 0 0 0

Delete 0 0 0 0 0 0 0 0 0 0 0

Maxage 0 0 0 0 0 0 0 0 0 0 0

  let's advertise 6 Inter-Area Prefix LSAs Type 3:   R2: int lo4 ip add 2.2.2.4 255.255.255.255 ipv enable ospfv3 1 ipv4 area 1 ! int lo5 ip add 2.2.2.5 255.255.255.255 ipv enable ospfv3 1 ipv4 area 1 ! int lo6 ip add 2.2.2.6 255.255.255.255 ipv enable ospfv3 1 ipv4 area 1 ! int lo7 ip add 2.2.2.7 255.255.255.255 ipv enable ospfv3 1 ipv4 area 1 ! int lo8 ip add 2.2.2.8 255.255.255.255 ipv enable ospfv3 1 ipv4 area 1 ! int lo9 ip add 2.2.2.9 255.255.255.255 ipv enable ospfv3 1 ipv4 area 1 ! int lo10 ip add 2.2.2.10 255.255.255.255 ipv enable ospfv3 1 ipv4 area 1 !

int lo11 ip add 2.2.2.11 255.255.255.255 ipv enable ospfv3 1 ipv4 area 1   R2 sent a total of 15 Inter-Area Prefix LSAs Type 3 and this number exceeds the maximum LSAs value allowed 14 and R1 displays a warning message as shown by the following output:   R1# *Jul 7 03:43:49.619: %OSPFv3-4-MAX_LSA_LIM: OSPFv3-1-IPv4 Maximum number of non self-generated LSA has been exceeded - 15 LSAs R1#   Verify the LSDB of R1, there are 15 LSAs with the Advertising Router 2.2.2.2 which is R2:   R1#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 1.1.1.1 825 0x80000003 0 1 None 2.2.2.2 831 0x80000003 0 1 B Net Link States (Area 0) ADV Router Age Seq# Link ID Rtr count 2.2.2.2 831 0x80000001 2 2 Inter Area Prefix Link States (Area 0) ADV Router Age Seq# Prefix 2.2.2.2 876 0x80000001 2.2.2.1/32 2.2.2.2 858 0x80000001 2.2.2.2/32 2.2.2.2 589 0x80000001 2.2.2.3/32 2.2.2.2 144 0x80000001 2.2.2.4/32 2.2.2.2 144 0x80000001 2.2.2.5/32 2.2.2.2 135 0x80000001 2.2.2.6/32 2.2.2.2 135 0x80000001 2.2.2.7/32 2.2.2.2 135 0x80000001 2.2.2.8/32 2.2.2.2 135 0x80000001 2.2.2.9/32 2.2.2.2 135 0x80000001 2.2.2.10/32 2.2.2.2 72 0x80000001 2.2.2.11/32 Link (Type-8) Link States (Area 0) ADV Router Age Seq# Link ID Interface 1.1.1.1 826 0x80000002 2 Fa0/0 2.2.2.2 950 0x80000001 2 Fa0/0 Intra Area Prefix Link States (Area 0) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 2.2.2.2 831 0x80000001 2048 0x2002 2 R1#   The total of LSAs installed in the LSDB is 17 =15+2 as shown by the show ospfv3 database database-summary command:   R1#show ospfv3 database database-summary OSPFv3 1 address-family ipv4 (router-id 1.1.1.1) Area 0 database summary LSA Type Count Delete Maxage Router 2 0 0 Network 1 0 0 Link 2 0 0 Prefix 1 0 0 Inter-area Prefix 11 0 0

Inter-area Router 0 Type-7 External 0 Unknown 0 Subtotal 17 Process 1 database summary LSA Type Count Router 2 Network 1 Link 2 Prefix 1 Inter-area Prefix 11 Inter-area Router 0 Type-7 External 0 Unknown 0 Type-5 Ext 0 Unknown AS 0 Total 17 R1#

0 0 0 0

0 0 0 0

Delete 0 0 0 0 0 0 0 0 0 0 0

Maxage 0 0 0 0 0 0 0 0 0 0 0

  Verify the routable table of R1:   R1#show ip route ospfv3 | beg Gate Gateway of last resort is not set 2.0.0.0/32 is subnetted, 11 subnets O IA 2.2.2.1 [110/1] via 10.0.12.2, 00:16:28, FastEthernet0/0 O IA 2.2.2.2 [110/1] via 10.0.12.2, 00:16:28, FastEthernet0/0 O IA 2.2.2.3 [110/1] via 10.0.12.2, 00:12:35, FastEthernet0/0 O IA 2.2.2.4 [110/1] via 10.0.12.2, 00:05:10, FastEthernet0/0 O IA 2.2.2.5 [110/1] via 10.0.12.2, 00:05:10, FastEthernet0/0 O IA 2.2.2.6 [110/1] via 10.0.12.2, 00:05:01, FastEthernet0/0 O IA 2.2.2.7 [110/1] via 10.0.12.2, 00:05:01, FastEthernet0/0 O IA 2.2.2.8 [110/1] via 10.0.12.2, 00:05:01, FastEthernet0/0 O IA 2.2.2.9 [110/1] via 10.0.12.2, 00:05:01, FastEthernet0/0 O IA 2.2.2.10 [110/1] via 10.0.12.2, 00:05:01, FastEthernet0/0 O IA 2.2.2.11 [110/1] via 10.0.12.2, 00:03:58, FastEthernet0/0 R1#   The show ospfv3 command is useful to verify the non self-generated LSAs:   R1#show ospfv3 OSPFv3 1 address-family ipv4 Router ID 1.1.1.1 Supports NSSA (compatible with RFC 3101) Maximum number of non self-generated LSA allowed 14 (warning-only) Current number of non self-generated LSA 15 Threshold for warning message 50% Event-log enabled, Maximum number of events: 1000, Mode: cyclic Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Retransmission limit dc 24 non-dc 24 Number of external LSA 0. Checksum Sum 0x000000

Number of areas in this router is 1. 1 normal 0 stub 0 nssa Graceful restart helper support enabled Reference bandwidth unit is 100 mbps RFC1583 compatibility enabled Area BACKBONE(0) Number of interfaces in this area is 1 SPF algorithm executed 2 times Number of LSA 17. Checksum Sum 0x0AE11F Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R1#                                                      

Lab 26: OSPF Refresh and Flooding Reduction in Stable Topologies    

  Basic configuration of all routers:  

R1: ipv uni ! interface Loopback0 ip address 1.1.1.1 255.255.255.0 ipv6 enable ospfv3 network point-to-point ospfv3 1 ipv4 area 0 ! interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 0 no shut ! router ospfv3 1 ! address-family ipv4 unicast router-id 0.0.0.1 exit-address-family   R2: ipv uni ! interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 0 no shut ! interface FastEthernet0/1 ip address 23.0.0.2 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 1 no shut ! router ospfv3 1 ! address-family ipv4 unicast router-id 0.0.0.2 area 1 nssa exit-address-family   R3: ipv uni ! interface Loopback0 ip address 3.3.3.3 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 1 ospfv3 network point-to-point ! interface FastEthernet0/0 ip address 23.0.0.3 255.255.255.0 ipv6 enable ospfv3 1 ipv4 area 1 no shut !

router ospfv3 1 ! address-family ipv4 unicast router-id 0.0.0.3 exit-address-family   By design, OSPF requires link-state advertisements (LSAs) to be refreshed as they expire after 3600 sec. When OSPF network is stable. The OSPF Flooding Reduction feature is used to reducing unnecessary refreshing and flooding of already known and unchanged information. To achieve this reduction, the LSAs are now flooded with the higher bit set called DNA bit, thus making them DoNotAge (DNA) LSAs. To suppress the unnecessary flooding of link-state advertisements (LSAs) in a stable topology we can use the following commands:   -With OSPFv2 use the ip ospf flood-reduction command. -With OSPFv3, use the ipv6 flood-reduction command. -With OSPFv3 AF, use the ospfv3 flood-reduction command.   RFC 2328 says on page 216 that OSPF LSAs age out after 60 minutes :   B. Architectural Constants   LSRefreshTime The maximum time between distinct originations of any particular LSA. If the LS age field of one of the router's self-originated LSAs reaches the value LSRefreshTime, a new instance of the LSA is originated, even though the contents of the LSA (apart from the LSA header) will be the same. The value of LSRefreshTime is set to 30 minutes. MaxAge The maximum age that an LSA can attain. When an LSA's LS age field reaches MaxAge, it is reflooded in an attempt to flush the LSA from the routing domain (See Section 14). LSAs of age MaxAge are not used in the routing table calculation. The value of MaxAge is set to 1 hour.   Therefore routers must refresh (flood) their LSAs every 30 minutes. This can create a fair amount of unnecessary traffic if the LSDB (Link State Database) has a large number of LSAs and is relatively stable. To mitigate the this behavior use the flood reduction feature.   The RFC 4136 explains the flood reduction feature, it allows the routers to flood their self-originated LSAs with the DoNotAge (DNA) bit set:   2. Changes in the Existing Implementation   This enhancement relies on the implementation of the DoNotAge bit and the Indication-LSA. The details of the implementation of the DoNotAge bit and the Indication-LSA are specified in "Extending OSPF to Support Demand Circuits" [2].   Flooding-reduction-capable routers will continue to send hellos to their neighbors and keep aging their self-originated LSAs in their database. However, these routers will flood their self-originated LSAs with the DoNotAge bit set. Thus, self-originated LSAs do not have to be re-flooded every 30 minutes and the re-flooding interval can be extended to the configured forced-flooding interval. As in normal OSPF operation, any change in the contents of the LSA will cause a reoriginated LSA to be flooded with the DoNotAge bit set. This will reduce protocol traffic overhead while allowing changes to be flooded immediately.  

Flooding-reduction-capable routers will flood received non-selforiginated LSAs with the DoNotAge bit set on all normal or floodingreduction-only interfaces within the LSA's flooding scope. If an interface is configured as both flooding-reduction-capable and Demand-Circuit, then the flooding is done if and only if the contents of the LSA have changed. This allows LSA flooding for unchanged LSAs to be periodically forced by the originating router.   Before configuring the flood reduction feature, let's look the LSDB of R1, each received LSA from the Advertising Router 0.0.0.2 which is R2 has a LSA Age value in seconds, in a stable topology they will be aged out in an hour (3600 seconds) if they are not refreshed (every 1800 seconds):   R1#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 0.0.0.1) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.1 123 0x80000002 0 1 None 0.0.0.2 92 0x80000002 0 1 B Net Link States (Area 0) ADV Router Age Seq# Link ID Rtr count 0.0.0.1 123 0x80000001 2 2 Inter Area Prefix Link States (Area 0) ADV Router Age Seq# Prefix 0.0.0.2 82 0x80000001 23.0.0.0/24 0.0.0.2 11 0x80000001 3.3.3.0/24 Link (Type-8) Link States (Area 0) ADV Router Age Seq# Link ID Interface 0.0.0.1 169 0x80000001 9 Lo0 0.0.0.1 191 0x80000001 2 Fa0/0 0.0.0.2 125 0x80000001 2 Fa0/0 Intra Area Prefix Link States (Area 0) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 0.0.0.1 123 0x80000004 0 0x2001 0 0.0.0.1 123 0x80000001 2048 0x2002 2 R1#   Let's configure the ospfv3 flood-reduction command R2's fa0/0 interface, it is required under interface:   R2(config-if)#int fa0/0 R2(config-if)#ospfv3 flood-reduction   Let's verify the LSDB of R1, we can see that R2 generates its LSAs with DNA bit set, then all LSAs received by R1 from R2 are now marked DNA (DoNotAge):   R1#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 0.0.0.1) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.1 2 0x80000003 0 1 None 0.0.0.2 1 (DNA) 0x80000003 0 1 B Net Link States (Area 0) ADV Router Age Seq# Link ID Rtr count 0.0.0.2 1 (DNA) 0x80000001 2 2 Inter Area Prefix Link States (Area 0) ADV Router Age Seq# Prefix 0.0.0.2 212 (DNA) 0x80000001 23.0.0.0/24 0.0.0.2 141 (DNA) 0x80000001 3.3.3.0/24 Link (Type-8) Link States (Area 0)

ADV Router 0.0.0.1 0.0.0.1 0.0.0.2 ADV Router 0.0.0.1 0.0.0.2 R1#

Age Seq# Link ID 8 0x80000001 9 3 0x80000002 2 255 (DNA) 0x80000001 2 Intra Area Prefix Link States (Area Age Seq# Link ID 2 0x80000005 0 1 (DNA) 0x80000001 2048

Interface Lo0 Fa0/0 Fa0/0 0) Ref-lstype 0x2001 0x2002

Ref-LSID 0 2

  The show ospfv3 interface fa0/0 command on R2 displays that this router is configured with the flood reduction feature and reduces the LSA flooding toward the neighbor R1:   R2#show ospfv3 interface fa0/0 FastEthernet0/0 is up, line protocol is up Link Local Address FE80::C802:3FF:FE38:8, Interface ID 2 Internet Address 12.0.0.2/24 Area 0, Process ID 1, Instance ID 64, Router ID 0.0.0.2 Network Type BROADCAST, Cost: 1 Reduce LSA flooding. Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 0.0.0.2, local address FE80::C802:3FF:FE38:8 Backup Designated router (ID) 0.0.0.1, local address FE80::C801:17FF:FE5C:8 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:02 Graceful restart helper support enabled Index 1/1/1, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 2, maximum is 3 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 0.0.0.1 (Backup Designated Router) Suppress hello for 0 neighbor(s) R2#   We have see that R2 sets the DNA bit in the LSAs self generated, what about the LSAs with different Advertising Router, such as LSA Type 5 and LSA Type 7?   Let's redistributes the loopback network as external on R3:   R3(config)#int lo0 R3(config-if)#no ospfv3 1 ipv4 area 1 R3(config)#route-map CONNECTED perm R3(config-route-map)#match interface lo0 R3(config-route-map)#router ospfv 1 R3(config-router)#address-family ipv4 unicast R3(config-router-af)#redistribute connected route-map CONNECTED   R2 receives the LSA Type 5 from R3 with Advertising Router 0.0.0.3:   R2#show ospfv3 database external OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 47 LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.3

LS Seq Number: 80000001 Checksum: 0x39A3 Length: 32 Prefix Address: 3.3.3.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R2#   As a result R2 creates an LSA Type 4 to tell R1 how to reach the ASBR R3:   R2#show ospfv3 database inter-area router OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Inter Area Router Link States (Area 0) LS age: 120 Options: (E-Bit, R-bit, DC-Bit, AF-Bit) LS Type: Inter Area Router Links Link State ID: 3 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0xDD20 Length: 32 Metric: 1 Destination Router ID: 0.0.0.3 R2#   Let's look the LSDB of R1, it receives both LSAs Type 4 and 5 with DNA bit set because R2 is configured with flood reduction feature:   R1#show ospfv3 database external OSPFv3 1 address-family ipv4 (router-id 0.0.0.1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 2 (DoNotAge) LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0x39A3 Length: 32 Prefix Address: 3.3.3.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 R1#   R1#show ospfv3 database inter-area router OSPFv3 1 address-family ipv4 (router-id 0.0.0.1) Inter Area Router Link States (Area 0) Routing Bit Set on this LSA LS age: 1 (DoNotAge) Options: (E-Bit, R-bit, DC-Bit, AF-Bit) LS Type: Inter Area Router Links Link State ID: 3 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0xDD20 Length: 32

Metric: 1 Destination Router ID: 0.0.0.3 R1#   Let's configure area 1 as NSSA:   R2(config)#router ospfv 1 R2(config-router)#address-family ipv4 unicast R2(config-router-af)#area 1 nssa   R3(config)#router ospfv 1 R3(config-router)#address-family ipv4 unicast R3(config-router-af)#area 1 nssa   R3 creates an LSA Type 7 and R2 translates this LSA Type 7 into an LSA Type 5, we can see the LSA Type 5 received by R1 from R2 with DNA bit set:   R1#show ospfv3 database external OSPFv3 1 address-family ipv4 (router-id 0.0.0.1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 1 (DoNotAge) LS Type: AS External Link Link State ID: 0 Advertising Router: 0.0.0.2 LS Seq Number: 80000001 Checksum: 0xF5BB Length: 48 Prefix Address: 3.3.3.0 Prefix Length: 24, Options: None Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 23.0.0.3 R1#   Another way to reduce flooding of unnecessary LSAs is the OSPF demand circuit options. The OSPF flooding reduction and demand circuit features us ethe same mechanism to eliminate the need for the periodic LSA refresh in other words they set the DNA bit. The main difference is that the OSPF demand circuit suppresses hellos while the OSPF flood reduction does not.   We can configure OSPF demand circuit using the ospfv3 1 ipv4 demand-circuit command for OSPFv3 AF under interface, let's configure this command on R1's fa0/0 interface:   R1(config)#int fa0/0 R1(config-if)#no ospfv3 flood-reduction R1(config-if)#ospfv3 1 ipv4 demand-circuit   Let's verify the LSDB of R2, notice the LSAs with Advertising Router 0.0.0.1 which is R1 have the DNA bit set:   R2#show ospfv3 database adv 0.0.0.1 OSPFv3 1 address-family ipv4 (router-id 0.0.0.2) Router Link States (Area 0) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.1 1 (DNA) 0x80000018 0 1 None Link (Type-8) Link States (Area 0) ADV Router Age Seq# Link ID Interface 0.0.0.1 1 (DNA) 0x80000010 2 Fa0/0

ADV Router 0.0.0.1 ADV Router R2#

Intra Area Prefix Link States (Area Age Seq# Link ID 1 (DNA) 0x80000013 0 Link (Type-8) Link States (Area 1) Age Seq# Link ID

0) Ref-lstype 0x2001

Ref-LSID 0

Interface

  Use the show ospfv3 interface fa0/0 command to verify the demand circuit configuration:   R1#show ospfv3 interface fa0/0 FastEthernet0/0 is up, line protocol is up Link Local Address FE80::C801:17FF:FE5C:8, Interface ID 2 Internet Address 12.0.0.1/24 Area 0, Process ID 1, Instance ID 64, Router ID 0.0.0.1 Network Type BROADCAST, Cost: 1 Configured as demand circuit. Run as demand circuit. DoNotAge LSA allowed. Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 0.0.0.1, local address FE80::C801:17FF:FE5C:8 Backup Designated router (ID) 0.0.0.2, local address FE80::C802:3FF:FE38:8 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:07 Graceful restart helper support enabled Index 1/2/2, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 0, maximum is 3 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 0.0.0.2 (Backup Designated Router) Suppress hello for 0 neighbor(s) R1#   By default, the device floods all outbound LSAs on all the OSPF interfaces within an area. You can configure a filter to block outbound LSAs on an OSPF interface. The ospfv3 database-filter feature is particularly useful when you want to block LSAs from some, but not all, of the interfaces attached to the area. When enabled, this command blocks the specified outgoing LSAs on the interface.   Before configuring this feature, let's verify the LSDB of R3, notice the LSAs with the Advertising Router 0.0.0.2 which is R2:   R3#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 0.0.0.3) Router Link States (Area 1) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.2 528 0x80000003 0 1 B 0.0.0.3 528 0x80000001 0 1 None Net Link States (Area 1) ADV Router Age Seq# Link ID Rtr count 0.0.0.2 528 0x80000001 3 2 Inter Area Prefix Link States (Area 1) ADV Router Age Seq# Prefix 0.0.0.2 594 0x80000001 12.0.0.0/24 0.0.0.2 134 0x80000003 1.1.1.0/24 Link (Type-8) Link States (Area 1) ADV Router Age Seq# Link ID Interface 0.0.0.3 517 0x80000001 9 Lo0 0.0.0.2 594 0x80000001 3 Fa0/0

0.0.0.3 ADV Router 0.0.0.2 0.0.0.3 R3#

528 0x80000001 2 Fa0/0 Intra Area Prefix Link States (Area 1) Age Seq# Link ID Ref-lstype Ref-LSID 528 0x80000001 3072 0x2002 3 517 0x80000001 0 0x2001 0

  To prevent the flooding of link-state advertisements (LSAs) on R2 to the the neighbor R3, use the ospfv3 database-filter all out command:   R2(config-if)#int fa0/1 R2(config-if)#ospfv3 database-filter all out   Let's verify the LSDB of R3, we can see that only the self-generated LSAs are displayed in the LSDB, all LSAs originated from R2 are filtered:   R3#show ospfv3 database OSPFv3 1 address-family ipv4 (router-id 0.0.0.3) Router Link States (Area 1) ADV Router Age Seq# Fragment ID Link count Bits 0.0.0.3 1 0x80000003 0 1 None Link (Type-8) Link States (Area 1) ADV Router Age Seq# Link ID Interface 0.0.0.3 7 0x80000001 9 Lo0 0.0.0.3 7 0x80000001 2 Fa0/0 Intra Area Prefix Link States (Area 1) ADV Router Age Seq# Link ID Ref-lstype Ref-LSID 0.0.0.3 1 0x80000002 0 0x2001 0 R3#   Since R3 does not have any LSA from the neighbor R2, there is no OSPF routes in its routing table:   R3#show ip route | beg Gate Gateway of last resort is not set 3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 3.3.3.0/24 is directly connected, Loopback0 L 3.3.3.3/32 is directly connected, Loopback0 23.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 23.0.0.0/24 is directly connected, FastEthernet0/0 L 23.0.0.3/32 is directly connected, FastEthernet0/0 R3#    

Lab 27: OSPF SPF Throttling  

  Basic configuration of all routers:   R1: interface Serial1/0 ip address 12.0.0.1 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut ! interface Loopback0 ip address 1.1.1.1 255.255.255.0 ip ospf 1 area 0 ip ospf cost 1 no shut ! router ospf 1 router-id 1.1.1.1   R2: interface Serial1/0 ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut ! interface Serial1/2 ip address 24.0.0.2 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut !

interface Serial1/1 ip address 23.0.0.2 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut ! router ospf 1 router-id 2.2.2.2   R3: interface Serial1/1 ip address 23.0.0.3 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut ! interface Serial1/0 ip address 34.0.0.3 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut ! router ospf 1 router-id 3.3.3.3   R4: interface Serial1/0 ip address 45.0.0.4 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut ! interface Serial1/2 ip address 24.0.0.4 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut ! interface Serial1/1 ip address 34.0.0.4 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut ! router ospf 1 router-id 4.4.4.4   R5: interface Serial1/0 ip address 45.0.0.5 255.255.255.0 ip ospf 1 area 0 ip ospf cost 64 no shut ! interface Loopback0 ip address 5.5.5.5 255.255.255.0 ip ospf 1 area 0 ip ospf cost 1

no shut ! router ospf 1 router-id 5.5.5.5   In OSPF, SPF is only run when certain conditions are met. One of those conditions is when a router originates a new Router Type 1 LSA or Network Type LSA. If a router interface goes down, it will originate a new LSA Type 1 to let other routers in the area know about it. How soon after the interface goes down does the type-1 get sent? Once another router in the area receives that LSA Type 1, does it run SPF straight away? Does it flood the LSA before or after it runs SPF? A temporarily routing loop form when router’s FIBs do not agree on where the best path is. Two routers will bounce a packet backwards and forwards to each other until those routers agree on the forwarding path and have that path installed in their FIB.   The best way to understand this is to show the routing loop forming.   Let’s consider the following topology of five routers. The OSPF costs of each link is also displayed, allt serial interfaces have a cost of 64, while R3-R4 link has a cost of 150.   Under normal circumstances, R1 prefers the path through R2-R4-R5 with a cost 193 to reach the loopback IP address 5.5.5.5 of R5 rather than the path through R2-R3-R4-R5 with a cost 343 as shown by the routing table of R1 and the traceroute output below and when the link between R2 and R4 fails, traffic should traverse the R2R3-R4 links:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 5.0.0.0/24 is subnetted, 1 subnets O 5.5.5.0 [110/193] via 12.0.0.2, 00:00:26, Serial1/0 23.0.0.0/24 is subnetted, 1 subnets O 23.0.0.0 [110/128] via 12.0.0.2, 00:03:38, Serial1/0 24.0.0.0/24 is subnetted, 1 subnets O 24.0.0.0 [110/128] via 12.0.0.2, 00:02:08, Serial1/0 34.0.0.0/24 is subnetted, 1 subnets O 34.0.0.0 [110/192] via 12.0.0.2, 00:01:48, Serial1/0 45.0.0.0/24 is subnetted, 1 subnets O 45.0.0.0 [110/192] via 12.0.0.2, 00:00:48, Serial1/0 R1#   R1#tracer 5.5.5.5 sou 1.1.1.1 Type escape sequence to abort. Tracing the route to 5.5.5.5 VRF info: (vrf in name/id, vrf out name/id) 1 12.0.0.2 84 msec 96 msec 68 msec 2 24.0.0.4 92 msec 84 msec 68 msec 3 45.0.0.5 352 msec 368 msec 332 msec R1#   OSPF Throttling feature allows to schedule SPF calculations in milliseconds interval and delay SPF calculations during network instability. SPF runs when there is a topology change. By default, SPF interval is chosen dynamically and depends on frequency of topology changes. SPF calculations occur at the interval set by the timers throttle spf command.   spf-start: Initial delay to schedule an SPF calculation after a topology change. Range is 1 to 600000 milliseconds. spf-hold: Minimum hold-time between two SPF calculations. Range is 1 to 600000 milliseconds. spf-max-wait: Maximum wait between two SPF calculations. Range is 1 to 600000 milliseconds.   The wait interval indicates the amount of time to wait until the next SPF calculation occurs. Each wait interval after that calculation is twice as long as the previous one until the wait interval reaches the maximum wait time specified.

  The SPF timing can be better explained using an example. "Timers throttle spf 5 1000 90000"   In this example the start interval is set at 5 milliseconds (ms), the wait interval at 1000 milliseconds, and the maximum wait time is set at 90,000 milliseconds.   The default values for SPF calculations can be seen below using the show ip ospf command: In this case when a router first detects topology change event, it will initiate SPF calculation after 5000msec. Meanwhile, if this router detects another topology change, it will wait for 10000msec (5000x2) before another SPF calculation. Once wait-interval reaches maximum wait-interval 10000msec, the wait-interval remains the same until topology stabilizes.   R3#show ip ospf Routing Process "ospf 1" with ID 3.3.3.3 Start time: 00:04:58.636, Time elapsed: 00:06:33.052 Supports only single TOS(TOS0) routes Supports opaque LSA Supports Link-local Signaling (LLS) Supports area transit capability Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Incremental-SPF disabled Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 0. Checksum Sum 0x000000 Number of opaque AS LSA 0. Checksum Sum 0x000000 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Number of areas transit capable is 0 External flood list length 0 IETF NSF helper support enabled Cisco NSF helper support enabled Reference bandwidth unit is 100 mbps Area BACKBONE(0) Number of interfaces in this area is 2 Area has no authentication SPF algorithm last executed 00:03:23.476 ago SPF algorithm executed 9 times Area ranges are Number of LSA 5. Checksum Sum 0x037920 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R3#   We can use the show ip ospf | i SPF command to filter the output of the show ip ospf command:   R3#show ip ospf | i SPF Initial SPF schedule delay 5000 msecs

Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Incremental-SPF disabled SPF algorithm last executed 00:06:28.424 ago SPF algorithm executed 9 times R3#   Let's verify the routing table of R3, the best path is through R2-R4 path and the tracerout output confirms the result:   R3#show ip route ospf | beg Gate Gateway of last resort is not set 1.0.0.0/24 is subnetted, 1 subnets O 1.1.1.0 [110/129] via 23.0.0.2, 00:01:59, Serial1/1 5.0.0.0/24 is subnetted, 1 subnets O 5.5.5.0 [110/193] via 23.0.0.2, 00:01:59, Serial1/1 12.0.0.0/24 is subnetted, 1 subnets O 12.0.0.0 [110/128] via 23.0.0.2, 00:01:59, Serial1/1 24.0.0.0/24 is subnetted, 1 subnets O 24.0.0.0 [110/128] via 23.0.0.2, 00:01:59, Serial1/1 45.0.0.0/24 is subnetted, 1 subnets O 45.0.0.0 [110/192] via 23.0.0.2, 00:01:59, Serial1/1 R3#   R3#tracer 5.5.5.5 Type escape sequence to abort. Tracing the route to 5.5.5.5 VRF info: (vrf in name/id, vrf out name/id) 1 23.0.0.2 156 msec 516 msec 200 msec 2 24.0.0.4 180 msec 132 msec 116 msec 3 45.0.0.5 156 msec 160 msec 128 msec R3#   In order to show how a routing loop is formed, we will first need to artificially increase the SPF timers. On R3 I’ll increase the wait time to run SPF after it receives an LSA to 40 seconds:   R3(config)#router ospf 1 R3(config-router)#timers throttle spf 40000 40000 40000   Now we disable the S1/2 interface of R2 in order to break the link between R2 and R4, a temporarily routing loop appears before reaching R5's loopback interface. At the same time we launch a traceroute command on R1:   We can see that a routing loop appear temporarily Because R3 is delaying it’s SPF run until 40 seconds after it receives a relevant LSA, it still assumes the best path is through R2. R2 has run it’s SPF and it assumes the best path is through R3. This is the reason the packet bounces between both routers. The packet get to it’s destination only when R3 has run SPF as shown by the last hop 45.0.0.5:   R1#tracer 5.5.5.5 sou 1.1.1.1 Type escape sequence to abort. Tracing the route to 5.5.5.5 VRF info: (vrf in name/id, vrf out name/id) 1 12.0.0.2 128 msec 160 msec 100 msec 2 * * 23.0.0.3 220 msec 3 23.0.0.2 136 msec 104 msec 84 msec 4 23.0.0.3 100 msec 104 msec 96 msec 5 23.0.0.2 112 msec 124 msec 376 msec

6 23.0.0.3 440 msec 404 msec 160 msec 7 23.0.0.2 164 msec 152 msec 232 msec 8 23.0.0.3 400 msec 572 msec 376 msec 9 23.0.0.2 424 msec 300 msec 312 msec 10 23.0.0.3 412 msec 356 msec 292 msec 11 23.0.0.2 388 msec 336 msec 520 msec 12 23.0.0.3 484 msec 396 msec 380 msec 13 23.0.0.2 368 msec 412 msec 376 msec 14 23.0.0.3 708 msec 396 msec 528 msec 15 23.0.0.2 560 msec 608 msec 492 msec 16 23.0.0.3 420 msec 312 msec 292 msec 17 23.0.0.2 264 msec 252 msec 348 msec 18 23.0.0.3 548 msec 484 msec 264 msec 19 23.0.0.2 248 msec 284 msec 348 msec 20 23.0.0.3 760 msec 268 msec 324 msec 21 23.0.0.2 616 msec 712 msec 260 msec 22 23.0.0.3 192 msec 188 msec 160 msec 23 23.0.0.2 264 msec 560 msec 392 msec 24 23.0.0.3 244 msec 208 msec 188 msec 25 23.0.0.2 204 msec 424 msec 376 msec 26 23.0.0.3 616 msec 672 msec 780 msec 27 23.0.0.2 844 msec 988 msec 984 msec 28 23.0.0.3 800 msec 668 msec 772 msec 29 23.0.0.2 1112 msec 45.0.0.5 576 msec 648 msec R1#   Verify the new SPF timers:   R3#show ip ospf Routing Process "ospf 1" with ID 3.3.3.3 Start time: 00:04:58.636, Time elapsed: 00:57:45.620 Supports only single TOS(TOS0) routes Supports opaque LSA Supports Link-local Signaling (LLS) Supports area transit capability Supports NSSA (compatible with RFC 3101) Event-log enabled, Maximum number of events: 1000, Mode: cyclic Router is not originating router-LSAs with maximum metric Initial SPF schedule delay 40000 msecs Minimum hold time between two consecutive SPFs 40000 msecs Maximum wait time between two consecutive SPFs 40000 msecs Incremental-SPF disabled Minimum LSA interval 5 secs Minimum LSA arrival 1000 msecs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 0. Checksum Sum 0x000000 Number of opaque AS LSA 0. Checksum Sum 0x000000 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Number of areas transit capable is 0 External flood list length 0 IETF NSF helper support enabled Cisco NSF helper support enabled Reference bandwidth unit is 100 mbps

Area BACKBONE(0) Number of interfaces in this area is 2 Area has no authentication SPF algorithm last executed 00:01:59.896 ago SPF algorithm executed 15 times Area ranges are Number of LSA 5. Checksum Sum 0x02F3C4 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R3#   R3#show ip ospf | incl SPF Initial SPF schedule delay 40000 msecs Minimum hold time between two consecutive SPFs 40000 msecs Maximum wait time between two consecutive SPFs 40000 msecs Incremental-SPF disabled SPF algorithm last executed 00:03:09.724 ago SPF algorithm executed 15 times R3#                                                                            

         

Lab 28: Inter-Area Summary route lowest cost and highest cost  

      Basic configuration of all routers:   R1: interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ip ospf 1 area 0 no shut ! interface FastEthernet0/1 ip address 13.0.0.1 255.255.255.0 ip ospf 1 area 0 no shut ! router ospf 1 router-id 0.0.0.1   R2: interface Loopback0 ip address 172.16.2.2 255.255.255.0 ip ospf network point-to-point ip ospf 1 area 1

! interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 0 no shut ! interface Serial1/0 ip address 24.0.0.2 255.255.255.0 ip ospf 1 area 1 no shut ! router ospf 1 router-id 0.0.0.2 area 1 range 172.16.0.0 255.255.0.0   R3: interface Loopback0 ip address 172.16.3.3 255.255.255.0 ip ospf network point-to-point ip ospf 1 area 1 ! interface FastEthernet0/0 ip address 13.0.0.3 255.255.255.0 ip ospf 1 area 0 no shut ! interface FastEthernet0/1 ip address 34.0.0.3 255.255.255.0 ip ospf 1 area 1 no shut ! router ospf 1 router-id 0.0.0.3 area 1 range 172.16.0.0 255.255.0.0   R4: interface Loopback0 ip address 172.16.4.4 255.255.255.0 ip ospf network point-to-point ip ospf 1 area 1 ! interface FastEthernet0/0 ip address 34.0.0.4 255.255.255.0 ip ospf 1 area 1 no shut ! interface Serial1/0 ip address 24.0.0.4 255.255.255.0 ip ospf 1 area 1 no shut ! router ospf 1 router-id 0.0.0.4   R2 and R3 are ABRs, and they are summarizing the networks 172.16.2.0/24, 172.16.3.0/24 and 172.16.4.0/24 into area 0 using the area 1 range 172.16.0.0 255.255.0.0 command.

Therefore both R2 and R3 advertise a summary route 172.16.0.0/16 for the network 172.16.2.0/24, 172.16.3.0/24 and 172.16.4.0/24:   The routing table below shown that R1 installing a load balancing for the summary route:   R1# show ip route ospf | beg Gate Gateway of last resort is not set 24.0.0.0/24 is subnetted, 1 subnets O IA 24.0.0.0 [110/65] via 12.0.0.2, 00:01:41, FastEthernet0/0 34.0.0.0/24 is subnetted, 1 subnets O IA 34.0.0.0 [110/2] via 13.0.0.3, 00:01:36, FastEthernet0/1 O IA 172.16.0.0/16 [110/2] via 13.0.0.3, 00:01:36, FastEthernet0/1 [110/2] via 12.0.0.2, 00:00:30, FastEthernet0/0 R1#   Let's verify the LSDB of R1, we can see below thatR1 is receiving two LSAs Type 3 for the summary route from R2 and R3, the metric listed in these LSA Type 3 is 1:   R1#show ip os data summ 172.16.0.0 OSPF Router with ID (0.0.0.1) (Process ID 1) Summary Net Link States (Area 0) Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 178 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 172.16.0.0 (summary Network Number) Advertising Router: 0.0.0.2 LS Seq Number: 80000003 Checksum: 0xFD7D Length: 28 Network Mask: /16 MTID: 0 Metric: 1 Routing Bit Set on this LSA in topology Base with MTID 0 LS age: 281 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 172.16.0.0 (summary Network Number) Advertising Router: 0.0.0.3 LS Seq Number: 80000001 Checksum: 0xFB80 Length: 28 Network Mask: /16 MTID: 0 Metric: 1 R1#   R1 looks the cost to reach the ABRs R2 and R3 as shown by show ip ospf border-routers command, the cost is 1 toward R2 and R3, therefore R1 adds this cost to the metric listed in the LSAs Type 3:

  to calculate the total cost to the summary route: 1+1=2.   R1#show ip ospf border-routers OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) Internal Router Routing Table Codes: i - Intra-area route, I - Inter-area route i 0.0.0.3 [1] via 13.0.0.3, FastEthernet0/1, ABR, Area 0, SPF 3 i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 3 R1#

  Another useful command to see all intra-area and inter-area routes/intra-area and inter-area routers is the show ip ospf route command which is hidden in IOS:   R1#show ip ospf route OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) Area BACKBONE(0) Intra-area Route List * 13.0.0.0/24, Intra, cost 1, area 0, Connected via 13.0.0.1, FastEthernet0/1 * 12.0.0.0/24, Intra, cost 1, area 0, Connected via 12.0.0.1, FastEthernet0/0 Intra-area Router Path List i 0.0.0.3 [1] via 13.0.0.3, FastEthernet0/1, ABR, Area 0, SPF 3 i 0.0.0.2 [1] via 12.0.0.2, FastEthernet0/0, ABR, Area 0, SPF 3 Inter-area Route List *> 172.16.0.0/16, Inter, cost 2, area 0 via 12.0.0.2, FastEthernet0/0 via 13.0.0.3, FastEthernet0/1 *> 24.0.0.0/24, Inter, cost 65, area 0 via 12.0.0.2, FastEthernet0/0 *> 34.0.0.0/24, Inter, cost 2, area 0 via 13.0.0.3, FastEthernet0/1 R1#   The show ip ospf command executed below on R2 and R3 shown that the cost of the summary route is 1, which is the same listed in the LSAs Type 3:   R2#show ip ospf | beg Area 1 Area 1 Number of interfaces in this area is 2 Area has no authentication SPF algorithm last executed 00:07:57.336 ago SPF algorithm executed 5 times Area ranges are 172.16.0.0/16 Active(1) Advertise Number of LSA 8. Checksum Sum 0x06DEB4 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 R2#   R3#show ip ospf | beg Area 1 Area 1 Number of interfaces in this area is 2 Area has no authentication SPF algorithm last executed 00:09:53.628 ago SPF algorithm executed 4 times Area ranges are 172.16.0.0/16 Active(1) Advertise Number of LSA 8. Checksum Sum 0x06DEB4 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0

Flood list length 0 R3#   Why the cost 1 of the summary route ?   -By default the routers implement the old RFC 1583, which means the cost of the summary route is the lowest metric of the summarized routes.   RFC 1583 says in Section 3.5:   The OSPF area concept is modelled after an IP subnetted network. OSPF areas have been loosely defined to be a collection of networks. In actuality, an OSPF area is specified to be a list of address ranges (see Section C.2 for more details). Each address range is defined as an [address,mask] pair. Many separate networks may then be contained in a single address range, just as a subnetted network is composed of many separate subnets. Area border routers then summarize the area contents (for distribution to the backbone) by advertising a single route for each address range. The cost of the route is the minimum cost to any of the networks falling in the specified range.   In this topology:   R2 has three intra-area routes toward: 1-172.16.3.0/24 with cost 66. 2-172.16.4.0/24 with cost 65. 3-172.16.2.0/24 with cost 1.   R2 has three intra-area routes toward: 1-172.16.3.0/24 with cost 1. 2-172.16.4.0/24 with cost 2. 3-172.16.2.0/24 with cost 66.   According to the RFC 1583, when an ABR summarizes intra-area routes with different cost, it selects the lowest cost for the summary route, as result:   R2 chooses the cost 1 for its summary route. R3 chooses the cost 1 for its summary route.   Cisco defines the no compatible rfc1583 command. The no compatible rfc1583 instructs the router to disable RFC 1583, and it activates the new RFC 2228, which means the cost of the summary route is the highest metric of the summarized routes.   RFC 2328 says in Section 3.5:   In order to get better aggregation at area boundaries, area address ranges can be employed (see Section C.2 for more details). Each address range is defined as an [address,mask] pair. Many separate networks may then be contained in a single address range, just as a subnetted network is composed of many separate subnets. Area border routers then summarize the area contents (for distribution to the backbone) by advertising a single route for each address range. The cost of the route is the maximum cost to any of the networks falling in the specified range.   Let's disable the RFC 1583 on R3, (in other words R3 will use the RFC 2328):   R3(config)#router ospf 1 R3(config-router)#no compatible rfc1583

  Let's kill the adjacencies:   R1#clear ip ospf process Reset ALL OSPF processes? [no]: y R1#   Now let's verify the routing table of R1, we can see that it installs the path through R2 to the summary route:   R1#show ip route osp | beg Gate Gateway of last resort is not set 24.0.0.0/24 is subnetted, 1 subnets O IA 24.0.0.0 [110/65] via 12.0.0.2, 00:01:06, FastEthernet0/0 34.0.0.0/24 is subnetted, 1 subnets O IA 34.0.0.0 [110/2] via 13.0.0.3, 00:01:06, FastEthernet0/1 O IA 172.16.0.0/16 [110/2] via 12.0.0.2, 00:00:07, FastEthernet0/0 R1#   Why?   The LSDB of R1 shown that R2 advertises a summary route (LSA Type 3) with a cost 1 while R3 advertises a summary route (LSA Type 3) with a cost 66:   R1#show ip os data su 172.16.0.0 | inc Metric|Router OSPF Router with ID (0.0.0.1) (Process ID 1) Advertising Router: 0.0.0.2 MTID: 0 Metric: 1 Advertising Router: 0.0.0.3 MTID: 0 Metric: 66 R1#   The traceroute below shown that R1 will go through R2-R4 to reach 172.16.3.3 and 172.16.4.4 causing a suboptimal routing, because RFC 1583 enabled on R2 uses the lowest summarized cost for the summary route, and the RFC 2328 enabled on R3 uses the highest summarized cost for the summary route.   R1# tracer 172.16.4.4 Type escape sequence to abort. Tracing the route to 172.16.4.4 VRF info: (vrf in name/id, vrf out name/id) 1 12.0.0.2 196 msec 524 msec 320 msec 2 24.0.0.4 372 msec 404 msec 332 msec R1#   R1# tracer 172.16.3.3 Type escape sequence to abort. Tracing the route to 172.16.3.3 VRF info: (vrf in name/id, vrf out name/id) 1 12.0.0.2 316 msec 56 msec 8 msec 2 24.0.0.4 652 msec 368 msec 316 msec 3 34.0.0.3 352 msec 364 msec 304 msec R1#   To solve this problem, disable RFC 1583 on R2 (in other words enable RFC 2328, and enable RFC 1583 on R3 (in other words disable RFC 2328): R2 will choose the highest cost 66 for the summary route because the RFC 2328 is enabled. R3 will choose the lowest cost 1 for the summary route because the RFC 1583 is enabled.   R2(config)#router ospf 1

R2(config-router)#no compatible rfc1583   R3(config)#router osp 1 R3(config-router)#compatible rfc1583   Let's verify the routing table of R1, now it installs the path through R3 to the summary route:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 24.0.0.0/24 is subnetted, 1 subnets O IA 24.0.0.0 [110/65] via 12.0.0.2, 00:07:13, FastEthernet0/0 34.0.0.0/24 is subnetted, 1 subnets O IA 34.0.0.0 [110/2] via 13.0.0.3, 00:07:13, FastEthernet0/1 O IA 172.16.0.0/16 [110/2] via 13.0.0.3, 00:00:18, FastEthernet0/1 R1#   The LSDB of R1 now shown that R1 receives an LSA Type 3 with cost 66 from R2 and an LSA Type 3 with cost 1 from R3:   R1#show ip os data su 172.16.0.0 | inc Metric|Router OSPF Router with ID (0.0.0.1) (Process ID 1) Advertising Router: 0.0.0.2 MTID: 0 Metric: 66 Advertising Router: 0.0.0.3 MTID: 0 Metric: 1 R1#   The traceroute executed on R1 shown that the packets now go through R3 to reach 172.16.3.3 and 172.16.4.4:   R1#tracer 172.16.4.4 Type escape sequence to abort. Tracing the route to 172.16.4.4 VRF info: (vrf in name/id, vrf out name/id) 1 13.0.0.3 324 msec 284 msec 160 msec 2 34.0.0.4 316 msec 356 msec 380 msec R1#   R1#tracer 172.16.3.3 Type escape sequence to abort. Tracing the route to 172.16.3.3 VRF info: (vrf in name/id, vrf out name/id) 1 13.0.0.3 80 msec 84 msec 72 msec R1#   But the problem of suboptimal routing remains for the network 172.16.2.0/24 connected to R2, since the network 172.16.2.0 is included in the area 1 range command on R2.   R1#tracer 172.16.2.2 Type escape sequence to abort. Tracing the route to 172.16.2.2 VRF info: (vrf in name/id, vrf out name/id) 1 13.0.0.3 72 msec 16 msec 84 msec 2 34.0.0.4 96 msec 100 msec 72 msec 3 24.0.0.2 96 msec 96 msec 100 msec R1#  

To solve this problem, leak the network 172.16.2.0/24 on R2 using the area 1 range 172.16.2.0 255.255.255.0 advertise command:   R2(config)#router ospf 1 R2(config-router)#area 1 range 172.16.2.0 255.255.255.0 advertise   Let's verify the routing table of R1, now it receives a summary route 172.16.0.0/24 through R3 and the specific route 172.16.2.0/24 through R2:   R1#show ip route ospf | beg Gate Gateway of last resort is not set 24.0.0.0/24 is subnetted, 1 subnets O IA 24.0.0.0 [110/65] via 12.0.0.2, 00:11:07, FastEthernet0/0 34.0.0.0/24 is subnetted, 1 subnets O IA 34.0.0.0 [110/2] via 13.0.0.3, 00:11:07, FastEthernet0/1 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks O IA 172.16.0.0/16 [110/2] via 13.0.0.3, 00:04:12, FastEthernet0/1 O IA 172.16.2.0/24 [110/2] via 12.0.0.2, 00:00:21, FastEthernet0/0 R1#   The traceroute command to 172.16.2.2 confirms the packets go through R2:   R1#tracer 172.16.2.2 Type escape sequence to abort. Tracing the route to 172.16.2.2 VRF info: (vrf in name/id, vrf out name/id) 1 12.0.0.2 84 msec 84 msec 92 msec R1#   Therefore in some topologies where we have several ABR routers, if we change one of these ABR to use the RFC 2328 with no compatiblerfc1583 command, it would automatically have a highest metric for the summary route than any other ABRs running RFC 1583, this can cause potential problem for the network.                                                    

Lab 29: OSPF Loop-Free Alternate LFA Fast Reroute FRR

  Basic configuration:   R1: interface FastEthernet0/0 ip address 12.0.0.1 255.255.255.0 ip ospf cost 6 ip ospf 1 area 0 no sh ! interface FastEthernet0/1 ip address 13.0.0.1 255.255.255.0 ip ospf cost 7 ip ospf 1 area 0 no sh ! interface FastEthernet1/0 ip address 14.0.0.1 255.255.255.0 ip ospf cost 8 ip ospf 1 area 0 no sh ! router ospf 1 router-id 0.0.0.1   R2: interface FastEthernet0/0 ip address 12.0.0.2 255.255.255.0 ip ospf cost 6 ip ospf 1 area 0 no sh ! interface FastEthernet0/1 ip address 25.0.0.2 255.255.255.0 ip ospf cost 6 ip ospf 1 area 1 no sh ! router ospf 1 router-id 0.0.0.2   R3:

interface FastEthernet0/0 ip address 13.0.0.3 255.255.255.0 ip ospf cost 7 ip ospf 1 area 0 no sh ! interface FastEthernet0/1 ip address 35.0.0.3 255.255.255.0 ip ospf cost 7 ip ospf 1 area 1 no sh ! router ospf 1 router-id 0.0.0.3   R4: interface FastEthernet0/0 ip address 14.0.0.4 255.255.255.0 ip ospf cost 8 ip ospf 1 area 0 no sh ! interface FastEthernet0/1 ip address 45.0.0.4 255.255.255.0 ip ospf cost 8 ip ospf 1 area 1 no sh ! router ospf 1 router-id 0.0.0.4   R5: interface Loopback0 ip address 5.5.5.5 255.255.255.0 ip ospf network point-to-point ip ospf 1 area 1 ! interface FastEthernet0/0 ip address 25.0.0.5 255.255.255.0 ip ospf cost 6 ip ospf 1 area 1 no sh ! interface FastEthernet0/1 ip address 35.0.0.5 255.255.255.0 ip ospf cost 7 ip ospf 1 area 1 no sh ! interface FastEthernet1/0 ip address 45.0.0.5 255.255.255.0 ip ospf cost 8 ip ospf 1 area 1 no sh ! router ospf 1 router-id 0.0.0.5  

Verify the routing table of R1 for the prefix 5.5.5.0/24. According to the configured cost, R1 is using R2 12.0.0.2 as the next hop.   R1#sh ip route 5.5.5.0 Routing entry for 5.5.5.0/24 Known via "ospf 1", distance 110, metric 13, type inter area Last update from 12.0.0.2 on GigabitEthernet1, 00:00:34 ago Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:00:34 ago, via GigabitEthernet1 Route metric is 13, traffic share count is 1 R1#   The OSPF RIB displays an inter-area route through R2 12.0.0.2, this is best path as shown by the Flags: RIB, the output also displays two possible paths to reach 5.5.5.0, via R3 and R4, these possible backup path are represented by a Type-3 LSAs originated by the ABRs R3 0.0.0.3 and R4 0.0.0.4.   R1#sh ip os rib 5.5.5.0 OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB LSA: type/LSID/originator *> 5.5.5.0/24, Inter, cost 13, area 0 SPF Instance 85, age 00:01:07 contributing LSA: 3/5.5.5.0/0.0.0.4 (area 0) contributing LSA: 3/5.5.5.0/0.0.0.3 (area 0) contributing LSA: 3/5.5.5.0/0.0.0.2 (area 0) Flags: RIB via 12.0.0.2, GigabitEthernet1 label 1048578 Flags: RIB LSA: 3/5.5.5.0/0.0.0.2 R1#   The next hop R2 12.0.0.2 is installed in the CEF forwarding table:   R1#sh ip cef 5.5.5.0 5.5.5.0/24 nexthop 12.0.0.2 GigabitEthernet1 R1#   At this level without LFA, if R2 fails, R1 will re-run SPF to calculate a new path, since the prefix 5.5.5.0/24 is learned from another area, R1 will run a partial SPF.   When a failure occurs in a routing protocol, there is a period of disruption to deliver a traffic until the routing protocol re-converges with new paths. Today, applications like voice and video are very sensitive to any traffic loss.   Traditionally, link state protocols such OSPF, even if OSPF routers have complete view of the topology, never calculated a backup route. With LFA, a router calculate a backup path that can be used to route traffic, in case of a failure of a directly connected link or node on primary path. LFA calculates a backup next-hop for every primary next-hop and programs Cisco Express Forwarding (CEF) table so that the router does re-run SPF.   To enable LFA, use the fast-reroute command, then the area we want to protect, area 0 in our case, next we have to configure the priority, there are two options; high and low. When we use the high priority, OSPF treats loopback and /32 prefixes with higher priority. When we choose the low priority, it just calculates an LFA for all prefixes.   R1(config)#router os 1 R1(config-router)#fast-reroute per-prefix enable area 0 prefix-priority low

R1(config-router)# *Dec 28 09:01:07.426: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh 13.0.0.3 proc:FRR, idb:GigabitEthernet2 handle:2 act   Verify that R1 selects R2 as the primary path and R3 as a backup path.   R1#sh ip route 5.5.5.0 Routing entry for 5.5.5.0/24 Known via "ospf 1", distance 110, metric 13, type inter area Last update from 12.0.0.2 on GigabitEthernet1, 00:04:16 ago Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:04:16 ago, via GigabitEthernet1 Route metric is 13, traffic share count is 1 Repair Path: 13.0.0.3, via GigabitEthernet2 R1#   Let’s verify the OSPF RIB table, the repair next hop via R3 13.0.0.3 is there as well.   R1#sh ip os rib 5.5.5.0 OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB LSA: type/LSID/originator *> 5.5.5.0/24, Inter, cost 13, area 0 SPF Instance 87, age 00:14:45 contributing LSA: 3/5.5.5.0/0.0.0.4 (area 0) contributing LSA: 3/5.5.5.0/0.0.0.3 (area 0) contributing LSA: 3/5.5.5.0/0.0.0.2 (area 0) Flags: RIB via 12.0.0.2, GigabitEthernet1 label 1048578 Flags: RIB LSA: 3/5.5.5.0/0.0.0.2 repair path via 13.0.0.3, GigabitEthernet2 label 1048578, cost 15 Flags: RIB, Repair, IntfDj, BcastDj, CostWon, NodeProt, Downstr LSA: 3/5.5.5.0/0.0.0.3 R1#   Now let's verify the forwarding table, as you can see, the entry for 5.5.5.0/24 is populated with a backup path with keyword "repair" through R3 13.0.0.3.   R1#sh ip cef 5.5.5.0 5.5.5.0/24 nexthop 12.0.0.2 GigabitEthernet1 repair: attached-nexthop 13.0.0.3 GigabitEthernet2 R1#   Let's configure the fast-reroute keep-all-paths command.   R1(config)#router os 1 R1(config-router)#fast-reroute keep-all-paths   Verify the routing table and the forwarding table, we have still R3 as the backup path.   R1#sh ip route 5.5.5.0 Routing entry for 5.5.5.0/24 Known via "ospf 1", distance 110, metric 13, type inter area Last update from 12.0.0.2 on GigabitEthernet1, 00:12:04 ago

Routing Descriptor Blocks: * 12.0.0.2, from 0.0.0.2, 00:12:04 ago, via GigabitEthernet1 Route metric is 13, traffic share count is 1 Repair Path: 13.0.0.3, via GigabitEthernet2 R1#   R1#sh ip cef 5.5.5.0 5.5.5.0/24 nexthop 12.0.0.2 GigabitEthernet1 repair: attached-nexthop 13.0.0.3 GigabitEthernet2 R1#   Let's verify the OSPF RIB table, there are the primary path via R2 12.0.0.2, the backup path via 13.0.0.3, and the ignored path through R4 14.0.0.4. The ignored path via R4 is displayed because fast-reroute keep-all-paths command.   R1#sh ip osp rib 5.5.5.0 OSPF Router with ID (0.0.0.1) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB LSA: type/LSID/originator *> 5.5.5.0/24, Inter, cost 13, area 0 SPF Instance 91, age 00:21:33 contributing LSA: 3/5.5.5.0/0.0.0.4 (area 0) contributing LSA: 3/5.5.5.0/0.0.0.3 (area 0) contributing LSA: 3/5.5.5.0/0.0.0.2 (area 0) Flags: RIB via 12.0.0.2, GigabitEthernet1 label 1048578 Flags: RIB LSA: 3/5.5.5.0/0.0.0.2 repair path via 13.0.0.3, GigabitEthernet2 label 1048578, cost 15 Flags: RIB, Repair, IntfDj, BcastDj, CostWon, NodeProt, Downstr LSA: 3/5.5.5.0/0.0.0.3 repair path via 14.0.0.4, GigabitEthernet3, cost 17 Flags: Ignore, Repair, IntfDj, BcastDj, NodeProt, Downstr LSA: 3/5.5.5.0/0.0.0.4 R1#   Let's test LFA backup path.   On R1 let's disable the interface connected to R2.   R1(config)#int g1 R1(config-if)#sh   Let's verify the routing table and forwarding table of R1. Now the backup path via R3 is installed as the best path and the route through R4 as a backup path.   R1#sh ip route 5.5.5.0 Routing entry for 5.5.5.0/24 Known via "ospf 1", distance 110, metric 15, type inter area Last update from 13.0.0.3 on GigabitEthernet2, 00:00:24 ago Routing Descriptor Blocks: * 13.0.0.3, from 0.0.0.3, 00:00:24 ago, via GigabitEthernet2 Route metric is 15, traffic share count is 1 Repair Path: 14.0.0.4, via GigabitEthernet3 R1#

  R1#sh ip cef 5.5.5.0 5.5.5.0/24 nexthop 13.0.0.3 GigabitEthernet2 repair: attached-nexthop 14.0.0.4 GigabitEthernet3 R1#                        

Lab 30: Capability Transit feature and routing loop      

    Basic Configuration:   R1: interface Loopback0 no shutdown ip address 1.1.1.1 255.255.255.0 ip ospf network point-to-point ip ospf 1 area 0 ! interface Ethernet0/0 no shutdown ip address 12.0.0.1 255.255.255.0 ip ospf 1 area 0 ! interface Ethernet0/1 no shutdown ip address 13.0.0.1 255.255.255.0 ip ospf 1 area 0 ! router ospf 1 router-id 0.0.0.1  

R2: interface Ethernet0/0 no shutdown ip address 12.0.0.2 255.255.255.0 ip ospf 1 area 0 ! interface Ethernet0/1 no shutdown ip address 24.0.0.2 255.255.255.0 ip ospf 1 area 1 ! router ospf 1 router-id 0.0.0.2   R3: interface Ethernet0/0 no shutdown ip address 13.0.0.3 255.255.255.0 ip ospf 1 area 0 ! interface Ethernet0/1 no shutdown ip address 35.0.0.3 255.255.255.0 ip ospf 1 area 1 ip ospf cost 100 ! router ospf 1 router-id 0.0.0.3   R4: interface Ethernet0/0 no shutdown ip address 46.0.0.4 255.255.255.0 ip ospf 1 area 2 ! interface Ethernet0/1 no shutdown ip address 24.0.0.4 255.255.255.0 ip ospf 1 area 1 ! interface Ethernet0/2 no shutdown ip address 45.0.0.4 255.255.255.0 ip ospf 1 area 1 ! router ospf 1 router-id 0.0.0.4   R5: interface Ethernet0/0 no shutdown no ip address shutdown ! interface Ethernet0/1 no shutdown ip address 35.0.0.5 255.255.255.0 ip ospf 1 area 1

ip ospf cost 100 ! interface Ethernet0/2 no shutdown ip address 45.0.0.5 255.255.255.0 ip ospf 1 area 1 ! router ospf 1 router-id 0.0.0.5   R6: interface Ethernet0/0 no shutdown ip address 46.0.0.6 255.255.255.0 ip ospf 1 area 2 ! router ospf 1 router-id 0.0.0.6   Verify the cost of the routers ‘ s interfaces, the cost of the link R3—R4 should be 100.   R1#sh ip os int br Interface PID Area IP Address/Mask Cost State Nbrs F/C Lo0 1 0 1.1.1.1/24 1 P2P 0/0 Et0/1 1 0 13.0.0.1/24 10 BDR 1/1 Et0/0 1 0 12.0.0.1/24 10 BDR 1/1 R1#   R2#sh ip os int br Interface PID Area IP Address/Mask Cost State Nbrs F/C Et0/0 1 0 12.0.0.2/24 10 DR 1/1 Et0/1 1 1 24.0.0.2/24 10 BDR 1/1 R2#   R3#sh ip os int br Interface PID Area IP Address/Mask Cost State Nbrs F/C Et0/0 1 0 13.0.0.3/24 10 DR 1/1 Et0/1 1 1 35.0.0.3/24 100 BDR 1/1 R3#   R4#sh ip os int br Interface PID Area IP Address/Mask Cost State Nbrs F/C Et0/2 1 1 45.0.0.4/24 10 BDR 1/1 Et0/1 1 1 24.0.0.4/24 10 DR 1/1 Et0/0 1 2 46.0.0.4/24 10 BDR 1/1 R4#   R5#sh ip os int br Interface PID Area IP Address/Mask Cost State Nbrs F/C Et0/2 1 1 45.0.0.5/24 10 DR 1/1 Et0/1 1 1 35.0.0.5/24 100 DR 1/1 R5#   R6#sh ip os int br Interface PID Area IP Address/Mask Cost State Nbrs F/C Et0/0 1 2 46.0.0.6/24 10 DR 1/1 R6#

  By definition on OSPF, Areas have to be connected to the backbone area but if they aren’t we can fix it with a virtual link.   Since area 2 is not connected to area 0, R6 has no knowledge of anything from area 0 and area 1 as shown by the routing table of R5 below.   R6#sh ip route os | beg Gate Gateway of last resort is not set R6#   Configure the virtual link between R3 and R4.   R3(config)#router os 1 R3(config-router)#area 1 virtual-link 0.0.0.4   R4(config)#router os 1 R4(config-router)#area 1 virtual-link 0.0.0.3   Use the show ip ospf virtual-links command to check if your virtual-link is working.   R3#sh ip os virtual-links Virtual Link OSPF_VL1 to router 0.0.0.4 is up Run as demand circuit DoNotAge LSA allowed. Transit area 1, via interface Ethernet0/1 Topology-MTID Cost Disabled Shutdown Topology Name 0 110 no no Base Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:02 Adjacency State FULL (Hello suppressed) Index 1/2/3, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec R3#   R4#sh ip os virtual-links Virtual Link OSPF_VL1 to router 0.0.0.3 is up Run as demand circuit DoNotAge LSA allowed. Transit area 1, via interface Ethernet0/2 Topology-MTID Cost Disabled Shutdown Topology Name 0 110 no no Base Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:03 Adjacency State FULL (Hello suppressed) Index 1/1/4, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec R4#   Now R6 learned all OSPF routes located in areas 0 and 1.   R6#sh ip route os | beg Gate

Gateway of last resort is not set 1.0.0.0/24 is subnetted, 1 subnets O IA 1.1.1.0 [110/31] via 46.0.0.4, 00:01:25, Ethernet0/0 12.0.0.0/24 is subnetted, 1 subnets O IA 12.0.0.0 [110/30] via 46.0.0.4, 00:01:25, Ethernet0/0 13.0.0.0/24 is subnetted, 1 subnets O IA 13.0.0.0 [110/40] via 46.0.0.4, 00:01:25, Ethernet0/0 24.0.0.0/24 is subnetted, 1 subnets O IA 24.0.0.0 [110/20] via 46.0.0.4, 00:02:04, Ethernet0/0 35.0.0.0/24 is subnetted, 1 subnets O IA 35.0.0.0 [110/120] via 46.0.0.4, 00:02:04, Ethernet0/0 45.0.0.0/24 is subnetted, 1 subnets O IA 45.0.0.0 [110/20] via 46.0.0.4, 00:02:04, Ethernet0/0 R6#   OSPF operates in a two level hierarchy;  backbone (Area 0) and non-backbone.  When a router in a nonbackbone area needs to communicate to a link in another non-backbone area in a normal design, the path should go via area 0 to reach the prefix.  As per the RFC 1583 which is the default RFC implemented by cisco routers and updated by RFC 2328, it states “The backbone is responsible for distributing routing information between non-backbone areas.” Furthermore, when routing between areas the RFC states “When routing a packet between two non-backbone areas the backbone is used”.   Per RFC 1583 section 1.3 The backbone of the Autonomous System   3.1. The backbone of the Autonomous System   The backbone is responsible for distributing routing information between areas. The backbone itself has all of the properties of an area. The topology of the backbone is invisible to each of the areas, while the backbone itself knows nothing of the topology of the areas.   Per RFC 2328 section 3.1 The Backbone of the Autonomous System   3.1. The backbone of the Autonomous System   The OSPF backbone is the special OSPF Area 0 (often written as Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP addresses). The OSPF backbone always contains all area border routers. The backbone is responsible for distributing routing information between non-backbone areas. The backbone must be contiguous. However, it need not be physically contiguous; backbone connectivity can be established/maintained through the configuration of virtual links.   Per RFC 1583 section 3.2 Inter-area routing   3.2. Inter-area routing   When routing a packet between two areas the backbone is used. The path that the packet will travel can be broken up into three contiguous pieces: an intra-area path from the source to an area border router, a backbone path between the source and destination areas, and then another intra-area path to the destination. The algorithm finds the set of such paths that have the smallest cost.   Per RFC 2328 section 3.2 Inter-area routing   3.2. Inter-area routing

  When routing a packet between two non-backbone areas the backbone is used. The path that the packet will travel can be broken up into three contiguous pieces: an intra-area path from the source to an area border router, a backbone path between the source and destination areas, and then another intra-area path to the destination. The algorithm finds the set of such paths that have the smallest cost.   In this design, this would mean then, that for R6 to reach 1.1.1.0/24, it should go through R4, then R4 should traverse the virtual-link to area 0 through R2 in order to reach the prefix 1.1.1.0/24. If we check this out, we can see that this is actually not the case as shown by the routing table of R4.   Verify the FIB of R4 for the entry 1.1.1.0/24 shown that the actual path is through R2. The reason why is because of a feature called “capability transit”, which is enabled by default in OSPFv2.   R4#sh ip route 1.1.1.0 Routing entry for 1.1.1.0/24 Known via "ospf 1", distance 110, metric 21, type intra area Last update from 24.0.0.2 on Ethernet0/1, 00:02:10 ago Routing Descriptor Blocks: * 24.0.0.2, from 0.0.0.1, 00:02:10 ago, via Ethernet0/1 Route metric is 21, traffic share count is 1 R4#   Verify the FIB of R5 for the entry 1.1.1.0/24 shown that the actual path is through R4. The reason why is because the total cost 31 to reach 1.1.1.0/24 through R4 is better than the total cost 111 through R3.   R5#sh ip route 1.1.1.0 Routing entry for 1.1.1.0/24 Known via "ospf 1", distance 110, metric 31, type inter area Last update from 45.0.0.4 on Ethernet0/2, 00:13:35 ago Routing Descriptor Blocks: * 45.0.0.4, from 0.0.0.2, 00:13:35 ago, via Ethernet0/2 Route metric is 31, traffic share count is 1 R5#   On R6 verify that the ping is successful to 1.1.1.1.   R6#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/5 ms R6#   Use the traceroute command on R6 to see the packets taken to reach 1.1.1.0/24 which is R4-R2-R1.   R6#tracer 1.1.1.1 Type escape sequence to abort. Tracing the route to 1.1.1.1 VRF info: (vrf in name/id, vrf out name/id) 1 46.0.0.4 1 msec 0 msec 0 msec 2 24.0.0.2 0 msec 1 msec 0 msec 3 12.0.0.1 0 msec 0 msec * R6#  

When we are using a virtual link , area 1 actually becomes a transit area for traffic passing from area 0 to area 2. When the “TransitCapability” is actually enabled (default setting in OSPFv2), the RFC specifically states: Per RFC 1583 section 6. The Area Data Structure   6. The Area Data Structure TransitCapability Set to TRUE if and only if there are one or more active virtual links using the area as a Transit area. Equivalently, this parameter indicates whether the area can carry data traffic that neither originates nor terminates in the area itself. This parameter is calculated when the area's shortest-path tree is built (see Section 16.1, and is used as an input to a subsequent step of the routing table build process (see Section 16.3).   Per RFC 2328 section 6. The Area Data Structure 6. The Area Data Structure TransitCapability This parameter indicates whether the area can carry data traffic that neither originates nor terminates in the area itself. This parameter is calculated when the area's shortest-path tree is built (see Section 16.1, where TransitCapability is set to TRUE if and only if there are one or more fully adjacent virtual links using the area as Transit area), and is used as an input to a subsequent step of the routing table build process (see Section 16.3). When an area's TransitCapability is set to TRUE, the area is said to be a "transit area".   “The OSPF Area Transit Capability feature provides an OSPF Area Border Router (ABR) with the ability to discover shorter paths through the transit area for forwarding traffic that would normally need to travel through the virtual-link path.” -Cisco   So to summarize what RFC 1583 and RFC 2328 state “When area border routers connecting to one or more transit areas (i.e, non-backbone areas whose TransitCapability is found to be TRUE), the transit areas’ summaryLSAs are examined to see whether better paths exist using the transit areas [vs the summary-LSAs advertised through the virtual-link from the backbone]”. In this example, what does this means, is that R4 discovers two paths to reach 1.1.1.0/24, one intra-area route through the transit area via R2 and one intra-area route through the virtual link (backbone area) via R5, since the capability transit is enabled on R4, this features causes R4 to select the best path based on the cost, in other words the path through the transit area (R2). If we disable the transit capability on R4, we now have to follow the normal procedure of routing inter-area traffic from non-backbone areas via area 0. So R4 MUST choose the best path to 1.1.1.0/64 via it’s virtual link to area 0 via R5, as opposed to the path towards R2 via area 1 even if the cost is higher. Verify that the capability transit is enabled on R4.   R4#sh ip os | s capa Supports area transit capability Number of areas transit capable is 1 This area has transit capability: Virtual Link Endpoint R4#   Let’s disable the capability transit feature on R4.  

R4(config)#router os 1 R4(config-router)#no capability transit   Verify that the feature is disabled.   R4#sh ip os | s capa Does not support area transit capability R4#   Since the TransitCapability is disabled, R4 can no longer choose the path via R2 to reach 1.1.1.0/24 because we have to follow the rule that states that if you are routing between areas, you must use area 0 for transit. The point is that we can no longer use the shorter via from R6–(area2)—>R4–(area1)—>R2–(area0)—R1 because the rules state that you must go through area 0 when routing between areas, in other words, R4 will go through the backbone area represented by the virtual link. The routing table of R4 shown that the path through R5 is chosen even if the cost is higher causing a rooting loop between R4 and R5.   R4#sh ip route 1.1.1.0 Routing entry for 1.1.1.0/24 Known via "ospf 1", distance 110, metric 121, type intra area Last update from 45.0.0.5 on Ethernet0/2, 00:00:57 ago Routing Descriptor Blocks: * 45.0.0.5, from 0.0.0.1, 00:00:57 ago, via Ethernet0/2 Route metric is 121, traffic share count is 1 R4#   Verify the routing table of R5, R4 points to R5 and R5 points to R4.   R5#sh ip route 1.1.1.0 Routing entry for 1.1.1.0/24 Known via "ospf 1", distance 110, metric 31, type inter area Last update from 45.0.0.4 on Ethernet0/2, 00:18:00 ago Routing Descriptor Blocks: * 45.0.0.4, from 0.0.0.2, 00:18:00 ago, via Ethernet0/2 Route metric is 31, traffic share count is 1 R5#   The ping fails from R6 to 1.1.1.1.   R6#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R6#   The traceroute from R6, you will see the packets loop between R4 and R5.   R6#tracer 1.1.1.1 Type escape sequence to abort. Tracing the route to 1.1.1.1 VRF info: (vrf in name/id, vrf out name/id) 1 46.0.0.4 4 msec 1 msec 0 msec 2 45.0.0.5 0 msec 5 msec 5 msec 3 45.0.0.4 5 msec 0 msec 0 msec 4 45.0.0.5 0 msec 1 msec 1 msec 5 45.0.0.4 0 msec 1 msec 0 msec 6 45.0.0.5 0 msec 1 msec 0 msec 7 45.0.0.4 0 msec 1 msec 0 msec

8 45.0.0.5 1 msec 0 msec 1 msec 9 45.0.0.4 0 msec 1 msec 0 msec 10 45.0.0.5 1 msec 1 msec 0 msec 11 45.0.0.4 1 msec 0 msec 0 msec 12 45.0.0.5 1 msec 1 msec 0 msec 13 45.0.0.4 1 msec 1 msec 0 msec 14 45.0.0.5 1 msec 1 msec 0 msec 15 45.0.0.4 1 msec 1 msec 0 msec 16 45.0.0.5 1 msec 1 msec 1 msec 17 45.0.0.4 0 msec 1 msec 0 msec 18 45.0.0.5 1 msec 5 msec 3 msec 19 45.0.0.4 5 msec 1 msec 1 msec 20 45.0.0.5 0 msec 1 msec 1 msec 21 45.0.0.4 1 msec 0 msec 1 msec 22 45.0.0.5 1 msec 1 msec 1 msec 23 45.0.0.4 1 msec 1 msec 1 msec 24 45.0.0.5 1 msec 1 msec 1 msec 25 45.0.0.4 1 msec 1 msec 1 msec 26 45.0.0.5 1 msec 5 msec 5 msec 27 45.0.0.4 5 msec 1 msec 1 msec 28 45.0.0.5 1 msec 1 msec 1 msec 29 45.0.0.4 0 msec 1 msec 0 msec 30 45.0.0.5 1 msec 6 msec 6 msec R6#   With transit capability enabled we can eliminate routing loops and also allowing the OSPF Area Border Router to install better cost routes to the backbone area through the transit area instead of the virtual links.                      

END