Traffic to GOOGLE goes through the path C - A - GOOGLE, so there is nothing to do.
C#traceroute 8.8.8.8 source 3.0.0.1 numeric
<..>
VRF info: (vrf in name/id, vrf out name/id)
1 111.91.76.61 1 msec 0 msec 0 msec
2 10.0.8.1 1 msec * 1 msec
Let's assume that IDEA and BHARTI upstream announce the same prefix for Internet 6.0.0.0/24 with same metrics (actually this should never) happen, but we need this for testing and simplicity. IDEA has IP address 6.0.0.1 and BHARTI has IP address 6.0.0.2. So we will check both of them to determine which path takes traffic to and from router C.
C#traceroute 6.0.0.1 source 3.0.0.1 numeric
<..>
VRF info: (vrf in name/id, vrf out name/id)
1 111.91.76.61 6 msec 5 msec 6 msec
2 10.0.2.2 6 msec * 2 msec
C#traceroute 6.0.0.2 source 3.0.0.1 numeric
<..>
VRF info: (vrf in name/id, vrf out name/id)
1 111.91.76.61 0 msec 0 msec 1 msec
2 10.0.2.2 1 msec 1 msec 0 msec
3 * *
C#ping 6.0.0.1 so
C#ping 6.0.0.1 source 3.0.0.1
<..>
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
C#ping 6.0.0.2 source 3.0.0.1
<..>
..
Success rate is 0 percent (0/2)
Here we see that "Internet" traffic from router C takes path C - A - IDEA, while we need C - B - A - IDEA.
Now we will modify BGP path attributes only on routers A and B, since they are under our control. I will make as little changes as possible to default BGP decision process to reduce overall network impact.
The easiest thing is to manipulate AS_PATH LENGTH attribute on router A - we will prepend our AS38457 once to all routes except google's when advertising to router C.
Now we have:
C#sh ip bgp
<..>
* 6.0.0.0/24 111.91.76.253 0 38457 3333 i
*> 111.91.76.61 0 38457 2222 i
Through router A.
ip prefix-list PL-google permit 8.8.8.0/24
route-map RM-prepend-once-inet permit 10
match ip address prefix-list PL-google
route-map RM-prepend-once-inet permit 20
set as-path prepend 38457
router bgp 38457
neighbor 111.91.76.62 route-map RM-prepend-once-inet out
And after these chages:
C#ip bgp clear 111.91.76.61
C#sh ip bgp
* 6.0.0.0/24 111.91.76.61 0 38457 38457 2222 i
*> 111.91.76.253 0 38457 3333 i
*> 8.8.8.0/24 111.91.76.61 0 38457 22859 i
Return traffic from router C to internet changed it's direction to B. Also note, that google's route is not affected.
But now we have another problem - since route decisions are made hop-by-hop, internet traffic from router C goes through router BGP to BHARTI upstream:
C#ping 6.0.0.1 source 3.0.0.1
<..>
..
Success rate is 0 percent (0/2)
C#ping 6.0.0.2 source 3.0.0.1
<..>
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
C#traceroute 6.0.0.1 source 3.0.0.1 numeric
<..>
VRF info: (vrf in name/id, vrf out name/id)
1 111.91.76.253 5 msec 5 msec 0 msec
2 10.0.5.1 0 msec 0 msec 0 msec
3 *
C#traceroute 6.0.0.2 source 3.0.0.1 numeric
<..>
VRF info: (vrf in name/id, vrf out name/id)
1 111.91.76.253 1 msec 1 msec 0 msec
2 10.0.5.1 1 msec * 1 msec
So we need to make router B prefer path through router A but only for networks from router C. Here we can use PBR:
ip prefix-list PL-c-networks seq 5 permit 3.0.0.0/24
route-map RM-c-networks-via-A permit 10
match ip address prefix-list PL-c-networks
set ip next-hop 10.1.1.1
interface Ethernet0/1
ip policy route-map RM-c-networks-via-A
And now let's check:
C#ping 6.0.0.1 source 3.0.0.1
<..>
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
C#ping 6.0.0.2 source 3.0.0.1
<..>
..
Success rate is 0 percent (0/2)
C#traceroute 6.0.0.1 source 3.0.0.1 numeric
<..>
VRF info: (vrf in name/id, vrf out name/id)
1 111.91.76.253 0 msec 4 msec 8 msec
2 10.1.1.1 0 msec 1 msec 0 msec
3 10.0.2.2 1 msec * 3 msec
C#traceroute 6.0.0.2 source 3.0.0.1 numeric
<..>
VRF info: (vrf in name/id, vrf out name/id)
1 111.91.76.253 5 msec 6 msec 3 msec
2 10.1.1.1 1 msec 0 msec 1 msec
3 10.0.2.2 1 msec 0 msec 1 msec
4 * * *
5 *
Nice, that's exact what we need. Also, good news - if e0/0 on A or B will fail, normal, PBR-less routing will work, I checked:
B#debug ip policy
Policy routing debugging is on
B#
*Apr 12 07:48:51.771: IP: s=3.0.0.1 (Ethernet0/1), d=6.0.0.1, len 100, FIB policy match
*Apr 12 07:48:51.771: IP: s=3.0.0.1 (Ethernet0/1), d=6.0.0.1, len 100, PBR Counted
*Apr 12 07:48:51.771: CEF-IP-POLICY: fib for addr 10.1.1.1 is Not Attached; Nexthop rejected
*Apr 12 07:48:51.771: IP: s=3.0.0.1 (Ethernet0/1), d=6.0.0.1, len 100, FIB policy rejected - normal forwarding
But interface may not fail, while IP connectivity could be lost and interface state is up/up - to avoid such situation you will need to write IP SLA rules - do it yourself, since I'm lazy ;)
At this point we corrected how traffic travels from C through network. And now we want traffic from IDEA to travel the same way IDEA - A - B - C, let's check:
IDEA#traceroute 3.0.0.1 source 4.0.0.1 numeric
<..>
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.2.1 5 msec 2 msec 5 msec
2 111.91.76.62 1 msec * 3 msec
IDEA - A - C, let's correct this by changing Local Preference path attribute on router B for networks announced from C. This gives the routers inside a single AS (A and B in our situation) a value that they can send per-route and advertise to all iBGP routers inside the AS, so that all routers in the AS agree about which router is the best exit point for packets destined for that prefix. By design, LocPrf can be set by routers as they receive eBGP routes by using an inbound route map (c) CCNP ROUTE :)
Now we see:
A>sh ip bgp
<..>
* i 3.0.0.0/24 111.91.76.254 0 100 0 45415 i
*> 111.91.76.62 0 0 45415 i
We need to set LocPrf for network 3.0.0.0/24 higher than 100 on B:
route-map RM-c-networks-set-LocPrf-150 permit 10
match ip address prefix-list PL-c-networks
set local-preference 150
router bgp 38457
neighbor 111.91.76.254 route-map RM-c-networks-set-LocPrf-150 in
Check:
A#clear ip bgp 10.1.1.2
A#sh ip bgp
<..>
* i 3.0.0.0/24 111.91.76.254 0 150 0 45415 i
*> 111.91.76.62 0 0 45415 i
Still wrong way, because next-hop 111.91.76.254 is not reachable, which is checked before LocPrf. Add some cosmetic on B:
router bgp 38457
neighbor 10.1.1.1 next-hop-self
Check again:
A#clear ip bgp 10.1.1.2
A#sh ip bgp
<..>
*>i 3.0.0.0/24 10.1.1.2 0 150 0 45415 i
* 111.91.76.62 0 0 45415 i
That's what we wanted to do, now check from IDEA's perspective:
IDEA#ping 3.0.0.1 source 4.0.0.1
<..>
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
IDEA#traceroute 3.0.0.1 source 4.0.0.1 numeric
<..>
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.2.1 5 msec 5 msec 5 msec
2 10.1.1.2 1 msec 0 msec 0 msec
3 111.91.76.254 1 msec * 2 msec
Good. Seems we've achieved what you wanted.
In conclusion - do not accept this solution as ready-to-use, since I do not know all your infrastructure and there may be better
implementations of the same task. If you administer such a network for a long time I would recommend to read, do all the labs and pass CCNP
ROUTE exam, it costs spending time and money, you will be more confident with such cases.
Good luck!
