OSPFv3 path selection issue

Hi all; I have this topology.

image

the network type on the ethernet segment between R1, R2 and R3 is "point-to-multipoint non-broadcast". so I setup neighborship on that segment with "neighbor" commands:

 

R1:

 ipv6 address 2000:1:1:123::1/64

 ospfv3 neighbor FE80::C803:AFF:FEA4:8 cost 20 ----> this is Link-local address of R3

 ospfv3 neighbor FE80::C802:6FF:FE6C:8 cost 30 ----> this is Link-local address of R2

 ospfv3 network point-to-multipoint non-broadcast

 ospfv3 1 ipv6 area 1

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

 

R2:

interface FastEthernet0/0

 ipv6 address 2000:1:1:123::2/64

 ospfv3 neighbor FE80::C801:BFF:FEE4:8 ----> this is Link-local address of R1

 ospfv3 neighbor FE80::C803:AFF:FEA4:8

 ospfv3 network point-to-multipoint non-broadcast

 ospfv3 1 ipv6 area 1

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

 

R3:

interface FastEthernet0/0

 ipv6 address 2000:1:1:123::3/64

 ospfv3 neighbor FE80::C802:6FF:FE6C:8

 ospfv3 neighbor FE80::C801:BFF:FEE4:8

 ospfv3 network point-to-multipoint non-broadcast

 ospfv3 1 ipv6 area 1

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

 

I have shutted down the R3 so there is just one path between R1 and 2000:1:1:45::/64 network for now. routing entry on R1 towards 2000:1:1:45::/64 network (ethernet segment between R4 and R5) is as follows:

 

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

O   2000:1:1:45::/64 [110/75]

     via FE80::C802:6FF:FE6C:8, FastEthernet0/0

 

the metric on R1 equals 75, while the metric on R2 is 65. regarding to the outputs the metric between R1 and R2 should equals 10, but I choose per-neighbor cost for R2 as 30!

 

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

O   2000:1:1:45::/64 [110/65]

     via FE80::C804:DFF:FE88:6, Serial1/0

 

at the second step, I enabled the R3, but disabled R2 and test the metric again:

 

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

O   2000:1:1:45::/64 [110/22]

     via FE80::C803:AFF:FEA4:8, FastEthernet0/0

 

the metric is 22 on R1 while the metric on R3 equals 2. Again, with regards to the outputs, the metric between R1 and R3 should be 20, that is what I have expected.

 

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

O   2000:1:1:45::/64 [110/2]

     via FE80::C805:CFF:FE80:8, FastEthernet0/1

 

As you see, the metric values are strange! any idea on how these values are calculated..?

and the second question; while both of R2 and R3 are enabled, R1 strangely chooses R2 as its next-hop toward 2000:1:1:45::/64 network with the metric of 13!

 

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

O   2000:1:1:45::/64 [110/13]

     via FE80::C802:6FF:FE6C:8, FastEthernet0/0

 

first of all, how this metric is calculated?!! besides, the routing table on R2 shows that R2 uses R3 and Fa0/0 as its next-hop. so a simple trace on R1 toward the mentioned network shows that the packet goes to R2 and R2 returnes it back to R3 through its Fa0/0. so why R1 chooses R2 as its next-hop while I setup per-neighbor cost and expect that R1 to choose R3 as its next-hop. And why doesn't R2 uses IPv6 ICMP redirect message to inform R1 to use another best next-hop if it knows it? you can easily setup the topology on GNS. it is good to mention that I'm using "C7200-ADVENTERPRISEK9-M), Version 15.2(4)S" image. 

Comments

  • hi,

    its easier to read the config/ output than you use static link-local addresses like for example "ipv6 addr fe80::1 link-local".

    the cost which you did set on R1 with the neighbor command is a local value. its not the ospf cost on interface f0/0,

    and its not the metric the other Routers use to calculate the path and the metric.

     

    sh ipv os int f0/0 | i Cost

    sh ipv os da prefix adv-router 1.1.1.1 ! shows you the prefixes adv. by R1 ( in case your RID is 1.1.1.1) and the metric.

     

    Br

    Martin

  • timaztimaz ✭✭ ✭✭

    the cost which you did set on R1 with the neighbor command is a local value. its not the ospf cost on interface f0/0,

    and its not the metric the other Routers use to calculate the path and the metric.

     

    if it has only local effect on R1, why does not it affect the metric calculation on R1 toward networks that are learnt through neighbor routers R2 and R3?! and even without considering the cost values that are set by neighbor command, how can we explain the metric valies that are calculated on R1 toward 2000:1:1:45::/64 which is an intra-area network?

  • it did affect the Route selection on R1 for network learned from R2 and R3 after i did some changes...

    I connect R1 to R3 via f0/0 and R1 to R2 via F0/1 same neighbhor ospf cost you used. So R3 with 20 and R2 with 30.

    and i advertised a prefix on R6 which i did connect directly with R2 and R3.

    all interfaces network type point-to-m non. 

    in this case it does prefer the route learned via R3 even though the Prefix LSA does show the same Metric for that route also.

     

    Output of the show commands:

     

    R1#sh ipv route 2001:6:6:6::6

    Routing entry for 2001:6:6:6::6/128

      Known via "ospf 1", distance 110, metric 84, type intra area

      Route count is 1/1, share count 0

      Routing paths:

        FE80::3, FastEthernet0/0

          Last updated 00:12:14 ago

     

    When i disable the Link to R3 it uses the added metric from the neighbor statement:

     

    R1#sh ipv route 2001:6:6:6::6

    Routing entry for 2001:6:6:6::6/128

      Known via "ospf 1", distance 110, metric 94, type intra area

      Route count is 1/1, share count 0

      Routing paths:

        FE80::2, FastEthernet0/1

          Last updated 00:00:00 ago

     

    The database prefix advertised by R6 describes the cost to R1 as seen by R6:

     

    R1#sh ospfv3 database prefix ad 6.6.6.6

     

              OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)

     

                    Intra Area Prefix Link States (Area 1)

     

      Routing Bit Set on this LSA

      LS age: 616

      LS Type: Intra-Area-Prefix-LSA

      Link State ID: 0

      Advertising Router: 6.6.6.6

      LS Seq Number: 80000004

      Checksum: 0x7DCA

      Length: 76

      Referenced LSA Type: 2001

      Referenced Link State ID: 0

      Referenced Advertising Router: 6.6.6.6

      Number of Prefixes: 3

      Prefix Address: 2001:6:6:6::6

      Prefix Length: 128, Options: LA, Metric: 0

      Prefix Address: 2000:1:1:32::

      Prefix Length: 64, Options: None, Metric: 64

      Prefix Address: 2000:1:1:36::

      Prefix Length: 64, Options: None, Metric: 64

     

    Let me know what you think..

  • timaztimaz ✭✭ ✭✭

    I rebuilt your scenario and it worked as expected. but what is wrong with the original topology that I've posted above? could you rebuilt it and test to see what will happen?

  • JoeMJoeM ✭✭✭ ✭✭✭

    I rebuilt your scenario and it worked as expected. but what is wrong with the original topology that I've posted above? could you rebuilt it and test to see what will happen?

    Hi Timaz,
    Can you post your original GNS3 topology?  That way we don't have to rebuild it, and we will have your exact config. 

    I would like to play with your puzzle a little bit.  Thanks.

     

    Also, can't we see both networks in the OSPF database without shutting down any interfaces.

     

  • timaztimaz ✭✭ ✭✭

    Hi Timaz,
    Can you post your original GNS3 topology?  That way we don't have to rebuild it, and we will have your exact config. 

    I would like to play with your puzzle a little bit.  Thanks.

    Also, can't we see both networks in the OSPF database without shutting down any interfac

     

    Hi JoeM;

    I'm using the topology that I put it at the first post of this topic. I enabled ospfv3 everywhere without manipulating the default metric values. I meant "maschumach" while I said rebuilding the topology. 

  • JoeMJoeM ✭✭✭ ✭✭✭

    Can you post the GNS3 package with configs.  I would like to play with the scenario.  Thanks.

  • i will lab it up...want to have a quick look if its the same with ipv4 and ipv6 

  • JoeMJoeM ✭✭✭ ✭✭✭

    Can you post the GNS3 package with configs.  I would like to play with the scenario.  Thanks.

    Timaz, in your other ospf question, I saw that you tried to post a zip file as media.     All you need to do is zip the already built gns3 topology file along with the config folder (nothing else=very small filesize).  After you upload it anywhere, just post a direct url (not as media).

    I am still curious about this scenario.   Thanks.

  • timaztimaz ✭✭ ✭✭

    I am still curious about this scenario. 

     

    thanks you JoeM! actually the VM that I was working on it has restarted and I missed some of my configs. so let me to rebuilt it and post the topology and configs here. it maybe take some hours. I think that we must find a solution or explanation to the weird issues that we might face with them. 

  • JoeMJoeM ✭✭✭ ✭✭✭

    Great.  You always ask good questions.  Now I want to know the answer too, but without guessing about it.

  • timaztimaz ✭✭ ✭✭

    Hi all, finally I managed to rebuild the topology. hooray! but this time, everything worked as expected. that is, the metric of route toward R6's loopback on R1 was calculated based on the metric that I'd assigned by per-neighbor-cost. I don't know why sometimes everything go wrong without clear explanation. maybe it is because of GNS or IOSs that are used. in this situation I think the better way to build lab topologies is using VIRL or physical device. anyway, thank you all for being involved in this lab [;)]

     

    the cost which you did set on R1 with the neighbor command is a local value. its not the ospf cost on interface f0/0, and its not the metric the other Routers use to calculate the path and the metric.

     

    based on the lab that finally worked for me, the router calculate the metric locally (as you said) based on the metric that is assigned by neighbor x cost x command not the physical interfaces. for this lab, R1 uses the metric that is manually assigned by the mentioned command to reach remote destinations. 

     

     

  • JoeMJoeM ✭✭✭ ✭✭✭

    Don't blame gns3 for ospf issues or user errors.  I have done this many times, but then after a lot of tenacity to solve an issue -- I have most often found that it was a easy time-wasting user issue (caused by myself).  OSPF is straight forward. ;-)

    This sounds more like the process hadn't been restarted.  Of course that is if your new topology matches the original exactly.

Sign In or Register to comment.