PBR using Route-map to Match only BGP Learned Routes

[j.drosyk_2]

I have a 7200VXR running static, eigrp, and ibgp/ebgp. This router has a LAN interface and two serial interfaces each attached to a DS3. I have a route-map that I believe should be using "AND" logic which must match all conditions for the route action to take place. The match conditions are an access-list and only routes that are learned via BGP. My goal is not to affect any routes that are connected, static or learned via eigrp. However, all TCP 80 traffic is somehow matching the route-map. Below is a sanitized config.

interface GigabitEthernet0/1

ip address 10.10.10.10 255.255.255.0

ip policy route-map TEST

interface Serial2/0

description DS3-1

ip address 20.20.20.20 255.255.255.0

interface Serial3/0

description DS3-2

ip address 30.30.30.30 255.255.255.0

ip access-list extended ROUTE_MAP

permit tcp any any eq www

route-map TEST permit 10

match ip address ROUTE_MAP

match source-protocol bgp 13979

set interface Serial3/0

As it is sits right now, all TCP 80 traffic is going out serial3/0. I want only TCP 80 traffic for remote routes learned via BGP to go out serial3/0 and all other traffic to route normally. Any help would be appreciated.

[j.drosyk_2]

I did a very basic diagram. Let me know if I need to elaborate on anything.

[Harold Ritter]

John,

Here are a few questions for you.

- If I understand the logic correctly, you want to forward all traffic, which source address is being learned via BGP and destination port is equal to 80, down interface se3/0, correct?

- In your diagram, I only see prefix 10.10.10.0/24 being learned via BGP. Is that correct?

- The PBR works on inbound traffic only. The "ip policy" statement is applied on Gig0/1, so only traffic coming from this interface will be policy based routed. Is that what you want.

Regards

[j.drosyk_2]

Hey Harold,

To answer your questions:

1. I want to forward numerous types of traffic destined to a remote /24 network learned via BGP down s3/0. I just opened the thread on TCP 80. I figured if that worked, than the others would too. I have also added icmp to the PBR ACL for testing.

2. There are many /24 network being learned. 10.10.10.0/24 is generic.

3. PBR is applied to gi0/1. I want PBR to work on all traffic destined for a /24 network learned via BGP. This includes traffic originating on the host network going to a /24 or return traffic to a /24. Currently the PBR ACL is only matching on return traffic to a /24 network. It needs to match anytime traffic enters gi0/1 and is destined for a /24 not just return traffic to a /24.

Let me know if this helps.

Thanks

[Harold Ritter]

John,

Thanks for the additional info. Here is a quote from one of your previous posts:

"However, traffic originating on a remote network traveling to the host network works great."

Did you mean traffic traveling back from host network to remote network?

Could you post the config for the home router.

Regards

[j.drosyk_2]

Yes. Return traffic to a remote /24 network matches the PBR ACL. However traffic originating from the host network destined for a remote /24 network does not match the PBR ACL.

Let me give you an example: If you telnet from a layer 3 switch to a /24 network, it will not match the PBR ACL and will not make it to the remote network. If you telnet from a remote network router to a layer 3 switch, it will match the PBR ACL and the return traffic will show matches on the PBR ACL.

The test host router config is attached. The route to null 0 is to verify that traffic being routed to a remote network is done by PBR and not by normal BGP routing.

Thanks

[Harold Ritter]

John,

The configuration looks fine. What IOS version are you running on the host router. What HW platform is it?

Could you run a quick test. Enable "debug ip policy" on the host router and ping one of the addresses belonging to one of the BGP received prefixes to see if it kicks in. Could you also post a "show ip cef " for the same prefix.

Regards

[j.drosyk_2]

Hey Harold,

Thanks to the debug and show statements, I realized that my issue might be a bit more complicated. I tried to not put too much into describing the topology of the network. However, the show ip cef made me understand that I will need to be a bit more descriptive.

Each remote site has two connections back to the host, a T1 and a broadband connection with an IPSec tunnel. On the host, it has a DS3 and a connection to a IPSec appliance. The IPSec appliance and the host router are running an interior routing protocol. Those routes are being added to the host routing table and not the BGP learned routes. That is why I am trying to run PBR to force certain traffic down the DS3 connection and let default routing send the rest of the traffic to the IPSec appliance.

When I did a show ip cef i see it coming from the IPSec appliance and not BGP. I believe this is the hang up. I tried it again in my test lab and the debug ip policy shows that your solution works. Sorry for not mentioning this before. I was trying to keep it as simple as I could, but it seems I have actually made it more complicated.

Thanks again.

[j.drosyk_2]

Here is a more acurate topology.

[j.drosyk_2]

Hey Harold,

I appreciate your help. I don't expect you to continue to try and resolve this issue. I might just have to find another piece of hardware or something in order for the PBR to work. If you want to continue helping me I would appreciate it, but I also understand if this is getting old.

Thanks

[Harold Ritter]

Hi John,

Sorry for the delay. I can sure help you solve this issue. I just need to better understand what you are trying to achieve. The additional information you provided makes me wonder what it is exactly you are trying to achieve.

Here's a few questions:

1- You receive the exact same route from the remote site via both BGP and IGP, right?

2- What is your policy on whether the traffic needs to go through the BGP or the IGP path?

Please provide additional information on what the routing policy need to be.

Regards

[j.drosyk_2]

Hey Harold,

Here are the answers to your questions.

1. Yes, the same routes are being learned via IGP and BGP. I have adjusted my BGP distances on the host router to enter IGP routes over BGP.

2. To answer this question i will break down the ultimate goal with solution. Our host router has a DS3 to an old frame network, a DS3 to a new MPLS network, and a connection to an IPSec appliance. An old frame site is being routed via static routes. The old frame sites are being migrated to the new MPLS network. Remote sites on the new MPLS network have two connection back to the host network now, instead of one. We are using PBR in order to use both links at the same time, while also being able to somewhat priortize traffic reliability. Certain web applications are being policy routed over the MPLS connection. Other non-time sensitive or bursty traffic is being sent out the broadband connection in an IPSec tunnel. The default route when both connections are active is the broadband route, since identifying a handful of internal web apps is much easier. The only issue with this solution is that is is also affecting the static routed sites still on the old frame network. If I can somehow only affect the IGP/BGP routes with PBR, that would be great. But with time, this issue becomes less and less important, since eventually all sites will be on the new MPLS network and the PBR that is currently on will work as it should.

Let me know if this helps.

[Harold Ritter]

John,

It makes much more sense now that I have the additional information ;-)

I think the PBR and QPPB technique I described could still work in this context but you would need to have the BGP route to be installed in the RIB though rather than the IGP route. You could then use the following route-map to achieve your goal:

ip access-list extended VIA_MPLS_CLOUD

permit tcp any any eq www precedence 2

ip access-list extended VIA_IPsec_Appliance

permit ip any any precedence 2

route-map TEST permit 10

match ip address VIA_MPLS_CLOUD

set interface

route-map TEST permit 20

match ip address VIA_IPsec_Appliance

set interface

The first instance of the route-map would match TCP traffic to port 80 (or whatever else you decide to forward via the MPLS core).

The second instance would match on everything else destined to a remote network connected via the new network.

The traffic going to a remote site via the old network (static route) would not match any of the route-map instance and would be routed according to the routing table.

Let me know if this makes sense.

Regards

[j.drosyk_2]

Hey Harold,

That makes perfect sense. I tested it in my lab and does work, however I see one issue. There is no built in mechanism for failover for an IPSec network learn via IGP. Failover does still work for BGP.

Currently failover works like this:

Core network, IPSec appliance and Host router all participate in IGP and BGP. The core network enters BGP routes into table first, so all initial traffic is sent to Host router by default. Host router enters IGP networks into table first, then policy routes everything else out the MPLS link. If a BGP network were to go away, the core network would not forward that traffic to the host router anymore, but forward it straight to the IPSec appliance. If an IGP network were to go away, the core network would still forward the traffic to the host router. The host router would policy route as normal, then the traffic not matching the policy would route via the routing table, which at this point, would not have the IGP route entered, but the BGP. So failover of both connections is working now.

With the solution presented, if an IGP route were to not be available, that traffic would still be sent to the IPSec appliance, which would more than likely drop it.

Let me know what you think. And thanks for all the help. Have a cold one for me this weekend ;).

[Harold Ritter]

John,

It looks like your scenario is getting very complicated. PBR offers nice functionality but can easily become overwhelming in a scenario like the one you exposed. Have you considered using BGP for both the IPsec and the MPLS paths and then load share per flow over these two path.

Regards

[j.drosyk_2]

I have, but the IPSec appliance cannot run BGP. Yes, this scenario is a bit complicated, but gets less each day that passes. By the end of July, this will no longer be an issue and the current PBR will work as designed. I was just trying to find a way to run the dual networks with PBR while we are in a transitional period. Again, Harold, I appreciate all of your help. The QoS via BGP was something I had never heard of before. It is a technology I know I will use now.

Thanks man.