It seems that you may not achieve what you want by manipulating interface cost as both of your neighbors 172.16.21.3 and 172.16.21.4 are connected through same interface f0/1 and changing interface f0/1 cost will affect both of these neighbors and eventually you end up having both routes in routing table with same manipulated cost.

One option I can think in your scenario is to use NBMA mode('ip ospf network non-broadcast') where you need to use neighbor command to build neighbor relationship. On neighbor command you have option of specifying cost on per neighbor basis. Be sure to test this in lab environment though.

If you don't want to tweak ospf network type then consider PBR as one option.

Hello Yagnesh,

Only a slight comment here: While the "neighbor" command allows you to define a cost to a neighbor, that syntax is valid only on point-to-multipoint nonbroadcast networks. The NBMA does not allow you to define different costs for different neighbors. That follows from the way how the OSPF models the network using a graph representation.

Best regards,

Peter

Hello Mohamed,

I agree there is no need to use NBMA network type.

However, to make the total cost different from the point of view of primary site routers I think the cost has to be changed on interface SVI vlan1 on HS-Sec-2811 node.

The cost of HS-Sec-2811 on the common subnet on the metro ethernet is not used on primary site.

This happens because this a lan segment that is treated in the following manner:

each node uses the cost of its connected interface as the way to access the multiaccess segment.

The cost of the other nodes is not used.

you can see for net 10.101.102.0/24 the total metric with default values is:

O 10.101.102.0/24 [110/2] via 172.16.21.3, 00:06:23, FastEthernet0/1

[110/2] via 172.16.21.4, 00:06:23, FastEthernet0/1

2 = 1 cost to reach the common subnet + 1 cost of SVI vlan1 on both hot site nodes.

if we change SVI vlan1 cost to 10 on HS-Sec-2811 only route via primary router is installed on nodes of primary site.

for original poster Jake:

However, having these equal cost paths is not necessary a bad thing.

so I would consider if keeping this scenario unchanged.

Hope to help

Giuseppe

Agree with Giuseppe. Here is how I interpret OSPF route cost calculation in this case.

OSPF will take cost(BW) of exit interface of each transit router and will add them all to derive complete route cost calculation. Forward route cost may be different from the reverse route cost. In above scenario here is how cost will be calculated in forward and reverse direction

Total cost in Forward direction (From Primary 2811 to hostsite to prefix 10.101.102.0)=

cost of FastEthernet0/1(Exit interface of Primary 2811 for prefix 10.101.102.0 ) + cost of SVI interface (exit interface of primary/secondary hostsite for prefix 10.101.102.0)

Total cost in Reverse direction (From prefix 10.101.102.0 to Primary 2811 prefix)=

cost of FastEthernet0/1(Exit interface of primary/secondary hostsite router) + cost of primary 2811 interface from which traffic is originated.

So to affect forward direction traffic, you can change any constituents interface cost but in your case you can't change f0/1 cost so you need to change SVI cost as Giuseppe suggested.

One thing you should take care while changing forward direction cost alone is asymmetric routing where your reverse traffic will not take same path as forward. You can nullify this effect by making appropriate changes in reverse direction cost.

Thank you everyone for your response. I am sorry I have not responded sooner but the email alerts went to spam so I did not know there were any responses.

So let me see if I understand adding the cost to the interface based on how the cost is calculated will remove both routes since there is a better path over the metro which is why it is best to add a cost to the vlan at the hot site backup router to make it less favorable. That makes some sense even with my limited knowledge. I will test this and let you all know how it goes.

Giuseppe in terms of having both routes I am not sure if this will work because currently only two routers are in one at the primary site and one at the hot site there is also a pix firewall behind each router and there is a vpn between them and I have always heard that this type of routing will break the VPN but with my limited knowledge I am not sure which is why I want it to have one path. Is this true?

Hello Jake,

>> there is also a pix firewall behind each router and there is a vpn between them

After you have added these details I understand your concerns:

however, it depends on how the firewall is interconnected:

if there are two firewalls one behind each router and they are not working in the so called active/active failover but they are independent you need to ensure that paths are symmetric and you should manipulate costs on both client vlans ip subnets on secondary routers on primary site and hot site to build a clear hierarchy of bidirectional paths.

If primary path is alive traffic goes between the devices in primary path.

If the firewall is only one or firewalls and routers share a common subnet that is the outside of the firewalls and the firewall use a standard active/standby failover the following should happen:

only one firewall is active in the network and regardless of the next-hop router traffic is considered legitimate because it comes from the same interface "outside"

So in this second case you don't need to discriminate between two paths on the metroethernet.

Another aspect to be considered is how VPN redundancy is implemented:

Typically VPN can be terminated using an HSRP VIP to make stateful ipsec

Hope to help

Giuseppe

Hello All,

I wish I could have responded sooner but I have been trying to get this up and running. I was told that I should test it in a lab before trying again so I have been using GNS3 but the deadline for me is fast approaching.

Giuseppe the firewalls are stand alone and as you suggested I have done the configuration on the routers that I think will work. I have modified the costs on the vlan interfaces of the standby routers as well as the cost for the redistributed routes, as these also were load balancing.

The HSRP seems to work as well because when I stop the primary router the back up kicks in and the routes are fine. Thank you all for those tips as they have fixed my first problem. However I need to ask another question.

If I shutdown one of the WAN links on the primary router the mock sp metro router that I have starts to load balance again for every route. Why is this? Is it possible to also achieve link redundancy and hardware redundancy with my design? I hope someone can help and I look forward to your responses your help so far has been very much appreciated.

Relevant info is attached.

Hello Jake,

I cannot analyze in depth your topology it would require time.

be aware that OSPF cost is calculated as:

REfBW/interfaceBW [kbps]

def ref BW is 100 Mbps = 10^8 bps

so when you set a bandwith 3000 instead of 10000 you are changing costs also on the backbone facing links not only on the client side.

100000 / 10000 = 10

100000 / 3000 = 33

you can check this with

sh ip ospf interface type x/y

>> If I shutdown one of the WAN links on the primary router the mock sp metro router that I have starts to load balance again for every route

Analyze your topology the costs of each link in the outgoing direction and you should find an explanation.

Hope to help

Giuseppe

Hello Giuseppe

Thanks again for your insight I will analyze more in depth the cost for each route. I am however skeptical that I will be able to do anything about it since the E2 route metrics will always remain the same. I am confused as to why the those E2 routes only load balance when the metro link on the ho pri is shutdown.

I am thinking maybe it's best to fail over to the standby router if any of the links go down on the ho pri router to avoid these load balance issues. Thanks again for all your help.

Hello Jake,

I've missed something I didn't realize you were meaning external routes.

you should use O E1 routes when multiple devices are redistributing the same set of routes into an OSPF domain

The reason is that O E1 routes sum internal cost to reach ASBR node to the seed metric so they are recommended in this case they provide more deterministic behaviour.

O E2 routes can foul routers because they consider seed metric separately.

Hope to help

Giuseppe

Thanks I will give that a try but I think I maybe trying to do too much.

Since both routers have a link to metro I was trying to guard against the cable being unplugged on the primary router to the metro in which case it should start routing to the secondary router. But I realize that chances are the metro will go down from the sp side in that situation everything works as expected.

But if the O E1 routes (not sure how to change them to O E1 but I will figure it out) can guard against the cable being unplugged then I will work with it.

Hello Jake,

router ospf 1

redistribute static metric 40 subnets metric-type 1

Hope to help

Giuseppe