Path MTU discovery & OSPF

This lab provides the scenario to practice OSPF troubleshooting skills.

Configuration

1. Setup basic addressing in the scheme: physical interfaces, loopbacks.
2. Enable OSPF on every link, except for R5 links.
3. Configure IPsec tunnel between R2 and R3.
4. Reduce MTU between R2 and R5 to 1400 bytes.
5. Enable path MTU discovery (PMTUD) on the tunnel interface.
6. Make sure R4 is able to reach the loopback on R1.

Task

1. Review PMTUD process over IPsec tunnel.
2. Trigger PMTUD from R4:

R4#ping 1.1.1.1 so loopback 0 df-bit size 1400
Type escape sequence to abort.
Sending 5, 1400-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4 
Packet sent with the DF bit set
..MMM

3. Clear OSPF process on R3.

Observations

Verify the reachability between R1 and R4. What is wrong?

Solution

Note the current state of OSPF neighbourship:

R3#show ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   EXSTART/  -     00:00:37    192.168.32.2    Tunnel0
4.4.4.4           1   FULL/DR         00:00:38    192.168.34.4    FastEthernet0/0

EXSTART state is a good indicator of MTU mismatch:

R3#deb ip ospf adj 
OSPF adjacency debugging is on
*Oct  1 18:47:46.863: OSPF-1 ADJ   Tu0: Send DBD to 2.2.2.2 seq 0xF1E opt 0x52 flag 0x7 len 32
*Oct  1 18:47:46.863: OSPF-1 ADJ   Tu0: Retransmitting DBD to 2.2.2.2 [2]
*Oct  1 18:47:47.403: OSPF-1 ADJ   Tu0: Rcv DBD from 2.2.2.2 seq 0x1074 opt 0x52 flag 0x7 len 32  mtu 1318 state EXSTART
*Oct  1 18:47:47.403: OSPF-1 ADJ   Tu0: Nbr 2.2.2.2 has smaller interface MTU
*Oct  1 18:47:47.403: OSPF-1 ADJ   Tu0: First DBD and we are not SLAVE

Remember that PMTUD is a unidirectional feature. R3 has already decreased its MTU, while R2 didn’t have a chance to do so. If a packet exceeds the available MTU, PMTUD should later update the value, so it’s relatively safe to ignore MTU mismatch:

R2(config)#interface Tunnel 0
R2(config-if)#ip ospf mtu-ignore 

R3(config)#interface Tunnel 0
R3(config-if)#ip ospf mtu-ignore 

Images

IOS image: c7200-adventerprisek9-mz.152-4.M11.image

Follow on Telegram, LinkedIn, Twitter

Zone-based firewall & traceroute

This lab points out one of important aspects of Cisco IOS traceroute utility in conjunction with ZBF.

Configuration

1. Setup basic addressing in the scheme.
2. DMZ and Client should use static routing to reach each other.
3. Make sure Client can reach DMZ by using ping and traceroute.

Task

1. Configure ZBF zone and zone-pair from INSIDE to OUTSIDE.
2. Permit ping (ICMP) and traceroute (UDP) traffic in ZBF, using stateful firewall (inspect).
3. Start Wireshark capture between DMZ and ZBF.
4. Make sure ping is successful between Client and DMZ.
5. Check out the sessions created by ZBF.
6. Verify that traceroute from Client to DMZ fails.

Observations

Why UDP-based traceroute is not successfully completed?

Solution

Cisco IOS uses ICMP for ping and UDP for traceroute. Although UDP is indeed permitted by ZBF, the return traffic is still ICMP that is dropped by default.

ZBF#show policy-map type inspect zone-pair INSIDE-OUTSIDE sessions 

policy exists on zp INSIDE-OUTSIDE
  Zone-pair: INSIDE-OUTSIDE 

  Service-policy inspect : PMAP

    Class-map: ICMP (match-all)  
      Match: protocol icmp

   Inspect

    Class-map: UDP (match-all)  
      Match: protocol udp

   Inspect

      Number of Half-open Sessions = 8
      Half-open Sessions
        Session 699E2FE0 (192.168.23.3:49284)=>(192.168.12.1:33437) udp SIS_OPENING
          Created 00:00:26, Last heard 00:00:26
          Bytes sent (initiator:responder) [0:0]
        Session 699E3360 (192.168.23.3:49285)=>(192.168.12.1:33438) udp SIS_OPENING
          Created 00:00:26, Last heard 00:00:26
          Bytes sent (initiator:responder) [0:0]
        Session 699E36E0 (192.168.23.3:49286)=>(192.168.12.1:33439) udp SIS_OPENING
          Created 00:00:26, Last heard 00:00:26
          Bytes sent (initiator:responder) [0:0]
        Session 699E3A60 (192.168.23.3:49291)=>(192.168.12.1:33437) udp SIS_OPENING
          Created 00:00:19, Last heard 00:00:19
          Bytes sent (initiator:responder) [0:0]
        Session 699E3DE0 (192.168.23.3:49292)=>(192.168.12.1:33438) udp SIS_OPENING
          Created 00:00:19, Last heard 00:00:19
          Bytes sent (initiator:responder) [0:0]
        Session 699E4160 (192.168.23.3:49293)=>(192.168.12.1:33439) udp SIS_OPENING
          Created 00:00:19, Last heard 00:00:19
          Bytes sent (initiator:responder) [0:0]
        Session 699E44E0 (192.168.23.3:49298)=>(192.168.12.1:33437) udp SIS_OPENING
          Created 00:00:04, Last heard 00:00:04
          Bytes sent (initiator:responder) [0:0]
        Session 699E4860 (192.168.23.3:49299)=>(192.168.12.1:33438) udp SIS_OPENING
          Created 00:00:01, Last heard 00:00:01
          Bytes sent (initiator:responder) [0:0]


    Class-map: class-default (match-any)  
      Match: any 
      Drop
        61 packets, 488 bytes

Solution: create a reverse zone that permits ICMP traffic:

ZBF#show running-config | section class-map|policy-map|zone-pair
class-map type inspect match-all ICMP
 match protocol icmp
class-map type inspect match-all UDP
 match protocol udp
policy-map type inspect PMAP-RETURN
 class type inspect ICMP
  pass
 class class-default
  drop
policy-map type inspect PMAP
 class type inspect ICMP
  inspect 
 class type inspect UDP
  inspect 
 class class-default
  drop
zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE
 service-policy type inspect PMAP
zone-pair security OUTSIDE-INSIDE source OUTSIDE destination INSIDE
 service-policy type inspect PMAP-RETURN

P.S. Try starting traceroute right after ping is finished 🙂

Images

IOS image: c7200-adventerprisek9-mz.152-4.M11.image

Follow on Telegram, LinkedIn, Twitter

EIGRP summary & BGP default route

This lab intends to highlight one of the potential pitfalls of EIGRP summarization.

Configuration

1. Setup the addressing: each router has at least one loopback for connectivity verification.
2. Enable eBGP between ISP and Hub.
3. Enable EIGRP between Hub and Spoke.

Task

1. ISP should announce only default route via eBGP.
2. Hub should announce both loopbacks into BGP: Hub loopback and Spoke loopback.
3. Spoke should not announce any routes, except for directly connected prefixes.
4. Make sure Spoke receives only a single route from Hub.

Observations

Test connectivity between ISP and Spoke. What is wrong with the path? Find the problem and fix it.

Solution

Note that pings fail on Hub. The reason – EIGRP summary has AD = 5 by default, so BGP default route does not get to be installed.

Hub#show ip route 0.0.0.0  
Routing entry for 0.0.0.0/0, supernet
  Known via "eigrp 1", distance 5, metric 28160, candidate default path, type internal
  Redistributing via eigrp 1
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 28160, traffic share count is 1
      Total delay is 100 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 0

Solution is simple – decrease AD, that is assigned to summary route:

Hub(config)#router eigrp 1
Hub(config-router)#summary-metric 0.0.0.0/0 distance 250

Images

IOS image: c7200-adventerprisek9-mz.152-4.M11.image

Follow on Telegram, LinkedIn, Twitter

DHCPv6 Prefix Delegation

This lab is dedicated to the feature of DHCPv6 – Prefix Delegation (DHCP PD). This technique allows service provider to hand out an aggregated prefix to the client who assigns subsequently self-defined subnets to the interfaces. Such an approach offers the following benefits:

• Less state information on ISP it is possible to store aggregated bindings (subnets) instead of individual ones;
• Automated public address assignment for clients.

Configuration

ISP:
1) Enable IPv6 unicast routing.
2) Configure local IPv6 prefix pool.
3) Create DHCPv6 pool and configure it for DHCP PD. Reference previously defined pool of prefixes.
4) Configure ISP to act as DHCPv6 server for CE.

CE:
1) Enable IPv6 unicast routing.
2) Receive address on FastEthernet0/0 via SLAAC.
3) Enable CE to act as DHCP PD client on FastEthernet0/0.
4) Assign addresses on ports facing clients from the received pool (general prefix).

Clients:
1) Receive address via SLAAC.

Tasks

1) Create a loopback on ISP. Try to ping it from clients. Identify the problem.
2) Fix the unreachability issue. No static routing or dynamic routing protocols are allowed.
3*) DHCP PD does not support deeper hierarchy. Suggest a solution when Client1 and Client2 are able to request prefixes on their own from ISP without knowing its address.

Observations

1) Take a look at RIB on ISP. DHCP PD server inserts a static route into its RIB for the prefix it handed out. This allows the operator to route downstream traffic to the correct CE dynamically without the need for IGP.
2) Take a look at RIB on CE. The purpose of the same entry pointing to Null0 is preventing routing loop. Let’s suppose ISP has provided 2001:db8::/48 prefix; CE assigned 2001:db8:0:1::/64 and 2001:db8:0:2::/64 only. If there is a packet for 2001:db8:0:3::1/64, the following would happen if not for Null0:

• ISP forwards packet according to static entry in RIB;
• CE matches the packet against default route towards ISP – routing loop!

The static entry in CE RIB allows dropping such packets. It is the only one responsible for such a prefix (ISP delegated it). So if CE does not know anything about more specific (= assigned) entries,
then there are none existing.

IOS image used: c7200-adventerprisek9-mz.152-4.M11.image

Resources

http://foxnetlab.com/index.php/9-articles/132-ipv6-in-cisco-or-the-future-is-about-to-come

https://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html

Follow on Telegram, LinkedIn, Twitter

HSRP Redirect

This lab exhibits the optimization behaviour of Hot Standby Router Protocol (HSRP) based on using ICMP redirects in case a more optimal path exists.

Configuration

1) Disable IP routing on R4. Implement addressing according to the scheme.
2) Enable an IGP on R1-R3, all interfaces included.
3) Create an HSRP1 group on R1 and R2. Make sure R1 is always Active.

Tasks

1) Enable ICMP debugging on R1. Run traceroute for the addresses several times. Which addresses are being redirected? What address are they redirected to?
2) Create HSRP2 group on R1 and R2, make sure R2 is always Active.
3) Run traceroute for 2.2.2.2 several times. Look at the debug output on R1 one more time. Where are packets redirected this time?

Observations

HSRP routers send redirects only to valid gateways or, in other words, to either HSRP Active routers or non-HSRP next-hops. Standby routers are not redirected to as they are intended to be fallback, not active forwarders. Of course, if mHSRP is implemented, Active in other group is a totally valid gateway. That is why ICMP Redirect is sent for 3.3.3.3/32 immediately (R3 does not run HSRP, it is just a next hop for the prefix) and Redirects for 2.2.2.2/32 require mHSRP in place.

IOS image used: c7200-adventerprisek9-mz.152-4.M11.image

Resources

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-mt/fhp-15-mt-book/fhp-hsrp-icmp.html

http://www.cathayschool.com/redirecting-icmp-with-hsrp-a149.html

Follow on Telegram, LinkedIn, Twitter

EIGRP RID

This lab shows network discrepancies in EIGRP domain caused by duplicate Router IDs.

Configuration (Part 1)

1) Redistribute loopbacks on R1 and R2 into EIGRP.
2) Shutdown any loopback.

Task (Part 1)

1) Identify the discrepancy in the network.
2) Find out the process of RID election.
3) Suggest the solution to the problem.

Observations (Part 1)

On redistribution EIGRP adds router ID to the external prefixes. Routers ignore updates with own RID in order to avoid routing loops. Although no log messages are issued, there is an entry in EIGRP events: “Ignored route, dup routerid ext: 8.8.8.8“

Configuration (Part 2)

1) Enable the shutdown loopback interface.
2) Instead of redistributing the loopbacks, add them to EIGRP domain as internal ones.
3) Shutdown any loopback once again.

Task (Part 2)

1) Identify the discrepancy.
2) Fix the problem.

Observations (Part 2)

Starting from IOS 15 train, EIGRP adds RID to the internal prefixes too so the behaviour is similar to the one with external routes. Older IOS versions, however, accept such updates as there is no RID present so it is not checked. The EIGRP event message is only slightly different: “Ignored route, dup routerid int: 8.8.8.8“

IOS image used: c7200-adventerprisek9-mz.152-4.M11.image

Resources

https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/18685-eigrp-dup-id.html

https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/118974-technote-eigrp-00.html#anc28

Follow on Telegram, LinkedIn, Twitter

OSPF RID

This lab shows network discrepancies in OSPF domain caused by duplicate Router IDs.

Configuration (Part 1)

Enable OSPF on R1 and R3 putting all the interfaces into area 0.

Task (Part 1)

1) Identify the discrepancy in the network. (Hint: look at R2 OSPF statistics)
2) Find out the process of RID election.
3) Identify OSPF LSA that are causing SPF recalculation.
4) Fix the problem (e.g. configuration change on R1)

Observations (Part 1)

Duplicate OSPF RID result in continuous SPF recalculations. R1 and R4 are receiving LSA1 and LSA2 supposedly issued by themselves. However, either the LSA age is different or the checksum. Anyway, R1 (or R4) issue a new LSA (flushing the received one) in order to “update” LSDB of other OSPF routers in the area. This process continues indefinitely as R1 and R4 continue to receive “outdated” LSA they are responsible for. After a while, IOS detects the problem and issues a report:

“%OSPF-4-DUP_RTRID_AREA: Detected router with duplicate router ID 8.8.8.8 in area 0”

Configuration (Part 2)

1) Enable OSPF on R3 and put the loopback address into the area 1. Make sure no problems arise.
2*) Explain why R2 chooses the path via R3 ignoring other 2 available routes.
3) Shutdown the loopback on R1. Redistribute loopbacks into OSPF on R3 and R4. Make sure no problems arise.
4) Add loopback on R3 with IP address 3.3.3.3/32 and redistribute it into OSPF.

Task (Part 2)

1) Identify the discrepancy. (Hint: look at R2 RIB)
2) Identify OSPF LSA that are causing SPF recalculation.
3) Fix the problem (e.g. configuration change on R3)

Observations (Part 2)

Inter-area prefixes are distributed via LSA3 that are the responsibility of an ABR. So neither R3 nor R4 take any action to flush out the LSA3. R2, however, sees no problem with different LSA1 or LSA2 from different area. That is why the topology is stable (compared to single area case).

After loopbacks are redistributed, corresponding LSA5 are created and sent to R2. As long as LSA5 are the same (checksum, LSID, sequence number) neither R3 nor R4 see any problem.

However, adding a loopback creates a new LSA5 which is valid only on one of the ASBRs, R3. R4 flushes this LSA5 as it considers it to be outdated, besides, R4 is “responsible” for the LSA as it carries its RID. Routers issue the following messages after a while:

R3# 
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID 3.3.3.3 type-5 adv-rtr 8.8.8.8 in area 1

R4#
%OSPF-4-FLOOD_WAR: Process 1 flushes LSA ID 3.3.3.3 type-5 adv-rtr 8.8.8.8 in area 0

As a result, LSA5 is being constantly flushed out causing flapping of the corresponding external prefix on other OSPF routers.

IOS image used: c7200-adventerprisek9-mz.152-4.M11.image

Resources

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/23862-duplicate-router-id-ospf.html

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/118880-technote-ospf-00.html#anc6

https://learningnetwork.cisco.com/thread/100302

Follow on Telegram, LinkedIn, Twitter