Lab Objective:
The focus of this lab is to understand Cisco Policy Based Routing (PBR) implementation and configuration in Cisco IOS routers. Additional technologies include path control.
Lab Topology:
The lab network topology is illustrated below:
|
IMPORTANT NOTE If you are using the www.howtonetwork.net racks, please bring up the LAN interfaces connected to the routers by issuing the no shutdown command on the connected switches. If you are using a home lab with no interface fastethernet 0/0 Alternately, you can simply connect the interfaces to a hub or switch if you have one available in your own lab. |
Task 1
Configure hostnames, IP addressing on all routers as illustrated in the network topology.
Task 2
Enable EIGRP using AS 254 on all routers as illustrated in the topology. Do NOT enable EIGRP on the link between R2 and R3. EIGRP packets should not be sent out of the FastEthernet 0/0 interfaces of either R2 or R3. Verify the EIGRP configuration using the appropriate commands.
Task 3
Management has requested that traffic sourced from the 150.1.1.0/24 subnet that has a packet size between 0 and 500 bytes and between 1000 and 1500 bytes and is destined to the 150.3.3.0/24 subnet be sent via R2. All other traffic should following the normal routing path. Verify and test your configuration using the appropriate commands.
Task 4
Management has requested that in the event that the R1-R3 link fails, all traffic sourced from the 150.3.3.0/24 subnet destined to the 150.1.1.0/24 and 150.2.2.0/24 subnets be forwarded via the R2-R3 link. This should ONLY happen when the R1-R2 link is down. Ensure that the 150.3.3.0/24 subnet can reach the 150.1.1.0/24 and 150.2.2.0/24 subnets and vice-versa when you complete this task. You are NOT allowed to configure static routes on R3 to complete this task. Additionally, to minimize device configuration, you MUST use a single ACL with a single entry or line. Verify and test your configuration using the appropriate commands.
Lab Validation
Task 1
Please refer to previous labs for basic IPv4, IPv6 addressing and hostname configuration. This will not be included in this section to avoid being redundant.
Task 2
Please refer to previous labs for basic EIGRP configuration. Following this, verify your EIGRP configuration using the show ip eigrp neighbors andshow ip route commands. Following this configuration, your route tables should show the following path information:
| R1#show ip route eigrp 150.2.0.0/24 is subnetted, 1 subnets D 150.2.2.0 [90/2172416] via 10.0.0.2, 00:03:31, Serial0/0 150.3.0.0/24 is subnetted, 1 subnets D 150.3.3.0 [90/2172416] via 10.0.0.6, 00:02:50, Serial0/1 |
| R2#show ip route eigrp 10.0.0.0/30 is subnetted, 3 subnets D 10.0.0.4 [90/2681856] via 10.0.0.1, 00:03:16, Serial0/0 150.1.0.0/24 is subnetted, 1 subnets D 150.1.1.0 [90/2172416] via 10.0.0.1, 00:03:36, Serial0/0 150.3.0.0/24 is subnetted, 1 subnets D 150.3.3.0 [90/2684416] via 10.0.0.1, 00:02:55, Serial0/0 |
| R3#show ip route eigrp 10.0.0.0/30 is subnetted, 3 subnets D 10.0.0.0 [90/21024000] via 10.0.0.5, 00:02:57, Serial1/0 150.1.0.0/24 is subnetted, 1 subnets D 150.1.1.0 [90/20514560] via 10.0.0.5, 00:02:57, Serial1/0 150.2.0.0/24 is subnetted, 1 subnets D 150.2.2.0 [90/21026560] via 10.0.0.5, 00:02:57, Serial1/0 |
| R4#show ip route eigrp 10.0.0.0/30 is subnetted, 2 subnets D 10.0.0.0 [90/2172416] via 150.1.1.1, 00:01:15, FastEthernet0/0 D 10.0.0.4 [90/2172416] via 150.1.1.1, 00:01:15, FastEthernet0/0 150.2.0.0/24 is subnetted, 1 subnets D 150.2.2.0 [90/2174976] via 150.1.1.1, 00:01:15, FastEthernet0/0 150.3.0.0/24 is subnetted, 1 subnets D 150.3.3.0 [90/2174976] via 150.1.1.1, 00:01:15, FastEthernet0/0 |
Task 3
Several steps are required to complete this task. The first step is that you need to configure an ACL that matches traffic that is sourced from the 150.1.1.0/24 subnet and is destined to the 150.3.3.0/24 subnet. Next, you will need to configure a route map with at least two permit statements. The first permit statement will match traffic in specified in the ACL as long as the packets are between 0 and 500 bytes. The second permit statement will match traffic in the specified ACL as long as the packets are between 1000 and 1500 bytes. Optionally, you can also configure an explicit deny statement for the route map to prevent all other traffic from being policy routed (default behavior). This task is completed as follows:
| R1(config)#access-list 100 permit ip 150.1.1.0 0.0.0.255 150.3.3.0 0.0.0.255 R1(config)#route-map LAN-PBR permit 10 R1(config-route-map)#match ip address 100 R1(config-route-map)#match length 0 500 R1(config-route-map)#set ip next-hop 10.0.0.2 R1(config-route-map)#exit R1(config)#route-map LAN-PBR permit 20 R1(config-route-map)#match length 1000 1500 R1(config-route-map)#match ip address 100 R1(config-route-map)#set ip next-hop 10.0.0.2 R1(config-route-map)#exit R1(config)#route-map LAN-PBR deny 30 R1(config-route-map)#exit R1(config)#interface fastethernet 0/0 R1(config-if)#ip policy route-map LAN-PBR R1(config-if)#exit |
NOTE: You can also use the set interface command when configuring the route map. This is because an explicit route to 150.3.3.0/24 exists in the routing table. If no there is no explicit, or if only a default route is present in the routing table, the command will be ignored.
Verify your route map configuration using the show route-map <name> command:
| R1#show route-map route-map LAN-PBR, permit, sequence 10 Match clauses: ip address (access-lists): 100 length 0 500 Set clauses: ip next-hop 10.0.0.2 Policy routing matches: 0 packets, 0 bytes route-map LAN-PBR, permit, sequence 20 route-map LAN-PBR, deny, sequence 30 |
Next, test your configuration by pinging the 150.3.3.0/24 subnet from R4 using different packet sizes. The following illustrates a 300 byte ping from R4 to R3s LAN interface address:
| R4#ping 150.3.3.3 size 300
Type escape sequence to abort. |
Using the show route-map command, we can see matches against the first permit statement:
| R1#show route-map route-map LAN-PBR, permit, sequence 10 Match clauses: ip address (access-lists): 100 length 0 500 Set clauses: ip next-hop 10.0.0.2 Policy routing matches: 5 packets, 1570 bytes route-map LAN-PBR, permit, sequence 20 route-map LAN-PBR, deny, sequence 30 |
Next, a 700 byte ping is sent from R4 to the LAN interface of R3:
| R4#ping 150.3.3.3 size 700
Type escape sequence to abort. |
This time, there will be no matches against the PBR configuration. Only the five packets from the previous ping test will have matched the configuration applied to R1:
| R1#show route-map route-map LAN-PBR, permit, sequence 10 Match clauses: ip address (access-lists): 100 length 0 500 Set clauses: ip next-hop 10.0.0.2 Policy routing matches: 5 packets, 1570 bytes route-map LAN-PBR, permit, sequence 20 route-map LAN-PBR, deny, sequence 30 |
Finally, to complete our validation, a 1300 byte ping is sent from R4 to the LAN interface of R3.
| R4#ping 150.3.3.3 size 1300
Type escape sequence to abort. |
This time the traffic will match the second permit statement in the route map. The only matches will therefore be 5 packets from the 300 byte ping (permit statement 10) and 5 packets from the 1300 byte ping (permit statement 20). This is validated using the show route-map command:
| R1#show route-map route-map LAN-PBR, permit, sequence 10 Match clauses: ip address (access-lists): 100 length 0 500 Set clauses: ip next-hop 10.0.0.2 Policy routing matches: 5 packets, 1570 bytes route-map LAN-PBR, permit, sequence 20 route-map LAN-PBR, deny, sequence 30 |
NOTE: You can also verify your configuration using the debug ip policy command while sending pings with varying sizes from the 150.1.1.0/24 subnet to the 150.3.3.0/23 subnet.
Task 4
The requirements of this task are two-fold: the first is PBR implementation and the second is IP routing implementation. The PBR requirement is that traffic is only sent across the R2-R3 link when the R1-R3 is down. This means that you must use either the default next hop or default interface route map ‘set’ statements. Either option is acceptable when completing this task. The first requirement of this task is completed as follows:
| R3(config)#access-list 100 permit ip 150.3.3.0 0.0.0.255 150.0.0.0 0.1.1.255 R3(config)#route-map LAN-PBR permit 10 R3(config-route-map)#set ip default next-hop 10.0.0.9 R3(config-route-map)#match ip address 100 R3(config-route-map)#exit R3(config)#route-map LAN-PBR deny 20 R3(config-route-map)#exit R3(config)#interface fastethernet 0/0 R3(config-if)#ip policy route-map LAN-PBR R3(config-if)#exit |
Following this, you can test PBR while dynamic routing information is still available for use by R3. The output below shows a ping from 150.3.3.254 to 150.1.1.1 while the EIGRP route for the destination network is still in the IP routing table:
| R3#show ip route 150.1.1.0 255.255.255.0 Routing entry for 150.1.1.0/24 Known via “eigrp 254”, distance 90, metric 20514560, type internal Redistributing via eigrp 254 Last update from 10.0.0.5 on Serial1/0, 00:09:47 ago Routing Descriptor Blocks: * 10.0.0.5, from 10.0.0.5, 00:09:47 ago, via Serial1/0 Route metric is 20514560, traffic share count is 1 Total delay is 20100 microseconds, minimum bandwidth is 128 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1 R3# R3#debug ip policy Policy routing debugging is on R3# R3# *May 16 17:51:01.863: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 17:51:01.863: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy rejected(explicit route) – normal forwarding *May 16 17:51:01.879: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 17:51:01.879: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy rejected(explicit route) – normal forwarding *May 16 17:51:01.899: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 17:51:01.899: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy rejected(explicit route) – normal forwarding *May 16 17:51:01.919: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 17:51:01.919: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy rejected(explicit route) – normal forwarding *May 16 17:51:01.935: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 17:51:01.935: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy rejected(explicit route) – normal forwarding |
The second requirement of this task is to ensure that routing between the 150.3.3.0/24 and the 150.1.1.0/24 and 150.2.2.0/24 subnets works when the R1-R3 link is no longer available. While the task requirements stipulate that no static routes can be configured on R3, there is no such restriction imposed on R1 or R2. The simplest solution is therefore to configure a floating static route on R2 which is then redistributed into EIGRP. This will be used to reach the 150.3.3.0/24 subnet when the R1-R3 link is unavailable. This task is completed as follows:
| R2(config)#ip route 150.3.3.0 255.255.255.0 10.0.0.10 254 R2(config)#router eigrp 254 R2(config-router)#redistribute static R2(config-router)#exit |
The following illustrates the same ping when the dynamic routing information is no longer available because, for example, the WAN interface has been disabled:
| R3(config)#interface serial 1/0 R3(config-if)#shutdown *May 16 18:12:13.147: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 254: Neighbor 10.0.0.5 (Serial1/0) is down: interface down *May 16 18:12:15.123: %LINK-5-CHANGED: Interface Serial1/0, changed state to administratively down *May 16 18:12:16.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down R3(config-if)#do show ip route 150.1.1.0 255.255.255.0 % Network not in table R3(config-if)#do show ip route 150.2.2.0 255.255.255.0 % Network not in table R3(config-if)# *May 16 18:12:52.171: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 18:12:52.171: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, g=10.0.0.9, len 100, FIB policy routed *May 16 18:12:52.191: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 18:12:52.191: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, g=10.0.0.9, len 100, FIB policy routed *May 16 18:12:52.251: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 18:12:52.251: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, g=10.0.0.9, len 100, FIB policy routed *May 16 18:12:52.271: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 18:12:52.271: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, g=10.0.0.9, len 100, FIB policy routed *May 16 18:12:52.291: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, len 100, FIB policy match *May 16 18:12:52.291: IP: s=150.3.3.254 (FastEthernet0/0), d=150.1.1.1, g=10.0.0.9, len 100, FIB policy routed |
The successful ping is possible because of the redistributed static route on R2 which is installed into the EIGRP Topology Table and IP routing table on R1 as follows:
| R1#show ip eigrp 254 topology 150.3.3.0 255.255.255.0 IP-EIGRP (AS 254): Topology entry for 150.3.3.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2681856 Routing Descriptor Blocks: 10.0.0.2 (Serial0/0), from 10.0.0.2, Send flag is 0x0 Composite metric is (2681856/2169856), Route is External Vector metric: Minimum bandwidth is 1544 Kbit Total delay is 40000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 External data: Originating router is 150.2.2.2 AS number of route is 0 External protocol is Static, external metric is 0 Administrator tag is 0 (0x00000000) |
Final Router Configurations
R1
|
R1#term len 0 Current configuration : 1303 bytes R1# |
R2
|
R2#term len 0 Current configuration : 996 bytes R2# |
R3
|
R3#term len 0 Current configuration : 1477 bytes R3# |
R4
|
R4#term len 0 Current configuration : 843 bytes R4# |