In my previous articles you have learned about the most common routing issues which are responsible for network breakdown, and also learned how to tackle and resolve them as quickly as possible.
A network engineer is not only responsible for end-to-end communication but also to provide secure communication with authorized networks only. To prevent unauthorized access, a network engineer has to implement some route filtering technologies such as:
Access Control Lists : ACL is a widely used route filtering technology. Using access-list you can either pass or drop the matched traffic. There are mainly two types of access-lists:
Standard ACL: Used mainly to filter layer 3 network traffic. It can be Named or Numbered.
Extended ACL: It can filter layer 3 as well as layer 4 network traffic and can be configured as Numbered or Named as per requirement.
Route-Maps: Route-map is an advanced route filtering technology which means you can perform conditional filtering with your matched network traffic. Using route map, you can change the attributes like metric, metric-types, next hop ip / interface (weight, local preference, origin with BGP networks) of matched network traffic.
Prefix-Lists: Prefix lists are very useful if you are planning to filter you network traffic on the basis of network size (slash values) for any specific network.
Distribute-Lists: If you want to perform router filtering for your routing database then you have to use distribute-lists. It is not a separate route filtering technology using distribute-list you can call ACLs, route-maps, prefix-lists under routing protocols.
For OSPF: Used to filter type 3 LSA , you can apply filter list using command “area filter-list prefix in | out“
But for BGP, filter list is a form of route policy that is used to filter network traffic on the basis of autonomous system path of the route so if you want your traffic should not be learned from any specific AS or group of AS then you have to use AS-Path filtering in BGP. You must first create an AS-path access list then you can apply it using following filter list command>
“neighbor filter-list in | out“
The above described route filtering technologies are most common and you will see these technologies everywhere in network implementation. I hope all of you are comfortable with these technologies because of previous articles posted here. If you are not then you can request them in the comment section.
Like previous articles, here you will find a GNS3 topology as shown in Fig.1 & you can get the GNS3 file from the Download Link and can start with the described configuration.
In this GNS3 lab, you will begin with preloaded configuration scripts on each of the routers. These scripts contain some errors related to route filtering technologies so you will have to establish end-to-end communication between Clients & Webserver. You will need to troubleshoot each router to determine the configuration errors for route filtering technologies, and then use the appropriate commands to correct the configurations. When you have corrected all of the configuration errors, clients on the network should be able to communicate with the webserver.
Learning Objectives with GNS3 Lab:
Upon completion of this lab, you will be able to troubleshoot and resolve:
Access Control List Issues
Improper Network Traffic Match Issues
Also, you will be able to:
Gather information about the misconfigured portion of the network
Analyze information to determine why communication is not possible
Implement solutions to resolve network errors
Okay, let’s start. Open GNS3 Topology and turn on all of the devices. You will see that Client 1 is not able to access Webserver (126.96.36.199) or not even Router LA.
Client1#ping 188.8.131.52 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 184.108.40.206, timeout is 2 seconds: .U.U. Success rate is 0 percent (0/5) Client1#ping 220.127.116.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5)
Only f0/0 interface of router HQ2 i.e. 10.123.12.1 is reachable from client 1 and running configuration of router HQ2 seems fine and also HQ2 is configured as HSRP Active router with priority 110 which means Client 1 will send all traffic towards HQ2. Eigrp is also working properly Not a single route-filtering technology is configured on HQ2 so let’s check the next router i.e. HQ1.
If you go through the running configuration of HQ1, you will find an access control list “infosec” which is applied on interface f0/0 for incoming traffic. A prefix-list named 23 is also configured which is called under a route-map EO and the route-map EO in applied at eigrp redistribution in the OSPF process. Let’s check ACL first using “show ip access-list” as shown in Fig. 2:
And if you look at the sequence number 30 “permit 10.1.1.0 0.0.0.3” of Access list infosec as shown in Fig. 2, it is only permitting 10.1.1.0/30 whereas client1 is configured with /29 which is why the client is not able to ping 10.123.12.2 so sequence number 30 should be configured for permitting /29 for 10.1.1.0 network. You can correct it using following commands,
HQ1(config)#ip access-list standard infosec HQ1(config-std-nacl)#no 30 HQ1(config-std-nacl)#30 permit 10.1.1.0 0.0.0.7
After configuring the above commands, you will be able to access router HQ1’s f0/0 but not s0/0 which means problem with EIGRP – OSPF communication and you know a route-map is configured under OSPF for EIGRP redistribution, consider the following output of running configuration to check route-map/ prefix-list,
! router ospf 1 log-adjacency-changes redistribute eigrp 10 metric 10 subnets route-map EO network 22.214.171.124 0.0.0.0 area 0 ! ip prefix-list 23 seq 5 permit 10.0.0.0/8 ge 30 le 30 ! ! ! route-map EO permit 1 match ip address prefix-list 23
Prefix list 23 is matching network 10.0.0.0/8 with subnet mask of /30, which means any network of 10 is permitted with /30 only and you know client/HSRP network 10.1.1.0 is configured with /29 which is why you are not able to access any ospf network so make it correct using the following commands:
HQ1(config)#no ip prefix-list 23 seq 5 permit 10.0.0.0/8 ge 30 le 30 HQ1(config)#ip prefix-list 23 seq 5 permit 10.0.0.0/8 ge 29 le 29
After configuring the above command, you will be reachable to Router LA but not with Router CANADA.
Now it’s time to check router LA & CANADA. Here you will see that BGP peering is in Active State and if you have read my previous article on BGP then it will be easy for you to resolve and if you haven’t already, please check out my previous article on BGP troubleshooting. Why is BGP in ACTIVE state? Even it is properly configured; there is no need of configuring update-source or ebgp-multihop because BGP peer is directly connected so what can be the issue?
BGP configuration seems fine but if you look at the running configuration of router LA, you will find an access-list 20 and it is permitting only 126.96.36.199/30 not 188.8.131.52/30.When applied on interface s0/1 which is connected to router CANADA, that’s why BGP peering is in ACTIVE.
So permit 184.108.40.206/30 in ACL 20 as below:
LA(config)#access-list 20 permit 220.127.116.11 0.0.0.3
Within 60 seconds, you will get BGP adjacency message for peer establishment and also Client 1 will be able to ping webserver so for now you have won half of the battle.
Client 2 is not able to ping the webserver and if you trace the webserver ip 18.104.22.168 from client 2, you will see that client 2’s traffic is not going out from its gateway (router WDC) as shown in Fig. 3 below:
If you check the running configuration on router WDC, you will find a route-map configured with “set interface null0” for any traffic coming from Client 2 (10.1.1.2) which means it is forwarding traffic to a black hole. Fig. 4 displays the specific output of show running-configuration of router WDC:
So we have to set proper exit interface as described below:
WDC(config)#route-map intense permit 10 WDC(config-route-map)#no set interface Null0 WDC(config-route-map)# set interface s0/1 /* connected to router LA
After configuring the above commands, you will be able to reach router LA but not beyond that. Let’s checks router LA again. Here you will find the Network Address Translation –PAT configuration and an access-list 10 is matching all inside local traffic for NAT except 10.2.1.0/30 which is Client 2’s network. That’s why everyone can ping the webserver except client 2. Fig. 5 displays the specific output of “show run” command on router LA:
Because NAT is not configured for client 2’s network, you will have to add 10.2.1.0/30 network in access list 10 so that client 2 will be able to translate.
LA(config)#access-list 10 permit 10.2.1.0 0.0.0.3
After configuring the above commands, client 2 will be able to access the webserver.
Now both clients can ping the webserver.
The following commands may be useful in troubleshooting route filtering issues:
- show access-lists |
- show ip access-lists |
- show ip access-lists interface
- show route-map
- show ip prefix-list details
- show ip prefix-list summary
I have also attached a solution file in this article to tally your solutions. After completing the above GNS3 lab, you will be able to resolve most of the route filtering issues.
Cisco Certified Internetwork Expert by Wendell Odom and others, Ciscopress.com
Guide to Cisco Certified Network Associate certification by Todd Lammle
CCNP- Route Quick reference by Denis Donohou, Ciscopress.com
Cisco Certified Internetwork Expert Quick reference by Brad Ellis, Ciscopress.com