Traffic Redirection Example with Policy-Based Routing (PBR)

January 9th, 2013 | Tags: , , ,

Background Information
Let’s spend a few words about PBR. More precisely about the way to force some traffic to a specific next-hop base on a list of criteria instead of using the route configured in your routing table. You can have plenty of reasons to do such traffic engineering. In this example we will redirect some traffic to another router even when the current router has direct access to the destination address. In real life, PBR can be use to force some traffic to go through your firewall or your proxy server for example.

Policy-Based Routing (PBR) allows you to use ACLs and route maps to selectively modify and route IP packets. The ACLs classify the traffic. Route maps that match on the ACLs set routing attributes for the traffic.

A PBR policy specifies the next hop for traffic that matches the policy. Using standard ACLs with
PBR, you can route IP packets based on their source IP address. With extended ACLs, you can route
IP packets based on all of the clauses in the extended ACL.

Equipment used

  • Brocade ICX6610 (Router with PBR capability)
  • Brocade ICX6450 (Router)

Network Diagram

Before focusing on the policy-based routing, let’s configure the standard infrastructure above and ensure that the two clients can ping each other as well as the other ip addresses defined. Then we will add the PBR and see how it behaves.

On the Brocade ICX6610 device, the configuration would look like this for the router with PBR capability:

!
vlan 100 by port
  untagged ethe 1/1/10
  router-interface ve 100
!
vlan 200 by port
  untagged ethe 1/1/20
  router-interface ve 200
!
ip route 0.0.0.0 0.0.0.0 172.16.0.1
ip route 0.0.0.0 0.0.0.0 172.17.0.1
!
interface ethernet 1/1/23
  ip address 172.16.0.2 255.255.255.252
!
interface ethernet 1/1/24
  ip address 172.17.0.2 255.255.255.252
!
interface ve 100
  ip address 192.168.100.254 255.255.255.0
!
interface ve 200
  ip address 192.168.200.254 255.255.255.0
!

Nothing fancy in the configuration above. Two virtual interfaces (ve 100 and ve 200 in vlan 100 and 200) are defined. These virtual interfaces will act as gateway for the clients in their respective vlans. The other interfaces 1/1/23 and 1/1/24 are L3 interfaces connected to the other router ICX6450. All unknown traffic will be redirected to these two interfaces thanks to the default routes configured (0.0.0.0/0).

ICX6610#show ip route
Total number of IP routes: 5, avail: 11995 (out of max 12000)
B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate default
    Destination      NetMask                Gateway     Port     Cost  Type
    0.0.0.0             0.0.0.0                 *172.16.0.1 1/1/23 1        S
    0.0.0.0             0.0.0.0                   172.17.0.1 1/1/24 1        S
1  172.16.0.0       255.255.255.252   0.0.0.0       1/1/23 1        D
2  172.17.0.0       255.255.255.252   0.0.0.0       1/1/24 1        D
3  192.168.100.0 255.255.255.0       0.0.0.0       v100    1        D
4  192.168.200.0 255.255.255.0       0.0.0.0       v200    1        D

Here is the configuration of the other router (ICX6450):

!
ip route 192.168.100.0 255.255.255.0 172.16.0.2
ip route 192.168.200.0 255.255.255.0 172.16.0.2
ip route 192.168.100.0 255.255.255.0 172.17.0.2
ip route 192.168.200.0 255.255.255.0 172.17.0.2
!
interface loopback 1
  ip address 10.0.0.1 255.255.255.0
!
interface ethernet 1/1/23
  ip address 172.16.0.1 255.255.255.252
!
interface ethernet 1/1/24
  ip address 172.17.0.1 255.255.255.252
!

As before two L3 interfaces are configured (1/1/23 and 1/1/24). The four static routes allow the client return traffic to reach the ICX6610 router. There is although one loopback ip address that could take the role of the WAN for example.

ICX6450#show ip route
Total number of IP routes: 5, avail: 11995 (out of max 12000)
B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate default
    Destination      NetMask                Gateway     Port     Cost  Type
1  10.0.0.0           255.255.255.0       0.0.0.0        lb1      1        D
2  172.16.0.0       255.255.255.252   0.0.0.0       1/1/23 1        D
3  172.17.0.0       255.255.255.252   0.0.0.0       1/1/24 1        D
4  192.168.100.0 255.255.255.0     *172.16.0.2 1/1/23 1        S
    192.168.100.0 255.255.255.0       172.17.0.2 1/1/24 1        S
5  192.168.200.0 255.255.255.0     *172.16.0.2 1/1/23 1        S
    192.168.200.0 255.255.255.0       172.17.0.2 1/1/24 1        S

You can imagine a firewall or a proxy server instead of a the ICX6450 router. The idea is only to demonstrate that the PBR can be used to force the traffic between two clients to go through another equipment instead of being routed directly. Before configuring PBR, let’s see the current behavior.

The ICX6610 routing table shows direct routes to the clients subnets 192.168.100.0/24 and 192.168.200.0/24 through the virtual interfaces configured before. If we do a traceroute from 192.168.100.10, we can see that the traffic is routed directly by the ICX6610 router which makes sense:

C:\>tracert 192.168.200.10

Tracing route to 192.168.200.10 over a maximum of 30 hops

   1      <1 ms      <1 ms      <1 ms      192.168.100.254    2      <1 ms      <1 ms      <1 ms      192.168.200.10 Trace complete.

PBR
Let’s configure PBR on ICX6610:

interface ve 100
   ip address 192.168.100.254 255.255.255.0
   ip policy route-map Vlan100ToVlan200ThroughICX6450
!
access-list 101 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
!
route-map Vlan100ToVlan200ThroughICX6450 permit 101
  match ip address 101
  set ip next-hop 172.16.0.1
  set ip next-hop 172.17.0.1

!

The ACL can be more granular, base on TCP/UDP ports, … like any other extended ACL. Here we simply defined an ACL to classify the traffic from 192.168.100.0/24 to 192.168.200.0/24. Then we configure a route-map that matches this ACL and set the next hop as the address of the other router and finally, we apply the route-map to the virtual address ve 100.

If we perform the traceroute again, we can see that the traffic between the same clients goes through the ICX6450, which is what we wanted to see 😉

C:\>tracert 192.168.200.10

Tracing route to 192.168.200.10 over a maximum of 30 hops

   1        7 ms      <1 ms      <1 ms      172.16.0.1    2      <1 ms      <1 ms      <1 ms      172.16.0.1    3      <1 ms      <1 ms      <1 ms      172.16.0.2    4      <1 ms      <1 ms      <1 ms      192.168.200.10 Trace complete.

Disable Redundant Link

Since we designed a redundant L3 path, we can even show that it’s working well even when one of the uplink is disabled:

ICX6610(config-if-e1000-1/1/23)#disable

ICX6610#show ip route
Total number of IP routes: 4, avail: 11996 (out of max 12000)
B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate default
    Destination      NetMask                Gateway     Port     Cost  Type
    0.0.0.0             0.0.0.0                   172.17.0.1 1/1/24 1        S
1  172.17.0.0       255.255.255.252   0.0.0.0       1/1/24 1        D
2  192.168.100.0 255.255.255.0       0.0.0.0       v100    1        D
3  192.168.200.0 255.255.255.0       0.0.0.0       v200    1        D

Now the redundant paths do not appear any more in the routing table which make sense since one of the route was disabled.

C:\>tracert 192.168.200.10

Tracing route to 192.168.200.10 over a maximum of 30 hops

   1        1 ms        1 ms      <1 ms      172.17.0.1    2      <1 ms      <1 ms      <1 ms      172.17.0.1    3      <1 ms      <1 ms      <1 ms      172.17.0.2    4      <1 ms      <1 ms      <1 ms      192.168.200.10 Trace complete.

When performing the same traceroute as before, we can see that the PBR redirect the traffic to the second next-hop provided since the first one disappeared from the routing table. This is what we wanted to demonstrate.

Comments are closed.