Policy Based Routing

Chris_Chris_ Member Posts: 326
in CCNP
Hi Guys,
I have been working through the CBT nuggets for ROUTE and the associated labs that come with them. I've just gone through Policy routing and have a few queries.

In the PBR lab I was doing, the scenario is that 2 clients are connected to a router that is connected 2 different ISPs.

The first objective is:
"Client1 surfs the Internet all day doing nothing productive. All traffic from this client should route out ISP2, which is a slower Internet connection. If ISP2 is down, Client1 should not be able to access the Internet."
the first part of this is easy enough using an access-list and route map
ip access-list extended client_1
 permit ip host 192.168.1.20 any
 
route-map POLICY permit 10
 match ip address client_1
 set ip next-hop 201.1.1.2
 
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip policy route-map POLICY

This forces any traffic from client 1 to use next hop 201.1.1.2, but does not complete the second part of the objective "If ISP2 is down, Client1 should not be able to access the Internet."

In the CBT nugget Jeremy configured the access-list and route-map the same as I did and said that the objective was achieved.. But he did not not verify the behaviour if ISP 2 was failed.

My understanding of PBR is that if the specified next hop is in the routing table, then the PBR is applied and the packet is forwarded to that next hop
But...
If the specified next hop is not in the routing table then PBR is ignored and the packet is forwarded as per the routing table, ISP1 in this case. I have verified that this is the behaviour in the lab if I fail the connection to ISP 2

So, my question is: What is the best way to achieve this objective?
I have tried 2 ways, which both seem to work:

1. set an access-list on the alternative exit interfaces(ISP1), denying client 1's IP - so if ISP2 fails the PBR will be ignored, as the specified next hop is no longer valid, and the router will fall back to using the routing table. However, the access-list will prevent the packet leaving from the interface specified in the routing table

2. I added a second set statement to the route-map, setting the output interface to Null0, effectively discarding the packet. 
 route-map policy permit 10
  match ip address client_1
  set ip next-hop 201.1.1.2
  set interface Null0

I think that this is effectively saying:

IF address is matched by the access-list
AND the specified next-hop address is in the routing table
THEN forward the packet to the specified next-hop
ELSE forward the packet to the interface Null0

Am i right about this? and are either of these methods valid, efficent ways of achieving the objective?

as always, your comments are appreciated
Going all out for Voice. Don't worry Data; I'll never forget you
:study: CVoice [X] CIPT 1 [ ] CIPT 2 [ ] CAPPS [ ] TVOICE [ ]
· Share on FacebookShare on Twitter

Comments

  • tomaifauchaitomaifauchai Member Posts: 301 ■■■□□□□□□□
    Have you tried this
    route-map policy permit 10   
 match ip address client_1   
 set ip next-hop 201.1.1.2 verify-availability
route-map policy deny 20
    · Share on FacebookShare on Twitter
  • MonkerzMonkerz Member Posts: 842
    Chris_ wrote: »
    This forces any traffic from client 1 to use next hop 201.1.1.2, but does not complete the second part of the objective "If ISP2 is down, Client1 should not be able to access the Internet."

    In the CBT nugget Jeremy configured the access-list and route-map the same as I did and said that the objective was achieved.. But he did not not verify the behaviour if ISP 2 was failed.

    Unless I am mistaken, Jeremy did not state that he was using a routing protocol or any static or default routes. So without configuring a routing protocol, a default route or any static routes, how would the router know to use a different link or next hop, from source Client1 and destination (one of 2.1 billion Public IPs), besides the one defined in the route-map?

    As far as I can tell, the host (Client1) sends traffic to it's default gateway because the destination is outside it's subnet. The policy running on Fa0/0 forwards Client1's traffic to ISP2, if ISP2 is not available the packets are dropped.
    · Share on FacebookShare on Twitter
  • Chris_Chris_ Member Posts: 326
    Monkerz wrote: »
    Unless I am mistaken, Jeremy did not state that he was using a routing protocol or any static or default routes. So without configuring a routing protocol, a default route or any static routes, how would the router know to use a different link or next hop, from source Client1 and destination (one of 2.1 billion Public IPs), besides the one defined in the route-map?

    As far as I can tell, the host (Client1) sends traffic to it's default gateway because the destination is outside it's subnet. The policy running on Fa0/0 forwards Client1's traffic to ISP2, if ISP2 is not available the packets are dropped.

    This is not the case, if the specified next-hop is not available then the routing decision falls back to the unicast routing in the routing table as per the following quote from cisco

    Policy-Based Routing Using the set ip default next-hop and set ip next-hop Commands Configuration Example [IP Routed Protocols] - Cisco Systems

    The set ip next-hop command verifies the existence of the next hop specified, and…
    • if the next hop exists in the routing table, then the command policy routes the packet to the next hop.
    • if the next hop does not exist in the routing table, the command uses the normal routing table to forward the packet.
    hence, the behaviour in Jeremy's lab is that if ISP2 were to fail then the client_1 would follow any other route to it's destination that might exist in the routing table, albeit a default route - in the case of Jeremy's lab it is a directly connected route to the other ISP

    I have configured the lab as per jeremy does in the video and I have failed ISP 2 - the result is that Client 1 can then communicate with ISP 1, which the objective says it shouldn't be able to - hence my question.
    Going all out for Voice. Don't worry Data; I'll never forget you
    :study: CVoice [X] CIPT 1 [ ] CIPT 2 [ ] CAPPS [ ] TVOICE [ ]
    · Share on FacebookShare on Twitter
  • tomaifauchaitomaifauchai Member Posts: 301 ■■■□□□□□□□
    You're right chris! I just tried what i've suggested you and it doesn't make sense anyway. Probably jeremy used only connected routes without an IGP running to reach whatever he wanted to reach outside of the network!

    I knew that you don't have to add a permit statement to the PBR route-maps for it to return in the routing table after a set command, but i didn't knew that even with a deny statement, it still go back in the routing table.
    We learn new stuff everydays ! So i guess the solutions you mentionned in your 1st post is the way to go. Access lists are brutal :)
    · Share on FacebookShare on Twitter
  • MonkerzMonkerz Member Posts: 842
    Chris_ wrote: »
    The set ip next-hop command verifies the existence of the next hop specified, and…
    • if the next hop exists in the routing table, then the command policy routes the packet to the next hop.
    • if the next hop does not exist in the routing table, the command uses the normal routing table to forward the packet.
    hence, the behaviour in Jeremy's lab is that if ISP2 were to fail then the client_1 would follow any other route to it's destination that might exist in the routing table, albeit a default route - in the case of Jeremy's lab it is a directly connected route to the other ISP

    Sure, I agree with you and these statements, but you are assuming there is a default route or something in the routing table.
    [*]if the next hop does not exist in the routing table, the command uses the normal routing table to forward the packet.

    If there is no default route, or what have you, then the packet goes no where.
    Chris_ wrote: »
    I have configured the lab as per jeremy does in the video and I have failed ISP 2 - the result is that Client 1 can then communicate with ISP 1, which the objective says it shouldn't be able to - hence my question.

    Yes, Client1 is then able to communicate with the ISP1 edge router, but are you able to get to the internet from Client1? Will Client1's web traffic be forwarded to ISP1 as the next hop?

    The objectives do not say Client1 should not be able to communicate with ISP1, it says Client1 should not be able to access the internet. And without assuming there is a default route, Client1's internet traffic will not route to ISP1's edge.



    Maybe this is just my way of thinking...It is 2am. :)
    · Share on FacebookShare on Twitter
  • Chris_Chris_ Member Posts: 326
    Monkerz wrote: »
    Sure, I agree with you and these statements, but you are assuming there is a default route or something in the routing table.



    If there is no default route, or what have you, then the packet goes no where.

    but the tests in the lab to check ISP1 are to telnet to ISP 1 on port 80 - there is a route to this in the routing table - a directly connected one, therefore client 1 can talk to ISP 1 on port 80, effectivley 'the internet'

    The whole point of the lab and the leson it tries to teach are that in the real world there would be a default route out to these 2 ISPS in the routing table - as opposed to talking to directly connected neighbors, which also happen to be the next-hop - they are just representative of the internet for training purposes

    i think this lab, and the point I'm trying to make, would be served better by having a simulated 'internet' on the other side of the 2 ISPs i.e. a connection to a switch with a web server (router running http/https). this would prove the point better and require 2 default routes in the policy router, taking away the confusion of your next hop address also being your destination address.

    Maybe this is just my way of thinking...It is 2am. icon_smile.gif
    It might just be my thinking!! had just come off night shift icon_cry.gif
    Going all out for Voice. Don't worry Data; I'll never forget you
    :study: CVoice [X] CIPT 1 [ ] CIPT 2 [ ] CAPPS [ ] TVOICE [ ]
    · Share on FacebookShare on Twitter
  • Chris_Chris_ Member Posts: 326
    tomaifauchai wrote: »
    Have you tried this
    route-map policy permit 10   
 match ip address client_1   
 set ip next-hop 201.1.1.2 verify-availability
route-map policy deny 20

    Thanks for this, I hadn't tried it and the background IP SLA config behind it looks quite daunting - but I'm more awake now and I think I'll have a play with it anyway - it looks interesting.
    Going all out for Voice. Don't worry Data; I'll never forget you
    :study: CVoice [X] CIPT 1 [ ] CIPT 2 [ ] CAPPS [ ] TVOICE [ ]
    · Share on FacebookShare on Twitter
  • faiixiifaiixii Registered Users Posts: 1 ■□□□□□□□□□
    dear all i am preparing my route exam i am doing this lab, i did no ip routing command on both clients and gave them a ip default-gateway 192.168.1.1 command. Both of clients can Ping Policy Router's all Interfaces but can't ping or communicate with the ISP1 and ISP2.
    Plz tell me what should i need to do.
    · Share on FacebookShare on Twitter
Sign In or Register to comment.