Internetwork Expert Volume IV (Troubleshooting) Workbook Review: Part 1

As we’re all painfully aware, the next version (4.0) of the CCIE lab exam goes live this October.  For those of us who did not nab a date before the cutover date, we’re looking at a different beast come October.  In addition to a number of new technologies (such as MPLS and Zone Based Firewall) and the dread Core Knowledge questions, there will be a brand new addition: troubleshooting.  Between the Core Knowledge section and the actual lab exam, there will be a troubleshooting section.  While details are still a little vague, here’s what Cisco has said about this section(may require CCO login):

Troubleshooting is allotted two of the eight hours required for the CCIE lab exam. Candidates will be presented with a series of trouble tickets for preconfigured networks and will need to diagnose and resolve the fault or faults. As with previous CCIE labs, the network will need to be up and running for the candidate to receive credit.  Candidates who finish the troubleshooting section early can move on to the configuration section, but they will not be allowed to go back to the troubleshooting section.

Here are some additional details culled from a recent Ask The Expert Section:

• The Troubleshooting section will be independent from the Configuration section, i.e., it will be presented on a different scenario.
• Once you finish the Troubleshooting you will move to the Configuration section that will be presented on a new scenario or topology.
• The Troubleshooting section will have a maximum of 2 hours. The candidate will be presented a series of questions or ‘trouble tickets’ for a given scenario or topology. The referred topology will pre-configured.
• Based on the information provided such as IP addressing diagrams, IGP routing diagrams, and so on you will work to identify and fix the issues. You will be given points for working scenarios.
• The Troubleshooting section will have a certain number of trouble tickets and points allocated to the section. You will receive credits for the points you get. Your score on this section will show as, 30%, or 50%, or 80%, and so on.
• You will need to get a minimum of 80% on each section of the exam to pass on the CCIE lab exam.
• Yes, we are planning to post a sample Troubleshooting questions/trouble ticket for study reference.

Internetwork Expert has a poll up asking CCIE candidates which part of the new lab format scares them the most.  Troubleshooting is the number one choice.

I’ll admit that when I first heard about the addition of troubleshooting to the lab, I was unconcerned.  While I don’t spend any time(outside of practice labs) building complex OSPF networks, I do troubleshoot networks for probably a good 30% – 50% of each workday(not to mention after hours when on call).  Plus, I’ve always been pretty good at the initial troubleshooting sections in the vendor labs.

Petr Lapukhov from INE emailed me recently and gave me access to the first couple of labs in the new Internetwork Expert Volume IV workbook.  This is INE’s new product covering the troubleshooting section of the lab.  I agreed to try the first couple of labs and write my thoughts.  My first thought? I vastly underestimated how potentially difficult the new troubleshooting section could be!

While I have spent a considerable amount of time troubleshooting networks over the last ten (sigh) years, they’ve always been MY networks.  Well, at least they’ve always been networks with which I was very familiar.  So if a server goon bitches about not being able to ping his heart beat IP address, I can quickly re-educate (an exercise in futility) him about the fact that this network exists on a layer-2 only network that is not trunked nor associated with an SVI so he’ll only be able to ping other heart beat IPs sourced from the heart beat IP address on his box.  If I was not aware of the design of this network, then I would have to start with the usual battery of pings and traceroutes to (hopefully) get to the same conclusion.  In other words, familiarity with the network design will make troubleshooting much easier and quicker.  I also overlooked the fact that a good 90% of my daily troubleshooting is really mundane shit like checking speed/duplex, verifying MAC addresses, checking ARP tables, etc.  It’s thankfully very rare that I ever troubleshoot any complicated layer 3 issues.

So while I might feel (justified or not) that I have a lot of troubleshooting experience, a lot of that experience will be worthless in a lab scenerio…as I was soon to discover.  🙂

GroupStudy: Great CCIE Study Strategy

This recent posting to the GroupStudy mailing list contains a lot of great suggestions for CCIE candidates who are crafting/refining their study strategy:

1st) Do practice labs! It’s that easy, do as many as you can from a reputable vendor. I’m not here to prop one vendor over another…just find 1 (more if possible) that has a proven track record and do their labs. *The key is not so much the material but how you study it! Do the labs just like you’re are going to do the real lab! Meaning…in the real lab you don’t get to see the questions or the topology before hand, you don’t get to go to a proctor guide or google when you get stuck, you have 8 hours. So, when you have a lab manual, schedule your 8 to 10 hours, don’t look at any of the material before hand…then just sit there for 8 hours straight, beating your head against the wall, using only the doc cd. When you start, don’t touch a router until you have read through the whole lab, written down your “blue print” and point values and have a plan for the lab. Then go at it, if you get stuck or stumped, don’t look up the answer! Track your points and save your configs (maybe a show ip route or ip bgp or what ever is relevant as well) to your PC for grading yourself later.

When you have finished (either right after if you’re that impatient) or the next day go through the lab and grade it, be honest with yourself, and find out what you missed, then study it, learn it and understand it. (Those are your “off” days). Then, schedule your next Lab session and do it again!

At first you’ll get owned, feel like crap and wonder what in the hell you are doing. Probably will take you more than 10 hours to get through the labs, but do it all. After the first 5 to 10 you’ll get to where you can finish them in 8 hours, hopefully even sooner after 15 or 20 (the assumption is the labs get progressively harder but you are getting even faster). *part of completing a lab, is going back through the questions and verifying each task…without fail you will find at least one thing you did wrong or missed…that means you need to calculate that into your 8 hours. Get in the habit though

2nd) Once you have done 5 or 10 labs, if you are in a position, do a graded mock lab or… 7. See how you do. I wouldn’t worry so much about the score or “explanations” after the fact, but more of “did I come up with A solution for every section?” “Did I finish it in time?” “How was my time management?” “How well did I think on my feet?” (While I did not pass one of my mock labs, I always completed them, came up with solutions and learned how important it is to notice the little details) Use the mock labs to evaluate your testing strategy.

In all I did over 30 full labs (including my mock labs)…so sitting down for 8 hours in the real lab was nothing for me, I had been doing it 2 to 3 times a week for months. That kind of experience is crucial for success in the real lab. What’s more, I finish my lab (had a solution in place for each question) in 5 and a half hours and was able to spend the next 2 hours going back over each question. I easily earned between 15 to 25 points that way. Having that extra time allowed me to re-read scenarios, pick up on key-words, verify syntax et…You need to be able to get through the lab quickly…if you have done 20+ “labs” all ready, the real lab isn’t nearly as daunting in terms of time or manageability.

The point is this, you can’t do practice labs one way and think that you’ll do the real lab another. The real lab should be 2nd nature in terms of your initial read through and assessment, your time management and troubleshooting of individual scenarios, and your re-read and verification at the end.

I hope this has been helpful. Doing simple math 8 hours X 2 or 3 times a week = a lot of time and that doesn’t include the “off” days where you need to “grade” your self, study weak areas, practice configs, and browse the doc cd. It’s a huge investment of time, but if you’re going to do it, do it right and don’t “cheat” yourself.

Internetwork Expert: Volume II v5 Labs To Start Releasing This Week

Internetwork Expert’s December newsletter announces that their flagship workbook product is going to be updated:

Updated Routing & Switching Volume II Labs Start Releasing This Week

The newest updates to the Routing & Switching Volume II labs are being released in electronic format starting this week. The updates will automatically show up in your members site account as the labs are released.

The IE blog has a post up today with more detail:

This Friday the CCIE R&S Lab Meet-Up series kicks off with the new CCIE R&S Lab Workbook Volume 2 Version 5 Lab 1.  The new lab will be posted on the members site on Thursday, and the lab meet-up starts at 9am Pacific time.  The session should lab about 4 hours, depending on how many questions people have.  Essentially I will be configuring and explaining the lab live on the command line, and going through the logic of the solutions in detail.

It’s not too late to sign-up for the series, so contact our sales department if you have any questions.  I hope to see you there!

It looks like IE will be releasing the new labs one lab at a time with a Lab Meet-Up scheduled for each lab to discuss the lab/solutions.

CCBootcamp: Site Redesign and New Blog

CCBootcamp has been the most quiet of the “core four” CCIE training vendors.  I am on their mailing list and it appeared to me that they were moving more towards a CCNx-focus.  It looks like I was wrong.  They recently redesigned their website and launched a new blog.

The new website has an intriguing ad for “CC-TV Coming Soon”.  Will CCBootcamp join IE and IPexpert and offer free online seminars?

The blog was launched yesterday.  There are a few posts up now including one that seems to be firing a shot at IE.  🙂  Regardless, it’s good to see what looks to me to be a renewed focus on their CCIE training program.

IPexpert: $999 Blended Learning Solution Special Ends Monday

If you were putting off purchasing IPexpert’s Blended Learning Solution at $999 then you only have a few more days to procrastinate (via Twitter).

Last chance to get the CCIE Blended Learning Solution (R&S, Voice, Security) for only $999. There is no better value! Promotion ends Monday. about 17 hours ago from web

After Monday the price will double.

Internetwork Expert Volume II: Lab 8 – Section 8

Section 8 – Security – 7 Points

8.1 Router Hardening

Configure r5 to:

Drop all source-routed packets
Disable proxy-arp and CDP support on the connections to BB2 and BB3
Drop all HTTP an telnet sessions destined for 174.x.0.0/16 and 150.x.0.0/16 from BB2 or BB3
Drop all inbound echo requests coming from BB2 or BB3

In the real lab I would just eat the 3 points rather than mess with connections to the backbone routers.  But this task is pretty easy so I gave it a shot.

The first requirement:

ip source-route
To allow the Cisco IOS software to handle IP datagrams with source routing header options, use the ip source-route command in global configuration mode.

r5(config)#no ip source-route

The second one:

r5(config-subif)#no cdp en
r5(config-subif)#no ip proxy-arp

And the rest:

r5(config)#ip access-list ex TASK_8_1
r5(config-ext-nacl)#deny tcp any 174.1.0.0 0.0.255.255 eq www
r5(config-ext-nacl)#deny tcp any 174.1.0.0 0.0.255.255 eq telnet
r5(config-ext-nacl)#deny tcp any 150.1.0.0 0.0.255.255 eq www
r5(config-ext-nacl)#deny tcp any 150.1.0.0 0.0.255.255 eq telnet
r5(config-ext-nacl)#deny icmp any any echo
r5(config-ext-nacl)#permit ip any any

8.2 Traffic Filtering

Drop all traffic from BB2 to BB3 and vice versa on r5 but do not use any access-lists to do this.

We can police inbound, but how to match on the destination without an ACL?

r5(config)#class-map TASK_8_2
r5(config-cmap)#match ?
  destination-address  Destination address
  input-interface      Select an input interface to match

r5(config-cmap)#match destination-address ?
  mac  MAC address

That will not work:

r5(config-cmap)#do sh int f0/1.52 | i bia
  Hardware is AmdFE, address is 0011.93b0.7521(bia 0011.93b0.7521)
r5(config-cmap)#do sh int f0/1.53 | i bia
  Hardware is AmdFE, address is 0011.93b0.7521(bia 0011.93b0.7521)
r5(config-cmap)#do sh int f0/1 | i bia
  Hardware is AmdFE, address is 0011.93b0.7521(bia 0011.93b0.7521)

Let’s check out the input-interface:

r5(config-cmap)#match input-interface fa0/1.52
                                           ^
% Invalid input detected at ‘^’ marker.

r5(config-cmap)#match input-interface fa0/1

Okay, so I can match on the interface, but only the physical interface (which makes sense). 

r5(config-cmap)#policy-map TASK_8_2
r5(config-pmap)#class TASK_8_2
r5(config-pmap-c)#drop

r5(config-pmap-c)#int fa0/1.52
r5(config-subif)#service-policy out TASK_8_2
r5(config-subif)#int fa0/1.53
r5(config-subif)#service-policy out TASK_8_2

8.3 Traffic Filtering

Open the filter you just configured to allow SMTP from 192.10.1.100 to 204.12.1.0/24

r5(config)#ip access-list ex TASK_8_3_FROM_SERVER
r5(config-ext-nacl)#permit tcp host 192.10.1.100 eq smtp 204.12.10.0 0.0.0.255
r5(config)#ip access-list ex TASK_8_3_TO_SERVER
r5(config-ext-nacl)#perm tcp 204.12.10.0 0.0.0.255 host 192.10.1.100 eq smtp

r5(config)#class-map TASK_8_3_FROM_SERVER
r5(config-cmap)#match access-group name TASK_8_3_FROM_SERVER

r5(config-cmap)#class-map TASK_8_3_TO_SERVER
r5(config-cmap)#match access name TASK_8_3_TO_SERVER

Because I did not create separate policy-maps per backbone router, I had to go back and do that:

r5(config-cmap)#policy-map OUT_TO_BB2
r5(config-pmap)# class TASK_8_3_FROM_SERVER
r5(config-pmap-c)# class TASK_8_2
r5(config-pmap-c)#   drop

r5(config-pmap-c)#policy-map OUT_TO_BB3
r5(config-pmap)# class TASK_8_3_TO_SERVER
r5(config-pmap-c)# class TASK_8_2
r5(config-pmap-c)#   drop

Then I had to go in and remove the old class and policy maps and add the new service-policies:

r5(config)#int fa0/1.52
r5(config-subif)#service-policy out OUT_TO_BB2
r5(config-subif)#int fa0/1.53
r5(config-subif)#service-policy out OUT_TO_BB3

IE went with a few less lines of configuration by using a ‘match not’ statement.

Internetwork Expert Volume II: Lab 8 – Section 5

Section 5 – IP Multicast – 11 Points

5.1 PIM

Basic multicast task. We are not told which PIM mode to use, but by reading ahead we can see that we’ll be using Auto-RP so we’ll need sparse-dense mode.

Sparse-Dense Mode for Auto-RP

5.2 Auto-RP

Configure r1 and r2 to use Auto-RP and announce their lo0 interfaces as candidate RP’s.

Configuring Sparse Mode with Auto-RP

“Configure r3 to map all multicast groups with an even numbered first octet to r1 and odd-numbered to r2.”

There’s no “minimal configuration” stipulation so let’s just make so basic access-lists:

r1(config)#ip access-list standard TASK_5_2_EVEN
r1(config-std-nacl)#permit 224.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 226.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 228.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 230.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 232.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 234.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 236.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 238.0.0.0 0.255.255.255

r1(config)#ip pim send-rp-announce lo0 scope 16 group-list TASK_5_2_EVEN

On r3(mapping agent) you will need to apply those same ACLs and then:

r3(config)#ip pim send-rp-discovery lo0 scope 16

Now we need to set up our rp-list ACLs:

r3(config)#ip access-list standard R1_LOOP
r3(config-std-nacl)#permit 150.1.1.1
r3(config-std-nacl)#ip access-list standard R2_LOOP
r3(config-std-nacl)#permit 150.1.2.2

Finally, we set our rp-announce-filters:

r3(config)#ip pim rp-announce-filter rp-list R1_LOOP group-list TASK_5_2_EVEN
r3(config)#ip pim rp-announce-filter rp-list R2_LOOP group-list TASK_5_2_ODD

For some reason I could not get the r2 to map even though my configuration was correct and r2 saw itself elected:

r2#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)

The problem was that there was no multicast path to r2.  I forgot to configure PIM on the Multilink interfaces on r2 and r3.  DOH!!!

5.3 Multicast Distribution

Multicast traffic should switch to a source based tree once a source is sending 128Kbps or more.

ip pim spt-threshold

r1(config)#ip pim spt-threshold 128

5.4 Multicast Testing

Users in VLAN 4 cannot receive multicast feeds from VLAN 52. 

“Configure…so that r4 responds to ICMP echo requests sent the multicast group 224.4.4.4 from VLAN 52.”

First things first:

r4(config)#int f0/0
r4(config-if)#ip igmp join-group 224.4.4.4

These VLANs are on the spokes.  PIM NBMA mode is needed on the hub.

Before:

r5#p 224.4.4.4 source 174.1.45.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 174.1.45.5
.
r5#

r1(config-if)#ip pim nbma-mode
PIM nbma-mode is not recommended for sparse-dense-mode

After:

r5#p 224.4.4.4 source 174.1.45.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 174.1.45.5

Reply to request 0 from 174.1.145.4, 52 ms

5.5 Broadcast Distribution

This is a common scenario in which we need to map a multicast feed to a broadcast address using the ‘ip multicast helper-map’ command.

Internetwork Expert Volume II: Lab 8 – Section 4

Section 4 – Exteriour Gateway Routing – 13 Points

4.1 BGP

Easy BGP peering task.  Only “twist” is that you’ll be configuring confederations.

SubAS 65145 has a full mesh. 65267 does not.  You’ll need make r6 a route-reflector.

You’ll also need to remember to set ‘next-hop-self’ between inter-confederation peers where needed (unlike true EBGP peerings, inter-confederation peers do not automatically set ‘next-hop-self’).  Or not…this will be addressed in later tasks.  🙂

For some reason IE peered between the loopbacks on the routers in SubAS 65145.

4.2 BGP Summarization

Advertise a summary of 174.x.0.0/16 to the backbone routers.

“Do not allow any other devices in your BGP network to see this prefix.”
“Use one static router on r5 and r6 to accomplish this.”

So we’ll need to create a static route to Null0 on r5 and r6 and redistribute it into BGP…while filtering it for the rest of the BGP routers.

First, create the static route:

r5(config)#ip route 174.1.0.0 255.255.0.0 null0

Next, match that route in a prefix-list and create route-maps to filter it for our network:

r5(config)#ip prefix-list TASK_4_2 permi 174.1.0.0/16

r5(config)#route-map OUT_TO_R4 deny 10
r5(config-route-map)#match ip add pre TASK_4_2
r5(config-route-map)#route-map OUT_TO_R4 permi 1000
r5(config-route-map)#do sh hist

r5(config-route-map)#route-map OUT_TO_R1 deny 10
r5(config-route-map)#match ip add pre TASK_4_2
r5(config-route-map)#route-map OUT_TO_R1 permi 1000

Finally, redistribute the static route into BGP and apply the route-maps outbound to the neighbors we need to filter for:

r5(config-route-map)#router bgp 65145
r5(config-router)#redistribute static
r5(config-router)#neigh 174.1.145.4 route-map OUT_TO_R4 out
r5(config-router)#neigh 174.1.145.1 route-map OUT_TO_R1 out

We are advertising the summary to BB3:

r5#sh ip bgp neigh 204.12.1.254 adv| b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 174.1.0.0        0.0.0.0                  0         32768 ?

Total number of prefixes 1

But we’re not advertising the summary to r4 and r1:

r5#sh ip bgp neigh 174.1.145.4 adv| b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i

Total number of prefixes 2

r5#sh ip bgp neigh 174.1.145.1 adv| b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i

Total number of prefixes 2

4.3 BGP Next-Hop Processing

“Configure the network in such a way that all devices throughout your network have reachablility to the BGP prefixes learned from AS54.”

Ugh.  That “all devices” bit had me worried that I would need to redistribute BGP into IGP. But the only devices not running BGP are sw3 and sw4 and they are in an OSPF stub area so they will just send traffic for unknown destinations to r3.  So we should be cool.

“Do not advertise the Frame Relay link to BB1 or the Ethernet link to BB3 into IGP or BGP to accomplish this.”

Not a problem I just use ‘next-hop-self’

“Do not use the next-hop-self command to accomplish this.”

Oh poop. I’m stumped.  Should I summarize the routes?  Create a default route? 

Nope. IE was being a bit tricky.  I need to use next-hop modification BUT I cannot use the command ‘next-hop-self’.  Instead I can set the next-hop in a route-map with ‘set ip next-hop peer-address’:

We can use the route-maps that we created for the last task and just add the line:

r6(config)#route-map OUT_TO_R2 perm 1000
r6(config-route-map)#set ip next-hop peer-address

I can ping prefixes from BB1 and BB3 from sw3 even though BGP is not running:

sw3#p 28.119.17.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 28.119.17.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

sw3#p 112.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 112.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

sw3#sh ip proto sum
Index Process Name
0     connected
1     static
2     ospf 100
*** IP Routing is NSF aware ***

4.4 BGP Bestpath Selection

Advertise some networks into BGP and then make the routes to some of these networks be preferred via one of the AS 54 backbone routers.

We’re affecting inbound traffic so we have a choice of AS-Path or MED. I picked AS-Path.

We also have this requirement:

“Other AS’s beyond AS 54 should not see these specific subnets, but instead should only see the previously advertised aggregate.”

This task would be very difficult without our good friend the BGP community attribute.  🙂

r6(config)#ip prefix-list VLAN3 permi 174.1.3.0/24
r6(config)#ip prefix-list VLAN4 permi 174.1.4.0/24
r6(config)#ip prefix-list VLAN7 permi 174.1.7.0/24

r6(config)#route-map OUT_TO_BB1
r6(config-route-map)#match ip add pre VLAN3 VLAN7
r6(config-route-map)#set as-path prepend 100 100 100 100
r6(config-route-map)#set community no-export
r6(config-route-map)#route-map OUT_TO_BB1 20
r6(config-route-map)#match ip add pre VLAN4
r6(config-route-map)#set community no-export
r6(config-route-map)#route-map OUT_TO_BB1 permit 1000

r6(config)#router bgp 65267
r6(config-router)#neigh 54.1.2.254 send-community
r6(config-router)#neigh 54.1.2.254 route-map OUT_TO_BB1 out

IE used MED instead of AS-Path (although they noted that both were acceptable).  They did drop this on me (I can’t believe that I didn’t know this):

MED is only compared (by default) between prefixes learned from the same autonomous system.

4.5 BGP Filtering

Advertise VLAN 1001 into BGP but make sure that devices outside of AS 65145 don’t have reachbility to this VLAN.

“Do not use any access-lists or prefix-lists to accomplish this.”

Another job for the BGP community attribute.  r1 is inside a confederation so we should use local-AS.

r1(config)#route-map TASK_4_5
r1(config-route-map)#set community local-AS

r1(config)#router bgp 65145
r1(config-router)#net 174.1.1.0 ma 255.255.255.0 route-map TASK_4_5
r1(config-router)#neighbor 174.1.145.4 send-comm
r1(config-router)#neighbor 174.1.145.5 send-comm

We see the route in AS 65145:

r4#sh ip bgp 174.1.1.0 255.255.255.0
BGP routing table entry for 174.1.1.0/24, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised outside local AS)
Flag: 0x880
  Not advertised to any peer
  Local
    174.1.145.1 from 174.1.145.1 (150.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      Community: local-AS

We do not see it outside of AS 65145:

r2#sh ip bgp 174.1.1.0 255.255.255.0
% Network not in table

Internetwork Expert Volume II: Lab 8 – Section 3

Section 3 – Interior Gateway Routing – 16 Points

3.1 OSPF

Simple OSPF task.  The only odd bit is that you’ll be configuring OSPF over the PPPoFR network.  It makes sense that the OSPF network type is point-to-point.  🙂

r3(config-router)#do sh ip os int | i proto|Type
Multilink1 is up, line protocol is up
  Process ID 100, Router ID 150.1.3.3, Network Type POINT_TO_POINT, Cost: 1

r2#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.3.3         0   FULL/  –        00:00:38    174.1.23.3      Multilink1

“Authenticate the OSPF adjacency between r2 and r6 using OSPF type 1 authentication.”

Crap.  I think that type 1 is just clear-text (type 0 = null and type 7 = md5).  It’s weird that the task does not mention a password.  I used the old standby of “CISCO”

r6(config-router)#int FastEthernet0/1.26
r6(config-subif)#ip ospf authentication
r6(config-subif)#ip ospf authentication-key CISCO

r2(config-subif)#do sh ip os int Gi0/0.26 | i proto|authe
GigabitEthernet0/0.26 is up, line protocol is up
  Simple password authentication enabled 

3.2 OSPF

Configure area 38 so that “external LSAs” are not advertised in.

We know that we’re done to stub or totally stubby at this point.

“Ensure that devices in OSPF area 38 still have specific forwarding information about prefixes originated in other OSPF areas.”

So we need to allow IA routes (LSA 3).  That sounds like a stub area to me.

3.3 OSPF

Create area 67 and then summarize 150.1.6.6 and 150.1.7.7 with no overlapping address space:

7 0000011|1
6 0000011|0

150.1.6.0/23 or 150.1.6.0 255.255.254.0

Summary will move from area to area so use…..area range.  🙂

r6(config)#router os 100
r6(config-router)#area 67 range 150.1.6.0 255.255.254.0

r3#sh ip route 150.1.6.6
Routing entry for 150.1.6.0/23
  Known via “ospf 100”, distance 110, metric 3, type inter area
  Last update from 174.1.23.2 on Multilink1, 00:00:36 ago
  Routing Descriptor Blocks:
  * 174.1.23.2, from 150.1.6.6, 00:00:36 ago, via Multilink1
      Route metric is 3, traffic share count is 1

r3#sh ip route 150.1.7.7
Routing entry for 150.1.6.0/23
  Known via “ospf 100”, distance 110, metric 3, type inter area
  Last update from 174.1.23.2 on Multilink1, 00:00:50 ago
  Routing Descriptor Blocks:
  * 174.1.23.2, from 150.1.6.6, 00:00:50 ago, via Multilink1
      Route metric is 3, traffic share count is 1

3.4 EIGRP

Basic EIGRP task.  The only confusing bit is that the task asks you to advertise the lo0 interface of all of the EIGRP devices into EIGRP.  r3 is already advertising its lo0 interface into OSPF.  They must have meant all of the EIGRP devices except r3 (the solution guide bears this out).

Remember to disable split-horizon on the Frame Relay hub (r1):

r1(config-router)#int s0/0
r1(config-if)#no ip split-horizon eigrp 1024

3.5 RIP

Easy RIP task with authentication.

3.6 IGP Redistribution

Redistribute between RIP and EIGRP on r5 and then between OSPF and EIGRP where needed.

Remember that OSPF area 38 is a stub area so it’s not going to let in any external routes.  That means our OSPF<->EIGRP redistribution needs to happen on r3.

I ran into one issue.  I had a route to 174.1.31.0/24 on r1 (connected) as well as r2-3(OSPF).  But r4 and r5 did not have the route.

The problem is that r3 gets that route via OSPF and then advertises it to r1.  R1 does not install the route from r3 because it has that network as connected.  The route does not get passed on to the EIGRP routers behind r1.

I need to either redistribute that connected interface into EIGRP on r1 or find some way to have r1 prefer the route to r3 over the connected route.

r1(config)#route-map CONN->EIGRP
r1(config-route-map)#match int Fa0/0.13

r1(config-route-map)#router ei 1024
r1(config-router)#redist conn met 1 1 1 1 1 route-map CONN->EIGRP

r4#sh ip route 174.1.31.1
Routing entry for 174.1.31.0/24
  Known via “eigrp 1024”, distance 170, metric 2560512256, type external
  Redistributing via eigrp 1024
  Last update from 174.1.145.1 on Serial0/0, 00:00:30 ago
  Routing Descriptor Blocks:
  * 174.1.145.1, from 174.1.145.1, 00:00:30 ago, via Serial0/0
      Route metric is 2560512256, traffic share count is 1
      Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

r4#trace 174.1.31.1

Type escape sequence to abort.
Tracing the route to 174.1.31.1

  1 174.1.145.1 4 msec *  4 msec

I ended up with full reachability by only redistributing RIP<->EIGRP on r5, OSPF<->EIGRP on r3, and Connected (fa0/0.13) -> EIGRP on r1.

IE went a different route.  Then redistributed OSPF->EIGRP on r1, OSPF<->EIGRP on r3, as well as RIP<->EIGRP on r5.

3.7 Load Distribution

Configure the network so that traffic from r4 to r5 is distributed in a 4:1 ratio between the Ethernet connection and the Frame Relay connection.

I messed with this for tooooooooo long.  I tried messing with the metric weight and I was still mindfucked.  I’ll just eat the 3 points and move on.

Update:

I have to try this tomorrow:

Becoming a CCIE: EIGRP Unequal path load balancing

Internetwork Expert Volume II: Lab 12 – Section 5

Section 5 – Exterior Gateway Routing – 20 Points

5.1 BGP Peering
5.2 BGP Route Reflection
5.3 BGP Origination

Thus begins the monster BGP section.  20 points!  Plus we get to deal with a network in which there is not end-to-end IGP reachability.  WHEE!!!

I drew out my BGPpeering diagram and spotted four possible route-reflectors.  I needn’t have bothered as the next task explicitly pointed them out. 🙂  The only twist is that these route-reflectors should not treat each other as clients.

All of these first three tasks were very basic, so I just did them all together.

Because of the broken IGP you’ll need to configure “next-hop-self” for all of the iBGP peerings behind routers with EBGP peerings.

The IE solution for r2 shows a ‘next-hop-self’ statement for the EBGP peering from r2 to BB2.  They do the same thing for the EBGP peering between r6 and BB1 as well as the EBGP peering between sw2 and BB3.  This seems redundant to me.  Watch the network masks (/25) when advertising in VLANs 3 and 33.  That task also asks you to use r2, but that’s a typo as it should be r3.  VLAN 45 is a /29 so watch that one as well.

5.4 BGP Bestpath Selection

Configure AS 200 to affect traffic inbound from AS 100 so that traffic to VLAN 3 goes one route and traffic to VLAN 33 goes another.  If either link fails, use the other as a backup.  Make sure that a third link is not used at all.

Well we’re tasked with affecting inbound traffic by configuring AS 200.  We have two primary options to do this: AS-Path or MED.  Since we are affecting all traffic and AS 200 is the destination AS,  MED is the easier method to use.  We will need to change the MED on two of the three AS border routers and then either crank up the MED to an impossibly high value or just filter the routes (my preference) on the third.

First we need to create prefix-lists for the two VLANs:

Rack16SW1(config)#ip prefix-list VLAN33 permit 129.16.3.128/25
Rack16SW1(config)#ip prefix-list VLAN3 permit 129.16.3.0/25

Then match those prefixes in a route-map and set the metric value accordingly.  In the case of sw1 we want traffic destined for VLAN 3 to prefer this link:

sw1:

Rack16SW1(config)#route-map OUT_TO_SW2
Rack16SW1(config-route-map)#match ip add pre VLAN3
Rack16SW1(config-route-map)#set metric ?
  +/-<metric>     Add or subtract metric
  <0-4294967295>  Metric value or Bandwidth in Kbits per second
  <cr>

Remember that MED = metric and that the LOWER the value, the more preferred that route is.

Rack16SW1(config-route-map)#set metric 1

Now let’s make sure that VLAN33 traffic has a higher (therefore less preferred) MED:

Rack16SW1(config-route-map)#route-map OUT_TO_SW2 permit 20
Rack16SW1(config-route-map)#match ip add VLAN33
Rack16SW1(config-route-map)#set metric 666

Finally, do NOT forget to add an ‘explicit permit’ statement for the rest of the traffic:

Rack16SW1(config-route-map)#route-map OUT_TO_SW2 permit 1000

Our route-map now looks like this:

route-map OUT_TO_SW2 permit 10
 match ip address prefix-list VLAN3
 set metric 1
!
route-map OUT_TO_SW2 permit 20
 match ip address VLAN33
 set metric 666
!
route-map OUT_TO_SW2 permit 1000

We can configure r1 the same way, but just flip the metric values so the VLAN 33 is prefered.

Finally we just need to add the route-map to the neighbor statement:

Rack16SW1(config-route-map)#router bgp 200
Rack16SW1(config-router)#nei 129.16.78.8 route-map OUT_TO_SW2 out

Next we need to make meet the last requirement:

“The Frame Relay circuit between r2 and r4 should not be used as a transit path for either of these destinations.”

We just need to make sure that these two VLANs are not advertised out this link:

Rack16R2(config)#ip prefix-list VLAN33 permit 129.16.3.128/25
Rack16R2(config)#ip prefix-list VLAN3 permit 129.16.3.0/25
Rack16R2(config)#route-map OUT_TO_R4 deny 10
Rack16R2(config-route-map)#match ip add pre VLAN33
Rack16R2(config-route-map)#route-map OUT_TO_R4 deny 20
Rack16R2(config-route-map)#match ip add pre VLAN3
Rack16R2(config-route-map)#route-map OUT_TO_R4 permit 1000
Rack16R2(config-route-map)#router bgp 200
Rack16R2(config-router)#neigh 129.16.124.4 route-map OUT_TO_R4 out

The IE solution guide got fancy with a prefix list that matched both networks with a single line:

ip prefix-list VLANS_3_33 seq 5 permit 129.16.3.0/24 ge 25 le 25

Good to know and understand, but not required for this task.

Verification:

Rack16R6#trace 129.16.3.3

Type escape sequence to abort.
Tracing the route to 129.16.3.3

  1 129.16.46.4 4 msec 0 msec 0 msec
  2 129.16.45.5 4 msec 4 msec 0 msec
  3 129.16.58.8 4 msec 4 msec 4 msec <-sw2
  4 129.16.78.7 0 msec 4 msec 4 msec <-sw1
  5 129.16.17.1 [AS 200] 20 msec 20 msec 20 msec
  6 129.16.13.3 36 msec *  32 msec

Rack16R6#trace 129.16.3.133

Type escape sequence to abort.
Tracing the route to 129.16.3.133

  1 129.16.46.4 0 msec 4 msec 4 msec
  2 129.16.124.1 28 msec 32 msec 28 msec <-FR link between r1 and r4
  3 129.16.13.3 44 msec *  40 msec

Note that the route via r2 is not available:

Rack16R4#sh ip bgp 129.16.3.0 255.255.255.128
BGP routing table entry for 129.16.3.0/25, version 29
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x4940
  Advertised to update-groups:
     2          3
  200
    129.16.58.8 (metric 2) from 150.16.5.5 (150.16.5.5)
      Origin IGP, metric 1, localpref 100, valid, internal, best
      Originator: 150.16.8.8, Cluster list: 150.16.5.5
  200
    129.16.124.1 from 129.16.124.1 (150.16.1.1)
      Origin IGP, metric 666, localpref 100, valid, external

5.5 BGP Filtering

Configure AS 200 to only route traffic destined for AS 254 (BB2) over the Frame Relay link between r2 and r4.  Do not allow traffic destined for AS 254 from AS 100 to route out any other connections even if the Frame Relay link between r2 and r4 is down.

This means that we need to filter all routes to destinations that have AS 254 in the AS-Path from using r1 and sw1 to enter AS 100.

Since we’re tasked with doing this in AS 100 AND we only want the traffic to AS 254 to use one link regardless of the state of that link, we just need to filter any advertisements with AS 254 in the path outbound on r1 and sw1.

First we need an AS-Path statement matching traffic with AS 254 in the path.  We need to match any AS-Path that contains an instance of ‘254’:

Rack16R1(config)#ip as-path access-list 55 permit _254_

Now we need to filter any prefixes that match that AS-Path in a route-map.  We already have an outbound route-map set up for r4:

route-map OUT_TO_R4 permit 10
 match ip address prefix-list VLAN3
 set metric 666
route-map OUT_TO_R4 permit 20
 match ip address VLAN33
 set metric 1
route-map OUT_TO_R4 permit 1000

So let’s just add our deny statement at the beginning of that existing route-map:

Rack16R1(config)#route-map OUT_TO_R4 deny 5
Rack16R1(config-route-map)#match as-path 55

Do the same on sw1:

Rack16SW1(config)#ip as-path access-list 55 permit _254_
Rack16SW1(config)#route-map OUT_TO_SW2 deny 5
Rack16SW1(config-route-map)#match as-path 55

SW2 now routes though r4 rather than sw1 (directly connected):

Rack16SW2#sh ip bgp reg _254_
BGP table version is 53, local router ID is 150.16.8.8
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i205.90.31.0      150.16.4.4               0    100      0 200 254 ?
*>i220.20.3.0       150.16.4.4               0    100      0 200 254 ?
*>i222.22.2.0       150.16.4.4               0    100      0 200 254 ?

Rack16SW2#trace 222.22.2.1

Type escape sequence to abort.
Tracing the route to 222.22.2.1

  1 129.16.58.5 0 msec 8 msec 0 msec
  2 129.16.45.4 0 msec 0 msec 0 msec
  3 129.16.124.2 34 msec 25 msec 33 msec <-FR link from r4 to r2
  4 192.10.16.254 34 msec *  25 msec

R4 only has these routes via the Frame Relay connection to r2:

Rack16R4#sh ip bgp reg _254_
BGP table version is 34, local router ID is 150.16.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 205.90.31.0      129.16.124.2                           0 200 254 ?
*> 220.20.3.0       129.16.124.2                           0 200 254 ?
*> 222.22.2.0       129.16.124.2                           0 200 254 ?

And of course after all of that….IE uses a different AS-Path statement:

ip as-path access-list 1 permit ^254$

I’m a little confused on this.  This matches any paths where AS 254 is the first AS in the path.  Both solutions provide the same results, but mine does not assume that there will always be only one exit path to AS 254.  I say tomato, IE says tomato.

5.6 BGP Default Routing

Just read the last few lines of this task as the rest may confuse you (as it did me).  You need to configure As 100 do advertise a default route into AS 200 but “send AS 200 a full view along with a default out each BGP connection.”

Well, don’t bite and go for this option:

default-information originate (BGP)

We need to advertise it to our neighbors in AS 200 and we need to include the more specific routes so we want:

neighbor default-originate

Before:

Rack16SW1#sh ip bgp neigh 129.16.78.8 route | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   129.16.78.8                            0 100 54 i
*> 28.119.17.0/24   129.16.78.8                            0 100 54 i
*> 112.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 113.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 114.0.0.0        129.16.78.8                            0 100 54 i
*> 115.0.0.0        129.16.78.8                            0 100 54 i
*> 116.0.0.0        129.16.78.8                            0 100 54 i
*> 117.0.0.0        129.16.78.8                            0 100 54 i
*> 118.0.0.0        129.16.78.8                            0 100 54 i
*> 119.0.0.0        129.16.78.8                            0 100 54 i
*> 129.16.45.0/29   129.16.78.8                            0 100 i
*> 129.16.46.0/24   129.16.78.8                            0 100 i
*> 129.16.58.0/24   129.16.78.8              0             0 100 i

Total number of prefixes 13

Rack16SW2(config)#router bgp 100
Rack16SW2(config-router)#neigh 129.16.78.7 default-originate

After:

Rack16SW1#sh ip bgp neigh 129.16.78.8 route | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                            0 100 i
*> 28.119.16.0/24   129.16.78.8                            0 100 54 i
*> 28.119.17.0/24   129.16.78.8                            0 100 54 i
*> 112.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 113.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 114.0.0.0        129.16.78.8                            0 100 54 i
*> 115.0.0.0        129.16.78.8                            0 100 54 i
*> 116.0.0.0        129.16.78.8                            0 100 54 i
*> 117.0.0.0        129.16.78.8                            0 100 54 i
*> 118.0.0.0        129.16.78.8                            0 100 54 i
*> 119.0.0.0        129.16.78.8                            0 100 54 i
*> 129.16.45.0/29   129.16.78.8                            0 100 i
*> 129.16.46.0/24   129.16.78.8                            0 100 i
*> 129.16.58.0/24   129.16.78.8              0             0 100 i

Total number of prefixes 14

5.7 BGP Default Routing

Configure sw1 so that the only prefix that it sees from AS 100 is the default route.

“Additionally, ensure that sw1 is the most preferred exit point out of AS 200 for a prefix that no other device in AS 100 has a longer match for.”

Okay…so we need to filter all routes from sw2(AS 100) except for the default route. We also need to make sure that AS 200 prefers our default route over the ones advertised to r1 and r2.

First things first.  Let’s write a prefix-list to match the default route:

Rack16SW1(config)#ip prefix-list DEFAULT permit 0.0.0.0/0

Now let’s filter everything except this route from sw2:

Rack16SW1(config)#route-map IN_FROM_SW2
Rack16SW1(config-route-map)#match ip add pre DEFAULT

We might as well address our last requirement at this point.  We need to affect outbound traffic from AS 200 to prefer this default route.  We have a choice of Weight or Local Preference to do this.  Since we are limited to configuring sw1 and we need to affect all of AS 200 only we need to use local_pref.  We just need to set the local-preference for this default route to a high value (higher than the default of 100 at least):

Rack16SW1(config-route-map)#set local-preference 666666

Now we just need to apply this route map inbound from sw2:

Rack16SW1(config-route-map)#router bgp 200
Rack16SW1(config-router)#neighbor 129.16.78.8 route-map IN_FROM_SW2 in

Verify:

Rack16SW1#sh ip bgp neigh 129.16.78.8 route | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                            0 100 i

R1 prefers the default route to sw1 over the default route it learns from EBGP peer r4 and iBGP peer r2:

Rack16R1#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 36
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x840
  Advertised to update-groups:
     1          3
  100
    129.16.124.4 from 129.16.124.4 (150.16.4.4)
      Origin IGP, metric 0, localpref 100, valid, external
  100, (Received from a RR-client)
    129.16.17.7 from 129.16.17.7 (150.16.7.7)
      Origin IGP, metric 0, localpref 666666, valid, internal, best

5.8 BGP Bestpath Selection

Configure AS 200 so that it will only send traffic out the Frame Relay circuit between r2 and r4 that is destined for AS 100 and it’s directly connected customers.

“Configure this filtering in such a way that it can account for an arbitrary amount of new customers that may be connected to AS 100 int the future.”

All of this means that we need to write as AS-Path statement that will match paths that start with AS 100 and can have exactly one more AS in the path.  Ugh.

Well we know that we need to match for ^100 and x$.  This is where it helps to know where to find the documentation for regular expressions.

Here’s what I came up with:

ip as-path access-list ^100_[0-9]*_$

This seemed to work:

Rack16SW1#sh ip bgp reg ^100_[0-9]*_$
BGP table version is 39, local router ID is 150.16.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                666666      0 100 i
*>i28.119.16.0/24   129.16.17.1              0    100      0 100 54 i
*>i28.119.17.0/24   129.16.17.1              0    100      0 100 54 i
*>i114.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i115.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i116.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i117.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i118.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i119.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i129.16.45.0/29   129.16.17.1              0    100      0 100 i
*>i129.16.46.0/24   129.16.17.1              0    100      0 100 i
*>i129.16.58.0/24   129.16.17.1              0    100      0 100 i

IE came up with ^100(_[0-9]+)?$

Rack16SW1#sh ip bgp reg ^100(_[0-9]+)$
BGP table version is 39, local router ID is 150.16.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i28.119.16.0/24   129.16.17.1              0    100      0 100 54 i
*>i28.119.17.0/24   129.16.17.1              0    100      0 100 54 i
*>i114.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i115.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i116.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i117.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i118.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i119.0.0.0        129.16.17.1              0    100      0 100 54 i

I guess that I read the requirements wrong as I thought that we needed to include traffic destined for AS 100 AND AS 100 plus one more AS.

DOH!!!  Those of you with a keen eye will see where I fucked up.  I pasted in the IE regular expression.  If you look at my command you’ll notice that the question mark is missing.  You need to use ‘control+v’ to insert a question mark.  Here’s what the output should look like:

Rack16SW1#sh ip bgp reg ^100(_[0-9]+)?$
BGP table version is 39, local router ID is 150.16.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                666666      0 100 i
*>i28.119.16.0/24   129.16.17.1              0    100      0 100 54 i
*>i28.119.17.0/24   129.16.17.1              0    100      0 100 54 i
*>i114.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i115.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i116.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i117.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i118.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i119.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i129.16.45.0/29   129.16.17.1              0    100      0 100 i
*>i129.16.46.0/24   129.16.17.1              0    100      0 100 i
*>i129.16.58.0/24   129.16.17.1              0    100      0 100 i

There’s a nice breakdown on how they came up with this regular expression.

We just need to use a filter-list inbound on r2 to make the magic happen:

Rack16R2(config)#ip as-path access-list 58 perm ^100(_[0-9]+)$
Rack16R2(config)#router bgp 200
Rack16R2(config-router)#neigh 129.16.124.4 filter-list 58 in

“This link should still be able to be used to send traffic out to AS 100 if there are no longer matches throughout the BGP domain, but should only be preferred as a default exit point if sw1’s connection to AS 100 is down.”

All this is saying is that we should leave the default route to AS 100 alone (we already configured the AS 200 to prefer the default route to sw2).

5.9 BGP Bestpath Selection

At this point I was sick to death of BGP.  Only two more tasks to go:

I had a hell of a time deciphering this mess.  I think that we just need to make sure that the default route that r1 is learning from r4 is only used if the link between sw1 and sw2 as well as the link between r2 and r4 are down.  This seems like it should be as simple as setting the local-preference on the default to be less than those two links.  sw1-sw2 has a local-preference of 666666 and r2-r4 has the default of 100, so we just need to configure the default on r1 to a value less than 100.

Rack16R1(config)#ip prefix-list DEFAULT perm 0.0.0.0/0
Rack16R1(config)#route-map IN_FROM_R4
Rack16R1(config-route-map)#match ip add DEFAULT
Rack16R1(config-route-map)#set local 50
Rack16R1(config-route-map)#route-map IN_FROM_R4 perm 1000
Rack16R1(config-route-map)#router bgp 200
Rack16R1(config-router)#neigh 129.16.124.4 route-map IN_FROM_R4 in

This is similar to task 5.7 except that we want to allow in all of the routes, not just the default route.  That’s why we need to add the ‘explicit permit’ line in the route-map.

5.10 BGP Aggregation

Last BGP task!!!

Configure BGP summaries to the three BB routers, but don’t let any of your devices see these summaries.

Since there are no loopback prefixes currently advertised into BGP, we need to advertise those in:

Rack16R2(config-router)#net 150.16.0.0 mask 255.255.0.0

There’s no requirement about “no overlapping address space” so let’s just advertise a /16 for the devices and another for the loopbacks.  Should we use ‘summary-only’?  I’m not sure:

Rack16R2(config-router)#aggregate-address 150.16.0.0 255.255.0.0
Rack16R2(config-router)#aggregate-address 129.16.0.0 255.255.0.0

Now we need to set up filtering so that our other BGP peers do not see these summaries.  First write prefix-lists to match the summaries:

Rack16R2(config)#ip prefix-list INTERNAL permit 150.16.0.0/24
Rack16R2(config)#ip prefix-list INTERNAL seq 10  permit 129.16.0.0/24

Now write a route-map (r2 will be a special case as there is already an existing route-map outbound to r4 – just add a deny statement to that map):

Rack16R2(config)#route-map FILTER_AGGREGATE deny 10
Rack16R2(config-route-map)#match ip add INTERNAL
Rack16R2(config-route-map)#route-map FILTER_AGGREGATE permit 1000

On r2:

Rack16R2(config)#route-map OUT_TO_R4 deny 30
Rack16R2(config-route-map)#match ip add INTERNAL

Finally just add the route-map to a neighbor statement outbound for each peer (other than the BB):

Rack16R2(config-router)#neighbor 129.16.23.3 route-map FILTER_AGGREGATE out

I’ll have to review how to advertise a summary in BGP.  I thought that the network needed to be in the BGP table before you could advertise it as an aggregate.  Obviously, this in not the case:

IE method (sans loopback advertisement):

Rack16R6#sh ip bgp neigh 54.16.1.254 adv | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 129.16.0.0       0.0.0.0                            32768 i
*>i129.16.3.0/25    129.16.58.8              1    100      0 200 i
*>i129.16.3.128/25  129.16.46.4              1    100      0 200 i
*>i129.16.17.0/24   129.16.46.4              1    100      0 200 i
r>i129.16.45.0/29   129.16.46.4              0    100      0 i
r>i129.16.46.0/24   129.16.46.4              0    100      0 i
r>i129.16.58.0/24   129.16.58.8              0    100      0 i

Total number of prefixes 7

My method:

Rack16R6#sh ip bgp neigh 54.16.1.254 adv | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 129.16.0.0       0.0.0.0                            32768 i
*>i129.16.3.0/25    129.16.58.8              1    100      0 200 i
*>i129.16.3.128/25  129.16.46.4              1    100      0 200 i
*>i129.16.17.0/24   129.16.46.4              1    100      0 200 i
r>i129.16.45.0/29   129.16.46.4              0    100      0 i
r>i129.16.46.0/24   129.16.46.4              0    100      0 i
r>i129.16.58.0/24   129.16.58.8              0    100      0 i

Total number of prefixes 7

I’m also not sure why the 150.16.0.0/16 summary is not being advertised to this backbone router.  Oh well.  Too much BGP. 

I’ll revisit this later.