[Dr.WoW] [No.58] Policy-based Routing-part 2

Latest reply: Jul 18, 2019 07:36:38 4810 7 5 2

4 Application-based Policy-based Routing

What I introduced above were some traditional uses of policy-based routing, but there is still a kind of common policy-based routing scenario in networks today that is related to applications. As everyone knows, there are more than a few types of applications used in networks, and of these some are applications with large traffic demands, such as P2P, online video, etc. These applications use a high amount of egress bandwidth, severely affecting the forwarding of enterprise service traffic. Application-based policy-based routing was developed for this sort of circumstance, and application-based policy-based forwarding is accomplished by combining policy-based routing with functions that identify applications and by using the traffic application type as a matching condition.

Below, I'll examine the actual results of application-based policy-based routing; please see Figure 1-1.

Figure 1-1 Application-based policy-based routing

[Dr.WoW] [No.58] Policy-based Routing-part 2-1045439-1 

Here, the firewall is the enterprise's egress network gateway, and is connected to the Internet using two links (one from ISP1 and one from ISP2). Of these, the link provided by ISP2 is a stable link with equal uplink and downlink bandwidth, and is the primary link used for forwarding the enterprise's normal traffic; the link provided by ISP1 has unequal uplink and downlink bandwidth and relatively slow speed, but the leasing price is low, and so this can be provided for use as a link for forwarding certain high traffic applications (in the figure this is P2P).

We'll use the "BitSpirit" tool to simulate P2P services, have simulated a P2P server on the server and a P2P client on the enterprise user's PC1, and have also used pings to simulate normal services.

We first configure application-based policy-based routing on the firewall, to cause the P2P application's traffic to be forwarded from the GE2/2/21 egress interface, while normal traffic is directly forwarded by routing from the GE2/2/17 egress interface. The configuration commands are below (we'll use the Eudemon8000E-X firewall series in this example):

1.         Configure the matching condition to be based on the source IP address.

[FW] acl number 3000

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

[FW-acl-adv-3000] quit

2.         Configure policy-based routing.

[FW] traffic classifier p2p

[FW-classifier-p2p] if-match acl 3000 category p2p      // set the user's P2P application as a matching condition

[FW-classifier-p2p] quit

[FW] traffic behavior p2p                                           

[FW-behavior-p2p] redirect ip-nexthop 10.1.1.2 interface GigabitEthernet2/2/21  // redirect the egress interface and next hop

[FW-behavior-p2p] quit

[FW] traffic policy p2p   

[FW-trafficpolicy-p2p] classifier p2p behavior p2p  

[FW-trafficpolicy-p2p] quit

3.         Apply policy-based routing.

[FW] interface GigabitEthernet2/2/23

[FW-GigabitEthernet2/2/23] traffic-policy p2p inbound             //apply policy-based routing on the ingress interface

[FW-GigabitEthernet2/2/23] quit

Following the completion of configuration, we enable the "BitSpirit" client download function on PC1. A screenshot of this is below.

[Dr.WoW] [No.58] Policy-based Routing-part 2-1045439-2 

We then view the session table (displayed below) on the firewall:

[FW] display firewall session table verbose                             

 Current total sessions: 2                                             

 tcp VPN: public --> public                                          

 Zone: trust --> untrust Slot: 3 CPU: 3 TTL: 00:00:05 Left: 00:00:02  

 Interface: GigabitEthernet2/2/21 Nexthop: 10.1.1.2

 <--packets: 0 bytes: 0 -->packets: 2 bytes: 96                  

 192.168.0.2:1712 --> 10.10.10.10:29553                                 

 

 tcp VPN: public --> public                                          

 Zone: trust --> untrust Slot: 3 CPU: 3 TTL: 00:00:05 Left: 00:00:02  

 Interface: GigabitEthernet2/2/21 Nexthop: 10.1.1.2

 <--packets: 0 bytes: 0 -->packets: 2 bytes: 96                  

 192.168.0.2:1711 --> 10.10.10.10:29553                                 

From the information displayed above, we can see that the session's destination address and port are the same as those displayed on the "BitSpirit" client―they all are 10.10.10.10:29553. Moreover, this portion of traffic is being forwarded from the link with GE2/2/21 as the egress interface and a next hop of 10.1.1.2. This is the same as the policy-based route's redirected egress interface and next hop, meaning that P2P application-based policy-based routing has been successfully applied.

Below, we'll ping server address 10.10.10.10 from PC1.

At this point, let's take another look at the session table, displayed below:

[FW] display firewall session table verbose                             

 Current total sessions: 1                                              

 icmp VPN: public --> public                                          

 Zone: trust --> untrust Slot: 3 CPU: 3 TTL: 00:00:20 Left: 00:00:17  

 Interface: GigabitEthernet2/2/17 Nexthop: 10.1.2.2              

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

 192.168.0.2:768 --> 10.10.10.10:2048                                  

The session table shows that the ping packet was forwarded from the link with egress interface GE2/2/17 and a next hop of 10.1.2.2. This demonstrates that our normal service traffic is being forwarded from the link provided by ISP2, meaning that our original objective has been achieved.

To summarize the above uses of policy-based routing, we now know that the flexibility of policy-based routing is rooted in the flexibility and diversity of the matching conditions. There are different matching conditions for different scenarios, and the matching conditions contained in the three above examples were destination IP address, source IP address and application type respectively. In addition to this, there are a multitude of other matching conditions that are relatively commonly used, including user, protocol type, etc. As the configuration methods for these are essentially the same, we won't introduce these one by one here.

5 Policy-based Routing In Out-of-path Networks

Another scenario in which policy-based routing is used in networks today must also be mentioned: when firewalls are deployed out-of-path off of enterprise egress routers or core switches. In this sort of scenario, policy-based routing is not configured on the firewall, but rather is configured on the router or switch. However, as this kind of approach is used on many enterprise egresses and data center egresses, I'll also give an introduction to this here.

First, we'll examine this kind of scenario using a model of actual network conditions, shown in Figure 1-2.

Figure 1-2 Network diagram for an out-of-path firewall

[Dr.WoW] [No.58] Policy-based Routing-part 2-1045439-3 

Here, the enterprise egress is router R1, and the firewall is deployed out-of-path off of the egress router R1. When an external network user accesses the intranet server, after traffic is guided from R1 to the firewall for security protection, it is then forwarded again to the intranet server.

In this networking approach, policy-based routing is configured on the egress router R1, and the approach used for configuring the router's policy-based routing is the same as that for firewall policy-based routing introduced above―both involve first defining a matching condition(s) (here, this is the destination IP address), setting an action (redirecting the egress interface or next hop), and then applying this on the ingress interface. In this networking approach, in addition to conducting security processing of the traffic guided to it, the firewall also needs to return (reinsert) traffic to the egress router R1.

Traffic return is actually quite simple, and below I'll introduce two return methods―static routing and OSPF.

l   Method for configuring static routing return

Table 1-1 only lists the configuration of policy-based routing and static routing.

Table 1-1 Configuring static routing return

R1

FW

#

acl number 3000

rule 5 permit ip destination 192.168.0.2 0

#

policy-based-route in permit node 10

 if-match acl 3000

 apply ip-address next-hop 10.1.2.2

#

interface GigabitEthernet0/0/3

 ip address 10.1.4.1 255.255.255.0

 ip policy-based-route in

#

ip route-static 10.10.10.0 255.255.255.0 10.1.4.2

ip route-static 192.168.0.0 255.255.255.0 10.1.1.1

 

l   Configuration method for OSPF routing return

When the number of connected users is relatively high, this configuration method can be considered, as it eases the administrator's maintenance. In the networking approach shown in Figure 1-3, R1 is the enterprise egress router, and the core switch LSW is connected to the intranet server. When an external network user accesses the intranet server, traffic passes through R1 to LSW, and is then guided onto firewall FW for security policy filtering by the policy-based routing configured on LSW. After filtering, the traffic is then returned to LSW through checking the OSPF route on FW, after which it accesses the intranet server.

Figure 1-3 OSPF network diagram

[Dr.WoW] [No.58] Policy-based Routing-part 2-1045439-4 

Table 1-2 only lists the configuration of policy-based routing and OSPF.

Table 1-2 Configuring OSPF routing return

R1

LSW

FW

ospf 2

 area 0.0.0.0

  network 10.1.3.0 0.0.0.255

  network 10.1.2.0 0.0.0.255

#

vlan batch 100

#

interface Vlanif100

 ip address 10.1.3.2 255.255.255.0

#

acl number 3000

 rule 5 permit ip destination 192.168.0.2 0

rule 10 permit ip destination 192.168.1.2 0

rule 15 permit ip destination 192.168.2.2 0

#

policy-based-route in permit node 10

 if-match acl 3000

 apply ip-address next-hop 10.1.2.2

#

interface GigabitEthernet0/0/3

port link-type access

 port default vlan 100

 ip policy-based-route in

#

ospf 1

 area 0.0.0.0

  network 10.1.1.0 0.0.0.255

  network 192.168.0.0 0.0.0.255

  network 192.168.1.0 0.0.0.255

  network 192.168.2.0 0.0.0.255

ospf 2

 area 0.0.0.0

  network 10.1.3.0 0.0.0.255

  network 10.1.2.0 0.0.0.255

ospf 1

 import-route ospf 2

 area 0.0.0.0

  network 10.1.1.0 0.0.0.255

ospf 2

 import-route ospf 1

 area 0.0.0.0

  network 10.1.2.0 0.0.0.255

 

Configuration for using OSPF return is a bit more complicated. First we need to use OSPF dual processes on the LSW to isolate upstream and downstream traffic, then use policy-based routing to guide traffic onto FW, and finally configure the incorporation of the two OSPF processes together on FW, allowing the two OSPF processes to learn each other's routes.

Traffic guidance is completed by policy-based routing on LSW, while static routing or OSPF routing on FW completes traffic return. After configuration is complete, using tracert from an external network PC (10.10.10.10) for the intranet server's address 192.168.0.2 gives the following result (a static routing network configuration is used in this example):

PC>tracert 192.168.0.2

 

traceroute to 192.168.0.2, 8 hops max

(ICMP), press Ctrl+C to stop

1   10.10.10.1   16 ms  <1 ms  <1 ms

2   10.1.4.1   31 ms  31 ms  32 ms

3   10.1.2.2   140 ms  63 ms  47 ms

4   10.1.1.1   94 ms  62 ms  47 ms

5   192.168.0.2   63 ms  78 ms  94 ms

This path information shows that after access traffic passes through FW it is returned again to R1, and finally arrives at the target server, achieving the expected results.

Policy-based routing is actually just conducting path selection and redefining the egress interface and next hop for traffic that matches the matching condition(s). This requires that administrators have an ample understanding of the current network state and be able to choose suitable matching conditions accordingly. For example, clearly knowing the merits of multiple egress links allows traffic from an enterprise's important clients or important services to be forwarded from a high priority link(s). Flexibly applied policy-based routing can provide administrators with an expanded network planning toolbox.

 

 

Questions from Dr. WoW:

1.         What is the difference between ISP routing and static routing?

2.         When there are many policy-based routing rules, which rule will the firewall use for packet matching?

 

 

 

 

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

  • x
  • convention:

user_2790689
Created Jan 30, 2016 01:29:53 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

Lastdon
Created Nov 29, 2016 08:15:19 Helpful(0) Helpful(0)

good
  • x
  • convention:

mobile12
Created Nov 29, 2016 11:44:58 Helpful(0) Helpful(0)

Excellent description about application-based Policy-based routing
  • x
  • convention:

Riogo
Created Apr 28, 2019 11:50:33 Helpful(0) Helpful(0)

Hello.
Please check the Figure 1-3 "OSPF network diagram", there is incorrect interface numbering for LSW. Interface Gi0/0/1 connected to the R1, but there should be Gi0/0/3 according to the configuration below.

One more, for R1 configuration I think there should be network 10.1.4.0 0.0.0.255 OSPF announcement instead of 10.1.2.0 0.0.0.255.

Overall it is a vastly helpful material, thank you!
  • x
  • convention:

HCIA%20R%26S%2C%20HCIP%20R%26S
E.DR_91
MVE Created Jul 1, 2019 05:21:11 Helpful(0) Helpful(0)

Thanks
  • x
  • convention:

user_3432183
Created Jul 9, 2019 12:55:40 Helpful(0) Helpful(0)

Awesome
  • x
  • convention:

spotoclub
Created Jul 18, 2019 07:36:38 Helpful(0) Helpful(0)

wonderful. And these materials are almost the same as I saw it in spotoclub.com
  • 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