OSPF E2 and N2 routes

Hi guys!

it seems the OSPF story does not have any end! I have this topology in hand:

 

image

as you see, OSPF is activated on routers and we have 2 areas, area 0 and area 1. Area 1 is set to be an NSSA area, because I have two loopback interface on R6 that are redistributed into OSPF. also, you can see the routers R3 and R4 are inter-connected by 2 sub-interfaces in which Fa0/0.1234 on both of them are placed in area 0 and Fa0/0.3456 are put into area 1. 

now routing table on R5, as an internal router in NSSA area, have two "N2" routes:

 

R5(config-router)#do sh ip route  ospf

O N2    6.6.6.2 [110/20] via 100.1.56.6, 00:26:02, FastEthernet0/0

O N2    6.6.6.1 [110/20] via 100.1.56.6, 00:26:27, FastEthernet0/0

 

let's take a look at routing table on ABR routers, R3 and R4:

 

R3(config-router)#do sh ip route  ospf

O E2    6.6.6.2 [110/20] via 100.1.35.5, 00:26:53, FastEthernet0/1

O E2    6.6.6.1 [110/20] via 100.1.35.5, 00:27:17, FastEthernet0/1

----------------------------------------------------------------------

R4(config-if)#do sh ip route  ospf

O N2    6.6.6.2 [110/20] via 100.1.156.3, 00:13:20, FastEthernet0/0.3456

O N2    6.6.6.1 [110/20] via 100.1.156.3, 00:13:20, FastEthernet0/0.3456

 

As I know, Cisco routers prefer E2 over N2 routes, but in this case R3 and R4 receive both N2 and E2 routes. but why does R4 prefer N2 and R3 prefer E2? I test the DB and both of them have N2 routes inside their OSPF DB. besides, I test it on both IPv4 and IPv6 and the IOS that I'm using is C3725-ADVENTERPRISEK9-M), Version 12.4(15)T7. 

 

R3(config-router)#do sh ip ospf data 

                Type-7 AS External Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Tag

6.6.6.1         6.6.6.1         1045        0x80000001 0x006567 0

6.6.6.2         6.6.6.1         1015        0x80000001 0x005B70 0

 

details of NSSA routes on R3 shows that "Routing Bit Set on this LSA" is missing on the NSSA route on R3. but why?!

 

R3(config-router)#do sh ip ospf data nssa 6.6.6.1

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

                Type-7 AS External Link States (Area 1)

  LS age: 455

  Options: (No TOS-capability, Type 7/5 translation, DC)

  LS Type: AS External Link

  Link State ID: 6.6.6.1 (External Network Number )

  Advertising Router: 6.6.6.1

  Network Mask: /32

        Metric Type: 2 (Larger than any link state path)

        Metric: 20 

        Forward Address: 100.1.56.6

 

 

R3(config-router)#do sh ip ospf data ex 6.6.6.1  

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA

  LS age: 636


«1

Comments

  • JoeMJoeM ✭✭✭

    R3(config-router)#do sh ip ospf data ex 6.6.6.1  

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


                    Type-5 AS External Link States


      Routing Bit Set on this LSA

      LS age: 636

    What is the rest of this output?

    In which area is the connection between R3 and R4?

    edit:  I see it is in area 1

    Again, if you want to post the gns3 package (post a URL), we can play with your scenario and use your exact configurations.  Very helpful. Thanks.

     

  • Again, if you want to post the gns3 package (same way you are posting the image), we can play with your scenario and use your exact configurations.  Very helpful. Thanks.

    Hi; I uploaded the configs as a Zip file with the help of "Insert Media" buttom at the toolbar, but after clicking on the "post" buttom, the link does not appear on the page. instead, it appears while editting the post as "(View:/cfs-file.ashx/__key/CommunityServer.Components.UserFiles/00.00.00.49.26/ospf-01.zip)" text.

    anyway, can you build the topology? I have used very simple configs on routers with OSPFv2 and OSPFv3 everywhere, put the area 1 as NSSA and at the final, I redistributed the loopbacks of R6 into OSPF domain. 

    [View:/cfs-file.ashx/__key/CommunityServer.Components.UserFiles/00.00.00.49.26/ospf-01.zip]

     

    What is the rest of this output?

     

    R3(config-router)#do sh ip ospf data ex 6.6.6.1  

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

                    Type-5 AS External Link States

      Routing Bit Set on this LSA

      Options: (No TOS-capability, DC)

      LS Type: AS External Link

      Link State ID: 6.6.6.1 (External Network Number )

      Advertising Router: 4.4.4.1

      Network Mask: /32

            Metric Type: 2 (Larger than any link state path)

            TOS: 0 

            Metric: 20 

            Forward Address: 100.1.56.6

            External Route Tag: 0

     

     

  • JoeMJoeM ✭✭✭

    edit: I see that you edited your last post.  Thanks for attempting to post the zipped file.  Don't post it as media.  You just need to post a direct url. I will take a look at this later. Thanks again for trying to upload this. ;-)

     

    Maybe you are not understanding.   I am asking for a zipped GNS3 package. Less than the size of the image being posted.

    You ask for a lot of help with your studies, and I do like your scenarios.    It would be easier to TS your questions if you would just post the gns3 topologies -- especially since you have them built already.

    Just a kind request.  I have an idea of the answer to your question, but want to TS this myself to be sure of what I am saying. 

    Thanks Timaz.

  • JoeMJoeM ✭✭✭

    Got your zip, but it is just config text.  But I still have to rebuild your topology.

    http:://ieoc.com/cfs-file.ashx/__key/CommunityServer.Components.UserFiles/00.00.00.49.26/ospf-01.zip

     

    Post a zip that has your already built topology along with the config folder.   This makes it a lot easier.  Thanks again.

  • JoeMJoeM ✭✭✭

    Thanks for posting this.  This is what I wanted to verify.

    R3 is getting the E2 from R4 (which is doing the 7/5 translation). 

    The routing bit is set because the local SPF calculation will be made on this entry. 

    EDIT: in your first post,  you say that R4 is also receiving both LSA's (E2 and N2). Double-check this.


    R3(config-router)#do sh ip ospf data ex 6.6.6.1  


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




                    Type-5 AS External Link States




      Routing Bit Set on this LSA




      Options: (No TOS-capability, DC)




      LS Type: AS External Link




      Link State ID: 6.6.6.1 (External Network Number )




      Advertising Router: 4.4.4.1




      Network Mask: /32




            Metric Type: 2 (Larger than any link state path)




            TOS: 0 




            Metric: 20 




            Forward Address: 100.1.56.6




            External Route Tag: 0



     

     

  • Thanks for posting this.  This is what I wanted to verify.

    R3 is getting the E2 from R4 (which is doing the 7/5 translation). 

    The routing bit is set because the calculation will be made on this entry. 

     

    I would like to thank you for your replies; you're sooo "hyper-active" man [;)]

    with regards to the scenario, why does R3 accept an E2 while there is an ASBR inside the same area that R3 is and generates N2? isn't it strange?

  • JoeMJoeM ✭✭✭

    I would like to thank you for your replies; you're sooo "hyper-active" man Wink

    with regards to the scenario, why does R3 accept an E2 while there is an ASBR inside the same area that R3 is and generates N2? isn't it strange?

    I just woke up in the middle of the night (3:30am).  Not "hyper-active" at all right now.  I just like to do good jobs -- not give half answers with only half information.    The better description is persistent and complete.   ;-)

     

    Take a look at R4 and post the same ospf database output that you did for R3.  I don't want to rebuild your gns3 topology.  Going back to sleep.  ;-)

     

  • JoeMJoeM ✭✭✭

    with regards to the scenario, why does R3 accept an E2 while there is an ASBR inside the same area that R3 is and generates N2? isn't it strange?

    Half asleep.  I did not answer this.  ;-)

    As you noted in your first post, E2 over N2.  R3 has feet in both areas (0 and 1) and gets both LSA's. It chooses E2 because it has the same forwarding metric as the N2 entry.

    What I think is important is the forwarding-address in the LSA that makes R3 point out the correct interface with the same metric.

    Also, your scenario is the result of having two ABR's.   There are are some additional things you can do with this scenario.  For example, reverse the situation between R3 and R4......or change the metric on the E2 LSA (make it higher).

     

    Maybe there is an expert with a better answer or more information on how this works.  That is my simple nutshell answer. ;-)

  • As you noted in your first post, E2 over N2.  R3 has feet in both areas (0 and 1) and gets both LSA's. It chooses E2 because it has the same forwarding metric as the N2 entry.

     

    Hi; yes I know and you're right when you are saying R3 forwards traffic to the "forwarder address". for example if I suppress the L7 to L5 translation, I can affect the path selection and make R3 to redirect traffic destined to R6's loopback toward R4 through its direct fa0/0.1234 interface. but what is strange for me is that why R3 chooses E2 over N2 while redistributing router resides inside the NSSA area, and why does R4 chooses the N2 over E2?

    maybe this scenario seems to be simple, but believe me or not, I have not faced with such a position in my studies yet!!

  • JoeMJoeM ✭✭✭

    As you noted in your first
    post, E2 over N2.  R3 has feet in both areas (0 and 1) and gets both
    LSA's. It chooses E2 because it has the same forwarding metric as the N2 entry.

    Think metric vs area:

    1. If the metrics are the same, then E2 over N2 (or E1 over N1).   
    2. If the metric is higher on the E2, than N2

    EDIT:  this is corrected later in the thread. rfc3101 vs rfc1587(old)

     

    if I had your gns3 topology, I would lab this myself and give examples.  Did you get a chance to look at the R4 output (database)?

     

  • Think metric vs area:

    1. If the metrics are the same, then E2 over N2 (or E1 over N1).   
    2. If the metric is higher on the E2, than N2

     

    Hi; are you sure about these? if these are right, this is my first time hearing those during whole of my networking career. 

  • JoeMJoeM ✭✭✭

    Hi; are you sure about these? if these are right, this is my first time hearing those during whole of my networking career. 

    Timaz,  I keep asking you to give us the GNS3 topologies for your mini-labs.  If you would do that, then I will use the extra-lab-building-time to instead show the examples/proof.   But until then, you will need to do the labbing. Right now, your posting are of a back-n-forth of requesting output from you.

    No offense intended, because I really like the scenarios that you keep creating in these mini-labs.  I enjoy that style of practice and proving concepts.   But I am not building these topologies that you have already built.  I have already done this for a few of your previous gns3 labs.

    Play with your setup.  If I am wrong, show me.  I would much rather be wrong here on the forum, than in the lab.  ;-)

  • Timaz,  I keep asking you to give us the GNS3 topologies for your mini-labs.  If you would do that, then I will use the extra-lab-building-time to instead show the examples/proof.

     

    Hi JoeM. how r u man? excuse me if I disturb you last night [:P]

    anyway, this is the link for this topic. if you face with an error let me know, so I can send the link to your email. http://1drv.ms/1LQ5eVS

  • I labbed the E2 vs N2 case up with the Anycast Address 66.66.66.66 on R6 (E2) and R10 (N2) and here is the order:

    (i) Metric is compared. Lower metric wins

    R5(config-subif)#do sh ip route 66.66.66.66
    Routing entry for 66.66.66.66/32
     Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 12
     * 155.1.58.8, from 150.1.10.10, 00:00:04 ago, via GigabitEthernet1.58
         Route metric is 20, traffic share count is 1

    Changing the metric to 19 on R6 (E2) 

    R5(config-subif)#do sh ip route 66.66.66.66
    Routing entry for 66.66.66.66/32
     Known via "ospf 1", distance 110, metric 19, type extern 2, forward metric 12
     * 155.1.45.4, from 150.1.11.11, 00:00:06 ago, via GigabitEthernet1.45
         Route metric is 19, traffic share count is 1

    (ii) If the metric is the same we take the forward metric into account. Lower metric wins

    R5(config-subif)#do sh ip route 66.66.66.66
    Routing entry for 66.66.66.66/32
     Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 12
         Route metric is 20, traffic share count is 1

    Increasing the forward metric of N2 to 13

    R5(config-subif)#ip ospf cost 11

    R5(config-subif)#do sh ip route 66.66.66.66
    Routing entry for 66.66.66.66/32
     Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 12
     * 155.1.45.4, from 150.1.11.11, 00:00:14 ago, via GigabitEthernet1.45
         Route metric is 20, traffic share count is 1 
     
     (iii) If metric and forwarding metric is the same N2 wins over E2

    R5(config-subif)#ip ospf cost 10

    Changing forwarding metric to 12 for E2 and N2

    R5(config-subif)#do sh ip route 66.66.66.66
    Routing entry for 66.66.66.66/32
    Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 12
     * 155.1.58.8, from 150.1.10.10, 00:00:30 ago, via GigabitEthernet1.58
        Route metric is 20, traffic share count is 1

     

    *EDIT*

    For the sake of completeness I tested the case E1 vs N1 as well. It works as expected

    E1 will win even with a worse metric:

    R5(config-subif)#do sh ip route 66.66.66.66
    Routing entry for 66.66.66.66/32
     Known via "ospf 1", distance 110, metric 32, type extern 1
     * 155.1.45.4, from 150.1.11.11, 00:00:48 ago, via GigabitEthernet1.45
         Route metric is 32, traffic share count is 1

    R5(config-subif)#ip ospf cost 2000

    R5(config-subif)#do sh ip route 66.66.66.66
    Routing entry for 66.66.66.66/32
     Known via "ospf 1", distance 110, metric 1022, type extern 1
     * 155.1.0.1, from 150.1.11.11, 00:00:02 ago, via Tunnel0
         Route metric is 1022, traffic share count is 1

  • JoeMJoeM ✭✭✭

    Hi Timaz,

    No problem. Thanks for the topology. I had to finally upgrade my gns3 for the new format, but I have your topology up now.

    I notice that F0/0 (r3-r4)is split into two sub-interfaces (area 0 and area 1).

     

    I have a question about your topology.  Are all of your interfaces up (R4-R6)?    I am asking, because although it does not change the E2/N2 selection, I saw the forwarding address change to the r4/r6 connection.  BUT again this doesn't change the E2/N2 question.

     But here is the output example that I saw change.

    Original forwarding address (with r4/r6 down):

    R3#do sh ip ospf data nssa 6.6.6.1
                OSPF Router with ID (3.3.3.1) (Process ID 1)
                    Type-7 AS External Link States (Area 1)
      LS age: 455
      Options: (No TOS-capability, Type 7/5 translation, DC)
      LS Type: AS External Link
      Link State ID: 6.6.6.1 (External Network Number )
      Advertising Router: 6.6.6.1
      Network Mask: /32
            Metric Type: 2 (Larger than any link state path)
            Metric: 20
            Forward Address: 100.1.56.6 <-- r4/46 serial down

     

    New forwarding address  (with r4/r6 serial up):

    R3#sh ip ospf data nssa 6.6.6.1
                OSPF Router with ID (3.3.3.1) (Process ID 1)
                    Type-7 AS External Link States (Area 1)
      LS age: 734
      Options: (No TOS-capability, Type 7/5 translation, DC)
      LS Type: AS External Link
      Link State ID: 6.6.6.1 (External Network Number )
      Advertising Router: 6.6.6.2
      LS Seq Number: 80000006
      Checksum: 0xD2FD
      Length: 36
      Network Mask: /32
            Metric Type: 2 (Larger than any link state path)
            TOS: 0
            Metric: 20
            Forward Address: 100.1.46.6 <-- r4/r6 up (no change to E2/N2 select

     

    R3#sh ip route 6.6.6.1
    Routing entry for 6.6.6.1/32
      Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 74
      Last update from 100.1.156.4 on FastEthernet0/0.3456, 00:51:25 ago
      Routing Descriptor Blocks:
      * 100.1.156.4, from 4.4.4.1, 00:51:25 ago, via FastEthernet0/0.3456
          Route metric is 20, traffic share count is 1

     

    I will post anything new that I find.

  • Hi,

    I labbed this up and got a different result.

     

    R3 sees the E2 route from R4 because R4 wins the LSA Type7-5 Translator election due to higher Router ID. R4 obviously also see its generated Type 5 LSA in its database.

     

    R3#sh ip ospf database external 6.6.6.1

     

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

                    Type-5 AS External Link States

     

      LS age: 191
     Options: (No TOS-capability, DC, Upward)
     LS Type: AS External Link
     Link State ID: 6.6.6.1 (External Network Number )
     Advertising Router: 155.1.24.4
     LS Seq Number: 80000001
     Checksum: 0xAE4B
     Length: 36
     Network Mask: /32
           Metric Type: 2 (Larger than any link state path)
           MTID: 0
            Metric: 20
            Forward Address: 155.1.56.6
           External Route Tag: 0


    Other than that R3 also sees an N2 route

    R3#sh ip ospf database nssa-external 6.6.6.1

                OSPF Router with ID (155.1.13.3) (Process ID 1)
                   Type-7 AS External Link States (Area 1)

      LS age: 418
     Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
     LS Type: AS External Link
     Link State ID: 6.6.6.1 (External Network Number )
     Advertising Router: 155.1.46.6
     LS Seq Number: 80000001
     Checksum: 0x7364
     Length: 36
     Network Mask: /32
           Metric Type: 2 (Larger than any link state path)
           MTID: 0
            Metric: 20
            Forward Address: 155.1.56.6
           External Route Tag: 0N2 route in its database:

    The metric is 20 for the E2 and N2 route. The forward metric is equals as well. In this case N2 wins over E2 and this explains why we see N2 in the RIB for R3 and R4. I tested this behavior on CSR 1000v running 15.4(2)S2.

    R3#sh ip route 6.6.6.1
    Routing entry for 6.6.6.1/32
     Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 2
     Last update from 155.1.35.5 on GigabitEthernet1.35, 00:09:30 ago
     Routing Descriptor Blocks:
     * 155.1.35.5, from 155.1.46.6, 00:09:30 ago, via GigabitEthernet1.35
         Route metric is 20, traffic share count is 1

    R4#sh ip route 6.6.6.1
    Routing entry for 6.6.6.1/32
     Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 2
     Last update from 155.1.46.6 on GigabitEthernet1.46, 00:10:11 ago
     Routing Descriptor Blocks:
     * 155.1.46.6, from 155.1.46.6, 00:10:11 ago, via GigabitEthernet1.46
         Route metric is 20, traffic share count is 1

    I think the outcome of this test depends on the NSSA implementation. RFC 1587 is considered obsolete now and is superseded by RFC 3101. 

    https://supportforums.cisco.com/discussion/11634576/ospf-e2-vs-n2

    Chances are the old code 12.4T is still running 1587. In this case E2 was considered better than N2 which would explain what you are seeing.

     

    Florian

  • JoeMJoeM ✭✭✭

    I think the outcome of this test depends on the NSSA implementation. RFC 1587 is considered obsolete now and is superseded by RFC 3101. 

     

    https://supportforums.cisco.com/discussion/11634576/ospf-e2-vs-n2

     

    Chances are the old code 12.4T is still running 1587. In this case E2 was considered better than N2 which would explain what you are seeing.

    Hi florian,

    This is interesting.   He is using the 3725 image with 12.4.  I didn't think this would be a problem, so I have been working with this.

     

    I have been using the SPF debug to see the calculations.   debug ip ospf spf external

    I will save off the output from this 3725 image and switch over to a 15.x image.

     

    Thanks for the post.

  • JoeMJoeM ✭✭✭

    Timaz,  I did a script while playing with your topology.  Below I changed the image to a 7200 (15.x). 

    There is a big difference in the outcome.  The rules that I stated above were for 12.4.   This was corrected in a later version

                       Big Thanks to Florian for saving me from spending more time on this.

     

    Hopefully this output is easy to read.  Note the red highlights for the selection.   At the bottom I show a snippet of the 12.4 debug

     

    I have scripted this below, in case you want to lab it yourself.  Good practice with the debug for spf calculations.

    ----------------------------------------------------------------------------------------------

    !!!!  SHUT R3/R4 CONNECTION (F0/0 DOWN) -- less LSA's in debug
    !!!!  SHUT R6-Lo2 --  only watch one external route (debug is less messy)

    !!!!  REMOVE R4 FROM AREA 1 -- only type-7 to R3
    !!!!  SHUT R6-Lo1 .... 6.6.6.1 has not been added yet.
    !!!!  CLEAR ospf process (R3)
    !!!! begin with clean database

     

    DEBUG IP OSPF SPF EXTERNAL

    SHOW IP ROUTE 6.6.6.1
    % Network not in table


    !!! START:UNSHUT R6's loop1 (remember R4 is removed from Area 1)

    OSPF-1 SPF  : Schedule partial SPF type 7, LSID 6.6.6.1, adv_rtr 6.6.6.2 area 1
    OSPF-1 SPF  : Service partial SPF, spf instance 51, 0/0/1
    OSPF-1 INTER: Process partial summary spf queue
    OSPF-1 EXTER: Process partial external spf queue
    OSPF-1 EXTER: Process partial nssa spf queue
    OSPF-1 EXTER: Process partial spfQ: type 7, LSID 6.6.6.1, mask 255.255.255.255, adv_rtr 6.6.6.2, age 2, seq 0x80000001, area 1
    OSPF-1 EXTER: Start partial processing Type 7 External LSA 6.6.6.1, mask 255.255.255.255
    OSPF-1 EXTER:  adv_rtr 6.6.6.2, age 2, seq 0x80000001, metric 20, metric-type 2, fw-addr 100.1.56.6
    OSPF-1 EXTER: Add forward address reachable 100.1.56.6, allowed types Intra, to watched queue
    OSPF-1 SPF  :    Add better path to LSA ID 6.6.6.1, gateway 100.1.35.5, dist 20
    OSPF-1 SPF  :    Add path: next-hop 100.1.35.5, interface FastEthernet0/1
    OSPF-1 EXTER: Route update succeeded for 6.6.6.1/255.255.255.255, next-hop FastEthernet0/1/100.1.35.5


    R3#SHOW IP ROUTE 6.6.6.1
    Routing entry for 6.6.6.1/32
      Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 2
      Last update from 100.1.35.5 on FastEthernet0/1, 00:03:53 ago
      Routing Descriptor Blocks:
      * 100.1.35.5, from 6.6.6.2, 00:03:53 ago, via FastEthernet0/1
          Route metric is 20, traffic share count is 1

     


    R3#!!! FUN BEGINS:  Bring up R4/R6 connection. R4 joins Area 1.

    OSPF-1 MON  : Schedule Full SPF in area 0, change in LSID 4.4.4.1, LSA type R

    OSPF-1 MON  : Schedule Full SPF in area 1, change in LSID 4.4.4.1, LSA type R
    OSPF-1 MON  : Schedule Full SPF in area 1, change in LSID 6.6.6.2, LSA type R

    OSPF-1 MON  : Schedule Prefix Recalculation SPF in area 0, change in LSID 4.4.4.1, LSA type X
    OSPF-1 MON  : Schedule Prefix Recalculation SPF in area 0, change in LSID 4.4.4.1, LSA type SN
    OSPF-1 EXTER: Started Building Type 5 External Routes
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Start processing Type 7 External LSA 6.6.6.1, mask 255.255.255.255
    OSPF-1 EXTER:  adv_rtr 6.6.6.2, age 330, seq 0x80000001, metric 20, metric-type 2, fw-addr 100.1.56.6
    OSPF-1 EXTER: Add forward address reachable 100.1.56.6, allowed types Intra, to watched queue

    OSPF-1 SPF  :    Add better path to LSA ID 6.6.6.1, gateway 100.1.35.5, dist 20
    OSPF-1 SPF  :    Add path: next-hop 100.1.35.5, interface FastEthernet0/1
    OSPF-1 EXTER: Route update succeeded for 6.6.6.1/255.255.255.255, next-hop FastEthernet0/1/100.1.35.5
    OSPF-1 EXTER: Entered External route sync for area dummy area
    OSPF-1 EXTER: Entered External route sync for area dummy area
    OSPF-1 EXTER: Entered NSSA route sync for area 0
    OSPF-1 EXTER: Entered NSSA route sync for area 0
    OSPF-1 EXTER: Entered NSSA route sync for area 1
    OSPF-1 EXTER: Entered NSSA route sync for area 1
    OSPF-1 MON  : Schedule Full SPF in area 1, change in LSID 4.4.4.1, LSA type R

    OSPF-1 SPF  : Detect change in LSA type 7, LSID 6.6.6.1 from 6.6.6.2 area 1
    OSPF-1 SPF  : Do not schedule partial SPF type 7, LSID 6.6.6.1, adv_rtr 6.6.6.2, area 1: INTRA/INTER spf scheduled

    OSPF-1 MON  : Schedule Prefix Recalculation SPF in area 1, change in LSID 4.4.4.1, LSA type X
    OSPF-1 MON  : Schedule Prefix Recalculation SPF in area 1, change in LSID 4.4.4.1, LSA type SN
    OSPF-1 EXTER: Started Building Type 5 External Routes
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Start processing Type 7 External LSA 6.6.6.1, mask 255.255.255.255
    OSPF-1 EXTER:  adv_rtr 6.6.6.2, age 4, seq 0x80000002, metric 20, metric-type 2, fw-addr 100.1.46.6
    OSPF-1 EXTER: Add forward address reachable 100.1.46.6, allowed types Intra, to watched queue
    OSPF-1 SPF  :    Add better path to LSA ID 6.6.6.1, gateway 100.1.35.5, dist 20
    OSPF-1 SPF  :    Add path: next-hop 100.1.35.5, interface FastEthernet0/1
    OSPF-1 EXTER: Route update succeeded for 6.6.6.1/255.255.255.255, next-hop FastEthernet0/1/100.1.35.5
    OSPF-1 EXTER: Entered External route sync for area dummy area

    OSPF-1 EXTER: Entered Externalroute sync for area dummy area
    OSPF-1 EXTER: Entered NSSA route sync for area 0
    OSPF-1 EXTER: Entered NSSA route sync for area 0
    OSPF-1 EXTER: Entered NSSA route sync for area 1
    OSPF-1 EXTER: Entered NSSA route sync for area 1
    OSPF-1 SPF  : Service partial SPF, spf instance 54, 2/0/0
    OSPF-1 INTER: Process partial summary spf queue
    OSPF-1 EXTER: Process partial external spf queue
    OSPF-1 EXTER: Process partial nssa spf queue
    OSPF-1 SPF  : Service partial SPF, spf instance 55, 1/0/0
    OSPF-1 INTER: Process partial summary spf queue
    OSPF-1 EXTER: Process partial external spf queue
    OSPF-1 EXTER: Process partial nssa spf queue
    OSPF-1 SPF  : Schedule partial SPF type 5, LSID 6.6.6.1, adv_rtr 4.4.4.1 area dummy area
    OSPF-1 SPF  : Service partial SPF, spf instance 56, 0/1/0
    OSPF-1 INTER: Process partial summary spf queue
    OSPF-1 EXTER: Process partial external spf queue
    OSPF-1 EXTER: Process partial spfQ: type 5, LSID 6.6.6.1, mask 255.255.255.255, adv_rtr 4.4.4.1, age 3, s
                  eq 0x80000001, area dummy area
    OSPF-1 EXTER: Start partial processing Type 5 External LSA 6.6.6.1, mask 255.255.255.255
    OSPF-1 EXTER:  adv_rtr 3.3.3.1, age 334, seq 0x80000001, metric 20, metric-type 2, fw-addr 100.1.56.6
    OSPF-1 EXTER: Start partial processing Type 5 External LSA 6.6.6.1, mask 255.255.255.255
    OSPF-1 EXTER:  adv_rtr 4.4.4.1, age 3, seq 0x80000001, metric 20, metric-type 2, fw-addr 100.1.46.6
    OSPF-1 EXTER:    Route to forwarding address is through NSSA area
    OSPF-1 EXTER: Add forward address unreachable 100.1.46.6, allowed types Inter, to watched queue
    OSPF-1 EXTER: Start partial processing Type 7 External LSA 6.6.6.1, mask 255.255.255.255
    OSPF-1 EXTER:  adv_rtr 6.6.6.2, age 5, seq 0x80000002, metric 20, metric-type 2, fw-addr 100.1.46.6
    OSPF-1 SPF  :    Add better path to LSA ID 6.6.6.1, gateway 100.1.35.5, dist 20
    OSPF-1 SPF  :    Add path: next-hop 100.1.35.5, interface FastEthernet0/1
    OSPF-1 EXTER: Route update succeeded for 6.6.6.1/255.255.255.255,
                  next-hop FastEthernet0/1/100.1.35.5

    OSPF-1 EXTER: Process partial nssa spf queue
    OSPF-1 EXTER: Started Building Type 5 External Routes
    OSPF-1 EXTER: Start processing Type 5 External LSA 6.6.6.1, mask 255.255.255.255
    OSPF-1 EXTER:  adv_rtr 4.4.4.1, age 7, seq 0x80000001, metric 20, metric-type 2, fw-addr 100.1.46.6
    OSPF-1 EXTER:    Route to forwarding address is through NSSA area
    OSPF-1 EXTER: Add forward address unreachable 100.1.46.6, allowed types Inter, to watched queue

    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Start processing Type 7 External LSA 6.6.6.1, mask 255.255.255.255
    OSPF-1 EXTER:  adv_rtr 6.6.6.2, age 9, seq 0x80000002, metric 20, metric-type 2, fw-addr 100.1.46.6
    OSPF-1 EXTER: Add forward address reachable 100.1.46.6, allowed types Intra, to watched queue
    OSPF-1 SPF  :    Add better path to LSA ID 6.6.6.1, gateway 100.1.35.5, dist 20
    OSPF-1 SPF  :    Add path: next-hop 100.1.35.5, interface FastEthernet0/1
    OSPF-1 EXTER: Route update succeeded for 6.6.6.1/255.255.255.255, next-hop FastEthernet0/1/100.1.35.5
    OSPF-1 EXTER: Entered External route sync for area dummy area
    OSPF-1 EXTER: Entered External route sync for area dummy area
    OSPF-1 EXTER: Entered NSSA route sync for area 0
    OSPF-1 EXTER: Entered NSSA route sync for area 0
    OSPF-1 EXTER: Entered NSSA route sync for area 1
    OSPF-1 EXTER: Entered NSSA route sync for area 1

    R3#SH IP ROUTE 6.6.6.1
    Routing entry for 6.6.6.1/32
      Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 66
      Last update from 100.1.35.5 on FastEthernet0/1, 00:19:03 ago
      Routing Descriptor Blocks:
      * 100.1.35.5, from 6.6.6.2, 00:19:03 ago, via FastEthernet0/1
          Route metric is 20, traffic share count is 1

     

    =================================================

    Note one big difference in the debug from IOS 12.4 (3725) -- look at the reason(s) between the two.

    OSPF: Start partial processing Type 5 External LSA 6.6.6.1, mask 255.255.255.255, adv 4.4.4.4, age 3, seq 0x80000001, metric 20, metric-type 2
       Add better path to LSA ID 6.6.6.1, gateway 100.1.35.5, dist 20
       Add path: next-hop 100.1.35.5, interface FastEthernet0/1
     network update dest_addr 6.6.6.1 mask 255.255.255.255 gateway 100.1.35.5

       Add External Route to 6.6.6.1. Metric: 20, Next Hop: 100.1.35.5
    OSPF: insert route list LS ID 6.6.6.1, type 5, adv rtr 4.4.4.4
    OSPF: Start partial processing Type 7 External LSA 6.6.6.1, mask 255.255.255.255, adv 6.6.6.6, age 13, seq 0x80000002, metric 20, metric-type 2
    OSPF: Type 5 route exist
    OSPF: delete lsa id 6.6.6.1, type 7, adv rtr 6.6.6.6 from delete list
    OSPF process partial spfQ entry

     

    =======================

    Here is a link to the updated GNS topology (using 7200-ios15.x)

     

     

  • Hi everybody,

    if i can give my little contribution to the conversation, i would add that by deactivating or activating the command "compatible rfc 1587" under the ospf router configuration mode it is possible to conditionate the behaviour changed by RFC3101, thus making the router capable to prefer the E2 routes over N2. So you could just play a little bit with that command to modify the default behaviour. I think that they added that option maybe for backward compatibility with previous versions.

     

  • quoting you "As I know, Cisco routers prefer E2 over N2 routes, but in this case R3 and R4 receive both N2 and E2 routes. but why does R4 prefer N2 and R3 prefer E2? "

    this is a wrong statement, ospf does a best metric check against e2 and n2 routes and e2 is not automatically preferred over n2

    1) e2 or n2 route with best metric wins
    2) if both e2 and n2 have same metric then e2 or n2 route with best forward metric wins (metric to the asbr)
    3) if both e2 and n2 have same metric and same forward metric then n2 wins because it has the p-bit set

    also the routing bit being set or not varies from code to code

    your e2/n2 route favours n2 because one of those 3 checks were violated

  • timaztimaz ✭✭

    I would say read RFC3103 but I hate reading RFCs, so always looking for good summary: 

    1. N1 & E1 are preferred over N2 & E2 for the same route

    2. When N1 & E1 have the same route to the destination, The one that have lower cost/Metric will win and get into the route table


    3. If both N1 & E1 have the same cost, P-bit in N1 will be used to break the tie.

    4. If P-bit is 0 (Then it would become E1) then we will have 2 E1 routes install into
    the routing table. (otherwise if maximum-path = 1, LSA with Higher Router-ID will get installed)


    from https://learningnetwork.cisco.com/thread/6038?start=0&tstart=0

    Edit: and senatoredu has good point.

     

    Hi again. following the replies of both of you (Martinl and senatoredu) I built the following lab to test it. 

     

    image

    in this lab I redistributed some routes into OSPFv3 domain on R4 and set the area 1 to act like Totally NSSA. then examined the OSPF DB and routing table on R5. this router has interfaces in both of the areas (0 and 1) and then its DB should dontain Type 7 and Type 5. this is confirmation:

     

    R5(config-if)#do sh ipv6 ospf data ex 2000:1:1:8::1/128  

                OSPFv3 Router with ID (5.5.5.5) (Process ID 1)

                    Type-5 AS External Link States

      Routing Bit Set on this LSA

      LS Type: AS External Link

      Advertising Router: 4.4.4.5

      Prefix Address: 2000:1:1:8::1

      Prefix Length: 128, Options: None

      Metric Type: 2 (Larger than any link state path)

      Metric: 20 

     

    R5(config-if)#do sh ipv6 ospf data nssa 2000:1:1:8::1/128

                OSPFv3 Router with ID (5.5.5.5) (Process ID 1)

                    Type-7 AS External Link States (Area 1)

      LS Type: AS External Link

      Advertising Router: 4.4.4.5

      Prefix Address: 2000:1:1:8::1

      Prefix Length: 128, Options: None

      Metric Type: 2 (Larger than any link state path)

      Metric: 20 

      Forward Address: 2000:1:1:45::4


    but routing table on R5 just shows the N2 route as it advertised by router R4 (4.4.4.5) and received by the F0/0 interface which is in the area 1. I expected that E2 should be preferred over N2 but based on what you said, it preferred N2. so the reason must be the metric here. both routes (E2 and N2) has equal metrics (20 by default). but regarding to the overall metric from R5 toward to the ASBR, the metric from R5 toward R4 through Area 1 (our NSSA area) is less than the metric to R4 through area 0. and this makes the N2 route preferred path. while I increased the OSPFv3 cost on F0/0 of R5, this time R5 selected the area 0 and E2 route as best path. this proves your ideas ;)

    .

    .

    .

    .

    .







    R5(config-if)#do sh ipv6 route ospf


    ON2 2000:1:1:8::1/128 [110/20]

         via 2000:1:1:45::4, FastEthernet0/0

    ON2 2000:1:1:8::2/128 [110/20]

         via 2000:1:1:45::4, FastEthernet0/0

    .

    .





    increasing the OSPF cost on F0/0 of R5:

    .

    .




    R5(config)#inter f0/0

    R5(config-if)#ospfv3 cost 1000

    !

    !

    R5(config-if)#do sh ipv6 route ospf


    OE2 2000:1:1:8::1/128 [110/20]

         via FE80::C806:CFF:FEEC:8, Serial1/1

    OE2 2000:1:1:8::2/128 [110/20]

         via FE80::C806:CFF:FEEC:8, Serial1/1


  • JoeMJoeM ✭✭✭

    ....but regarding to the overall metric from R5 toward to the ASBR, the metric from R5 toward R4 through Area 1 (our NSSA area) is less than the metric to R4 through area 0. and this makes the N2 route preferred path. while I increased the OSPFv3 cost on F0/0 of R5, this time R5 selected the area 0 and E2 route as best path. this proves your ideas ;)


    increasing the OSPF cost on F0/0 of R5:






    R5(config)#inter f0/0




    R5(config-if)#ospfv3 cost 1000



    ...




    R5(config-if)#do sh ipv6 route ospf





    OE2 2000:1:1:8::1/128 [110/20]

         via FE80::C806:CFF:FEEC:8, Serial1/1

    OE2 2000:1:1:8::2/128 [110/20]

         via FE80::C806:CFF:FEEC:8, Serial1/1


    Timaz,  are you still using IOS 12.4 ?  Remember the RFC changes.

    I built a mini 3 router lab and redistributed the loopback on the ASBR.  The result is always N1/N2 now, and the reason is the same as in the previous output.  
       forwarding address is through an NSSA area = forward address unreachable

     

    NOTE: since i needed to rebuild this lab, I kept it simple and stayed with IPv4 (7200 15.2).  ;-)

    Partial output here, when adding 1000 cost to the direct link towards ASBR.


    OSPF-1 MON  : Schedule Prefix Recalculation SPF in area 1, change in LSID 2.2.2.2, LSA type SN
    OSPF-1 EXTER: Started Building Type 5 External Routes
    OSPF-1 EXTER: Start processing Type 5 External LSA 3.3.3.0, mask 255.255.255.0
    OSPF-1 EXTER:  adv_rtr 2.2.2.2, age 9, seq 0x80000001, metric 20, metric-type 2, fw-addr 23.23.23.3
    OSPF-1 EXTER:    Route to forwarding address is through NSSA area
    OSPF-1 EXTER: Add forward address unreachable 23.23.23.3, allowed types Inter, to watched queue
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Start processing Type 7 External LSA 3.3.3.0, mask 255.255.255.0
    OSPF-1 EXTER:  adv_rtr 3.3.3.3, age 11, seq 0x8000000A, metric 20, metric-type 2, fw-addr 23.23.23.3
    OSPF-1 EXTER: Add forward address reachable 23.23.23.3, allowed types Intra, to watched queue

     

    NOTE that it does not even care about the huge difference in the forward metric.

    R1(config-if)#do sh ip route 3.3.3.3
    Routing entry for 3.3.3.0/24
      Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 1064
      Last update from 13.13.13.3 on Serial1/1, 00:04:07 ago
      Routing Descriptor Blocks:
      * 13.13.13.3, from 3.3.3.3, 00:04:07 ago, via Serial1/1
          Route metric is 20, traffic share count is 1

     

     

    As PGallo posted earlier, we can use the backwards compatible option -- and the change is immediate (although it still uses the longer but direct leg for some reason)

    R1(config-router)#compatible rfc1587

    OSPF-1 EXTER: Started Building Type 5 External Routes
    OSPF-1 EXTER: Start processing Type 5 External LSA 3.3.3.0, mask 255.255.255.0
    OSPF-1 EXTER:  adv_rtr 2.2.2.2, age 637, seq 0x80000001, metric 20, metric-type 2, fw-addr 23.23.23.3
    OSPF-1 EXTER: Add forward address reachable 23.23.23.3, allowed types Intra and Inter, to watched queue
    OSPF-1 SPF  :    Add better path to LSA ID 3.3.3.0, gateway 13.13.13.3, dist 20
    OSPF-1 SPF  :    Add path: next-hop 13.13.13.3, interface Serial1/1
    OSPF-1 EXTER: Route update succeeded for 3.3.3.0/255.255.255.0, next-hop Serial1/1/13.13.13.3
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Start processing Type 7 External LSA 3.3.3.0, mask 255.255.255.0
    OSPF-1 EXTER:  adv_rtr 3.3.3.3, age 638, seq 0x8000000A, metric 20, metric-type 2, fw-addr 23.23.23.3
    OSPF-1 EXTER: Add forward address reachable 23.23.23.3, allowed types Intra, to watched queue

     

    Routing entry for 3.3.3.0/24
      Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1064
      Last update from 13.13.13.3 on Serial1/1, 00:01:39 ago
      Routing Descriptor Blocks:
      * 13.13.13.3, from 2.2.2.2, 00:01:39 ago, via Serial1/1
          Route metric is 20, traffic share count is 1

     

  • timaztimaz ✭✭

    Timaz,  are you still using IOS 12.4 ?  Remember the RFC changes.

     

    Hi; Now I'm using 15.x IOS on 7200 router. I think this is relatively new IOS and the changes that I talked about is because of the new code. interesting thing is that while I entered "compatible rfc1587" on the R5, nothing changed at all. I expected that this command make R5 to choose N route again but the behavior was the same. 

  • JoeMJoeM ✭✭✭

    The command compatible 1587 does the opposite.   It will act like the 12.4 code, where E2 can win.

     

    Which exact IOS are you using?  which 15.x

    Also, you changed the scenario for this thread completely to ospfv3.    I do not know if this makes a difference, but I don't want to build another topology to prove this.  Sorry if I seem lazy.  lol

  • timaztimaz ✭✭

    Which exact IOS are you using?  which 15.x

    I'm using "C7200-ADVENTERPRISEK9-M), Version 15.2(4)S" image. 

  • JoeMJoeM ✭✭✭

    I am not sure what to say about your result, as you changed to using OSPFv3. 

    Try using the comparable debug that I have been using:  

                 debug ospfv spf external

    I would not expect that there is a difference, but I am not sure if OSPFv3 acts differently vs the standard ospf (ipv4).  I am trying to compare apples-to-apples.     If you want to link to your lab (ospfv3), I will take a look at it.

  • timaztimaz ✭✭

    can anyone confirm that "compatible rfc..." command works on GNS with the 7200 IOS? tnx.

  • JoeMJoeM ✭✭✭

    Yes, I confirmed it with 15.2(4)M5.

    As PGallo posted earlier, we can use the backwards compatible option
    -- and the change is immediate (although it still uses the longer but
    direct leg for some reason)


    R1(config-router)#compatible rfc1587


    OSPF-1 EXTER: Started Building Type 5 External Routes
    OSPF-1 EXTER: Start processing Type 5 External LSA 3.3.3.0, mask 255.255.255.0
    OSPF-1 EXTER:  adv_rtr 2.2.2.2, age 637, seq 0x80000001, metric 20, metric-type 2, fw-addr 23.23.23.3
    OSPF-1 EXTER: Add forward address reachable 23.23.23.3, allowed types Intra and Inter, to watched queue
    OSPF-1 SPF  :    Add better path to LSA ID 3.3.3.0, gateway 13.13.13.3, dist 20
    OSPF-1 SPF  :    Add path: next-hop 13.13.13.3, interface Serial1/1
    OSPF-1 EXTER: Route update succeeded for 3.3.3.0/255.255.255.0, next-hop Serial1/1/13.13.13.3
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Started Building Type 7 External Routes
    OSPF-1 EXTER: Start processing Type 7 External LSA 3.3.3.0, mask 255.255.255.0
    OSPF-1 EXTER:  adv_rtr 3.3.3.3, age 638, seq 0x8000000A, metric 20, metric-type 2, fw-addr 23.23.23.3
    OSPF-1 EXTER: Add forward address reachable 23.23.23.3, allowed types Intra, to watched queue

     

    Routing entry for 3.3.3.0/24
      Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1064
      Last update from 13.13.13.3 on Serial1/1, 00:01:39 ago
      Routing Descriptor Blocks:
      * 13.13.13.3, from 2.2.2.2, 00:01:39 ago, via Serial1/1
          Route metric is 20, traffic share count is 1

  • JoeMJoeM ✭✭✭

    Timaz,

    From what you said in a previous post, your router was already acting with the backward compatibility.  This would mean that the command would have no affect, because it is already in effect.

    I am shooting a little in the dark about your setup.  Maybe try NO compatible rfc1587.

     

  • timaztimaz ✭✭

    From what you said in a previous post, your router was already acting with the backward compatibility.  This would mean that the command would have no affect, because it is already in effect.

     

    first of all, I entered "no compatibile rfc1587" command and it did not change anything. so I think what "Martinl" said is true.

    and second, I thought being affected by the metric in choosing N2 over E2 was introduced in new IOSs. I mean in the older IOSs, routers always prefer E2 over N2 but in newer IOSs routers consider the metric to the forwarder address if it is presented. so if I managed to affect path selection on an OSPF router to make it to select N2 over E2, it means it is based on the newer RFC 3101 not older one. am I right?

Sign In or Register to comment.