From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

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

1,218 Words. Plan about 8 minute(s) to read this.

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 NetMasterClass.com 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 170.18.0.0/16, the network used in the scenario. Since all IGP subnets fell into 170.18.0.0/16 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 170.18.0.0/16 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 cisco.com/univercd, 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 170.18.64.4 255.255.255.0
    duplex auto
    speed auto
    end

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

    R4#

  • 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.

    R1
    !
    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 170.18.10.2 remote-as 200
    neighbor 170.18.10.2 route-map SET-COMM out
    neighbor 170.18.10.2 send-community
    exit
    !
    exit
    !
    wri mem

    R2
    !
    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 170.18.10.1 remote-as 100
    neighbor 170.18.10.1 route-map SET-PREF in
    exit
    !
    exit
    !
    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 170.18.255.3 255.255.255.0
    ip irdp
    ip irdp maxadvertinterval 10
    ip irdp minadvertinterval 7
    ip irdp holdtime 90
    ip irdp preference 200

    end

    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.

    R3#

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

    Default gateway is 170.18.255.3

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

    FRS#