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:
set interfaces ge-0/0/3 disable
/* Wait 30 seconds */
delete interfaces ge-0/0/3 disable
/* 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:
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.
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)
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 firstname.lastname@example.org.
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.
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