May
10

Edit: Thanks for playing! You can find the official answer and explanation here.

I had an interesting question come across my desk today which involved a very common area of confusion in OSPF routing logic, and now I'm posing this question to you as a challenge!

The first person to answer correctly will get free attendance to our upcoming CCIE Routing & Switching Lab Cram Session, which runs the week of June 1st 2015, as well as a free copy of the class in download format after it is complete.  The question is as follows:

Given the below topology, where R4 mutually redistributes between EIGRP and OSPF, which path(s) will R1 choose to reach the network 5.5.5.5/32, and why?

Bonus Questions:

  • What will R2's path selection to 5.5.5.5/32 be, and why?
  • What will R3's path selection to 5.5.5.5/32 be, and why?
  • Assume R3's link to R1 is lost.  Does this affect R1's path selection to 5.5.5.5/32? If so, how?

Tomorrow I'll be post topology and config files for CSR1000v, VIRL, GNS3, etc. so you can try this out yourself, but first answer the question without seeing the result and see if your expected result matches the actual result!

 

Good luck everyone!

Jan
11

UPDATE: I have received numerous submissions and currently in the process of reviewing them. I'm going to extend the deadline until Wednesday (2012-01-18). At that time all people who submitted working solutions will be awarded 100 tokens!

Recently I have been working with a large enterprise customer that is looking to implement a new change control policy. The main goal of the policy is to be able to track who is making changes to devices in the network, and specifically what those changes are. As opposed to using a full blown network management suite to do this for them, I suggested a simple solution of using TACACS for exec and command accounting (all devices are Cisco), and EEM scripting along with a TFTP server for tracking the actual configuration changes in case they need to roll back to a well-known good working config. The final result worked out very well, and I thought it would make a good CCIE level challenge as well.

So here is the challenge - write an EEM script to manage change control in the network as follows. The first person to submit a working script will win 100 rack rental tokens valid for any rack rental or mock lab session.

Every time a user makes a change to the configuration, the router should automatically TFTP its running configuration to the TFTP server 10.0.0.1 using the following naming convention:

HOSTNAME.YYYY-MM-DD.HHhMMmSSs.ADMIN_NAME.working.cfg

This ensures that if a change is made to the network but not actually saved to NVRAM, and there is a device crash, you can recover the last working running config of the device. Also this naming format tells you when exactly the change was made and by who. Remember that the router always generates a %SYS-5-CONFIG log message when a change is made. So for example suppose the following change was made:

EDGE-ROUTER-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
EDGE-ROUTER-1(config)#int lo1234
EDGE-ROUTER-1(config-if)#shutdown
EDGE-ROUTER-1(config-if)#
*Jan 11 19:05:49.694: %LINK-5-CHANGED: Interface Loopback1234, changed state to administratively down
*Jan 11 19:05:50.694: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1234, changed state to down
EDGE-ROUTER-1(config-if)#end
EDGE-ROUTER-1#
*Jan 11 19:05:59.054: %SYS-5-CONFIG_I: Configured from console by bmcgahan on console

The router would then TFTP its running config to 10.0.0.1 using the filename EDGE-ROUTER-1.2011-01-11.19h05m59s.bmcgahan.working.cfg

Secondly, the script should also make backups of configs that are actually saved to NVRAM. Similar to the previous requirement, files should be backed up to TFTP using the naming convention HOSTNAME.YYYY-MM-DD.HHhMMmSSs.ADMIN_NAME.startup.cfg. However in this case you need to account for the fact that different admins use different syntax when saving configs. Some of them use "write memory" or shorter variations like "wr m" or just "wr", while others use the "copy run start" variations. However regardless which variation is used, the router spits out the same output afterwards as follows:

EDGE-ROUTER-1#wr
Building configuration...

[OK]
EDGE-ROUTER-1#copy run start
Destination filename [startup-config]?
Building configuration...

[OK]

Lastly make sure that the script doesn't mistake a "show run" output for the same as a "write memory", as the outputs are similar:

EDGE-ROUTER-1#sh run
Building configuration...

Current configuration : 3438 bytes
!
! Last configuration change at 19:05:59 UTC Wed Jan 11 2012 by bmcgahan
version 15.1

Submit your script as a comment and the first one with fully functional requirements wins 100 tokens!

May
14

Hi Everyone!

The Challenge
People tend to underestimate the important of IGP routing features in modern network. So here is a small challenge scenario for you to practice OSPF traffic engineering. Take a look at the diagram below for information on the topology and link bandwidth. You may assume that every router has a loopback interface for network testing and OSPF router-id selection.

ospf-traffic-engineering

There is a large cloud of media servers behind R4, and the users behind R1 need to use full 300Mbps of bandwidth when downloading files off the servers. The network is running single-area OSPF for IP routing. Ensure you can accomplish the above goal without using MPLS Traffic Engineering or Policy Based Routing. You are allowed to create additional logical interfaces, but the routing protocol, OSPF areas, physical links and their characteristics should remain unchanged. Keep the amount of changes to minimum and do not introduce new IP addresses.

The first person to provide a working solution will receive 100 rack rental tokens from our partner company GradedLabs. Please use your valid e-mail address when posting a comment, so we can locate your INE account.

UPD
OK I forgot to rule out the "route-via" option :) Try solving the task without relying on any "policy-based" routing decisions.

The winner is: Antonie Henning (http://21500.net). Ivan Pepelnjak helped finding a logical "loophole" in my scenario by pointing to the "route-via" option available with GRE tunnels and correctly stating there should be 6 end-to-end tunnels to implement proper load-balancing. Hans Verkerk was close in his idea, but used static routing which was slightly against the rules and not as elegant as Antonie's solution. Chris Stos-Gale and Nitzan Tzelniker came with the correct solution as well, but Antonie completed the challenge ahead of them. Thanks to everyone for participating in the challenge, it's been fun!

The Solution:

The problem is that there are three paths with varying minimum bandwidth values (50, 100 and 150, totaling to 300Mbps). Since OSPF does not support unequal-cost load-balancing, it is somewhat challenging to fully use the available bandwidth. There was a lot of ideas posted in the comments, and they mainly fall in three main categories:

1) Modify OSPF costs to create three equal cost paths from R4 to R1. This will result in slow (50Mbps) link oversaturation. Another variation was using three tunnel interfaces between R1/R4 with the same ECMP logic. This results in the same problem.
2) Create six tunnels between R4 and R1 and configure the network so that 3 tunnels go across the fastest path, 2 tunnels take the medium path and one tunnel take the slowest path. This is somewhat similar to MPLS TE. To steer the tunnels you may use either static routes or the "route-via" option (Thanks to Ivan Pepelnjak to pointing me that!!). This solution would work, but violate the "updated" requirement not to use any "policy-based" routing decision, relying purely on OSPF path selection.
3) The solution that I had on mind was splitting the links connecting R4 to it's neighbors into "sub-channels" proportional to the bandwidth assigned to a given path:

ospf-traffic-engineering-solution

The link labels represent OSPF costs. You only need to split the links at R4, as this is the "source" of the traffic flows. Link splitting could be done in two ways: using logical virtual circuits (e.g. FR PVCs or Ethernet VLANs/VCs) or by using IP tunnels. You will only need to run the IP tunnels between R4 and the directly attached routers, disabling OSPF on the physical link and enabling it on the tunnels. Sample output at R4 for R1's prefix:

R4#show ip route 10.0.1.1
Routing entry for 10.0.1.1/32
Known via "ospf 1", distance 110, metric 4, type intra area
Last update from 10.0.3.3 on Tunnel341, 00:46:50 ago
Routing Descriptor Blocks:
* 10.0.45.5, from 10.0.1.1, 00:46:50 ago, via Serial0/0/0.45
Route metric is 4, traffic share count is 1
10.0.3.3, from 10.0.1.1, 00:46:50 ago, via Tunnel340
Route metric is 4, traffic share count is 1
10.0.3.3, from 10.0.1.1, 00:46:50 ago, via Tunnel341
Route metric is 4, traffic share count is 1
10.0.1.1, from 10.0.1.1, 00:46:50 ago, via Tunnel142
Route metric is 4, traffic share count is 1
10.0.1.1, from 10.0.1.1, 00:46:50 ago, via Tunnel140
Route metric is 4, traffic share count is 1
10.0.1.1, from 10.0.1.1, 00:46:50 ago, via Tunnel141
Route metric is 4, traffic share count is 1

Summary

I would like to thank everyone who participated in the "challenge", I read all your responses but had to stop commenting when I found the right solution. I hope you enjoyed that little scenario as much as I did. Personally, I have some incline toward the "traditional" traffic engineering solutions based on pure IGP metric manipulation. Even though the solution presented does not scale in the real world, where you may resort to a different option (e.g. end-to-end route-via tunnels), it perfectly illustrates the little hacks you can do to a link-state IGP to break the default "ECMP paradigm".

Sep
17

This is the follow up discussion for the post titled, "Have you seen my Router ID?"

The underlying issue here was trying to get OSPF to bypass the usual selection process for Router ID. The normal selection order is:

Manual router ID configured under ospf process
Highest IP address of a loopback in the up state in the respective routing table
Highest IP address of an interface of an up state in the respective routing table

If there are no up interfaces and you have not manually configured a router ID, you will get an error when you try to configure an OSPF process.

In general, most solutions focused around either using the OSPF selection process to one's advantage, or trying to "hide" the loopback from OSPF, so that it would select something else.


Some solutions were flat out wrong, because they broke the section requirements (mostly either configuring a router-id, or shutting down a loopback interface. Be sure to read the lab requirements carefully.

Solutions that didn't work (at least on the versions that I tested)

Backup interface
The idea being that the interface is down, and will not be assigned out as a router ID. This worked fine initially, but the router grabbed the (wrong) address after a reload, violating the requirement of functionality after the reload.

Interface Dampening with a restart penalty
The idea here was presumably that the interface would start off dampened, and not be selected as the router ID. After a reload, the interface did indeed show as dampened, but the interface was still up, and was chosen as the router ID.

Solutions that worked:

Easiest / most common answer:

Two OSPF routing processes

If there are two processes configured on the router, the highest loopback will be assigned to the first one CONFIGURED, and the second highest loopback will be assigned to the second process. The first process doesn't have to have any networks assigned, nor does it need to have a process number numerically smaller than the second process.

More complex:

One or more VRFs, possibly with secondary addresses.

Instructor Favorite (of the proposed solutions):

Kron scheduling to kick off a EEM applet when the router reloads to "no shut" the loopback interface. Since the loopback starts off shutdown, the OSPF process doesn't use it, and grabs the other one. The EEM applet runs, enabling the loopback, allowing the networks to be advertised properly to the neighbor. Although this configuration did include the loopback being shutdown, it was only shutdown for a brief period of time while the device was loading.

(Note: Scott Morris laughed out loud when informed of this one.)

Sep
16

There is more than one possible solution for this challenge. Feel free to post your proposed answer in the comments section. We will try to keep comments hidden from public view, so that the fun isn't spoiled for others. Also, don't feel bad if the answer(s) aren't immediately apparent. A number of very bright people have been puzzled by this scenario.  Answers will be posted on Friday, September 18th.

Scenario:

R1 and R2 are configured with their FastEthernet interfaces on the same subnet. R1 will be forming an OSPF neighbor adjacency to R2 over the FastEthernet interface, and will also be advertising some loopback networks into OSPF.

R1R2

R1's Relevant Configuration:

interface Loopback1
 ip address 1.1.1.1 255.255.255.255

interface Loopback11
 ip address 11.11.11.11 255.255.255.255

interface Loopback111
 ip address 111.111.111.111 255.255.255.255

interface FastEthernet0/0
 ip address 150.10.12.1 255.255.255.0
 no shut

R2's Relevant Configuration:

interface FastEthernet0/0
 ip address 150.10.12.2 255.255.255.0
 no shut

router ospf 1
 network 150.10.12.0 0.0.0.255 area 0

Challenge:

Your task is to configure R1 while meeting all of the following criteria for requirements and restrictions:

  • R2 should see the networks 1.1.1.1/32, 11.11.11.11/32, and 111.111.111.111/32 as OSPF routes in R2's routing table, but they should not appear as IA, E2, or E1.
  • The output of "show ip ospf neighbor" on R2 should show 11.11.11.11 as the Neighbor ID for the adjacency to R1, even if R1 is reloaded.  No other Neighbor IDs should show up on R2.
  • You are not allowed to use the "router-id" command on R1.
  • You are not permitted to shut down any interfaces on R1, or remove any of the existing configuration on R1.
  • No additional configuration may be added to R2, all configuration for this challenge is done on R1.
Aug
07

For the sake of simplicity and enabling a wider audience we decided to post our regular CCIE brainteasers to the blog.  The winner will get a coupon worth 10% off the price of any of our training packages for R&S, Security, Voice or Service Provider or a $250 Amazon.com gift card! Note that the 10% off discount can not be used with any other discount code you may already have. Please post your solution under the comments for this blog entry - the first person to post the correct solution is the winner. Make sure you provide the correct email address in your response so we can contact you in the event you won.  On Tuesday (August 12th) we will post the solution and announce the winner.

For today the task is an easy one or at least appears to be ;-) Imagine a simple topology made of 3 switches:

STP topology

All switches are running STP for VLAN123 with SW3 being the root.  Your task is to configure the network in such a way so that SW1 port fa0/13 is the root port and SW1 port fa0/16 is the alternate port for VLAN 123.  Sound easy?  Here are the requirements:

1) Do not change any STP link cost

2) SW3 must remain the root for VLAN 123

3) The port types must be access

4) Do not use the switchport backup interface command

5) Do not try to use SPAN or RSPAN

6) Do not disable STP

Good luck!

The correct solution is:

1) Configure SW2 to tunnel STP BPDUs between SW1 and SW3. This will make SW1 thinking that that SW3 is directly connected with cost 19. STP is still active on SW2, but SW2 considers itself the root.

SW2:
interface FastEthernet 0/13
l2protocol-tunnel stp
!
interface FastEthernet 0/16
l2protocol-tunnel stp

2) Configure SW3 port Fa0/16 with lower STP priority than SW3 Fa 0/13. This will make SW1 select its connection to SW2 as the root port and the other uplink is alternate: both uplinks have equal costs, the upstream port priority is the tiebreaker.

SW3:
interface FastEthernet 0/16
spanning-tree port-priority 64

Below is a summarization of some of the close but not quite correct approaches people submitted:

1) Change interface bandwidth/speeds. This is not allowed, since the requirement was not to change spanning-tree costs.

2) Use dot1q tunnel on SW2 – this was prohibited by requirement to set port modes to access

3) Filter spanning-tree BPDUs coming to SW1 from SW3. This would break the requirement for Fa 0/16 port to be alternate path to root. Aside from that, that would result in STP loop, since this is a circular topology.

4) Disabling STP in SW2 explicitly which is prohibited by the requirements

5) Incorrectly assuming that port-priority on SW1 may influence root port selection

6) One complicated MSTP solution submitted by two people actually works but was submitted after the above solution was posted.  The solution is based on differentiation between regional root and CIST root.  Not the simplest solution but it works.  The two people that posted this solution also deserve credit for their MSTP knowledge.  We'll do a post on MSTP inter-region operations here on the blog in the next few days.

The winner is: "Roman”
 roman.aprias@[snip].com

Subscribe to INE Blog Updates