5 Diagnostics Ticket Your are working as a network administrator of a network where, users connected to R1.are reporting problems in accessing web based services. As per information provided in the ticket logs, Host 1is not able to ping Web Address 8.8.8.8 while Host 2 does. Configurations and Outputs: Rand R2, RLand R@ are configured eBGP. R2 and R3 are running iBGP. R1Lis recieving many routes via R2 and R3. R1, R2 and R3is confugured BGP community and other attributes. Ri prefers, R1- R3 path to access Web. Web Prefers R2 - R1 path to access Host 1. Ris configured 2 NAT statements. RLis translating Host 1 connected with E0/0 to its loopback0. Ris translating Host 2 connected with EO/1 to its loopback]. RL configured uRPF on its interface E0/2. RL configured uRPF on its interface EO/3. 470_© 2014CcieFor your understanding: URPF is configured on R: this interface, packets will be droped for that source. Route 8.8.8.8 or 0.0.0.0 is being preffered via interface E0/3 (Connects to R3). terface EO/2 (Connects to CPS R2) which says any route which is not learnt Our suggestions for your understanding: Check how is the routing for destination, which interface or next-hop IP is having proffered route to web on R1. Check how source (NAT Interface for Hosts) is being advertised on Rand its reaching to R2 and R3. Check weather NAT statement for source Hosts are correct or not. Check how the uRPF is acting, it is Loose Mode or Strict. Correct NAT satement should have ip nat inside source/etc. WAN interface must be configured ip nat outside or PAT/NAT Loopback. Check NAT Access list is matching correct source and destination. 471_© 2014Ccie Perfect SolutionsUnderstanding uRPF: Unicast RPF checks to see if any packet received at a router interface arrives on the best return path (return route) to the source of the packet. Unicast RPF does this by doing a reverse lookup in the CEF table. If the packet was received from one of the best reverse path routes, the packet is forwarded as normal. If there is no reverse path route on the same interface from which the packet was received, it might mean that the source address was modified. If Unicast RPF does not find a reverse path for the packet, the packet is dropped or forwarded, depending on whether an access control list (ACL) is specified in the ip verify unicast reverse-path interface configuration command. With Unicast RPF, all equal-cost "best" return paths are considered valid. This means that Unicast RPF works i where multiple return paths exist, provided that each path Is equal to the others in terms of the routing cost (number of hops, weights, and so on) and as long as the route isin the FIB. Unicast RPF also functions where EIGRP variants are being used and unequal candidate paths back to the source IP address exist. When a packet is received at the interface where Unicast RPF and ACLs have been configured, the following actions occur: Step 1 Input ACLs configured on the inbound interface are checked. ‘Step 2 Unicast RPF checks to see if the packet has arrived on the best return path to the source, which it does by doing a reverse lookup in the FIB table. Step 3 CEF table (FIB) Lookup is carried out for packet forwarding. Step 4 Output ACLs are checked on the outbound interface. ‘Step 5 The packet is forwarded. Unicast RPF works in one of three different modes: trict mode, loose mode, or VRF mode. Strict Mode - When administrators use Unicast RPF in strict mode, the packet must be received on the interface that the router would use to forward the return packet. Unicast RPF configured in strict mode may drop legitimate traffic that is, received on an interface that was not the router's choice for sending return traffic. Dropping this legitimate traffic could occur when asymmetric routing paths are present in the network. Loose Mode - When administrators use Unicast RPF in loose mode, the source address must appear in the routing table. Administrators can change this behavior using the allow-default option, which allows the use of the default route in the source verification process. Additionally, a packet that contains a source address for which the return route points to the Nult 0 interface will be dropped. An access list may also be specified that permits or denies certain source addresses in Unicast RPF loose mode. 472_© 2014Ccie Perfect Solutionsinterface FastEthernet 0/0 ip verify unicast source reachable-via {rx | any} [allow-default] [allow-self-ping] Unicast RPF is enabled on a per-interface basis. The ip verify unicast source reachable-via rx command enables Unicast RPF in strict mode: To enable loose mode, administrators can use the any option to enforce the requirement that the source IP address fora packet must appear in the routing table. The allow-default option may be used with either the rx or any option to include IP addresses not specifically contained in the routing table. The allow-self-ping option should not be used because it could create a denial of service condition. ‘An access list such as the one that follows may also be configured to specifically permit or deny a list of addresses through Unicast RPF. http: //www.cisco.comAweb/about/security /intelligence/unicast-rpf.htmt http://www.cisco.com/c/en/us/td/docs/ios/12_2/security /configuration/guide/tsecur_c/sefrpf.htmt Example of Correct NAT statements: Correct Static NAT Example ip nat inside source static 1.1.1.12.2.2.2 Where 1.1.1.1is inside host and 2.2.2.2 is WAN Advertised IP. Correct Dynamic NAT Example interface fastethernet 0/0 Ip address 1.1.1.1 255. ! interface serial 0/0/0 ip address 2.2.2.1 255. ! access-list 1 permit 1.1.0.00.0.0.255 ip nat pool CPS 2.2.2.1 2.2.2.5 netmask 255.0.0.0 ip nat inside source list 1 pool CPS ! 0 interface fastEthernet 0/0 ip nat inside ! interface serial 0/0/0 ip nat outside 473_© 2014Ccie Perfect SolutionsCorrect PAT Example access-list 1 permit 1.1.1.00.0.0.255 ip nat inside source list 1 interface loopback0 overload Correct PAT With Pool Example access-list 1 permit 1.1.1.00.0.0.255 ip nat pool CPS 2.2.2.12.2.2.5 netmask 255.0.0.0 ip nat inside source list 1 pool CPS overload Please connect 3 routers R1.- R2 and R3 and test all possible NAT/PAT Options, you need to be master of NAT. 474 © 2014CciePart 1 Question: Order correct 8 options from below list to expt Poe to your colleague the problem why Host 1 is unable to ping web server: Packets are received by R2 and forwarded to the R1 looks up its routing table (RIB) and selects interface E0/3 destination as Egress Interface Packets are received by R3 and forwarded to the destination R11 looks up its routing table (RIB) and selects R11 translates the source IP address to its interface loopbackO interface E0/3 as Egress Interface R2and R3 drop the packet due to missing routing information for the destination The destination does not reply with an icmp echo reply | R1 transmits the icmp request to R3 via interface EO/3 R2 transmits the echo reply to R1 R2 and R3 (CPS ) drop the packet due to missing Packets are received by R3 and forwarded to the destination routing information for the source Unicast RPF on R1 drops the echo reply Ri translates the source IP address to its interface | The destination replies with iemp echo reply toopbacko R1 looks up its routing table (RIB) and selects interface E0/2 as Egress Interface Ri access-list drops the echo reply The echo reply is routed via R2 ‘The echo reply is routed via R2 ‘The destination replies with icmp echo reply R2 transmits the echo reply to R1 ‘The echo reply is routed via R2 Ri translates the source IP address tots interface | Unicast RPF on R1 drops the echo reply Loopabck1 R3 transmits the echo reply to R1 The echo reply is routed via R R1 transmits the icmp request to R3 via interface EO/3 475 _© 2014Ccie Perfect SolutionsSuggestions for your understanding: ‘The Idea is, when Host 1 issues pings to internet, it gets send to R1. R1(CPS) looks up the destination IP address in RIB. It finds E0/3 (connecting to R3) as exit interface It Changes the source Private IP to NAT/PAT IP. It (CPS) forwards icmp echo requests to R3 (CPS). R3 (CPS) looks up its table and sends to Internet. Internet replies back to host 1 via R2(C PS). R2 (CPS) sends reply to R1 (CPS) via interface EO/2 R1 (CPS) looks up reverse path in RIB as per uRPF rules RL(CPS) \ds source being learnt via EO/3 (connecting to R3 (CPS)). Its drops the reply. 476 © 2014Ccie Perfect SolutionsPart 2 Question 1: What is most likely casue and solution of the problem? Answer: uRPF Part 2 Question 1 Alternate: Select is most likely casue and solution of the problem: © Asymmetric routinng with unicast RPF © Symmetric routing with unicast RPF Routing loop due to Wrong BGP community configuration Traffic dropped via access list Traffic droped because of oversubscription of bandwidth Traffic droped because of incomplete routing information Traffic droped because of oversubscription of input queue © Traffic droped because of oversubscription of output queue Answer: Asymmetric routinng with unicast RPF 477 _© 2014Ccie Perfect Solutions