Junos Cup 2014
Highlighted
Junos Cup 2014

Tournament 3: Colombia Challenge & Solution: OSPF Topology Convergence

[ Edited ]
‎06-26-2014 07:21 AM

Country Flag: Colombia

 

Author: Antonio Sánchez-Monge

 

Title: OSPF Topology Convergence

 

Type: Enterprise

 

Difficulty: High (2 points).

 

Technical Description: With just one configuration command, prevent the R1-to-R5 flow from being affected by the Time to Live (TTL) exceed condition right after R3 ge-0/0/3 link flaps.

 

Topology:

 

Columbia-Topology

 

Challenge Instructions:

For this challenge you need to start the topology called: “COLOMBIA – OSPF Topology Convergence”.

 

When you try to solve this challenge leave a ping command running all the time from R1 to R5:

 

juniper@R1> ping 10.100.5.5 source 10.100.1.1 rapid count 1000000000

PING 10.100.5.5 (10.100.5.5): 56 data bytes

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![...]

 

In this scenario, every link is in OSPF area 0. The SPF delay timer is artificially increased in some of the routers. This is done with the intention of making the topology instabilities last longer, so the effects can be noticed over a simple ping stream.

 

You can trigger the topology changes by executing the following sequence at R3:

 

configure

set interfaces ge-0/0/3 disable

commit

/* Wait 30 seconds */

delete interfaces ge-0/0/3 disable

commit and-quit

/* Wait until "show ospf neighbor" displays 3 Full adjacencies */

 

 

Yes, it is expected to have packet loss when the link goes down, especially with virtual bridges interconnecting the routers, not to mention the tuned SPF delay timers. However, there is a transient condition that one shouldn’t want to have. As you can see in the output of the ping command, and by executing at some router(s):

 

juniper@R#> show pfe statistics ip icmp | match "ttl expired"

 

There are packets with TTL expired during the topology convergence. This is a bad indication, especially for such a simple network!

 

In order to solve this challenge, find a way to fix that behavior with just one configuration command at one particular router:

 

configure

<set command>

commit and-quit

 

Keep in mind the following conditions:

- You should explain the answer in detail (it must follow best practice logic).

- You are not allowed to change the SPF settings in any of the routers.

- You are not allowed to introduce any other protocol or address family.

- Do not delete, deactivate, or disable any part of the configuration, except of course to temporarily test the link flap.

- When all links are up, the flow must go through R3 ge-0/0/3.

 

Strictly speaking, the best practice would only be complete if you apply the same command on a specific additional router. But for the purpose of this challenge, one command on one single router meets the requirements.

 

To solve this challenge submit the one set command and the router it is issued on. Please submit the logic of your submission explained in a few sentences or paragraphs.

 

NOTE: If you have issues connecting to the Junosphere topology please check Junosphere Technical documentation, or request assistance in the Junosphere forum 

Send an email with your proposed solution to junos-cup@juniper.net:

  •  The subject should be “<country-name-of-the-challenge> -  <your-full-name>”. For example: “Brazil – Wolfgang Amadeus Mozart”.
  • In the email body, please include your proposed solution, along with your first and last name and complete mailing address including zip/postal code and your shirt size (S, M, L, XL, XXL, XXXL) (Only if you haven’t already submitted your address/shirt size on a previous submission)

 

Deadline to Respond: Tuesday, 1st of July 23:59:59 Pacific Daylight Time (PDT) 

Timezone Converter
Current PDT Time


Some additional notes:

  • You can try to solve and submit answers for as many active challenges as you wish
  • The answers will be read by the organization right after the deadline
  • The challenge instructions are final, and no additional information or tips will be provided before the publication of the solution and the winner list. Please don’t expect a reply from junos-cup@juniper.net.
  • If you feel that your initial solution is wrong or incomplete, you can send up to three messages for the same challenge, but please note that only your last message (received before the deadline) will be read.
  • If you think there is an error in the definition of the challenges, please send us an email with subject (“<country-name> ERROR”); if there is no reply, then it’s likely an intentional condition of the challenge, rather than an error.

 

OFFICIAL SOLUTIONS:

 

When the link ge-0/0/3 fails at R3, the packet bounces between R3 and R4 until the IPv4 Time to Live (TTL) expires. In order to avoid that, you can configure at R4:

 

juniper@R4# set protocols ospf area 0 interface ge-0/0/2.0 metric 10

 

And, for completeness, you can do the same on R3.

 

What’s the logic behind that? In general, link flaps may result into short forwarding plane loops (often called microloops) during the time that it takes for the IGP to converge.

 

This is something that you cannot completely avoid in a network. For example, with the metric change above, R3-R5 link failure does not longer trigger a microloop at R3-R4 link for traffic going from R1 to R5. But it would result in a microloop at R5-R6 link for traffic going from R2 to R3.

 

So the choice of a good solution from a global perspective is not straightforward.

 

Several contestants came up with a better solution, at R3:

juniper@R3# set interfaces ge-0/0/2.0 family inet rpf-check         

Julie Wider
Advocacy Manager
Twitter: @JNetCommunity & @jawider