CCNP ROUTE 300-101 Prt 3.12 – Configure and Verify Policy Base Routing

Policy-Based Routing

When a packet arrives at the incoming interface of a router, the router’s data plane processing logic takes several steps to process the packet. The incoming packet actually
arrives encapsulated inside a data link layer frame, so the router must check the incoming frame’s FCS and discard the frame if errors occurred in transmission.

If the FCS check passes, the router discards the incoming frame’s data-link header and trailer, leaving the Layer 3 packet. Finally, the router does the equivalent of  comparing the destination IP address of the packet with the IP routing table, matching the longest-prefix route that matches the destination IP address.

PBR overrides a router’s natural destination-based forwarding logic. PBR intercepts the packet after deencapsulation on the incoming interface, before the router performs the CEF table lookup. PBR then chooses how to forward the packet using criteria other than the usual matching of the packet’s destination address with the CEF table.

PBR chooses how to forward the packet by using matching logic defined through a route
map, which in turn can refer to an ACL, Prefix-List, etc. That same route map also defines the forwarding instructions—the next-hop IP address or outgoing interface—for packets matched by the route map.

Below shows the general concept of operation of a Route Map, with PBR on interface Fa0/0 overriding the usual routing logic, forwarding packets out three different outgoing interfaces.

PBR Operational Concept

 

To perform the actions shown below, you have to configure two general steps:

1– Create a Route Map with the logic to match packets, and choose the route, as
shown on the left side of the figure.

2– Enable the Route Map for use with PBR, on an interface, for packets entering
the interface.

 

Matching the Packet and Setting the Route

To match packets with a route map enabled for PBR, you use the familiar route-map
match command. However, you have two match command options to use:

  • match ip address
  • match length min max

 

The match ip address command can reference standard and extended ACLs. Any item
matchable by an ACL can be matched in the route map. The match length command
allows you to specify a range of lengths, in bytes.

When a route map clause (with a permit action) matches a packet, the set command
defines the action to take regarding how to forward the packet. The four set command
options define either the outgoing interface or the next-hop IP address, just like routes in
the IP routing table.

 

Next-hop addresses must be in a connected subnet; PBR forwards to the first address in the list for which the associated interface is up.

set ip next-hop ip-address [...ip-address]

 

Same logic as previous command, except PBR first attempts to route based on the routing table.

set ip default next-hop ip-address [...ip-address]

 

PBR forwards packets using the first interface in the list that is up.

set interface interface-type interfacenumber [...interface-type interface-number]

 

Same logic as previous command, except PBR first attempts to route based on the routing table.

set default interface interface-type interface- number [...interface-type interface-number]

 

Note that two of the commands allow the definition of a next-hop router, and two allow
the definition of an outgoing interface. The other difference in the commands relates
to whether the command includes the default keyword. (I’ll go through that in a few).

After the route map has been configured with all the clauses to match packets and to set
an outgoing interface or next-hop address, the only remaining step requires the ip policy
route-map name command to enable PBR for packets entering an interface.

 

Configure and Verify Path Control

PBR

 

Objectives

• Configure and verify policy-based routing.
• Select the required tools and commands to configure policy-based routing operations.
• Verify the configuration and operation by using the proper verification commands.

Routers are running the following version:

R1# sh version
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version 15.4(2)T4, DEVELOPMENT TEST SOFTWARE
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Thu 08-Oct-15 21:21 by prod_rel_team

ROM: Bootstrap program is Linux

R1 uptime is 9 minutes

 

Let’s start with the initial configuration of all routers, hostnames, interface addresses and descriptions, routing protocol configuration.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# hostname R1
R1(config)# interface Loopback1
R1(config-if)# description R1 LAN
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# interface Serial0/0
R1(config-if)# description R1 --> R2
R1(config-if)# bandwidth 128
R1(config-if)# ip address 172.16.12.1 255.255.255.248
R1(config-if)# no shut
R1(config-if)# interface Serial0/1
R1(config-if)# description R1 --> R3
R1(config-if)# bandwidth 64
R1(config-if)# ip address 172.16.13.1 255.255.255.248
R1(config-if)# no shut
R1(config-if)# router eigrp 1
R1(config-router)# network 172.16.12.1 0.0.0.0
R1(config-router)# network 172.16.13.1 0.0.0.0
R1(config-router)# network 192.168.1.0
R1(config-router)# end
R1# sh interfaces description | e admin
Interface Status Protocol Description
Se0/0 up up R1 --> R2
Se0/1 up up R1 --> R3
Lo1 up up R1 LAN

R1#
*Jun 21 10:31:06.405: %SYS-5-CONFIG_I: Configured from console by console
R1# sh ip int bri | e admin
Interface IP-Address OK? Method Status Protocol
Serial0/0 172.16.12.1 YES NVRAM up up 
Serial0/1 172.16.13.1 YES NVRAM up up 
Loopback1 192.168.1.1 YES NVRAM up up

R1#


R2# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# hostname R2
R2(config)# interface Loopback2
R2(config-if)# description R2 LAN
R2(config-if)# ip address 192.168.2.1 255.255.255.0
R2(config-if)# interface Serial0/0
R2(config-if)# description R2 --> R1
R2(config-if)# bandwidth 128
R2(config-if)# ip address 172.16.12.2 255.255.255.248
R2(config-if)# no shut
R2(config-if)# interface Serial0/1
R2(config-if)# description R2 --> R3
R2(config-if)# bandwidth 128
R2(config-if)# ip address 172.16.23.2 255.255.255.248
R2(config-if)# no shut
R2(config-if)# router eigrp 1
R2(config-router)# network 172.16.12.2 0.0.0.0
R2(config-router)# network 172.16.23.2 0.0.0.0
R2(config-router)# network 192.168.2.0
R2(config-router)# end
R2# sh interfaces description | e admin
Interface Status Protocol Description
Se0/0 up up R2 --> R1
Se0/1 up up R2 --> R3
Lo2 up up R2 LAN

R2# sh ip interface brief | e admin
Interface IP-Address OK? Method Status Protocol
Serial0/0 172.16.12.2 YES NVRAM up up 
Serial0/1 172.16.23.2 YES NVRAM up up 
Loopback2 192.168.2.1 YES NVRAM up up 

R2#


R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# hostname R3
R3(config)# interface Loopback3
R3(config-if)# description R3 LAN
R3(config-if)# ip address 192.168.3.1 255.255.255.0
R3(config-if)# interface Serial0/0
R3(config-if)# description R3 --> R1
R3(config-if)# bandwidth 64
R3(config-if)# ip address 172.16.13.3 255.255.255.248
R3(config-if)# no shut
R3(config-if)# interface Serial0/1
R3(config-if)# description R3 --> R2
R3(config-if)# bandwidth 128
R3(config-if)# ip address 172.16.23.3 255.255.255.248
R3(config-if)# no shut
R3(config-if)# interface Serial0/2
R3(config-if)# description R3 --> R4
R3(config-if)# bandwidth 64
R3(config-if)# ip address 172.16.34.3 255.255.255.248
R3(config-if)# no shut
R3(config-if)# router eigrp 1
R3(config-router)# network 172.16.13.3 0.0.0.0
R3(config-router)# network 172.16.23.3 0.0.0.0
R3(config-router)# network 172.16.34.3 0.0.0.0
R3(config-router)# network 192.168.3.0
R3(config-router)# end
R3# sh interfaces description | e admin
Interface Status Protocol Description
Se0/0 up up R3 --> R1
Se0/1 up up R3 --> R2
Se0/2 up down R3 --> R4
Lo3 up up R3 LAN

R3# sh ip interface brief | e admin
Interface IP-Address OK? Method Status Protocol
Serial0/0 172.16.13.3 YES NVRAM up up 
Serial0/1 172.16.23.3 YES NVRAM up up 
Serial0/2 172.16.34.3 YES NVRAM up down 
Loopback3 192.168.3.1 YES NVRAM up up 

R3#


R4# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)# hostname R4
R4(config)# interface Loopback4
R4(config-if)# description R4 LAN A
R4(config-if)# ip address 192.168.4.1 255.255.255.128
R4(config-if)# interface Loopback5
R4(config-if)# description R4 LAN B
R4(config-if)# ip address 192.168.4.129 255.255.255.128
R4(config-if)# interface Serial0/0
R4(config-if)# description R4 --> R3
R4(config-if)# bandwidth 64
R4(config-if)# ip address 172.16.34.4 255.255.255.248
R4(config-if)# no shut
R4(config-if)# router eigrp 1
R4(config-router)# network 172.16.34.4 0.0.0.0
R4(config-router)# network 192.168.4.0
R4(config-router)# end
R4# sh interfaces description | e admin
Interface Status Protocol Description
Se0/0 up up R4 --> R3
Lo4 up up R4 LAN A
Lo5 up up R4 LAN B

R4# sh ip interface brief | e admin
Interface IP-Address OK? Method Status Protocol
Serial0/0 172.16.34.4 YES NVRAM up up 
Loopback4 192.168.4.1 YES NVRAM up up 
Loopback5 192.168.4.129 YES NVRAM up up 

R4#

 

At this point all basic configuration is done, let’s now verify EIGRP connectivity.

R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
1 172.16.13.3 Se0/1 10 00:33:27 34 2340 0 14
0 172.16.12.2 Se0/0 14 00:33:52 21 1170 0 18
R1#

R2# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
1 172.16.23.3 Se0/1 10 00:33:36 22 1170 0 13
0 172.16.12.1 Se0/0 10 00:33:49 20 1170 0 18
R2#

R3# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
2 172.16.34.4 Se0/2 13 00:32:24 50 2340 0 3
1 172.16.13.1 Se0/0 10 00:33:01 35 2340 0 19
0 172.16.23.2 Se0/1 11 00:33:13 19 1170 0 19
R3#

R4# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
0 172.16.34.3 Se0/0 13 00:32:20 46 2340 0 15
R4#

 

All looks correct, now let’s verify full connectivity with the below script.

R1# tclsh
R1(tcl)# foreach potato {
+>(tcl)# 172.16.12.1
+>(tcl)# 172.16.12.2
+>(tcl)# 172.16.13.1
+>(tcl)# 172.16.13.3
+>(tcl)# 172.16.23.2
+>(tcl)# 172.16.23.3
+>(tcl)# 172.16.34.3
+>(tcl)# 172.16.34.4
+>(tcl)# 192.168.1.1
+>(tcl)# 192.168.2.1
+>(tcl)# 192.168.3.1
+>(tcl)# 192.168.4.1
+>(tcl)# 192.168.4.129
+>(tcl)# } { ping $potato }

 

Test it on all routers, troubleshoot if necessary but you should have full connectivity between all router’s interfaces at this point.

 

Now, before we configure PBR, verify the routing table on R1. Notice the next-hop IP address for all networks discovered by EIGRP.

R1# sh ip route eigrp | b Gateway
Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
D 172.16.23.0/29 [90/21024000] via 172.16.12.2, 01:50:13, Serial0/0
D 172.16.34.0/29 [90/41024000] via 172.16.13.3, 01:49:37, Serial0/1
D 192.168.2.0/24 [90/20640000] via 172.16.12.2, 01:50:13, Serial0/0
D 192.168.3.0/24 [90/21152000] via 172.16.12.2, 01:50:13, Serial0/0
 192.168.4.0/25 is subnetted, 2 subnets
D 192.168.4.0 [90/41152000] via 172.16.13.3, 01:49:35, Serial0/1
D 192.168.4.128 [90/41152000] via 172.16.13.3, 01:49:35, Serial0/1
R1#

 

On R4, perform a traceroute to the R1 LAN address and source the ICMP packets from R4 LAN A and LAN B.

R4# traceroute 192.168.1.1 source 192.168.4.1 
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
 1 172.16.34.3 13 msec 13 msec 12 msec
 2 172.16.23.2 26 msec 24 msec 21 msec
 3 172.16.12.1 29 msec 30 msec 29 msec
R4#
R4# traceroute 192.168.1.1 source 192.168.4.129
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
 1 172.16.34.3 15 msec 12 msec 12 msec
 2 172.16.23.2 26 msec 25 msec 22 msec
 3 172.16.12.1 33 msec 29 msec 29 msec
R4#

 

Notice that the path chosen for the packets sourced from the R4 LANs are going through R3 -> R2 -> R1. Why are the R4 interfaces not using the R3 -> R1 path? It’s the most direct path right? Let’s have a look into it. Notice the bandwidth configured on each interface and also the next-hop to the 192.168.1.0/24 route.

R3# sh interface s0/0 | s BW
 MTU 1500 bytes, BW 64 Kbit/sec, DLY 20000 usec, 
 reliability 255/255, txload 1/255, rxload 1/255

R3#
R3# sh interface s0/1 | s BW
 MTU 1500 bytes, BW 128 Kbit/sec, DLY 20000 usec, 
 reliability 255/255, txload 1/255, rxload 1/255

R3# sh ip route eigrp | b Gateway
Gateway of last resort is not set

 172.16.0.0/16 is variably subnetted, 7 subnets, 2 masks
D 172.16.12.0/29 [90/21024000] via 172.16.23.2, 03:27:38, Serial0/1
D 192.168.1.0/24 [90/21152000] via 172.16.23.2, 03:27:38, Serial0/1
D 192.168.2.0/24 [90/20640000] via 172.16.23.2, 03:27:38, Serial0/1
 192.168.4.0/25 is subnetted, 2 subnets
D 192.168.4.0 [90/40640000] via 172.16.34.4, 03:27:01, Serial0/2
D 192.168.4.128 [90/40640000] via 172.16.34.4, 03:27:01, Serial0/2
R3#

 

It’s obvious why, because interface s0/1 which connects to R2 has a higher bandwidth than s0/0 interface connecting to R1.

 

Confirm that R3 has a valid route to reach R1 from its serial 0/0/0 interface. Do this with the following.

R3# sh ip eigrp topology 192.168.1.0 255.255.255.0
EIGRP-IPv4 Topology Entry for AS(1)/ID(192.168.3.1) for 192.168.1.0/24
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21152000
 Descriptor Blocks:
 172.16.23.2 (Serial0/1), from 172.16.23.2, Send flag is 0x0
 Composite metric is (21152000/20640000), route is Internal
 Vector metric:
 Minimum bandwidth is 128 Kbit
 Total delay is 45000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 2
 Originating router is 192.168.1.1
 172.16.13.1 (Serial0/0), from 172.16.13.1, Send flag is 0x0
 Composite metric is (40640000/128256), route is Internal
 Vector metric:
 Minimum bandwidth is 64 Kbit
 Total delay is 25000 microseconds
 Reliability is 255/255
 Load is 1/255
 Minimum MTU is 1500
 Hop count is 1
 Originating router is 192.168.1.1
R3#

 

From the output we can see that R4 has two routes to reach 192.168.1.0. However, the metric for the route to R1 (172.16.13.1) is much higher (40640000) than the metric of the route to R2 (21152000), making the route through R2 the successor route. That’s all good but this network topology is not a democracy and I want something else!

 

Configure PBR to provide path control

Now we will implement source-based IP routing by using PBR. I will force a default IP routing decision based on the EIGRP-acquired routing information for selected IP source-to-destination flows and apply a different next-hop router.

Recall that routers normally forward packets to destination addresses based on information in their routing table. By using PBR, you can implement policies that cause packets to take different paths based on source address, protocol type, or application type. Therefore, PBR overrides the router’s normal routing behavior.

Configuring PBR involves defining the interesting traffic with an ACL, configuring a route map with match and set commands and then applying the route map (policy) to the interface.

 

The steps required to implement path control include:

• Choose the path control tool to use. Path control tools manipulate or bypass the IP routing table. For PBR, route-map commands are used.

• Implement the Traffic-matching configuration, specifying which traffic will be manipulated. The match commands are used within route maps.

• Define the action for the matched traffic using set commands within route maps.

• Apply the route map to incoming traffic.

 

So, now as a test, we will configure the following policy on router R3:

• All traffic sourced from R4 LAN A must take the R3 -> R2 -> R1 path.
• All traffic sourced from R4 LAN B must take the R3 -> R1 path.

On router R3, create a standard access list to identify the R4 LAN B network.

R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# ip access-list standard PBR-R4_LAN_B
R3(config-std-nacl)# remark ACL matches R4 LAN B traffic
R3(config-std-nacl)# permit 192.168.4.128 0.0.0.127
R3(config-std-nacl)# exit
R3(config)#

 

Create a route map that matches the ACL we just created and sets the next-hop interface to R1’s s0/1.

R3(config)# route-map R3->R1_FLOW_B permit 
R3(config-route-map)# match ip address PBR-R4_LAN_B
R3(config-route-map)# set ip next-hop 172.16.13.1
R3(config-route-map)# exit
R3#

 

Now apply the route map to the serial interface on R3 that receives the traffic from R4 (s0/2).

R3(config)# interface s0/2
R3(config-if)# ip policy route-map R3->R1_FLOW_B
R3(config-if)# end
R3#

 

On R3, let’s verify the policy implemented, and matches that hit the rout-map.

R3# sh route-map
route-map R3->R1_FLOW_B, permit, sequence 10
 Match clauses:
 ip address (access-lists): PBR-R4_LAN_B 
 Set clauses:
 ip next-hop 172.16.13.1
 Policy routing matches: 0 packets, 0 bytes
R3#

 

Note:  There are currently no matches because no packets matching the ACL have passed through R3 S0/1.

 

Testing the Policy

Now you are ready to test the policy configured on R3. Debug the policy on R3 so that you can observe the policy decision-making in action. To help filter the traffic, first create an ACL that identifies all traffic from the R4 LANs.

R3# conf t
R3(config)# access-list 1 permit 192.168.4.0 0.0.0.255
R3(config)# end
R3# debug ip policy 1
Policy routing debugging is on for access list 1
R3#

 

Let’s test the policy from R4 with a traceroute, using R4 LAN A as the source network.

R4# traceroute 192.168.1.1 source 192.168.4.1
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
 1 172.16.34.3 15 msec 13 msec 13 msec
 2 172.16.23.2 22 msec 22 msec 21 msec
 3 172.16.12.1 29 msec 29 msec 32 msec
R4#

 

Notice the path taken for the packet sourced from R4 LAN A is still going through R3 -> R2 -> R1. As the traceroute was being executed, router R3 is generating the following output.

R3#
*Jun 21 17:12:02.791: IP: s=172.16.23.2 (Serial0/1), d=192.168.4.1, len 56, FIB policy rejected(no match) - normal forwarding
*Jun 21 17:12:02.813: IP: s=172.16.23.2 (Serial0/1), d=192.168.4.1, len 56, FIB policy rejected(no match) - normal forwarding
*Jun 21 17:12:02.835: IP: s=172.16.23.2 (Serial0/1), d=192.168.4.1, len 56, FIB policy rejected(no match) - normal forwarding
R3#

 

Obviously the route chosen is still decided by the EIGRP routing table because the source-based packets don’t match the policy we have created. Now let’s test the policy from R4 using LAN’s B as the source network and observe the results.

R4# traceroute 192.168.1.1 source 192.168.4.129
Type escape sequence to abort.
Tracing the route to 192.168.1.1
VRF info: (vrf in name/id, vrf out name/id)
 1 172.16.34.3 13 msec 12 msec 13 msec
 2 172.16.13.1 27 msec 38 msec 30 msec
R4#

 

And here we go! We are now having the packet forwarding according to the policy we created, R4 LAN B is routed through R3 -> R1, as expected, terrific! And the debug output on R3 also confirms that the traffic meets the criteria of the policy.

R3#
*Jun 21 17:24:12.956: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, len 28, policy match
*Jun 21 17:24:12.956: IP: route map R3->R1_FLOW_B, item 10, permit
*Jun 21 17:24:12.956: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1 (Serial0/0), len 28, policy routed
*Jun 21 17:24:12.956: IP: Serial0/2 to Serial0/0 172.16.13.1
*Jun 21 17:24:12.969: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, len 28, policy match
*Jun 21 17:24:12.969: IP: route map R3->R1_FLOW_B, item 10, permit
*Jun 21 17:24:12.969: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1 (Serial0/0), len 28, policy routed
*Jun 21 17:24:12.969: IP: Serial0/2 to Serial0/0 172.16.13.1
*Jun 21 17:24:12.982: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, len 28, policy match
*Jun 21 17:24:12.982: IP: route map R3->R1_FLOW_B, item 10, permit
*Jun 21 17:24:12.982: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1 (Serial0/0), len 28, policy routed
*Jun 21 17:24:12.982: IP: Serial0/2 to Serial0/0 172.16.13.1
*Jun 21 17:24:12.995: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, len 28, FIB policy match
*Jun 21 17:24:12.995: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, len 28, PBR Counted
*Jun 21 17:24:12.995: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed
R3#
*Jun 21 17:24:13.022: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, len 28, FIB policy match
*Jun 21 17:24:13.022: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, len 28, PBR Counted
*Jun 21 17:24:13.022: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed
*Jun 21 17:24:13.065: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, len 28, FIB policy match
*Jun 21 17:24:13.065: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, len 28, PBR Counted
*Jun 21 17:24:13.065: IP: s=192.168.4.129 (Serial0/2), d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed
R3#

 

Let’s  verify on R3, display the policy and matches (the hits on the policy).

R3# sh route-map
route-map R3->R1_FLOW_B, permit, sequence 10
 Match clauses:
 ip address (access-lists): PBR-R4_LAN_B 
 Set clauses:
 ip next-hop 172.16.13.1
 Policy routing matches: 6 packets, 192 bytes
R3#

 

We now are able to see 6 packets matching the policy as expected. Obviously this can get much more complex depending on the scenario you have at hand but just as an example is good enough. “Alrighty Then!”

 

Hope this helps someone else!

Advertisements

One response to “CCNP ROUTE 300-101 Prt 3.12 – Configure and Verify Policy Base Routing

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s