12-10-2007 05:28 AM
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,
Solved! Go to Solution.
12-10-2007 08:07 AM
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
12-10-2007 08:07 AM
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
12-10-2007 08:59 AM
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.
12-11-2007 07:58 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide