Cool OSPF Problem

I ran into a pretty obscure case with OSPF today and I actually don't know of a good way to fix it. See the topology and problem in the link below.

http://postimg.org/image/xqpnwl7h7/

Basically if fa0/0 was shutdown on R3, then R3 would have two equal cost routes for the default route path. However, since R3 is also now learning the default route from R5 (with an LSA type 5 via area 0), it is now being preferred over the type 7 default from R2 and R4, It means that now R4 takes the path via R6 for routes via the default route.

So I would like to know what design decisions should be normally made to stop a problem like this occuring. It's very interesting because no redistribution occurs in this network at all.

 

The only way I can think of stoppnig this is by using a distribute list like below, but this really seems like more of a hack than a fix for the design.

ip prefix-list STOP_DEFAULT seq 5 deny 0.0.0.0/0
ip prefix-list STOP_DEFAULT seq 10 permit 0.0.0.0/0 le 32

router ospf 1
distribute-list prefix STOP_DEFAULT i fa0/0

Comments

  • What version of code are you running? If your boxes support RFC-3103 this should not be happening, as R3 should be preferring the N2 over the E2. What you are seeing is behavior from RFC-1587, where E2 is preferred over N2.

     

  • R5#sh ver | i Software
    Cisco IOS Software, 3700 Software (C3745-ADVIPSERVICESK9-M), Version 12.4(25d), RELEASE SOFTWARE (fc1)
    ROM: 3700 Software (C3745-ADVIPSERVICESK9-M), Version 12.4(25d), RELEASE SOFTWARE (fc1)

     

    Why should R3 prefer the N2 over the E2 in this example? That doesn't make sense because the forward metric to R5 is THE SAME (as i've just figured out actually) because of the supress-fa command.

     

    R3#sh ip ospf database external

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

    Type-5 AS External Link States

    Routing Bit Set on this LSA
    LS age: 96
    Options: (No TOS-capability, DC)
    LS Type: AS External Link
    Link State ID: 0.0.0.0 (External Network Number )
    Advertising Router: 5.5.5.5
    LS Seq Number: 8000000A
    Checksum: 0x8016
    Length: 36
    Network Mask: /0
    Metric Type: 2 (Larger than any link state path)
    TOS: 0
    Metric: 1
    Forward Address: 0.0.0.0
    External Route Tag: 0

    So the metric here says that the metric that R5 knows to reach the external path is 1. And the forward metric to R5 is 20

    R3#sh ip ospf int brief
    Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
    Fa0/0        1     0               10.0.36.3/24       10    P2P   1/1
    R6# sh ip ospf int brief
    Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
    Fa0/1        1     0               10.0.56.6/24       10    P2P   1/1

     

    Making the forward metric 10+10 = 20 to reach R5. But now if I check the path via the NSSA

    R3#sh ip ospf da nssa

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

                    Type-7 AS External Link States (Area 1)

      LS age: 750
      Options: (No TOS-capability, Type 7/5 translation, DC)
      LS Type: AS External Link
      Link State ID: 0.0.0.0 (External Network Number )
      Advertising Router: 2.2.2.2
      LS Seq Number: 8000000B
      Checksum: 0x6B14
      Length: 36
      Network Mask: /0
            Metric Type: 2 (Larger than any link state path)
            TOS: 0
            Metric: 1
            Forward Address: 10.0.12.2
            External Route Tag: 0

    The external metric that R2 has advertised is 1. So now it's down the a tiebreaker of the forward metric to work out if the E2 or N2 route gets installed.


    R3#sh ip route 10.0.12.2
    Routing entry for 10.0.12.0/24
      Known via "ospf 1", distance 110, metric 20, type intra area
      Last update from 10.0.23.2 on FastEthernet0/1, 00:05:55 ago
      Routing Descriptor Blocks:
      * 10.0.23.2, from 2.2.2.2, 00:05:55 ago, via FastEthernet0/1
          Route metric is 20, traffic share count is 1

    So the forward metric to reach the forward address is 20. So now the R3 has a default route to 0.0.0.0/0 via an advertised cost of 1 from R2 and R5. And the forward metric to reach either R2 or R5 is both 20. So in this case, the router should prefer the E2 over the N2.

    And now I've just worked out how to fix it haha. So if I lower the cost of the interfaces towards R2 and R4 to 9 instead of 10, this should fix it.

    Routing table before any changes:


    R3#sh ip route 0.0.0.0
    Routing entry for 0.0.0.0/0, supernet
      Known via "ospf 1", distance 110, metric 1, candidate default path, type extern 2, forward metric 20
      Last update from 10.0.36.6 on FastEthernet0/0, 00:10:12 ago
      Routing Descriptor Blocks:
      * 10.0.36.6, from 5.5.5.5, 00:10:12 ago, via FastEthernet0/0
          Route metric is 1, traffic share count is 1

    Changes applied:

    R3(config)#int f1/0
    R3(config-if)#ip ospf cost 9
    R3(config-if)#int fa0/1
    R3(config-if)#ip ospf cost 9
    R3(config-if)#end

    Routing table after changes

    R3#sh ip route 0.0.0.0
    Routing entry for 0.0.0.0/0, supernet
      Known via "ospf 1", distance 110, metric 1, candidate default path, type NSSA extern 2, forward metric 19
      Last update from 10.0.23.2 on FastEthernet0/1, 00:00:41 ago
      Routing Descriptor Blocks:
      * 10.0.34.4, from 4.4.4.4, 00:00:41 ago, via FastEthernet1/0
          Route metric is 1, traffic share count is 1
        10.0.23.2, from 2.2.2.2, 00:00:41 ago, via FastEthernet0/1
          Route metric is 1, traffic share count is 1

     

    I don't know why I couldn't figure this out before. I'm just tired as I've had a nasty cold all week. Thanks for your help anyways.

  • When
    you do "show ip ospf" on R3, do you see RFC-3101?

     

    R1#show ip ospf 

     Routing Process "ospf 1" with ID 192.122.3.1

     Start time: 00:26:46.598, Time elapsed: 1w6d

     Supports only single TOS(TOS0) routes

     Supports opaque LSA

     Supports Link-local Signaling (LLS)

     Supports area transit capability

     Supports NSSA (compatible with RFC 3101)

     

    Or do you see RFC-1587?

     

    R1#show ip ospf 

     Routing Process "ospf 1" with ID 192.122.3.1

     Start time: 00:26:46.598, Time elapsed: 1w6d

     Supports only single TOS(TOS0) routes

     Supports opaque LSA

     Supports Link-local Signaling (LLS)

     Supports area transit capability

     Supports NSSA (compatible with RFC 1587)

     

    Even with suppress-fa, RFC-3101 ensures both R3 and R5 route into
    the NSSA in your topology. The forward metric on the Type-7 and the Type-5
    should be 2 from R3's perspective, since you don’t have a link between R3
    and R5. Since both routes are equal (same metric, same forward metric), the
    Type-7 is selected, according to RFC-3101, since
    it has the P-bit set 
    (one of
    the last steps in the best path selection algorithm).

    If you enable a link in Area 0 between R3 and R5 with a default
    cost, then the E2 will be preferred over the N2, regardless of RFC-3101
    support. Since R5 will suppress the FA, R3 will see the forward metric as 1 over the R3-R5 link, where the forward
    metric from the NSSA will be 2. This difference in forward metric will make the
    E2 win over the N2. However, with the absence of this link, you are just seeing
    old NSSA behavior, described in RFC 1587. 

    If you upgrade to new code, you will be able to toggle this
    behavior, by using "compatible rfc1587" under the OSPF process.

    Hope this helps 

     

     

     

  • All links have a cost of 10, so the forward metric can't be 2. It has correctly been calculated at 20.

    I don't get what you mean when you saying that you can toggle this behaviour? I don't have a link between R3 and r5. Correct. But then you say I can toggle this behavour??? Toggle what behaviour?

  • Ok, cost of 20 in your network. Replace 1 for 10 and 2 for 20 in my previous post. I was assuming FastEthernet or GigE costs, but the principle is still the same. 

    In recent versions of code that support RFC-3101, you can toggle (enable/disable) support for RFC-1587. By default, the 3101 rules are enabled. You can selectively disable them, and fall back to 1587, by using the 'compatible rfc-1587' command. This is what I meant by "toggle". 

     

  • Hey thanks for getting back to me. I was trying to work out what the difference is when you toggle. I couldn't quiet grasp what you meant is different between each rfc

  • By using the newer code, you can see both path selection rules in action and see the difference. The network you have set up is perfect for testing this out. I would add a link between R3 and R5 so you can see the difference that it makes. Try it out =) 

    http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-e/iro-15-e-book/iro-ospfv2-nssa-cfg.html

     

  • So what is the difference lol? I don't know how many ways I can ask you. What difference does it make and why?

  • try it out and let me know =)  I think what I've said in my previous posts should point you in the right direction. There is no equivalent to trying this stuff out and seeing for yourself. 

    If you take your network, use a more recent version of code (15.X) which supports RFC-3101 you will see the difference. Adding a link between R3-R5 will re-inforce how the path selection works. With the more recent version of code you will be able to see both path selection behaviors (old vs new == 1587 vs 3101). In your current environment you are stuck with the 1587, as that version of code your running does not seem to support 3101.

    There are also loads of good writeups on this. Search for stuff like "E2 vs N2 RFC 3101", and so on. But at least i believe that seeing it in action for yourself will make you understand it better than anything else.

    Regards,

  • Well it looks like my IOS appears to be using RFC3101 since I do have a command option to do "compatible rfc 1587" (although it doesn't explicitly state it in the #sh ip ospf output). So it just looks like you are incorrect, but I can't confirm it since I don't know what the difference is supposed to be. So by keep speaking in riddles and hiding the answer, you are really not helping at all. People don't use forums with the hope that they will be told to go find the answer out themselves, otherwise what is the point of using the forum? It's just annoying. From the RFC 1301 it looks like you are referring to the section that states

    "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."


    But, since my forward address is actually 0 from R5, this rule doesn't apply. So the RFC also appears to contradict you. In order to save me wasting any more time on this topic, would you be so kind to explain what you think the results should be?

  • Hi All,

    Did someone mention Murphy's Law?  "compatible rfc1583" is very close to "compatible rfc1587", which is a pretty recent command.  

    rg, your lab work looks great.  I'll attempt to do same next week.  Many thanks for your post.//RandyB

  • In order to save me wasting any more time on this topic, would you be so kind to explain what you think the results should be?

    As I've stated in my previous posts, your network is selecting the E2 over the N2 because it is using the older path selection algorithm, where when comparing two equal cost (metric/forward metric) it will select the E2 over the N2. 

    And again, as I've stated in my previous posts, If you change to the newer model (upgrade code), the two routes will be compared, but the N2 will win over the E2. This is what I am suggesting you try...just upgrade the code, and see the difference in your existing topology. All the other stuff about adding a link between R3 and R5 is to change the topology around a bit and see what happends, under both RFC's path selection model, when the forwarding metric is not the same.

     If your "show ip ospf" does not show RFC-3101, then its not running it. Your running very old code, from the output you showed. 

    I though I've answered your question every time I respond...perhaps I am not fully understanding what your asking. Your question is about the difference, which I've responded to every time. Also keep in mind that Cisco does not always stick 100% to the RFC. Just because it is written there, does not mean Cisco implemented it 100% to spec. All I am saying is just try it. I tested it on your same network, only running 15.4. 

     

  • Dude, if you can see a command and its not really implemented then it is just a wish list for the future. Don't trust it until you test it.

     

    Well it looks like my IOS appears to be using RFC3101 since I do have a command option to do "compatible rfc 1587" (although it doesn't explicitly state it in the #sh ip ospf output). So it just looks like you are incorrect, but I can't confirm it since I don't know what the difference is supposed to be. So by keep speaking in riddles and hiding the answer, you are really not helping at all. People don't use forums with the hope that they will be told to go find the answer out themselves, otherwise what is the point of using the forum? It's just annoying. From the RFC 1301 it looks like you are referring to the section that states

    "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."


    But, since my forward address is actually 0 from R5, this rule doesn't apply. So the RFC also appears to contradict you. In order to save me wasting any more time on this topic, would you be so kind to explain what you think the results should be?

     

  • For me easy to remember that rfc1587 is for nssa and not rfc1583,as it ends with 7 and in nssa area we have type 7 Lsa's. If all is a tie for the metric and forwarding metric, in old rfc1587 E is always preferred against N and this is a problem. If you run the new rfc3101 and you have a tie, N is preferred over E if the Lsa has the P-bit set, otherwise E is preferred over N; this makes sense as if the P-bit is set you want at least one abr to make the 7-5 translation and because for type-7 ospf runs in distance vector behaviour, it needs to install the N route in the RIB to make the translation.

    Sent from my iPhone

    On Aug 10, 2015, at 10:00, Murad <[email protected]> wrote:

    Dude, if you can see a command and its not really implemented then it is just a wish list for the future. Don't trust it until you test it.

     

    imagesg4rb0:

    Well it looks like my IOS appears to be using RFC3101 since I do have a command option to do "compatible rfc 1587" (although it doesn't explicitly state it in the #sh ip ospf output). So it just looks like you are incorrect, but I can't confirm it since I don't know what the difference is supposed to be. So by keep speaking in riddles and hiding the answer, you are really not helping at all. People don't use forums with the hope that they will be told to go find the answer out themselves, otherwise what is the point of using the forum? It's just annoying. From the RFC 1301 it looks like you are referring to the section that states

    "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."


    But, since my forward address is actually 0 from R5, this rule doesn't apply. So the RFC also appears to contradict you. In order to save me wasting any more time on this topic, would you be so kind to explain what you think the results should be?

     




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • And that is not really route feedback , just suboptimal routing in your case. You can fix it by injecting the default route into nssa with the p-bit set and run rfc3101 by "no compatible rfc1587".

    Sent from my iPhone

    On Aug 10, 2015, at 10:00, Murad <[email protected]> wrote:

    Dude, if you can see a command and its not really implemented then it is just a wish list for the future. Don't trust it until you test it.

     

    imagesg4rb0:

    Well it looks like my IOS appears to be using RFC3101 since I do have a command option to do "compatible rfc 1587" (although it doesn't explicitly state it in the #sh ip ospf output). So it just looks like you are incorrect, but I can't confirm it since I don't know what the difference is supposed to be. So by keep speaking in riddles and hiding the answer, you are really not helping at all. People don't use forums with the hope that they will be told to go find the answer out themselves, otherwise what is the point of using the forum? It's just annoying. From the RFC 1301 it looks like you are referring to the section that states

    "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."


    But, since my forward address is actually 0 from R5, this rule doesn't apply. So the RFC also appears to contradict you. In order to save me wasting any more time on this topic, would you be so kind to explain what you think the results should be?

     




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • What you can consider cool is that ospf is not loop free by itself, in two specific designs it creates loops.

    Sent from my iPhone

    On Aug 10, 2015, at 10:00, Murad <[email protected]> wrote:

    Dude, if you can see a command and its not really implemented then it is just a wish list for the future. Don't trust it until you test it.

     

    imagesg4rb0:

    Well it looks like my IOS appears to be using RFC3101 since I do have a command option to do "compatible rfc 1587" (although it doesn't explicitly state it in the #sh ip ospf output). So it just looks like you are incorrect, but I can't confirm it since I don't know what the difference is supposed to be. So by keep speaking in riddles and hiding the answer, you are really not helping at all. People don't use forums with the hope that they will be told to go find the answer out themselves, otherwise what is the point of using the forum? It's just annoying. From the RFC 1301 it looks like you are referring to the section that states

    "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."


    But, since my forward address is actually 0 from R5, this rule doesn't apply. So the RFC also appears to contradict you. In order to save me wasting any more time on this topic, would you be so kind to explain what you think the results should be?

     




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • Ok. Well I've read both the old and the new RFCs (the new one twice now). And I know the path selection is the same except for the statement where I said earlier.


    "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."

     

    So I am trying to work out where you might have read that the N2 route would be preferred in my topology since R5 is setting the forwarding address to 0.0.0.0 (because of the supress-fa command). So I can't understand the reason why you think the N2 would be more prefferred providing that the original reason you thought the N2 would be preferred was because of the statement above (which I've proven in my case, doesn't apply due to the forwarding address being all 0's).

  • Hi All, interesting post and showing me how much more there is to learn.  Both about ospf and reading these RFCs.  After going through RFC 1587, I've labeled sections that are unclear.  Will be doing same with RFC 3101, and wish to post notes either in this thread or another in hopes of getting clarification.

    SG and All, have you seen this part of the RFC 3101 algorithm?  Murphy doesn't state this important step, even though he could have done so with a few lines.  One has to go to RFC 2328 and read this step.  Reads like it is applicable, but haven't labbed.  How does one paste to get single line spacing?

    RFC 3101       The OSPF Not-So-Stubby Area (NSSA) Option    January 2003

    2.5 Calculating Type-7 AS External Routes

    <snip>

    it might be this step as it selects intra-area over backbone

    (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. <<<< this is rfc 2328
    Here intra-NSSA paths are equivalent to the intra-area
    paths of non-backbone regular OSPF areas.
    [NSSA]

    [EDIT NOTE] randy:  LSA5 is using a backbone intra-area path to reach 7to5 translator, while LSA7 is using an NSSA area intra-area path to reach an NSSA ASBR.  RFC 2328 sec 16.4.1 states that a AS external paths that use intra-area paths to reach FA are preferred over those that use backbone paths. right?

  • Hi; 

     

    as long as I remember, I had and still have difficulties regarding route selection algorithm in ospf while dealing with "O" and "N" routes. I have written many topics and have asked many questions regarding this but still I feel that I don't know anything about this issue!

    I'm working on a scenario which you can find it's topology here (http://ieoc.com/forums/p/33032/258377.aspx). I'm using VIRL that uses IOS 15.5 on the routers. I redistributed EIGRP routes (including many loopback interfaces that are created on R13 with the IP addresses of 13.13.13.1/128 to 13.13.13.13/128) into OSPF domain, while area 2 is set to NSSA. R5 is our translator and it gets two N2 routes about redistributed networks, one from R4 and one from R6. the metric to both forward-address is the same as you can see from the picture. 

    examining DB on the R7 and R8 indicates that R5 has translated only one of the N routes (the one that has redistributed by R6), so the DB of the R7 and R8 contains just one of the external routes. for example, for R7 to reach R13's loopback address, it must route the traffic toward R6 instead of the R4. the first confusion is this. why has not R5 translate and advertise both N routes into the area 0?

    and another confusion; the IOS version on the routers support compatability for these RFCs: 

     

    R2(config-router-af)#do sh ospfv3 1 ipv4 | inc RFC

     Supports NSSA (compatible with RFC 3101)

     Supports Database Exchange Summary List Optimization (RFC 5243)

     RFC1583 compatibility enabled

     

    as expected, R5 translate the N routes to E routes and R2, as another ABR router, now has both N and E routes. because the forward-address of both of the E and N routes is the same, based on the new RFCs that are enabled bby default in this version of IOS, R2 selected the N routes over E. [[ I want to solidify this for myself so I need to ask a mini-question here in parenthesis; does routers evaluate the metric of the forward-address before the route type to select the best route among E and N routes? ]]. but after I entered "compatible rfc1587" command on R2, nothing happened and R2 again used the N routes. I appreciate you If you clear these for me too. thanks a lot. 

  • [[ I want to solidify this for myself so I need to ask a mini-question here in parenthesis; does routers evaluate the metric of the forward-address before the route type to select the best route among E and N routes? ]]

     

    I reviewed the RFCs specified on this doc and managed to find answer to my previous mini question. based on what I managed to get from the RFCs, the route type is evaluated only and only if there is a tie on metric (weather toward forward-address or advertising router). so if this metric is the same, then routers choose the best route among E and N based on the RFC. am I right?

    any idea about my main question?

  • Thanks Randy. That's what I was looking for. I'm sure I read that, but I tried to find the part where it says the path selection what happens if the RFC1583 is enabled. The RFC only appears to state what happens when its disabled.

  • When you enabled RFC1587, it should have preferred the E path, if it still preferred the N path, it means thst either you did not wait enough for OSPF to receonverge, or the cost for the N path was better and NOT equal to the cost of the E path; thus N path wins as that is the first tie-breaker.

     

    Hi; 

     

    as long as I remember, I had and still have difficulties regarding route selection algorithm in ospf while dealing with "O" and "N" routes. I have written many topics and have asked many questions regarding this but still I feel that I don't know anything about this issue!

    I'm working on a scenario which you can find it's topology here (http://ieoc.com/forums/p/33032/258377.aspx). I'm using VIRL that uses IOS 15.5 on the routers. I redistributed EIGRP routes (including many loopback interfaces that are created on R13 with the IP addresses of 13.13.13.1/128 to 13.13.13.13/128) into OSPF domain, while area 2 is set to NSSA. R5 is our translator and it gets two N2 routes about redistributed networks, one from R4 and one from R6. the metric to both forward-address is the same as you can see from the picture. 

    examining DB on the R7 and R8 indicates that R5 has translated only one of the N routes (the one that has redistributed by R6), so the DB of the R7 and R8 contains just one of the external routes. for example, for R7 to reach R13's loopback address, it must route the traffic toward R6 instead of the R4. the first confusion is this. why has not R5 translate and advertise both N routes into the area 0?

    and another confusion; the IOS version on the routers support compatability for these RFCs: 

     

    R2(config-router-af)#do sh ospfv3 1 ipv4 | inc RFC

     Supports NSSA (compatible with RFC 3101)

     Supports Database Exchange Summary List Optimization (RFC 5243)

     RFC1583 compatibility enabled

     

    as expected, R5 translate the N routes to E routes and R2, as another ABR router, now has both N and E routes. because the forward-address of both of the E and N routes is the same, based on the new RFCs that are enabled bby default in this version of IOS, R2 selected the N routes over E. [[ I want to solidify this for myself so I need to ask a mini-question here in parenthesis; does routers evaluate the metric of the forward-address before the route type to select the best route among E and N routes? ]]. but after I entered "compatible rfc1587" command on R2, nothing happened and R2 again used the N routes. I appreciate you If you clear these for me too. thanks a lot. 

     

  • Correct.

    [[ I want to solidify this for myself so I need to ask a mini-question here in parenthesis; does routers evaluate the metric of the forward-address before the route type to select the best route among E and N routes? ]]

     

    I reviewed the RFCs specified on this doc and managed to find answer to my previous mini question. based on what I managed to get from the RFCs, the route type is evaluated only and only if there is a tie on metric (weather toward forward-address or advertising router). so if this metric is the same, then routers choose the best route among E and N based on the RFC. am I right?

    any idea about my main question?

     

Sign In or Register to comment.