BGP Route Aggregation with AS-SET

This little scenario involves 3 routers (R1, R2 and R3)  R1 (AS 1) and R2 (AS 2) are directly connected via Frame Relay.  R2 is directly connected to R3 (AS 3) via Frame Relay as well but R3 is an uncontrolled device (in the CCIE Lab this could be a Backbone router) and we plan on aggregating routes R2 learns from R3 so R1 has a more manageable routing table.

The configs are pretty simple (R3's config wont be displayed until the end but it can be inferred as we go along)

R1

hostname R1
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
interface Serial0/0.12 point-to-point
 ip address 10.1.12.1 255.255.255.0
 frame-relay interface-dlci 102
router bgp 1
 no synchronization
 neighbor 10.1.12.2 remote-as 2
 no auto-summary

R2

hostname R2
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
interface Serial0/0.21 point-to-point
 ip address 10.1.12.2 255.255.255.0
 frame-relay interface-dlci 201
interface Serial0/0.23 point-to-point
 ip address 10.1.23.2 255.255.255.0
 frame-relay interface-dlci 203
router bgp 2
 no synchronization 
 neighbor 10.1.12.1 remote-as 1
 neighbor 10.1.23.3 remote-as 3
 no auto-summary

So let's start off with with R2 sees from R3


R2#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.168.0.0/24   10.1.23.3                0             0 3 ?
*> 172.168.1.0/24   10.1.23.3                0             0 3 ?
*> 172.168.2.0/24   10.1.23.3                0             0 3 ?
*> 172.168.3.0/24   10.1.23.3                0             0 3 ?
*> 172.199.0.0/24   10.1.23.3                0             0 3 ?
*> 172.199.1.0/24   10.1.23.3                0             0 3 ?
*> 172.199.2.0/24   10.1.23.3                0             0 3 ?
*> 172.199.3.0/24   10.1.23.3                0             0 3 ?

So let's aggregate these for R1 so it only sees the summary routes

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 172.199.0.0 255.255.252.0 summary-only
R2(config-router)#aggregate-address 172.168.0.0 255.255.252.0 summary-only
R2(config-router)#end

Let's see what R1 now sees

R1>sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.168.0.0/22   10.1.12.2                0             0 2 i
*> 172.199.0.0/22   10.1.12.2                0             0 2 i

Alright, we can see the two aggregate routes, however we see that the AS-PATH shows R2 as the originator.  What if we wanted to see that these originated from R3?

Within the aggregate-address command, we can include the AS-SET option, which will show us the  Autonomous Systems in the path which contribute to this route

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 172.168.0.0 255.255.252.0 summary-only as-set
R2(config-router)#aggregate-address 172.199.0.0 255.255.252.0 summary-only as-set
R2(config-router)#end

So now let's see what R1 sees:

R1>sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.199.0.0/22   10.1.12.2                0             0 2 3 ?

Now this is a little odd, we can see that the route that is present does now indeed include the full AS-Path, however we have lost the route for 172.168.0.0/22 even though we previously had it.  Maybe R2 is doing something wrong?

R2#show ip bgp neighbor 10.1.12.1 advertised-routes
BGP table version is 21, local router ID is 10.1.23.2
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
*> 172.199.0.0/22   0.0.0.0                       100  32768 3 ?

Hello 172.168.0.0/22? Have we lost it?


R2#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
s> 172.168.0.0/24   10.1.23.3                0             0 3 ?
*> 172.168.0.0/22   0.0.0.0                       100  32768 3 ?
s> 172.168.1.0/24   10.1.23.3                0             0 3 ?
s> 172.168.2.0/24   10.1.23.3                0             0 3 ?
s> 172.168.3.0/24   10.1.23.3                0             0 3 ?
s> 172.199.0.0/24   10.1.23.3                0             0 3 ?
*> 172.199.0.0/22   0.0.0.0                       100  32768 3 ?
s> 172.199.1.0/24   10.1.23.3                0             0 3 ?
s> 172.199.2.0/24   10.1.23.3                0             0 3 ?
s> 172.199.3.0/24   10.1.23.3                0             0 3 ?

No, something must have happened to stop us sending things it on to R1 though.

R2#show ip bgp 172.168.0.0/22
BGP routing table entry for 172.168.0.0/22, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
  Not advertised to any peer
  3, (aggregated by 2 10.1.23.2)
    0.0.0.0 from 0.0.0.0 (10.1.23.2)
      Origin incomplete, localpref 100, weight 32768, valid, aggregated, local, best
      Community: no-export

When the AS-SET parameter is used, the communities of the contributing routes are also attached to the aggregate, at least one of these contributing routes must have had the no-export community attached to it.

R2#show ip bgp community no-export
BGP table version is 21, local router ID is 10.1.23.2
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
s> 172.168.0.0/24   10.1.23.3                0             0 3 ?
*> 172.168.0.0/22   0.0.0.0                       100  32768 3 ?
s> 172.168.2.0/24   10.1.23.3                0             0 3 ?

So if we would like to ignore R3's instruction of no-export to R1 while maintaining the AS-Path, we have to use our favourite IOS swiss-army knife also known as the route-map which in this form will be used as an attribute map to remove any communities on the aggregate which would normally be inherited from contributing routes:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#route-map NoAttributes
R2(config-route-map)#set community none
R2(config-route-map)#router bgp 2
R2(config-router)#aggregate-address 172.168.0.0 255.255.252.0 summary-only as-set attribute-map NoAttributes
R2(config-router)#end

So let's check that this now works

R2#show ip bgp community no-export
BGP table version is 22, local router ID is 10.1.23.2
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
s> 172.168.0.0/24   10.1.23.3                0             0 3 ?
s> 172.168.2.0/24   10.1.23.3                0             0 3 ?

172.168.0.0/22 is no longer in this list, so it appears that this should be resolved:



R2#sh ip bgp nei 10.1.12.1 advertised-routes
BGP table version is 22, local router ID is 10.1.23.2
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
*> 172.168.0.0/22   0.0.0.0                       100  32768 3 ?
*> 172.199.0.0/22   0.0.0.0                       100  32768 3 ?

Total number of prefixes 2

R1>sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.168.0.0/22   10.1.12.2                0             0 2 3 ?
*> 172.199.0.0/22   10.1.12.2                0             0 2 3 ?

Success!

R3 Config for reference:

hostname R3
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
interface Serial0/0.32 point-to-point
 ip address 10.1.23.3 255.255.255.0
 frame-relay interface-dlci 302
router bgp 3
 no synchronization
 redistribute static
 neighbor 10.1.23.2 remote-as 2
 neighbor 10.1.23.2 send-community
 neighbor 10.1.23.2 route-map R2-OUT out
 no auto-summary
route-map R2-OUT permit 10
 match ip address 1
 set community no-export
route-map R2-OUT permit 20
access-list 1 permit 172.168.0.0 0.0.254.255

Cisco 360 Assessment Lab Review

Troubleshooting has been the major area in the lab exam that I have needed help in lifting my game.  I have used resources in multiple areas to give assistance and they have all helped improve my performance but I have been searching for that extra push to get there.  As previously mentioned I gave the Netmaster class updated assessment labs a spin and to be honest I found particularly in the troubleshooting area that this is the best I've come up against to simulate what you get in the real lab.

The NMC Lab is split into two parts - Troubleshooting and Configuration.  The Troubleshooting section is newer and handled differently to how the Configuration section appears.  To access the TS lab, you have to install a Cisco VPN client (the instructions you are sent a day or two before your actual sessions starts includes a download link for the VPN client as well as a test account to validate that you can connect)  Also included are recommendations to configure your web browser and telnet client which will make things easier so you can click on a router and have putty (or securecrt if that's your poison) fire up

Once your session has begun and you have connected to the VPN, you go to a web page which has the tickets and the network diagrams.  The major difference is that there appears to be 3 hours allocated for TS rather than 2.  I used a timer to force myself to stop after 2 hours to make it as real as possible.  The troubleshooting section is based on the Cisco IOU platform and supports approximately 30 routers.  Unlike the actual lab exam, this doesn't include simulated catalyst platforms, so it's not 100% accurate but is close enough for the majority of tickets you might actually encounter in the real thing and appears to cover all of the technologies in the blueprint.  The types of questions in this simulation are actually more vague than what I recall seeing in the actual lab itself which can be a little annoying, however if you can deal with those you will probably find the actual lab a bit easier.

The configuration section in the lab was a 6 hour configuration section using real routers and switches.  The copyright date of the exam was 2009 and the presentation was not web based - the questions were in a PDF file.  Although the actual config lab these days is usable via a web interface to read questions/see diagrams and no printed material is given, I would actually recommend that you print the configuration section questions out so you can get easy reference to the diagrams otherwise there will be a lot of scrolling up and down.  I found the config lab to be a nice challenge and I guess of similar level to what I have encountered in the real lab.

The timing of events were 3 hours for TS, 1 hour break, 6 hours of Config (I stopped TS after 2 hours so ended up with a 2 hour break in between)  The good thing about the Cisco 360 labs as far as booking the lab session itself is that the booking is based on a local timezone to the student allowing a good deal of flexibility compared to other rack vendors.   The other component that I liked was the automatic grading gave results and feedback in approximately 90 minutes after completion and included a comprehensive marking system and answer key and even a web based system that allows you to compare your configurations against the working reference as well as performing show commands for status and configurations.  The Cisco 360 assessment labs are more expensive than other vendors (approximately twice the cost of some) however with the most up to date version of the Troubleshooting scenario, richer and faster results and feedback and flexible booking times do help offset the higher costs.

What was interesting for my particular session was after the assessment lab, a group mentoring session was held which focused only on the TS component.  Things that were discussed included NMC's recommended strategy for attempting questions as well as an indepth dive into addressing all of the tickets in the assessment lab we did.  This group session was the first time it was run, and while I did find it useful considering it ran for 2.5 hours - I don't think I would attend it against, particularly since it was held at 3am my local time on a Thursday morning (thank goodness for caffeinated beverages or I wouldn't have survived the day at work)


I found the updated TS component in the Cisco 360 Assessment Labs to be very helpful.  There are a number of labs available.  If you are interested in doing one of these, some of the labs listed on their site are the older TS versions that don't use the IOU environment - so if you want the new labs (highly recommended) take care and select labs that have "TC" in the ordering code.  At the time I'm posting the updated labs are

CIERS1-TC-LAB02 (Assessment Lab 2)
CIERS-TC-LAB01 (Assessment Lab 3)
CIERS-TC-LAB02 (Assessment Lab 4)
CIERS2-TC-LAB02 (Assessment Lab 6)
CIERS2-TC-LAB04 (Assessment Lab 8)
CIERS-TC-LAB03 (Assessment Lab 10)
CIERS-TC-LAB04 (Assessment Lab 11)

The lab I took was CIERS-TC-LAB01 (Assessment Lab 3) and this was all paid for out of my own pocket.  I'm considering taking another one of these labs before my next attempt, so I think you could say I'm recommending this as a potential tool for your CCIE Lab preparation.

More Troubleshooting Focus

The blog has been a little quiet lately but I have still been playing with routers in the background.  As part of the Micronics Training Bootcamp I attended back in May, some of the Cisco 360 assessment lab material was included, basically it had some Mock Labs that at least for the configuration portion was pretty much on par as what the actual lab itself presented.  At the time, the troubleshooting material was very similar as to what you find with other vendors, not bad at all but based on the same physical topology as the configuration components.

Netmasterclass who I believe developed a lot of the Cisco 360 material, have recently reworked the way they provide the troubleshooting environment, and it is now based on Cisco IOU just like the real lab, as this is a virtual environment it is mean to span about 30 devices - I'm uncertain as to whether switches are included in the topology, however I think having to deal with such a large environment will be a good thing.  There is quite a rich level of instrumentation and feedback from the Cisco 360 labs, so it should be quite helpful in pinpointing weak points.  I have just signed up for a Troubleshooting and mentoring package which includes the lab and a group mentoring session that should help unveil common issues that others may be encountering as well.  Due to the timezone differences, it means it will be a 3am session in the middle of the week for me which is a little annoying; however I will be making every attempt to be there regardless (hopefully I wont be too fragile at work the next day)

I have my next lab attempt scheduled for December, hopefully this will assist me in getting over the line.