cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
965
Views
0
Helpful
3
Replies

suboptimal routing for Dual CE to Dual PE

maher
Level 1
Level 1

Hi there,

In addition to this topic, I found quite interesting having this topology, observing network traffic flow. Based on my observation, I noticed that there is a suboptimal routing on this design. Attach network diagram to ease your understanding.

With this type scenario, if prefix 172.16.5.1/32 behind CEB-2 going to 172.16.4.1/32 to CEB-1, it follows to CEHQ network as per below:

CEB-2#traceroute 172.16.4.1 source 172.16.5.1 numeric

Type escape sequence to abort.

Tracing the route to 172.16.4.1

1 161.142.1.21 8 msec 12 msec 36 msec <<---PE2

2 161.142.1.6 16 msec 44 msec 112 msec <<---CEA2

3 192.168.1.1 44 msec 40 msec 24 msec <<---CEA1

4 161.142.1.1 64 msec 52 msec 36 msec <<---PE1

5 161.142.1.18 84 msec * 68 msec <<--CEB-1

Since CEB-1 is connected to PE2, based on sh ip route, it learned via OSPF. Based on my understanding, OSPF wins over iBGP.

PE2-AS1#sh ip route vrf CustomerA 172.16.4.1

Routing entry for 172.16.4.1/32

Known via "ospf 2000", distance 110, metric 194, type intra area <<<---

Redistributing via bgp 1

Advertised by bgp 1 match internal external 1 & 2

Last update from 161.142.1.6 on Serial1/0, 00:19:47 ago <<<---

Routing Descriptor Blocks:

* 161.142.1.6, from 172.16.4.1, 00:19:47 ago, via Serial1/0

Route metric is 194, traffic share count is 1

Where as in BGP table, it installed:

PE2-AS1#sh ip bgp vpn vrf CustomerA 172.16.4.1

BGP routing table entry for 1:102:172.16.4.1/32, version 460

Paths: (2 available, best #1, table CustomerA)

Advertised to update-groups:

1

Local

161.142.1.6 from 0.0.0.0 (10.10.10.102)

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

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

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

mpls labels in/out 38/nolabel

Local, imported path from 1:101:172.16.4.1/32

10.10.10.101 (metric 129) from 10.10.10.101 ( 10.10.10.101)

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

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

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

mpls labels in/out 38/21

How can I force this traffic not going to CEHQ? Any manipulation on the OSPF metric? I tried not to used sham-link because in this scenario, it's not a backdoor link. It seems to be that CEHQ is dual CE connected to dual PE plus another 2 sites more connected to PE which multi homed CEHQ is attached. Is there any possibilities that we could use like SoO in BGP/EiGRP?

Appreciate your comments.

regards,

1 Accepted Solution

Accepted Solutions

swaroop.potdar
Level 7
Level 7

I believe that you need to have a sham link between PE1 and PE2, this would install the BGP learnt route(for CEB1 or B2) into ospf as a intra area route and not a inter area route.

Which would make it comparable to the routes via directly connected CEA routes.

Do give it a try and post the results, if possible i will try to simulate it.

HTH-Cheers,

Swaroop

View solution in original post

3 Replies 3

swaroop.potdar
Level 7
Level 7

I believe that you need to have a sham link between PE1 and PE2, this would install the BGP learnt route(for CEB1 or B2) into ospf as a intra area route and not a inter area route.

Which would make it comparable to the routes via directly connected CEA routes.

Do give it a try and post the results, if possible i will try to simulate it.

HTH-Cheers,

Swaroop

Swaroop,

I have configure sham link between PE1 and PE2. Looks it does work. Below is the output:

CEB-2#traceroute 172.16.4.1 source 172.16.5.1 numeric

Type escape sequence to abort.

Tracing the route to 172.16.4.1

1 161.142.1.21 12 msec 8 msec 20 msec

2 10.10.10.5 56 msec 32 msec 44 msec

3 161.142.1.17 48 msec 36 msec 72 msec

4 161.142.1.18 92 msec * 44 msec

PE2-AS1#sh ip route vrf CustomerA 172.16.4.1

Routing entry for 172.16.4.1/32

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

Redistributing via bgp 1

Advertised by bgp 1 match internal external 1 & 2

Last update from 10.10.10.101 00:02:23 ago

Routing Descriptor Blocks:

* 10.10.10.101 (Default-IP-Routing-Table), from 172.16.4.1, 00:02:23 ago

Route metric is 66, traffic share count is 1

PE2-AS1#sh ip bgp vpn vrf CustomerA 172.16.4.1

BGP routing table entry for 1:102:172.16.4.1/32, version 695

Paths: (2 available, best #1, table CustomerA)

Advertised to update-groups:

1

Local

161.142.1.6 from 0.0.0.0 (10.10.10.102)

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

Extended Community: SoO:1:1 RT:1:100

OSPF DOMAIN ID:0x0005:0x000007D00200 OSPF RT:0.0.0.0:2:0

OSPF ROUTER ID:161.142.1.5:512,

mpls labels in/out 27/nolabel

Local, imported path from 1:101:172.16.4.1/32

10.10.10.101 (metric 129) from 10.10.10.101 (10.10.10.101)

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

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

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

mpls labels in/out 27/21

I'm confuse a bit with the result. I've read about SoO - not to advertised back routes learnt and also domain-tag for OSPF but does not seems to work. Any ideas the connection between those features?

thanks again.

Maher, SOO would be in effect if you have BGP as the PE-CE, in OSPF you would have down bit set, so the route learnt via MPBGP is not sent back into MPBGP.

The domain tag is not configured defaults to your ospf process id.

Now from the inputs what I learn is that you have configured the same process id for both the sites, hence at PE1 or PE2 the routes are getting learnt via ospf between the sites(like in vrf lite/ multiple vrf interfaces belong to the same ospf vrf process) and hence the MPBGP route was not being preferred, as it gets treated as a inter area route.

HTH-Cheers,

Swaroop