Yes, it is possible to use PBR to route based on the source IP as well. Simply use extended ACLs and match criteria based on both source and destination. Actually, this has been achieved in the lesson, since the source IP address used in the access list is that of H1.
Hi Rene,
Thanks for the lesson,
I try the lab with prefix-list instead of access-list and I notice that the PBR canāt be applied on the interface. I understand a bit the reason, but I will appreciate if you can tell me more about the why.
Best Regards,
Thierry
Only the access list is supported as a match clause. Prefix list and other match clauses are not supported.
Now as to why this is the case: Prefix lists were designed to perform routing protocol route filtering. So essentially, they werenāt designed to function like that. Actually, you may find that on some platforms it will let you configure the prefix lists for PBR, but it will simply match all packets. In other cases, it wonāt let you apply it to the interface.
Policy Based Routing can be used to route using the source address as a parameter. Remember that PBR can use access lists to match criteria in order to make routing decisions. One of those parameters within the access lists is indeed the source address.
Hi Laz, iāve an issue that local policy based routing isnāt working with your scenario and it just went through 192.168.12.2 , keep showing policy rejectedā¦
You must ensure that the IP address in the ICMP_R1 access list is the same as the source IP address of your pings. To ensure that the source IP address of the pings is correct, you can use an extended ping and specify it. Only if the source matches the ACL, only then will it match the route map policy and be routed differently.
You can also see the particular specifications of this command at this Cisco command reference.
Hi,
I understand if you want to apply PBR to an interface then it needs to be a L3 interface.
So Iām wondering is there any way around this on a switch ? For example if I had traffic flowing straight through a switch at layer 2 the only way around this is I would have to create an SVI and then use that to apply the ip policy command or created a routed port. Would these be the 2 options available ?
Also would I then need to enter the ip routing command? if I wanted to use either of these 2 options.
Then if I did need to use the ip routing command to make it happen then I would probably also have to add a static default route as the ip default gateway command would cease to work if I enabled ip routing command ?
As you correctly stated, PBR can only be applied to a Layer 3 interface, so there is no way to apply any kind of PBR on a switch at Layer 2. This means that you can apply PBR on a routed port or on an SVI. If you had a purely L2 switch, traffic traversing this device would be transmitted without any routing involved.
If you have a Layer 3 switch and you wanted to apply this then yes, you would first have to implement the ip routing command so that the device will route traffic. If you do this then yes, you will have to add a static default route in order to access the switch from other subnets. You would have to do this for any routing device you configure anyway, so it is not out of the ordinary.
I have been reading about using the default next-hop e.g.:
set ip default next-hop x.x.x.x
And that it is only used if there is not a route to the destination in the routing table, which is fine, but does the default route count? Or is it excluded from the check?
Thanks
Got my answer from Cisco literatureā¦
A packet is routed to the next hop specified by the set ip default next-hop command only if there is no explicit route for the packetās destination address in the routing table. A default route in the routing table is not considered an explicit route for an unknown destination address.
*Jan 22 08:02:39.450: IP: s=192.168.1.100 (GigabitEthernet0/0), d=4.4.4.4, len 84, FIB policy match
*Jan 22 08:02:39.450: IP: s=192.168.1.100 (GigabitEthernet0/0), d=4.4.4.4, len 84, PBR Counted
*Jan 22 08:02:39.450: IP: s=192.168.1.100 (GigabitEthernet0/0), d=4.4.4.4, g=192.168.13.3, len 84, FIB policy routed
But when I do traceroute on host, it still show traffic passing through 192.168.12.2 instead of 192.168.13.3, see trace below.
VPCS> trace 4.4.4.4
trace to 4.4.4.4, 8 hops max, press Ctrl+C to stop
1 192.168.1.254 1.489 ms 1.386 ms 1.321 ms
2 192.168.12.2 2.011 ms 2.184 ms 2.245 ms
3 *192.168.24.4 3.149 ms (ICMP type:3, code:3, Destination port unreachable) *
In the lesson, the policy routing that was applied is only for ICMP traffic. Traceroute is a utility that is employed using different protocols than ICMP. The way it is implemented depends upon the operating system. You can find out more about traceroute at the following lesson:
Now the debug you show in your post was created based on the ping command, which uses ICMP, so policy routing was used. The traceroute however did not use policy routing because it didnāt match the ICMP paramter of the ACL, and that is why it was routed normally.
if we are doing policy based routing and that link goes down traffic will still be forwarded to the down link and blackholed or it will sent to another link
Policy-based routing, when it is applied, will put packets through the route map before routing them. This means that if packets match the criteria, the route map, and not the routing table, will decide to which next-hop IP they are to be forwarded. However, if the next-hop indicated by the route map does not exist in the routing table, then the route map is bypassed, and the normal routing table is used for routing.
So if for whatever reason, a link goes down, and the next-hop IP indicated by the route map is no longer in the routing table, the traffic will not be blackholed but will use the normal routing table for routing.
If F1/0 on R3 goes down, you should still see R1 routing traffic via R2 to 4.4.4.4. This is because if F1/0 goes down on R3, interface F1/0 on R1 will also go down, thus R1 will not have an active interface on the 192.168.13.0/24 network, and will thus not have a route to this network.
However, if F0/0 goes down on R3, then yes, the scenario you describe will indeed take place. This is because, as you say, R1 will still have an active interface on the 192.168.13.0/24 subnet and will route traffic to R3, but R3 will drop the traffic since it canāt do anything with it.
In such a case, you will have to use IP SLA to ensure that the IP addresses on the link between R3 and R4 are up, that is, you can set up an SLA for either 192.168.34.1 or 192.168.34.2. If those go down, then you should reroute traffic via R2. You can find an example of how to use PBR with IP SLA to enable such reliable routing at the following lesson:
Thatās one of the problems with PBR, it is not aware of the rest of the topology like routing protocols are so you will need to use IP SLA to ensure correct routing in the event of such a failure.