Ethan Banks On productivity.

NMC DOiT Vol.2 Scenario 17 – IP Event Dampening + BGP Communities + IRDP


First off, it’s Thanksgiving today here in the United States. So to all of you here in the States, Happy Thanksgiving! I hope you spend it with family and friends, and not with a Cisco book. I’m looking forward to my family being here in a few hours, and to having a nice meal and good conversation. Until then, I have little time to blog. ;)

I did DOiT scenario 17 yesterday. I owned this lab at first, setting a personal best time of 3 hours flat with completed IGP redistribution. That 3 hours included nearly an hour of reading the lab over and doing prep diagrams. After IGP redistribution, I started the BGP section, and had a meltdown of my own making. Part of the problem was my BGP diagram. I made the diagram at about 5am, having just rolled out of bed. The BGP featured both AS10 and AS100; AS10 was not allowed to have a full-mesh. My fuzzy 5am brain saw that AS100 was not allowed to have a full-mesh, not AS10. So my diagram for both AS10 and AS100 was wrong. Therefore, I built AS10 and AS100 wrong, which confused some things. Once I sorted that and some other problems out with the help of the answer key, I had reachability issues, which I hammered away for quite a while. Then I discovered that NMC themselves didn’t even test for reachability in the BGP domain. The BGP exercise was about filtering, communities and local preference…NOT reachability. The lab could have made that clearer. <sigh>

But enough about that! Let’s move on to the tech notes.

  • I have discovered that the correct answer to a given task depends an awful lot on the rest of the lab parameters. For example, when instructed to send the minimum amount of information into an OSPF area, you should be considering a stubby, total stubby, not-so-stubby, or totally no-so-stubby area. Which one is appropriate depends on whether or not a quad-zero route is allowed to appear in any routing tables and whether or not you will need to redistribute routes into this OSPF area.
  • I had a RIP task that instructed me to “send the minimum required information” from one RIP router R2 to R5. This scenario allowed quad-zero routes to appear in routing tables, just no static quad-zero routes. So I thought the minimum information would be quad-zero summary route on the R2 interface facing R5. The answer key didn’t see it that way. They said the minimum would be a summary route of, the network used in the scenario. Since all IGP subnets fell into somewhere, that summary would be the minimum. And now that I think about it, that does make sense. It’s just such a touchy-feely area. I could see it the other way, that a quad-zero route is technically less information…but in the sense that covers much less address space than a quad-zero route, I suppose it would be the “minimum”. I could argue it either way, I guess. I hope that’s the kind of thing that a proctor would help clarify. Hmm. “Sir, Mr. Cisco Proctor, sir? Sir, do you consider a quad-zero route to be more information or less information than a /16 summary route? Sir?”
  • IP event dampening is an IOS feature that takes a flapping interface out of play for a configurable amount of time to maintain routing table stability. I had never seen this command before, but I was able to read the task, find it on, and correctly configure it in 6 minutes. I’m not trying to brag, but make a point. The point is that familiarity with the Cisco doc CD could earn us easy points on the exam. This was one of those tasks – easy, but a little obscure.

    R4#show run interf fa0/0
    Building configuration…

    Current configuration : 122 bytes
    interface FastEthernet0/0
    dampening 30 100 200 200
    ip address
    duplex auto
    speed auto

    R4#show interf fa0/0 dampening
    Flaps Penalty Supp ReuseTm HalfL ReuseV SuppV MaxSTm MaxP Restart
    0 0 FALSE 0 30 100 200 200 10158 0


  • One of the BGP tasks was to set local preference so that one router would be the preferred AS exit for certain prefixes, and that a different router would be the preferred AS exit for others. The catch was that you could not set local pref based on AS path or prefix. My (incorrect) thought was to set a tags on the routes as they left one AS, and then set local pref based on the tag as the routes hit the other AS. I was on the right track, but sadly you can’t set a tag on a BGP route advertisement…I tried it. IOS mocked me, letting me know that the route-map was going to set a tag, and that tags weren’t supported on BGP advertisements, and so there. And to my surprise, the CLI stuck its tongue out at me. So what was the right answer? Communities. Include a community attribute on the route as it leaves one AS, and then set the local pref based on that community attribute as it enters the other AS. Now, there’s a couple of catches with communties, too. One is that you have to do a “neighbor send-community“, since community attributes are not sent to neighbors by default. The other is that in order to do a route-map “match” (and consequent “set”) based on community, you have to use an “ip community-list“. You can’t do a match based on the community value directly.
    In this example, R1 sets the community attribute based on AS path. R2 sets local preference based on the community attribute that is sent.

    conf t
    ip as-path access-list 2 permit .*_1581_1771$
    ip as-path access-list 2 permit ^1581_1771$
    ip as-path access-list 3 permit ^1581$
    ip as-path access-list 3 permit .*_1581$
    route-map SET-COMM permit 10
    match as-path 2
    set community 222
    route-map SET-COMM permit 20
    match as-path 3
    set community 333
    router bgp 100
    neighbor remote-as 200
    neighbor route-map SET-COMM out
    neighbor send-community
    wri mem

    conf t
    ip community-list 2 permit 222
    ip community-list 3 permit 333
    route-map SET-PREF permit 10
    match community 2
    set local-preference 30000
    route-map SET-PREF permit 20
    match community 3
    set local-preference 300
    router bgp 200
    neighbor remote-as 100
    neighbor route-map SET-PREF in
    wri mem

  • ICMP Router Discovery Protocol (IRDP) is an obscure (to me) little protocol that allows a client to dynamically discover gateways that are also advertising with IRDP. In this example, R3 has been configured as an IRDP gateway. FRS has been configured as an IRDP client. Check out these IOS commands before reviewing the code: “ip irdp” (used on the IRDP gateway router interfaces) and “ip gdp irdp” (used on an IOS router you wish to act as an IRDP client, note that you have to disable IP routing on a router you make an IRDP client).

    R3#show run interf fa0/0
    Building configuration…

    Current configuration : 275 bytes
    interface FastEthernet0/0
    ip address
    ip irdp
    ip irdp maxadvertinterval 10
    ip irdp minadvertinterval 7
    ip irdp holdtime 90
    ip irdp preference 200


    R3#show ip irdp Fa0/0
    FastEthernet0/0 has router discovery enabled

    Advertisements will occur between every 7 and 10 seconds.
    Advertisements are sent with broadcasts.
    Advertisements are valid for 90 seconds.
    Default preference will be 200.


    FRS#show run | i irdp|routing
    no ip routing
    ip gdp irdp
    FRS#show ip route
    Gateway Using Interval Priority Interface IRDP 8 200 FastEthernet2/0

    Default gateway is

    Host Gateway Last Use Total Uses Interface
    ICMP redirect cache is empty



  • I completed this lab today and this lab was quite hard for me in such points:

    1. IRDP – very big surprise. I still not sure who is wining default-gateway selection. Solution key says that router with lower preference win. Cisco Command Lookup Tool and IOS context help says that router with higher preference will win gateway election

    2. NAT. I use same static NAT configuration both on R3 and R6, but unfortunally I haven’t reachabilty from FRS to R3 if default-gateway for FRS is R6. Solution key recommends “no-alias” keyword, but on my rack it does not help

    3. BGP reachability: After configuring all BGP requirements I noticed that I have not IP reachability to BGP advertised network due to some BGP routing loops. To resolve this issue I add PVC between R1 and R2. But solution key didn’t do it. So I guess, that they haven’t all BGP addresses reachable.

    As I understood from 17 NMC labs, real lab will contain many hidden issues, which need clarification because almost every task has two or even more ways solution. I hope, that in my lab day proctor will have good mood :)

  • Hello All,
    I have some points I want to clarify with you guys.
    The NAT task says:
    All packets originating from FRS should have the source IP address changed at the first
    hop router. The source IP address must be in the range.

    Thats cool but the way I see the router FRS has its IP already in this range.
    I really do not understand which address needs to be changed

    Side note:
    One line is enough for there 2 statements:
    ip as-path access-list 2 permit .*_1581_1771$
    ip as-path access-list 2 permit ^1581_1771$

    which is
    ip as-path access-list 2 permit 1581_1771$

    Just remember it is just a string that gets matched at the end

By Ethan Banks
Ethan Banks On productivity.

You probably know Ethan Banks because he writes & podcasts about IT. For example, he co-authored "Computer Networks Problems & Solutions" with Russ White.

This site is Ethan on productivity--not tech so much.

Find out more on his about page.