OSPF costs for neighbors on mGRE tunnels

[hmdavies]

We have recently migrated our core router from a 7206VXR to an ASR1002-F, following the migration we cannot assign specific OSPF costs to individual spoke destinations as the "neighbor x.x.x.x cost nn" command is not supported on the ASR.

Any ideas how the OSPF cost for individual mGRE end-points can be manipulated?

[Marwan ALshawi]

Can you post you diagram as I might help u to tweak it using different way

And specify which one has to primary path and which one secondary for certain networks

Sent from Cisco Technical Support iPhone App

[Peter Paluch]

Hello,

To my best knowledge, per-neighbor costs in OSPF can be specified only when the mGRE network is run in point-to-multipoint nonbroadcast mode. However, if that command is not supported on ASR even after specifically setting the network type to PtMPNB, some other solution has to be found.

Marwan, looking forward to your ideas after OP posts the network topology.

Best regards,

Peter

[Giuseppe Larosa]

Hello Peter,

correct me if 'm wrong ip ospf network point-to-multipoint non-broadcast is a Cisco proprietary feature.

if IOS XE does not support it means Cisco is leaving this or there is some implementation issues in IOS XE.

the only way to emulate without would be to use p2p GRE tunnels but this would mean losing mGRE advantages.

we could even think of using p2p GRE over mGRE if possible or to divide the mGRE in multiple clouds with different OSPF cost associated to ech of it reaching a subset of neighbors each

Marwan has better experience with the DMVPN topic.

Hope to help

Giuseppe

[Peter Paluch]

Hello Giuseppe,

First of all, I have to apologize for spreading a slight misinformation: the neighbor X.X.X.X cost N command is supported both for PtMP and PtMP-NB network types. I thought previously that it is supported on PtMP-NB network types only. One never ceases to learn ...

Still, the fact holds that the cost keyword is supported with PtMB-derived network types. It is not possible to use it with multiaccess type networks (BMA, NBMA) nor PtP.

correct me if 'm wrong ip ospf network point-to-multipoint non-broadcast is a Cisco proprietary feature.

Yes, that is true. Then again, the PtMP-NB is not a significant change to the protocol itself but rather to its control. The neighbors must be defined manually, as opposed to standard PtMP where the neighbors are located using multicasted Hello packets, and instead of taking the cost of the egress interface when creating an entry to a neighbor router in router's own LSA1, the cost can be configured manually as well.

if IOS XE does not support it means Cisco is leaving this or there is some implementation issues in IOS XE.

I would find this quite strange. The PtMP-NB is not so commonly used but then again, it is a network type that gives you the most precise control about what adjacencies are going to be created and how they are to be evaluated in the terms of costs. I have seen using the PtMP-NB even on Ethernet networks (well, Metro Ethernet/VPLS) to solve some intricate demands that would otherwise be hard to solve. It would be strange to me to think Cisco would be abandoning it - considering that the code already exists, and IOS-XE is not such an extensive rewrite of the older IOS anyway.

In addition, I briefly skimmed over IOS-XE documentation for versions 2 and 3. In both versions, the Configuration Guide for OSPF in IOS-XE maintains that the PtMP-NB mode is supported, and the neighbor command should recognize the cost keyword for both PtMP and PtMP-NB. So my feeling about this is that perhaps the OSPF network type has to be set up on the DMVPN interface before the cost keyword can be used. But it definitely should be supported, according to the IOS-XE docs.

I am really looking forward to hear the original poster's comment on this.

Best regards,

Peter

[Giuseppe Larosa]

Hello Peter,

clearly the ip ospf network type has to be configured first, but in IOS XE it may need to be configured under protocol OSPF stanza if it is similar to IOS XR and not under the interface (IOS like)

in my personal study notes the use of neighbor .. cost is possible only with p-mp NB Cisco extension but they may be outdated or wrong on this specific subject!

NBMA - > neigh .. priority or neiigh poll -interval

p2mp non broadcast ---> neigh ... cost is allowed

it is clearly an handy feature that the OP was using in his network

let's wait for his feedback

Hope to help

Giuseppe

[Peter Paluch]

Hi Giuseppe,

clearly the ip ospf network type has to be configured first, but in IOS  XE it may need to be configured under protocol OSPF stanza if it is  similar to IOS XR and not under the interface (IOS like)

The IOS-XE, to my limited knowledge, maintains the IOS syntax almost identically. It is because the IOS actually runs compartmentalized in an execution environment over a Linux kernel. Even according to the IOS-XE documentation, the OSPF network type is configured under interface stanza, and the neighbors are configured under OSPF process stanza.

in my personal study notes the use of neighbor .. cost is possible only  with p-mp NB Cisco extension but they may be outdated or wrong on this  specific subject!

That was exactly my idea as well but I've just tested it on 2691 IOS and it works perfectly even with Point-to-Multipoint (Broadcast) configuration. Then again, it is not so illogical... the PtMP may discover neighbors with multicast Hellos but the costs may either be borrowed from the interface cost towards those neighbors, or redefined by the neighbor command. Funny... but it works

Thank you for sharing your insight!

Best regards,

Peter

[hmdavies]

simplied diagram attached - traffic from any spoke to C should go via B as 1st Choice, D as 2nd choice then direct C if no other path available - all routers are in Area 0

as you have mentioned in the previous comments - thsi problem only exists in XE code, standard IOS on the old 7206 worked fine

[Marwan ALshawi]

well it is tricky one because you want the directly connected LAN/interface to be lease preferred and if you play around with cost this will effect both B and D

however can you try this work around

first of all we want B to be preferred and second D and last C

assumptions

all in same area including the links to the LAN/and links between B, C and D

changes:

OSPF cost calculation works in the inbound direction

you need to increase the cost in the router D in the interface going to C make for example 1000

while for router B interface going to router C make 10

using the command ip ospf cost xx

now about router C we can not change the cost because whatever we add it will be less than other paths

however whati think to do here is to change the route type of C when it gose over the DMVPN only

now lets assume C network is 10.1.1..0/24

and ospf 1 configured on interfaces of C, to B and to D

network C advertised with network command

now create in router C only new ospf process lets say ospf 2 and make the DMVPN tunnel interface under this process in area 0

now redistribute ospf 1 into ospf 2 ( you can filter the route to advertise C only ) inthis way remote sites over DMVPN will see network c as external route through C path DMVP while it is INTRA area route through B and D and because the cost through B is less then B will be used first

please try it in quick lab prove it orks even using GNS 3 is enough to prove the concept

again in brief the idea is to have C to be seen as external route through C path while intra area via B and D and increase the cost thorugh D to make B as first path

and you got best of CSC expert in this discussion Peter and Giuseppe who can comment on it too

good luck

[Marwan ALshawi]

one more thing, not sure if it was addressed in your original design before

about the returning path not sure if you need to have te returning path from C to the rest of the networks same concept vi B, D then last direct via C

if this is the case then just increase the ospf cost on the tunnel interface of router C make it 2000 for example and on the interface going to D make it 1000 and on the interface going to B make it 10

this is for the returning traffic path

[Marwan ALshawi]

please update us with the result if you are going to test/try it

[hmdavies]

I intend to test this week but have one more question, Router C is an ABR - which path would routers A,E & F see as the most preferred to the leaf area addresses

[Marwan ALshawi]

you mentioned above all in area 0

if router C is ABR i am assuming the tunnel interface, links to B ADN D are all  in area 0

and network C/LAN maybe in differnt area

if this is the case then based on what i suggested is to have the tunnel interface to be in area 0 but in differnt ospf process and redistribute network C into it

then C will be seen as INTER area route LSA 3 by remote sites through B and D

while thorugh C it is external LSA 5 and still B and D prefered over C in this case

not sure if my assumption to your question is right !

[Marwan ALshawi]

Could you please update us if this issue has been resolved ? And how ?

[hmdavies]

built in GNS and works OK, customer has now decided to close one site so design no longer needed

Thanks all for your comments