Re: OSPF Multihoming creates suboptimal routing

maher · ‎10-12-2008

Hi NetPro,

I'm having situation whereby my customer CE2 is running multihoming. Both links need to be up all the times. However, on site, which is CE3 connected to the same PE (PE3). Attach network diagram to ease reference.

From CE3 going to CE2 of course it does follow directly based on OSPF 110 AD due to MP-iBGP 200 AD.

pe3#sh ip route vrf vpn 2.2.2.2

*Mar 1 04:05:29.438: %SYS-5-CONFIG_I: Configured from console by console

pe3#sh ip route vrf vpn 192.168.2.1

Routing entry for 192.168.2.1/32

Known via "ospf 2000", distance 110, metric 65, type intra area

Redistributing via bgp 100

Advertised by bgp 100

Last update from 172.16.4.2 on Serial0/1, 00:35:39 ago

Routing Descriptor Blocks:

* 172.16.4.2, from 192.168.2.1, 00:35:39 ago, via Serial0/1

Route metric is 65, traffic share count is 1

pe3#sh ip bgp vpn vrf vpn 192.168.2.1

BGP routing table entry for 100:100:192.168.2.1/32, version 169

Paths: (2 available, best #2, table vpn)

Advertised to update-groups:

1

Local

10.10.10.2 (metric 30) from 10.10.10.2 (10.10.10.2)

Origin incomplete, metric 65, localpref 100, valid, internal

Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000007D00200

OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:172.16.2.1:512,

mpls labels in/out 25/28

Local

172.16.4.2 from 0.0.0.0 (10.10.10.3)

Origin incomplete, metric 65, localpref 100, weight 32768, valid, sourced, best

Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000007D00200

OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:172.16.4.1:512,

mpls labels in/out 25/nolabel

How do I manipulate this behaviour forcing the traffic should go via MP-iBGP? Tried to do sham-links and distance command, but seems not to be working.

Appreciate your feedback on this issue.

Thanks.

Giuseppe Larosa · ‎10-12-2008

Hello Ahmad,

>> How do I manipulate this behaviour forcing the traffic should go via MP-iBGP? Tried to do sham-links and distance command, but seems not to be working

Sham-links are useful to manage backdoor horizontal links between different VRF sites with OSPF running over them.

I don't understand from your picture if CE2 and CE3 have a direct link between them without going via service-providers links.

I suppose there isn't a direct link CE2-CE3.

Traffic from CE3 to 192.168.2.1/32 arrives on PE3 and is routed to PE3 to CE2 link just using the OSPF instance in VRF.

pe3#sh ip route vrf vpn 192.168.2.1

Routing entry for 192.168.2.1/32

Known via "ospf 2000", distance 110, metric 65, type intra area

even in the BGP table the BGP advertisement locally generated is preferred over the one that comes from other PE:

Local

172.16.4.2 from 0.0.0.0 (10.10.10.3)

Origin incomplete, metric 65, localpref 100, weight 32768, valid, sourced, best

this is the result of redistribute OSPF into BGP address-family ipv4 vrf VPN.

How you could do:

in the BGP table you could increase to 40000 the weight of BGP advertisements coming from other PE router (using a route-map on incoming vpnv4 updates in vpnv4 AF).

you need also if supported to increase the AD of OSPF learned route to 201.

This should allow you to achieve the result : BGP route via other PE is preferred and so BGP will propose that.

The process that manages the VRF VPN routing table will compare the BGP route to the OSPF route (with an increased AD) the BGP route should win and be installed

note: a collateral effect could be that PE3 will not advertise net 192.168.2.1/32 over vpnv4 to other PEs because its best path is now via PE2. This can be a worse drawback then the one you see now.

Edit:

On CE2 you may need to increase ip ospf cost on interface towards PE3 so that path via PE2 is preferred this completes the solution also for the other direction.

Another idea could be to use a different VRF for PE3-CE2 link with a different RD and import and exporting the same RT.

This could allow a greater control using an import-map.

I would suggest to accept this behavior that comes from the topology you have built for the customer.

Hope to help

Giuseppe

maher · ‎10-12-2008

Hi Giuseppe,

Thanks for the feedback. CE2 and CE3 have a leased line to PE3. There is no direct horizontal between CE2 and CE3.

Yes. I have changed as per your suggestion and look OK so far :)

pe3#sh ip route vrf vpn 192.168.2.1

Routing entry for 192.168.2.1/32

Known via "bgp 100", distance 200, metric 65, type internal

Redistributing via ospf 2000

Advertised by bgp 100 (self originated)

ospf 2000 subnets

Last update from 10.10.10.2 00:05:46 ago

Routing Descriptor Blocks:

* 10.10.10.2 (Default-IP-Routing-Table), from 10.10.10.2, 00:05:46 ago

Route metric is 65, traffic share count is 1

AS Hops 0

pe3#sh ip bgp vpn vrf vpn 192.168.2.1

BGP routing table entry for 100:100:192.168.2.1/32, version 204

Paths: (1 available, best #1, table vpn)

Not advertised to any peer

Local

10.10.10.2 (metric 30) from 10.10.10.2 (10.10.10.2)

Origin incomplete, metric 65, localpref 100, weight 40000, valid, internal, best

Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000007D00200

OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:172.16.2.1:512,

mpls labels in/out nolabel/28

The drawback as per your note can be seen from PE1 perspective.

pe1#sh ip bgp vpn vrf vpn 192.168.3.1

BGP routing table entry for 100:100:192.168.3.1/32, version 65

Paths: (1 available, best #1, table vpn)

Not advertised to any peer

Local

10.10.10.2 (metric 30) from 10.10.10.2 (10.10.10.2)

Origin incomplete, metric 193, localpref 100, valid, internal, best

Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000007D00200

OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:172.16.2.1:512,

mpls labels in/out nolabel/29

Now, CE1 going to CE3 have to go through PE2 travel to CE2 up to PE3 and reach final destination of CE3. Yiks! :)

Thanks again.

maher · ‎10-12-2008

I tried to use different VRF on CE2-PE3 link with different RD and VRF but import/exporting same RT.

So far so good :) Thanks for your input and suggestion!

pe3#sh ip bgp vpn vrf vpn 192.168.2.1

BGP routing table entry for 100:100:192.168.2.1/32, version 242

Paths: (1 available, best #1, table vpn)

Flag: 0x800

Not advertised to any peer

Local

10.10.10.2 (metric 30) from 10.10.10.2 (10.10.10.2)

Origin incomplete, metric 65, localpref 100, valid, internal, best

Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000007D00200

OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:172.16.2.1:512,

mpls labels in/out nolabel/28

pe3#sh ip route vrf vpn 192.168.2.1

Routing entry for 192.168.2.1/32

Known via "bgp 100", distance 200, metric 65, type internal

Redistributing via ospf 2000

Advertised by ospf 2000 subnets

Last update from 10.10.10.2 00:00:39 ago

Routing Descriptor Blocks:

* 10.10.10.2 (Default-IP-Routing-Table), from 10.10.10.2, 00:00:39 ago

Route metric is 65, traffic share count is 1

AS Hops 0

From PE1 as well look to be OK.

pe1#sh ip bgp vpn vrf vpn 192.168.3.1

BGP routing table entry for 100:100:192.168.3.1/32, version 75

Paths: (1 available, best #1, table vpn)

Not advertised to any peer

Local

10.10.10.3 (metric 30) from 10.10.10.3 (10.10.10.3)

Origin incomplete, metric 65, localpref 100, valid, internal, best

Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000007D00200

OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:172.16.4.1:512,

mpls labels in/out nolabel/23

pe1#sh ip route vrf vpn 192.168.3.1

Routing entry for 192.168.3.1/32

Known via "bgp 100", distance 200, metric 65, type internal

Redistributing via ospf 2000

Advertised by ospf 2000 subnets

Last update from 10.10.10.3 00:08:48 ago

Routing Descriptor Blocks:

* 10.10.10.3 (Default-IP-Routing-Table), from 10.10.10.3, 00:08:48 ago

Route metric is 65, traffic share count is 1

AS Hops 0

Giuseppe Larosa · ‎10-12-2008

Hello Ahmad,

thanks for your kind remarks I'm happy my suggestions have been helpful for your issue.

Best Regards

Giuseppe