IWAN:AR

From DocWiki

(Redirected from PfR:Solutions:NBAR2 AR)
Jump to: navigation, search

iwan-banner.png



Application Control with Asymmetric Routing


IWAN Navigation


Contents



Performance Routing

PfR allows network administrators to minimize bandwidth costs, enable intelligent load distribution, improve application performance, and deploy dynamic failure detection at the WAN access edge. Whereas other routing mechanisms can provide both load sharing and failure mitigation, Cisco IOS PfR makes real-time routing adjustments based on criteria other than static routing metrics such as response time, packet loss, jitter, path availability, traffic load distribution, and cost minimization.


Deep Packet Inspection and Asymmetric Routing - Problem Statement

Performance Routing (PfR) is an intelligent path control solution that makes an informed-decision on which path should be taken per application or per DSCP. PfR makes decisions based on realtime performance metrics and user defined constraints. This means PfR can introduce asymmetric routing for some flows.


Asymetric routing is when traffic takes one path in one direction, and a different path in the opposite direction. Asymmetric routing is not an issue for a WAN deployment, and this is not an issue for PfR because the Master Controller (MC) has a comprehensive view of all the flows in a specific site by controlling all local Border Routers (BR).

In most cases PfR and QoS are deployed with DSCP based policies and can work properly with asymmetric routing without problems. Challenges arise when Network Based Application Recognition (NBAR2) is used to classify and learn traffic. NBAR2 (and more generally all Deep Packet Inspection engines) should be able to see both sides of flows to be able to correctly classify a large fraction of applications.


PfR manipulates path selection uni-directionally and can introduce asymmetric routing and can therefore breaks this rule.

Asymetric Routing at Hub Locations

In Figure 1, Site1’s MC has decided that the best path for the traffic flow from Site1 to Site3 should use the MPLS DMVPN tunnel. Site3’s MC has decided that the best path for the traffic flow from Site3 to Site1 should use the Internet DMVPN tunnel. Now the NBAR process in R11 (Transit BR) can see the flow going from Site1 to Site 3, but the return path goes through Tunnel 200 and returns through R12, which is then forwarded onto the host in Site1’s network.

Asymmetric1.jpg
Figure 1 Asymetric Flow at the Hub

If we look carefully at the topology in Figure 1, the asymmetric routing (MPLS one direction, Internet in the other) is not the real problem here, but rather the fact that R11 never sees the return traffic. Based on this assumption, ensuring that R11 sees the return traffic provides a solution.

Hub Workaround Description

To ensure that a BR’s NBAR2 process is able to see both sides of flows, we have to be able to redirect all returning flows to the BR that started the classification. In other words, one BR is defined as a primary, and the other BR(s) as the secondary. When the secondary BR receives a flow, the secondary BR redirects the flow to the primary BR so that it sees the flow in both directions.

Changes only need to be made only at sites that have multiple BRs for a transport. This document displays sites that have only two BRs at a site:

Hub Site Configuration

The configuration of Hub or Transit Sites include the following fixes:

  • Deploying Policy Based Routing (PBR) on the DMVPN tunnel for traffic received from the WAN being sent to the LAN. This is only required on DMVPN routers that contain the non-primary transport.
  • Traffic Steering from Interior Gateway Protocols (IGP) should redirect traffic to the primary BR.

Figure 2,shows the traffic flow after deploying the two changes on the DMVPN hub routers. As part of the routing design for PfR, traffic should be steered towards the primary transport in the event that traffic becomes in an uncontrolled state.

R11 has been identified as the primary router because it connects to the primary transport (MPLS). PBR has been configured on R12’s DMVPN tunnel 200 which sends any traffic received on DMVPN tunnel 200 to R11 via the 10.1.12.0/24 network.

Asymmetric2.jpg
Figure 2 Full Hub NBAR Visibility with Asymetric Flow

Hub DMVPN PBR Configuration:

Step 1: Define an ACL for matching traffic coming from the WAN. For simplicity, a simple ACL matching anything can be created.

Example 1 Create an ACL for PBR

! R12 (Secondary Router for AVC)
ip access-list extended ACL-ANY
 permit ip any any


Step2: Create a route-map on R12 that redirects traffic to R11. It is important that we add the keyword verify-availability keyword to ensure that the R12 detects that defined next hop is still available. If it does not deem it available, PBR is not used.

Example 2 PBR Route-map Configuration for Secondary Router

! R12 (Secondary Router for AVC)
route-map RM-PBR-TO-R11 permit 10
 match ip address ACL-ANY
 set ip next-hop verify-availability 10.1.12.1


Note: This configuration is based off the fact that R11 and R12 are L2 adjacent (directly connected, etc.) which simplifies the design, but not required. If the hub routers are not L2 adjacent, then a more advanced design/configuration is required.

Step 3: Apply the PBR to the DMVPN Tunnel on the Secondary Router’s WAN interface (i.e DMVPN tunnel):

Example 3 Applying PBR Route-map to Ingress WAN interface

!R12 (Secondary Router for AVC)
interface Tunnel 200
 ip policy route-map RM-PBR-TO-R11

Traffic Steering Per Hub Configuration:

The IWAN design uses EIGRP or IBGP for the WAN protocol. In-bound LAN path preference for EIGRP is controlled by setting delay on the ingress DMVPN tunnel. Routes that are received by the tunnel are modified (steered) versus routes that are learned via the LAN.

EIGRP

On the primary DMVPN hub routers, a delay of 1,000 is configured on the primary DMVPN tunnel. For the secondary DMVPN hub routers, a delay of 2,000 is configured on the secondary DMVPN tunnel. Example 4 provides sample configuration:

Example 4 EIGRP Traffic Steering for Hub Routers

! R11 (Primary Router for AVC)
interface Tunnel 100
 delay 1000
!---------------------------------------------------!
! R12 (Secondary Router for AVC)
interface tunnel 200
  delay 2000

BGP

If IBGP is used as the transport, then the metric values can be set at the point of redistribution. Setting the values to 1,000 on the primary and 2,000 for the secondary makes things easy to interpret.

Example 5 provides a reference configuration. The prefix-lists were not included for the sake of brevity. The focus is on the different metric values used during redistribution.

Example 5 OSPF Traffic Steering for Hub Routers

! R11 (Primary Router for AVC)
router ospf 1
 redistribute bgp 10 subnets route-map REDIST-BGP-TO-OSPF
 passive-interface default
 no passive-interface GigabitEthernet0/3
 no passive-interface GigabitEthernet1/0
 network 0.0.0.0 255.255.255.255 area 0
!
route-map REDIST-BGP-TO-OSPF deny 10
 match ip address prefix-list BGP-ENTERPRISE-PREFIX
route-map REDIST-BGP-TO-OSPF deny 20
 match ip address prefix-list BGP-LOCALDC-PREFIX
route-map REDIST-BGP-TO-OSPF deny 30
 match ip address prefix-list DEFAULT-ROUTE
route-map REDIST-BGP-TO-OSPF permit 40
 description Modify Metric to Prefer MPLS over Internet
 set metric 1000
 set metric-type type-1
!---------------------------------------------------!
! R12 (Secondary Router for AVC)
router ospf 1
 redistribute bgp 10 subnets route-map REDIST-BGP-TO-OSPF
 passive-interface default
 no passive-interface GigabitEthernet0/3
 no passive-interface GigabitEthernet1/0
 network 0.0.0.0 255.255.255.255 area 0
!
route-map REDIST-BGP-TO-OSPF deny 10
 match ip address prefix-list BGP-ENTERPRISE-PREFIX
route-map REDIST-BGP-TO-OSPF deny 20
 match ip address prefix-list BGP-LOCALDC-PREFIX
route-map REDIST-BGP-TO-OSPF deny 30
 match ip address prefix-list DEFAULT-ROUTE
route-map REDIST-BGP-TO-OSPF permit 40
 description Modify Metric to Prefer MPLS over Internet
 set metric 2000
 set metric-type type-1



Note: More information on IWAN routing design can be found in the Cisco Validated Design Document which can be found here: http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-branch-wan/index.html#~designs

Aysmetric Routing at Branch Locations

The same issue with asymmetric routing can occur at branch locations that have multiple BRs too.

In Figure 4, Site1’s MC has decided that the best path for the traffic flow from Site1 to Site5 should use the Internet DMVPN tunnel (Traffic is forwarded to R12 via the PfR Auto-Tunnel). Site5’s MC has decided that the best path for the traffic flow from Site5 to Site1 should use the MPLS DMVPN tunnel.

Now the NBAR process in R11 (Transit BR) can see the traffic flows in both directions, but at Site5, neither R51 nor R52 has the flow for both directions of the traffic.

Asymmetric3.jpg
Figure 3 Asymetric Flow at Branch Locations

Note: Asymetric routing is only an issue for AVC at Branch sites that have more than one router. Single router sites are not impacted.


Branch Workaround Description

To ensure that a BR’s NBAR2 process is able to see both sides of flows, we have to be able to redirect all returning flows to the BR that started the classification. Just as the Hub BRs, a Branch BR is defined as a primary, and the other BR as the secondary. When the secondary BR receives a flow, it redirects the flow to the primary BR.

Changes only need to be made only at sites that have multiple BRs for a transport. This document displays sites that have only two BRs at a site:

Branch Site Configuration

The configuration of Hub or Transit Sites include the following fixes:

  • Deploying Policy Based Routing (PBR) on the DMVPN tunnel for traffic received from the WAN being sent to the LAN. This is only required on DMVPN routers that contain the non-primary transport.
  • Traffic Steering from Interior Gateway Protocols (IGP) should redirect traffic to the proper location if there are downstream routers (or layer3 switches) connected at the branch.
  • If the WAN routers are acting as the IP Gateway, then HSRP can be deployed. The HSRP configuration should make the primary AVC router the higher priority to ensure that traffic flows through it.

Figure 4, shows the traffic flow after deploying the changes on the DMVPN branch routers. As part of the routing design for PfR, traffic should be steered towards the primary transport in the event that traffic becomes in an uncontrolled state.

R51 has been identified as the primary router because it connects to the primary transport (MPLS). PBR has been configured on R52’s DMVPN tunnel 200 which sends any traffic received on DMVPN tunnel 200 to R51 via the 10.5.12.0/24 network.

Asymmetric4.jpg
Figure 4 Full Branch NBAR Visibility with Asymmetric Flow

Branch DMVPN PBR Configuration:

Step 1: Define an ACL for matching traffic coming from the WAN. For simplicity, a simple ACL matching anything can be created.

Example 6 Create an ACL for PBR

R52 (Secondary Router for AVC)
ip access-list extended ACL-ANY
 permit ip any any

Step2: Create a route-map on R52 that redirects traffic to R51. It is important that we add the keyword verify-availability keyword to ensure that the R52 detects that defined next hop is still available. If it does not deem it available, PBR is not used.


Example 7 PBR Route-map Configuration for Secondary Router

! R52 (Secondary Router for AVC)
route-map RM-PBR-TO-R11 permit 10
 match ip address TRAFFIC_TO_LAN
 set ip next-hop verify-availability 10.12.1.1


Note: This configuration is based off the fact that R51 and R52 are L2 adjacent (directly connected, etc.) which is required.


Step 3: Apply the PBR to the DMVPN Tunnel on the Secondary Router’s WAN interface (i.e DMVPN tunnel):


Example 8 Applying PBR Route-map to Ingress WAN interface

! R12 (Secondary Router for AVC)
interface Tunnel 200
 ip policy route-map RM-PBR-TO-R11

Traffic Steering Per Branch Configuration:

The IWAN design uses EIGRP or IBGP for the WAN protocol. In-bound LAN path preference for EIGRP is controlled by setting delay on the ingress DMVPN tunnel. Routes that are received by the tunnel are modified (steered) versus routes that are learned via the LAN.

EIGRP

On the primary DMVPN branch router, a delay of 1,000 is configured on the primary DMVPN tunnel. For the secondary DMVPN branch routers, a delay of 20,000 is configured on the secondary DMVPN tunnel. Example 9 provides sample configuration:

Example 9 EIGRP Traffic Steering for Branch Routers

! R51 (Primary Router for AVC)
interface Tunnel 200
 delay 1000
!---------------------------------------------------!
! R52 (Secondary Router for AVC)
interface tunnel 200
  delay 20000


BGP

If IBGP is used as the transport, then the metric values can be set at the point of redistribution. Setting the values to 1,000 on the primary and 2,000 for the secondary makes things easy to interpret.

Example 10 provides a reference configuration. The prefix-lists were not included for the sake of brevity. The focus is on the different metric values used during redistribution.

Example 10 OSPF Traffic Steering for Branch Routers

! R51 (Primary Router for AVC)
router ospf 1
 redistribute bgp 10 subnets route-map REDIST-BGP-TO-OSPF
 passive-interface default
 no passive-interface GigabitEthernet0/3
 no passive-interface GigabitEthernet1/0
 network 10.0.0.0 255.255.255.255 area 0
 default-information originate
!
route-map REDIST-BGP-TO-OSPF permit 10
 description Set a route tag to identify routes redistributed from BGP
 set tag 1
 set metric 1000
 set metric-type type-1
!---------------------------------------------------!
! R52 (Secondary Router for AVC)
router ospf 1
 redistribute bgp 10 subnets route-map REDIST-BGP-TO-OSPF
 passive-interface default
 no passive-interface GigabitEthernet0/3
 no passive-interface GigabitEthernet1/0
 network 10.0.0.0 255.255.255.255 area 0
 default-information originate
!
route-map REDIST-BGP-TO-OSPF permit 10
 description Set a route tag to identify routes redistributed from BGP
 set tag 1
 set metric 2000
 set metric-type type-1


Note: More information on IWAN routing design can be found in the Cisco Validated Design Document which can be found here: http://www.cisco.com/c/en/us/solutions/enterprise/design-zone-branch-wan/index.html#~designs

Deployment of HSRP

HSRP allows for two routers to create and allocate a virtual IP (VIP) address between multiple routers. This allows for hosts on a LAN segment to configure the VIP as the gateway. In the event of a failure of the router with the VIP, another router could take over the VIP.

In the configuration, the primary router would take ownership of the HSRP VIP which then redirects any directly connected traffic to that router. Example 11 demonstrates the HSRP configuration for R51 and R52 where R51 is the primary router.

Example 11 HSRP Configuration for R51 (Primary) and R52 (Secondary)

! R51 (Primary Router for AVC)
interface GigabitEternet 1/0
 ip address 10.5.5.2 255.255.255.0
 standby 1 ip 10.5.5.1
 standby 1 priority 110
 standby 1 preempt
 standby 1 track 50 decrement 10
!
track 10 interface Tunnel10 line-protocol
!---------------------------------------------------!
! R52 (Secondary Router for AVC)
interface GigabitEternet 1/0
 ip address 10.5.5.3 255.255.255.0
 standby 1 ip 10.5.5.1
 standby 1 priority 105
 standby 1 preempt

Conclusion

Performance Routing can introduce asymmetric routing issues for all deep packet inspection engines. NBAR2 router has to be able to see both sides of flows. The current workaround is to use Policy Based Routing on the tunnel interfaces for the secondary rouers, and then traffic steering in the routing protocol.

Rating: 5.0/5 (3 votes cast)

Personal tools