Cisco – Traffic preferring iBGP route over static route

bgpcisco

I have a cisco core switch that is connected directly to our mpls router. It learns about the 172.16.0.0/12 network via iBGP from the mpls router.

We have a lab subnet 172.16.100.0/22 behind a firewall which directly connects to the core switch.

I configured a static route on the core switch for the 172.16.100.0/22 network with the next hop of the firewall.

I cannot ping anything on the 172.16.100.0/22 network from the core switch. The firewall is open so this is not the reason.

However, a traceroute to 172.16.100.253 shows the route being taken via the mpls router.

Is there any reason why the core switch would prefer the iBGP route to 172.16.0.0/12 over the static route to 172.16.100.0/22 ???

Many thanks,

Paul

Best Answer

Based on the limited information you provided, I'd bet that the next hop in your static route isn't reachable (isn't in the routing table). Is the static route to the lab subnet seen in a "show ip route static"?

Would need at least partial configs to troubleshoot more.

Related Solutions

Bgp – Routing traffic out different links from the same BGP AS

Is there a clear definition between site A and site B?

If so then I would look to define a policy on the edge routers to inject a community when receiving routes from the carrier MPLS.

Once this community has been put on the prefixes (say 100:1 for site A and 100:2 for site B) you could then add a policy to each of site A's routers to increase the LP for any routes with community 100:1 and likewise for site B with community 100:2.

This solution would match the requirement of only using BGP and also would be flexible enough to still allow B to use A's uplink if it lost its own uplink to the carrier.

Cisco – traffic engineering – policies for BGP vs static routes

Policy-based routing works great for this. I recently did this to slowly cut over a hospital to a new internet edge one internal subnet at a time in exactly this way.

ip access-list extended PBR_SUBNETS
 permit ip 172.16.1.0 0.0.0.255 any
!
route-map POLICY_ROUTE permit 10
 match ip address PBR_SUBNETS
 set ip next-hop 192.168.1.2

The above will redirect all packets from 172.16.1.0/24 to the IP address specified in the route-map. Change both as needed to fit your situation.

Apply this policy to the router interface that's facing your internal subnets.

interface GigabitEthernet0/1
 ip policy route-map POLICY_ROUTE

This route-map will set the next hop for all permitted traffic, regardless of the routing table. (Use of the "default" keyword can get around this but doesn't sound like you need to) This means that your static route is probably not needed for this purpose, but you can leave it in there as a fallback in case BGP fails.

FYI - the way I did this was to enter the entire configuration, live, during the day, but with no entries in the access list. Since nothing matches, obviously, all traffic behaves normally, following the routing table. This provides for a very easy, testable, reversible framework for switching internal subnets over, since all it takes from this point is just to add them to the ACL.

Best Answer

Related Solutions

Bgp – Routing traffic out different links from the same BGP AS

Cisco – traffic engineering – policies for BGP vs static routes

Related Topic