Software defined WAN (SD-WAN) has gained ground in recent years. SD-WAN technology brings to forefront many benefits - ranging from lower cost, increased flexibility to reduced complexity of the overall branch office network. In addition larger players such as Cisco – which launched its IWAN (Intelligent WAN) solution some years back and Citrix with its Cloud Bridge offering, this domain has seen many new entrants – CloudGenix, VeloCloud, Viptela, Talari Networks, Aryaka to name a few. These networking companies need an environments to demonstrate the value gained from SD-WAN, and Ravello’s Network Smart Labs offers the perfect environment to do so.
The following describes in detail how to setup Performance Routing (PfR) - one of the cornerstones of Cisco’s IWAN solution - to show SD-WAN in action. It also includes a base blueprint built with Cisco CSR1000v on Ravello Networking Smart Labs.
The WAN edge is one of the most important functional blocks in the network. It is also one of the hardest areas to design. Traditional WAN’s are based around Border Gateway Protocol (BGP), which is used to peer with other BGP speakers in remote AS. BGP is a policy based routing protocol that allows you to tailor outbound traffic with a variety of metrics. It has proved to be the de facto WAN protocol and is great for reducing network complexity.
However, by default, BGP does not take into account transit performance or detect transitory failures. It misses the shape of the network and cannot dynamically adjust the routing table based on real-time events. To enhance performance, many WAN protocols are manually combined with additional mechanism such as IP SLA and Enhanced Object tracking but these add to configuration complexity. Also, traditional routing is destination based only, which prohibits any type of granular forwarding. All these factors have made the WAN edge a cumbersome module in the network. Flow and application awareness are needed to meet today's application requirements. We need additional insights into the protocols crossing the WAN edge in order to make intelligent routing decisions.
Performance Routing (PfR) formerly known as Optimized Edge Routing (OER) enhances the WAN and adjusts traffic flows based on real-time events. It adds intelligence to network and makes the WAN intelligent and dynamic. It doesn't replace classic IP routing, it augments it and adds application awareness. PfR can select an egress or ingress interface based upon unique characteristics like reachability, jitter, delay, MOS score, throughput and monetary cost. Pfr gains its intelligence by automatically collecting statistics with Cisco IP SLA for active monitoring, and NetFlow for passive monitoring. There is no need to manually configure Netflow or IP SLA, it is automatically implemented by the PfR network.
Link and path information is analysed by a central controller, known as PfR Master Controller (MC), a decision is made based on predefined policy and then an action is carried out by the local Border Edge routers (BR). The MC is where all the decisions are made. It's similar to an SDN controller but IOS based. It does not participate in any data plane forwarding, only control plane services, similar to how a BGP route reflector sits in the network. All policies are configured on the controller, such as preferred link and path parameters. It gathers information from the BR edge nodes and determines whether or not traffic classes are in or out of policy. If traffic is not in policy, it can instruct the BR to carry out route injection or dynamic PBR injection and use an alternative path.
The PfR BR sits within the data plane and participates in traffic forwarding. It is an edge router with one or more exit links to an ISP. The MC doesn't make any changes, it is the BR that actually implements the enforcements. A BR can be enabled on the same router as a MC or it can be separate. All information between the MC and BR is protected with key chains.
Pfr is a useful tool to have in any network. It has a observe mode, which lets the Pfr nodes analyse path and link characteristics and report back for analysis. There is also a route control mode. If the controller determines there is an out of policy event, it can influence the routing table to a more preferred path.
The Ravello Lab consists of two LAN networks separated by a Core. There is a jump host that has access to all nodes and it's here that external connectivity is permitted.
On LAN1 we have 2 x BR and 1 x MC. The MC and the BR device functionality are combined on BR2. Each BR has two uplink to either core nodes, SP1 and SP2. OSPF is running internally and redistribute connected subnets is used for transit link reachability.
On LAN2 we have a single BR and MC component on BR3. OSPF is also running in the Internal LAN, redistributing connected subnets for transit link reachability.
There are a number of test networks on SP1 and SP2. 22.214.171.124/24 & 126.96.36.199/24 on SP1. 188.8.131.52/24 & 184.108.40.206/24 on SP2. These networks are pingable from the LAN routers and can be used for reachability and performance testing.
The first thing to do is set up a keychain so the BR and MC devices can communicate. All communication between the BR and MC is protected. The authentication key must be configured on both the Master Controller and the Border Router.
key chain PFR key 1 key-string CISCO
A PFR network must have at least two exit interface and these must be explicitly configured on the MC. Logging is also turned on.
On BR1 interfaces GigabitEthernet3 and GigabitEthernet4 directly connect to SP1 and are specified as external.
pfr master logging border 220.127.116.11 key-chain PFR interface GigabitEthernet4 external interface GigabitEthernet3 external interface GigabitEthernet1 internal
On BR2 interfaces GigabitEthernet3 and GigabitEthernet4 directly connect to SP2 and are specified as external.
border 18.104.22.168 key-chain PFR interface GigabitEthernet1 internal interface GigabitEthernet3 external interface GigabitEthernet4 external
On BR3 interfaces GigabitEthernet1 and GigabitEthernet2 directly connect to SP1 and SP2 and are specified as external.
border 22.214.171.124 key-chain PFR interface GigabitEthernet1 external interface GigabitEthernet2 external interface GigabitEthernet4 internal
Once completed, you setup the BR functionality on BR1, BR2 and BR3. The loopback addresses are reachable to the internal LAN of each node.
pfr border local Loopback0 master 150.1.X.X key-chain PFR
The following command
show pft master displays the status of the BR connectivity and also the default settings. Notice that the default mode is
mode route control
Both LAN routers have reachability to test prefixes 126.96.36.199 - 188.8.131.52.1. Use these endpoints to test PFR functionally. As a test under the pft config change the external interface to
max-xmit-utilization absolute 1
border 184.108.40.206 key-chain PFR interface GigabitEthernet4 external max-xmit-utilization absolute 1 interface GigabitEthernet3 external max-xmit-utilization absolute 1 interface GigabitEthernet1 internal
Send large packet from LAN1 to 220.127.116.11 and telnet to the prefix from a different host. The IP 18.104.22.168 is on SP2. The large PINGS trigger the out of policy event and the telnet triggers the Netflow. You will notice that the prefix 22.214.171.124 is now out of policy.
The complete configurations for this setup is available on GitHub.
Ravello Network Smart Labs offers a unique way for SD-WAN solution providers and their ecosystem of resellers and trainers to show their technology in action. Interested in playing with this blueprint? Just open a Ravello account and add this blueprint to your library.