PBR using Route-map to Match only BGP Learned Routes

Answered Question
Jun 11th, 2009
User Badges:

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.

Correct Answer by Harold Ritter about 7 years 9 months ago

John,


Since PBR can only act on the packets being forwarded you need to relate these packets to BGP somehow. One way to do that would be to use QOS Policy Propagation via BGP (QPPB) feature. This would allow you to set a given precedence to prefixes learned via BGP. You could then do a PBR match on an extended ACL with the proper precedence that has been set by QPPB.


int

ip policy route-map TEST

/* this will set the precedence to 2 for all destination previously set by the BGP table-map */

bgp-policy destination ip-prec-map


router bgp xxx

/* this will set ip precedence 2 to all cef entries for BGP learned prefixes */

table-map set_prec

route-map set_prec permit 10

set ip precedence immediate (2)


ip access-list extended ROUTE_MAP

permit tcp any any eq www precedence 2


route-map TEST permit 10

match ip address ROUTE_MAP

set interface Serial3/0


Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (6 ratings)
Loading.
Jon Marshall Thu, 06/11/2009 - 13:04
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

John


Once it matches the first "match" statement then it immediately jumps to the set clause and that's why all traffic is going via s3/0.


Try this instead


route-map TEST permit 10

match ip address ROUTE-MAP

continue 20

route-map TEST permit 20

match source-protocol bgp 13979

set interface s3/0


Jon

j.drosyk_2 Thu, 06/11/2009 - 13:08
User Badges:

Jon,

Thanks. For some reason I thought if all match statements were on the same line of the route-map, it would use "AND" logic. I will try that this evening. I want to make sure though that the route-map you suggests will not match for all ip traffic from learned BGP routes.


Thanks

Jon Marshall Thu, 06/11/2009 - 13:13
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

John


"I want to make sure though that the route-map you suggests will not match for all ip traffic from learned BGP routes."


That depends on what you have in the acl that you use in your route-map.


Jon

j.drosyk_2 Thu, 06/11/2009 - 13:18
User Badges:

If the configuration is:


ip access-list extended ROUTE_MAP

permit tcp any any eq www


and


route-map TEST permit 10

match ip address ROUTE-MAP

continue 20

route-map TEST permit 20

match source-protocol bgp 13979

set interface s3/0


I want to make sure that the above configuration will only "match" if both scenarios are met. I do not want the set command to be active on traffic that is not TCP 80 going to BGP learned routes. Will the configuration above achieve this?


Thanks again for your assistance.

Jon Marshall Thu, 06/11/2009 - 13:58
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

John


In the process of testing this and getting some odd results. Don't apply the config i posted as it seems to block other IP traffic.


Will update you after i've done some more testing.


Jon

Jon Marshall Thu, 06/11/2009 - 13:15
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

John


Actually that's a good point. I will have to lab that up to test :-)


Jon

Harold Ritter Thu, 06/11/2009 - 14:00
User Badges:
  • Cisco Employee,

John,


"source-protocol" is not a valid match condition in the PBR context. PBR can only match against the packet being forwarded, not against the routing table. Please refer to the following document for a valid PBR match conditions. In short, you can match using a standard or extended ACL and with more recent versions you can also match on packet length.


http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800a4409.shtml#wp14040



Regards

j.drosyk_2 Thu, 06/11/2009 - 14:08
User Badges:

Interesting. I guess the "source-protocol" match feature is limited to only routing protocol manipulation. I was hoping it would be able to match not only on ACL but how the routes were learned. I might have to rethink the route-map all together. Is there any other distinguishing characteristic of a BGP route over a static or eigrp?

Correct Answer
Harold Ritter Thu, 06/11/2009 - 15:27
User Badges:
  • Cisco Employee,

John,


Since PBR can only act on the packets being forwarded you need to relate these packets to BGP somehow. One way to do that would be to use QOS Policy Propagation via BGP (QPPB) feature. This would allow you to set a given precedence to prefixes learned via BGP. You could then do a PBR match on an extended ACL with the proper precedence that has been set by QPPB.


int

ip policy route-map TEST

/* this will set the precedence to 2 for all destination previously set by the BGP table-map */

bgp-policy destination ip-prec-map


router bgp xxx

/* this will set ip precedence 2 to all cef entries for BGP learned prefixes */

table-map set_prec

route-map set_prec permit 10

set ip precedence immediate (2)


ip access-list extended ROUTE_MAP

permit tcp any any eq www precedence 2


route-map TEST permit 10

match ip address ROUTE_MAP

set interface Serial3/0


Regards

j.drosyk_2 Sun, 06/14/2009 - 16:58
User Badges:

Harold,

You sir have too much time on your hands ;). The solution you proposed totally resolved my issue. I gns3'ed a simulation network recreating my issue, then using your solution and it worked. I was worried that I might need the bgp-policy destination ip-prec-map, the table-map set_prec, and the route-map set_prec on every ibgp peer in my network, but I did not. I really appreciate the help. I also appreciate the help from Jon and anyone else who posted.


Thanks again.

Harold Ritter Sun, 06/14/2009 - 18:26
User Badges:
  • Cisco Employee,

John,


I know, I should get a life ;-) I am glad the proposed solution worked for you.


Regards

j.drosyk_2 Tue, 06/16/2009 - 10:47
User Badges:

Harold,

I found an issue with my lab that was giving me incorrect results for this solution. I fixed it and now I see an issue with your solution. It is not working on traffic originating on the host network going to the remote networks. However, traffic originating on a remote network traveling to the host network works great. I am only advertising network 0.0.0.0 to the remote sites, and they are advertising /24 networks back. Let me know what you think and again, I appreciate the help.

Harold Ritter Tue, 06/16/2009 - 11:04
User Badges:
  • Cisco Employee,

John,


Could you please help me understand the traffic flows that work and those that don't with a simple diagram.


Which networks do we learn via BGP?


Regards

Harold Ritter Tue, 06/16/2009 - 12:12
User Badges:
  • Cisco Employee,

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 Tue, 06/16/2009 - 13:43
User Badges:

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 Tue, 06/16/2009 - 16:06
User Badges:
  • Cisco Employee,

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 Tue, 06/16/2009 - 17:22
User Badges:

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



Attachment: 
Harold Ritter Tue, 06/16/2009 - 19:00
User Badges:
  • Cisco Employee,

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 Thu, 06/18/2009 - 06:25
User Badges:

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 Fri, 06/19/2009 - 06:29
User Badges:

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 Fri, 06/19/2009 - 09:38
User Badges:
  • Cisco Employee,

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 Fri, 06/19/2009 - 10:07
User Badges:

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 Fri, 06/19/2009 - 13:17
User Badges:
  • Cisco Employee,

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 Sat, 06/20/2009 - 07:42
User Badges:

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 Tue, 06/23/2009 - 04:05
User Badges:
  • Cisco Employee,

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 Tue, 06/23/2009 - 04:12
User Badges:

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.

Jon Marshall Thu, 06/11/2009 - 14:08
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Harold


Oops, thanks for sorting that out.


John, apologies for the mistake.


Jon

Actions

This Discussion