[Dr.WoW] [No.57] Policy-based Routing-part 1 Highlighted

Latest reply: Aug 9, 2019 19:29:23 3789 3 2 0

Now that we've reached policy-based routing, the first thing that comes to my mind is that in its early years, policy-based routing's greatest use in China was in interconnecting China Telecom and China Netcom. After Telecom and Netcom split into different companies, a networking environment unique to China formed, with the south of the country being dominated by China Telecom and the north by Netcom (which now has merged into China Unicom). When networks only had single egresses, service for Telecom users accessing Netcom services was relatively slow, as was service for Netcom users accessing Telecom's services. Therefore, people thought of an enterprise network dual egress plan consisting of network egresses that connected to both Telecom and Netcom. The widespread use of the dual egress plan allowed policy-based routing to display its functionality! Configuring policy-based routing on enterprise egress network gateway devices allowed Telecom traffic to use each network's Telecom egress, and Netcom traffic to use each network's Netcom egress.

How did policy-based routing accomplish the splitting of Telecom and Network traffic? Let's begin by describing what policy-based routing is.

1 Policy-based Routing Concepts

So-called 'policy-based routing' is exactly what it sounds like: forwarding packets based on specific policies. Moreover, these policies are human-formulated, and therefore policy-based routing is a more flexible mechanism for multi-homing than the traditional method of selecting routes based upon destination address. After policy-based routes are configured on a firewall, the firewall first conducts filtering of the packets it receives based upon the rules configured in policy-based routing. After matching is successful, the packets are then forwarded according to specific forwarding policies. The 'configured rules' need matching conditions to be defined, usually using ACL; meanwhile, the "specific forwarding policies" require related actions be executed according to the matching condition(s). Therefore, we can deduce that policy-based routing is comprised of the following two components:

l   Matching conditions (defined using ACL)

Used to differentiate traffic that will be forwarded using policy-based routing. Matching conditions include: packets' source IP address, destination IP address, protocol type, application type, etc. The matching conditions that can be set by different firewalls are different. One policy-based routing rule may contain multiple matching conditions, related in an "And" manner, and packets must satisfy all of the matching conditions before the subsequent defined forwarding action can be executed.

l   Actions

Involve performing an action (such as designating the egress interface and next hop) on traffic that meets the matching conditions.

When there are multiple policy-based routing rules, a firewall will accord with their matching order and check the first rule first; if the first policy-based routing rule's matching condition is met, then the packet will be processed using the designated action. If the first rule's matching condition is not met, then the firewall will check the next policy-based routing rule. If all policy-based routing rules' matching conditions cannot be met, the packet will be forwarded according to the routing table― policy-based routing matching is completed prior to a packet checking the routing table, which is to say that policy-based routing's priority is higher than that of routing. The process for policy-based routing rule matching is shown in Figure 1-1.

Figure 1-1 Process of policy-based routing rule matching

[Dr.WoW] [No.57] Policy-based Routing-part 1-1045297-1 

Additionally, if the status of the egress interface designated by policy-based routing is 'Down' or the next hop cannot be reached, the packet will be forwarded by checking the routing table.

Now that we've finished discussing the basic principles of policy-based routing, let's look back at how policy-based routing was able to bring about the forwarding of Telecom traffic by Telecom and Netcom traffic by Netcom.

2 Destination IP Address-based Policy-based Routing

We'll use a network environment (shown in Figure 1-2) to verify the results of this kind of policy-based routing.

Figure 1-2 Destination IP address-based policy-based routing

[Dr.WoW] [No.57] Policy-based Routing-part 1-1045297-2 

Here, the firewall is serving as the enterprise's egress network gateway and is connected to the Internet via two links. Of these, the link passing through R1 is Telecom's line, and the link passing through R2 is Netcom's line. At this point, we'll want to allow enterprise users accessing server 10.10.11.11/32 to be forwarded through the Telecom path, while users accessing server 10.10.10.10/32 are forwarded through the Netcom path.

If two default routes are configured on the firewall, when enterprise users access the two services 10.10.11.11/32 and 10.10.10.10/32, we can see that all corresponding packets are forwarded through the R1 link. We discussed this in the shortest path routing section above―path selection for default routing is accomplished using a source IP address+destination IP address HASH algorithm that calculates the egress link chosen by packets, and there is no way to ensure that the requirement that traffic accessing 10.10.11.11/32 be forwarded through the Telecom line and traffic accessing 10.10.10.10/32 be forwarded through the Netcom line is fulfilled.

Below, we'll configure policy-based routing on the firewall, and look at what the results of this experiment are. The configuration is as follows (we'll use the USG2000/5000 firewall series in this example):

1.         Configure the matching conditions to be based on the packet's destination address.

[FW] acl number 3000

[FW-acl-adv-3000] rule 5 permit ip destination 10.10.11.11 0

[FW-acl-adv-3000] quit

[FW] acl number 3001

[FW-acl-adv-3001] rule 5 permit ip destination 10.10.10.10 0

[FW-acl-adv-3001] quit

2.         Configure policy-based routing.

[FW] policy-based-route test permit node 10

[FW-policy-based-route-test-10] if-match acl 3000                         //apply matching condition

[FW-policy-based-route-test-10] apply ip-address next-hop 10.1.1.2    // configure action, redirect Telecom as the next hop

[FW-policy-based-route-test-10] quit

[FW] policy-based-route test permit node 20

[FW-policy-based-route-test-20] if-match acl 3001                         //apply matching condition

[FW-policy-based-route-test-20] apply ip-address next-hop 10.1.2.2    // configure action, redirect Netcom as the next hop

[FW-policy-based-route-test-20] quit

3.         Apply policy-based routing.

[FW] interface GigabitEthernet0/0/3

 [FW-GigabitEthernet0/0/3] ip policy-based-route test               //apply policy-based routing on the ingress interface

[FW-GigabitEthernet0/0/3] quit

After configuration is complete, we ping both the 10.10.11.11 and10.10.10.10 addresses from the PC, and the pings go through successfully. We can also take a look on the firewall at the detailed information expressed in the session table, displayed below:

[FW] display firewall session table verbose                             

 Current total sessions: 2                                             

 icmp VPN: public --> public                                          

 Zone: trust --> untrust TTL: 00:00:20 Left: 00:00:16  

 Interface: GigabitEthernet0/0/1 Nexthop: 10.1.1.2  MAC:54-89-98-1d-74-24

 <--packets: 4 bytes: 240 -->packets: 4 bytes: 240                  

 192.168.0.2:54999 --> 10.10.11.11:2048                                 

 

 icmp VPN: public --> public                                          

 Zone: trust --> untrust TTL: 00:00:20 Left: 00:00:17  

 Interface: GigabitEthernet0/0/2 Nexthop: 10.1.2.2  MAC:54-89-98-ea-53-c9

 <--packets: 4 bytes: 240 -->packets: 4 bytes: 240                  

 192.168.0.2:63959 --> 10.10.10.10:2048                                 

From the displayed information we can see that packets going to 10.10.11.11 are forwarded from the firewall's GE0/0/1 interface, with the next hop as the address of the interface connecting R1 with the firewall; meanwhile, packets going to 10.10.10.10 are forwarded from the firewall's GE0/0/2 interface, with the next hop as the address of the interface connecting R2 with the firewall. This therefore accomplishes the requirement of traffic accessing 10.10.11.11/32 being forwarded from Telecom's path and traffic accessing 10.10.10.10/32 being forwarded from the Netcom path.

Having read to here, some may say, "The shortest path access introduced in the previous section can also accomplish this objective." Correct! Indeed, as the 'default routing+specific routing' method of shortest path routing forwards packets according to destination address, and as the policy-based routing configured above also uses packet's destination addresses as the condition for formulating the forwarding policy, these are both able to accomplish the same objective.

However, in reality, traditional static routes and dynamic routes are only able to provide a relatively simple routing method for users based upon a packet's destination address―this primarily solves network packet forwarding problems, but is not able to provide flexible service. Policy-based routing, on the other hand, is different―it allows network administrators to not only be able to choose forwarding routes based upon destination address, but also to be able to do this based upon packet source IP address, protocol type, application type or other conditions. Therefore, policy-based routing provides greater control over packets than traditional routing protocols.

3 Source IP Address-based Policy-based Routing

If it seems there was still some crossover between the application of policy-based routing described in the last section and that of shortest path routing, then let's look at another application of policy-based routing. Everyone knows that networks today are developing towards Fiber to the Home (FTTH), however, the cost associated with fiber-optics is not a small one in today's China, and many networks therefore use the fiber + ADSL connection method, which entails two simultaneous connections to the Internet via two lines of different speeds. This means that we can configure policy-based routing to allow traffic with relatively high priorities to use the fiber-optic connection, while traffic with relatively low priorities uses the ADSL connection.

Figure 1-3 Source IP address-based policy-based routing

[Dr.WoW] [No.57] Policy-based Routing-part 1-1045297-3 

In this scenario, the firewall is the enterprise's egress network gateway, and is connected to the Internet through two links belonging to different ISPs. Of these, the link passing through R1 has a relatively high bandwidth bitrate―let's say it is 10 Mbit/s; the link passing through R2 has a relatively low bandwidth bitrate, 2 Mbit/s. In order to ensure a good user experience for one of the enterprise's manager's Internet access, we want to allow his/her traffic accessing the Internet to be forwarded through the R1 link, while an employee's traffic accessing the Internet is forwarded through the R2 link.

This aforesaid goal cannot be achieved through checking for a route using the destination address. Instead, setting the source IP address as the matching condition using policy-based routing allows for this problem to be easily solved. Configure this on the firewall as follows (we'll use the USG2000/5000 firewall series in this example):

1.         Configure the matching conditions to be based on the packet's source IP address.

[FW] acl number 3000

[FW-acl-adv-3000] rule 5 permit ip source 192.168.10.0 0.0.0.255

[FW-acl-adv-3000] quit

[FW] acl number 3001

[FW-acl-adv-3001] rule 5 permit ip source 192.168.0.0 0.0.0.255

[FW-acl-adv-3001] quit

2.         Configure policy-based routing.

[FW] policy-based-route boss permit node 10

[FW-policy-based-route-boss-10] if-match acl 3000                       //apply matching condition

[FW-policy-based-route-boss-10] apply ip-address next-hop 10.1.1.2  // configure action, redirect next hop as R1

[FW-policy-based-route-boss-10] quit

[FW] policy-based-route employee permit node 10

[FW-policy-based-route-employee-10] if-match acl 3001                     //apply matching condition

[FW-policy-based-route-employee-10] apply ip-address next-hop 10.1.2.2  // configure action, redirect next hop as R2

[FW-policy-based-route-employee-10] quit

3.         Apply policy-based routing.

[FW] interface GigabitEthernet0/0/3

[FW-GigabitEthernet0/0/3] ip policy-based-route employee           //apply policy-based routing on the ingress interface

[FW-GigabitEthernet0/0/3] quit

[FW] interface GigabitEthernet0/0/4

[FW-GigabitEthernet0/0/4] ip policy-based-route boss               //apply policy-based routing on the ingress interface

[FW-GigabitEthernet0/0/4] quit

After completing configuration, ping server address 10.10.10.10 on the Internet from both the manager's and employee's PCs, and view the detailed session table information on the firewall, displayed below:

[FW] display firewall session table verbose                             

 Current total sessions: 2                                             

 icmp VPN: public --> public                                          

 Zone: trust --> untrust TTL: 00:00:20 Left: 00:00:16  

 Interface: GigabitEthernet0/0/1 Nexthop: 10.1.1.2  MAC:54-89-98-1d-74-24

 <--packets: 4 bytes: 240 -->packets: 4 bytes: 240                  

 192.168.10.2:47646 --> 10.10.10.10:2048                                 

 

 icmp VPN: public --> public                                          

 Zone: trust --> untrust TTL: 00:00:20 Left: 00:00:17  

 Interface: GigabitEthernet0/0/2 Nexthop: 10.1.2.2  MAC:54-89-98-ea-53-c9

 <--packets: 4 bytes: 240 -->packets: 4 bytes: 240                  

 192.168.0.2:53022 --> 10.10.10.10:2048                                 

In the information displayed above, the manager's (192.168.10.2) traffic accessing the server is forwarded from the link connected to R1 (10.1.1.2), while the employee's (192.168.0.2) traffic accessing the server is forwarded from the link connected to R2 (10.1.2.2), thus meeting the user's need for higher priority traffic to use the high speed link and for lower priority traffic to use the lower speed link.

 

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

tron
Created Feb 10, 2016 16:28:19 Helpful(0) Helpful(0)

Greats document, excelent for learning, thank´s

  • x
  • convention:

user_2790689
Created Jan 29, 2016 03:11:47 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

MPatel
MVE Created Aug 9, 2019 19:29:23 Helpful(0) Helpful(0)

Thanks for sharing information
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login