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 220.127.116.11/16, the network used in the scenario. Since all IGP subnets fell into 18.104.22.168/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 22.214.171.124/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
Current configuration : 122 bytes
dampening 30 100 200 200
ip address 126.96.36.199 255.255.255.0
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.
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 188.8.131.52 remote-as 200
neighbor 184.108.40.206 route-map SET-COMM out
neighbor 220.127.116.11 send-community
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 18.104.22.168 remote-as 100
neighbor 22.214.171.124 route-map SET-PREF in
- 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
Current configuration : 275 bytes
ip address 126.96.36.199 255.255.255.0
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
188.8.131.52 IRDP 8 200 FastEthernet2/0
Default gateway is 184.108.40.206
Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty