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.

Another Expensive Lunch

Yesterday I grappled with the CCIE R&S Version 4.0 lab for the third time and walked away again without a number.

Troubleshooting is again the bane of my existence with configuration being challenging but more of a good exercise.  To be quite honest I would have preferred to have given up an hour of configuration time to take an extra half hour for troubleshooting, I think I probably needed an extra 10 minutes to close off another ticket.  The score report for the TS section was in alignment with my expectations that I was one ticket away from a pass - which I guess is at least an improvement on each of my previous attempts but still a fail.

I'm very thankful for my wife for her patience and understanding and encouragement not to give up.  Her support coupled with the original intentions on why I wanted to pursue this certification in the first place (Like the title of blog says, I do like playing with routers) helps keep the motivation going when the chips are down when otherwise I could throw in the towel.  Fortunately I still have some vacation days available I can use for a couple of days preparation before the next attempt however at this rate I think someone may be assigned #31337 before I get my digits :)

EIGRP and Static Routes

This posting is going to cover an interesting topic - redistribution and specifically redistribution of static routes into EIGRP.  Now before you skip the post, we're going to cover how you can make static routes appear as if they are internal to EIGRP.

Here's the initial configs - the topology is R1-R2-R3.  Where R1 is not performing any dynamic routing (R2 is it's default gateway) and R2 has an EIGRP adjacency with R3.

R1

hostname R1
interface Loopback0
 ip address 10.1.1.0 255.255.255.255
!
interface Loopback1
 ip address 10.1.1.1 255.255.255.255
!
interface Loopback2
 ip address 10.1.1.2 255.255.255.255
!
interface Loopback3
 ip address 10.1.1.3 255.255.255.255
!
interface Serial0/0
 ip address 10.1.12.1 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 10.1.12.2 102 broadcast
 no frame-relay inverse-arp
!
ip route 0.0.0.0 0.0.0.0 10.1.12.2

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
 snmp trap link-status
 frame-relay interface-dlci 201
!
interface Serial0/0.23 point-to-point
 ip address 10.1.23.2 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 203
!
router eigrp 23
 redistribute static metric 1 1 1 1 1
 network 10.1.23.2 0.0.0.0
 no auto-summary
!
ip route 10.1.1.0 255.255.255.255 10.1.12.1
ip route 10.1.1.1 255.255.255.255 10.1.12.1
ip route 10.1.1.2 255.255.255.255 10.1.12.1
ip route 10.1.1.3 255.255.255.255 10.1.12.1

R3
hostname R3
interface Serial0/0
 ip address 10.1.23.3 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 10.1.23.2 302 broadcast
 no frame-relay inverse-arp
!
router eigrp 23
 network 10.1.23.3 0.0.0.0
 no auto-summary
!

Ok, so nothing special so far, lets have look at what's in the EIGRP topology table:

R2#sh ip eigrp topology
IP-EIGRP Topology Table for AS(23)/ID(10.1.23.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.1.1.2/32, 1 successors, FD is 2560000256
        via Rstatic (2560000256/0)
P 10.1.1.3/32, 1 successors, FD is 2560000256
        via Rstatic (2560000256/0)
P 10.1.1.0/32, 1 successors, FD is 2560000256
        via Rstatic (2560000256/0)
P 10.1.1.1/32, 1 successors, FD is 2560000256
        via Rstatic (2560000256/0)
P 10.1.23.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0.23
R2#sh ip eigrp topology 10.1.1.0/32
IP-EIGRP (AS 23): Topology entry for 10.1.1.0/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560000256
  Routing Descriptor Blocks:
  10.1.12.1, from Rstatic, Send flag is 0x0
      Composite metric is (2560000256/0), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 10 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 0
      External data:
        Originating router is 10.1.23.2 (this system)
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)

This is all normal, static routes redistributed to into EIGRP are external routes...

R3#sh ip route | b Gateway
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D EX    10.1.1.2/32 [170/2560512256] via 10.1.23.2, 00:03:05, Serial0/0
D EX    10.1.1.3/32 [170/2560512256] via 10.1.23.2, 00:03:05, Serial0/0
D EX    10.1.1.0/32 [170/2560512256] via 10.1.23.2, 00:03:05, Serial0/0
D EX    10.1.1.1/32 [170/2560512256] via 10.1.23.2, 00:03:05, Serial0/0
C       10.1.23.0/24 is directly connected, Serial0/0

So as I mentioned earlier we can actually make these static routes appear as internal to EIGRP but to make it happen we need to follow a few rules to make it work:

1) The static routes must use an interface as the next-hop rather than an using the next-hop IP Address:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#no ip route 10.1.1.0 255.255.255.255 10.1.12.1
R2(config)#ip route 10.1.1.0 255.255.255.255 s0/0.21
R2(config)#no ip route 10.1.1.1 255.255.255.255 10.1.12.1
R2(config)#ip route 10.1.1.1 255.255.255.255 s0/0.21
R2(config)#no ip route 10.1.1.2 255.255.255.255 10.1.12.1
R2(config)#ip route 10.1.1.2 255.255.255.255 s0/0.21
R2(config)#no ip route 10.1.1.3 255.255.255.255 10.1.12.1
R2(config)#ip route 10.1.1.3 255.255.255.255 s0/0.21

2) Enable EIGRP on the interface that has the static routes (making the interface passive is optional)


R2(config)#router eigrp 23
R2(config-router)#passive-interface Serial0/0.21
R2(config-router)#network 10.1.12.2 0.0.0.0

Update: 31 March 2012 - Tom Kacprzynski rightly informed me that step 2 is not actually required at all for this procedure to work.  Thanks Tom!

3) Include the networks of the static routes into EIGRP


R2(config-router)#network 10.1.1.0 0.0.0.3
R2(config-router)#end



Now to see what has changed:

R2#show ip route | b Gateway
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C       10.1.12.0/24 is directly connected, Serial0/0.21
S       10.1.1.2/32 is directly connected, Serial0/0.21
S       10.1.1.3/32 is directly connected, Serial0/0.21
S       10.1.1.0/32 is directly connected, Serial0/0.21
S       10.1.1.1/32 is directly connected, Serial0/0.21
C       10.1.23.0/24 is directly connected, Serial0/0.23

These are still definitely static routes, what about the EIGRP topology?

R2#sh ip eigrp topology 10.1.1.0/32
IP-EIGRP (AS 23): Topology entry for 10.1.1.0/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560000256
  Routing Descriptor Blocks:
  0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (2560000256/0), Route is Internal
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 10 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 0

It is now showing up as an internal route even though it shows it was redistributed from static, what does our EIGRP peer R3 see?

R3#show ip route | b Gateway
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D       10.1.12.0/24 [90/2681856] via 10.1.23.2, 00:02:55, Serial0/0
D       10.1.1.2/32 [90/2560512256] via 10.1.23.2, 00:02:55, Serial0/0
D       10.1.1.3/32 [90/2560512256] via 10.1.23.2, 00:02:55, Serial0/0
D       10.1.1.0/32 [90/2560512256] via 10.1.23.2, 00:02:55, Serial0/0
D       10.1.1.1/32 [90/2560512256] via 10.1.23.2, 00:02:55, Serial0/0
C       10.1.23.0/24 is directly connected, Serial0/0

R3#sh ip eigrp topology 10.1.1.0/32
IP-EIGRP (AS 23): Topology entry for 10.1.1.0/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560512256
  Routing Descriptor Blocks:
  10.1.23.2 (Serial0/0), from 10.1.23.2, Send flag is 0x0
      Composite metric is (2560512256/2560000256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 20010 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1


Yes, those static routes on R2 appear to R3 as if they are internal EIGRP routes.  Actually, we can remove the "redistribute static" from the EIGRP process as it is no longer required in this instance.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router eigrp 23
R2(config-router)#no redistribute static
R2(config-router)#end


Strange as it seems, this appears to be a design intent for EIGRP and is documented on Cisco's website about this.

Interdomain Multicast using MSDP

This post is talking about using MSDP to join multicast domains together.

The topology here is very simple even if it does consist of 6 routers.

R1-R2-R3---------R4-R5-R6

Multicast Domain 1

R1, R2 and R3 use EIGRP as their IGP

AutoRP is used for RP election and R3 will be the RP

Multicast Domain 2

R4, R5 and R6 use OSPF as their IGP
AutoRP is used for RP election and R4 will be the RP


Both Multicast Domains are connected using BGP (R3 AS 3) and (R4 AS 4)
All routers have their loopback0 interfaces and interconnecting interfaces running PIM sparse-mode so we are using "ip pim autorp listener"

Note: AutoRP advertisements are blocked between R3 and R4 on their corresponding interfaces "ip multicast boundary 1" is applied where the 1 refers to an access list which blocks AutoRP rp candidate and mapping agent advertisements but allows all other multicast traffic

The base configurations are shown below

R1
hostname R1
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip pim sparse-mode
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.12 point-to-point
 description PVC to R2
 ip address 10.1.12.1 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 102
!
router eigrp 123
 network 1.1.1.1 0.0.0.0
 network 10.1.12.1 0.0.0.0
 no auto-summary
!
ip pim autorp listener

R2
hostname R2
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode
!
interface Loopback23
 ip address 23.23.23.2 255.255.255.255
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.21 point-to-point
 description PVC to R1
 ip address 10.1.12.2 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 201
!
interface Serial0/0.23 point-to-point
 description PVC to R3
 ip address 10.1.23.2 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 203
!
router eigrp 123
 network 2.2.2.2 0.0.0.0
 network 10.1.12.2 0.0.0.0
 network 10.1.23.2 0.0.0.0
 no auto-summary
!
ip pim autorp listener

R3
hostname R3
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip pim sparse-mode
!
interface Loopback34
 ip address 34.34.34.3 255.255.255.255
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.32 point-to-point
 description PVC to R2
 ip address 10.1.23.3 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 302
!
interface Serial0/0.34 point-to-point
 description PVC to R4
 ip address 10.1.34.3 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 304
 ip multicast boundary 1
!
router eigrp 123
 network 3.3.3.3 0.0.0.0
 network 10.1.23.3 0.0.0.0
 no auto-summary
!
router bgp 3
 no synchronization
 bgp log-neighbor-changes
 network 34.34.34.3 mask 255.255.255.255
 neighbor 10.1.34.4 remote-as 4
 no auto-summary
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 3
ip pim send-rp-discovery Loopback0 scope 3
ip msdp peer 34.34.34.4 connect-source Loopback34
!
access-list 1 deny   224.0.1.39
access-list 1 deny   224.0.1.40
access-list 1 permit any

R4
hostname R4
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip pim sparse-mode
!
interface Loopback34
 ip address 34.34.34.4 255.255.255.255
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.43 point-to-point
 description PVC to R3
 ip address 10.1.34.4 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 403
 ip multicast boundary 1
!
interface Serial0/0.45 point-to-point
 description PVC to R5
 ip address 10.1.45.4 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 405
!
router ospf 1
 network 4.4.4.4 0.0.0.0 area 0
 network 10.1.45.4 0.0.0.0 area 0
!
router bgp 4
 no synchronization
 bgp log-neighbor-changes
 network 34.34.34.4 mask 255.255.255.255
 neighbor 10.1.34.3 remote-as 3
 no auto-summary
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 3
ip pim send-rp-discovery Loopback0 scope 3
ip msdp peer 34.34.34.3 connect-source Loopback34
!
access-list 1 deny   224.0.1.39
access-list 1 deny   224.0.1.40
access-list 1 permit any

R5
hostname R5
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
 ip pim sparse-mode
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
!
interface Serial0/0.54 point-to-point
 ip address 10.1.45.5 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 504
!
interface Serial0/0.56 point-to-point
 ip address 10.1.56.5 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 506
!
router ospf 1
 log-adjacency-changes
 network 5.5.5.5 0.0.0.0 area 0
 network 10.1.45.5 0.0.0.0 area 0
 network 10.1.56.5 0.0.0.0 area 0
!
ip pim autorp listener

R6
hostname R6
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
 ip pim sparse-mode
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
!
interface Serial0/0.65 point-to-point
 ip address 10.1.56.6 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 605
!
router ospf 1
 log-adjacency-changes
 network 6.6.6.6 0.0.0.0 area 0
 network 10.1.56.6 0.0.0.0 area 0
!
ip pim autorp listener

Quick verification of RP Mappings

R1/R2/R3 should have R3 as the RP:

R1#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:13:05, expires: 00:02:45

R2#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:13:25, expires: 00:02:23

R3#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:14:41, expires: 00:02:17


R4/R5/R6 will use R4 as their RP:

R4#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:11:28, expires: 00:02:45

R5#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:04:49, expires: 00:02:11

R6#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:05:04, expires: 00:02:55

R3 and R4 each have loopback34 advertised into BGP and use this for MSDP peering.  MSDP is used to transmit the knowledge of multicast sources between domains.  PIM does not need to be run on these interfaces

R3#sh ip msdp peer
MSDP Peer 34.34.34.4 (?), AS 4
  Connection status:
    State: Up, Resets: 0, Connection source: Loopback34 (34.34.34.3)
    Uptime(Downtime): 00:04:40, Messages sent/received: 5/5
    Output messages discarded: 0
    Connection and counters cleared 00:16:10 ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests:
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 0
  Input queue size: 0, Output queue size: 0
  MD5 signature protection on MSDP TCP connection: not enabled

R4#sh ip msdp peer
MSDP Peer 34.34.34.3 (?), AS 3
  Connection status:
    State: Up, Resets: 0, Connection source: Loopback34 (34.34.34.4)
    Uptime(Downtime): 00:04:51, Messages sent/received: 5/5
    Output messages discarded: 0
    Connection and counters cleared 00:12:34 ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests:
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 0
  Input queue size: 0, Output queue size: 0
  MD5 signature protection on MSDP TCP connection: not enabled

So with everything looking ok, our objective is to verify multicast traffic can traverse the domains by having  R1 Loopback0 join multicast group 239.1.1.1 with R6 receive a response when it pings that group

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int loopback0
R1(config-if)#ip igmp join-group 239.1.1.1

Lets enable a debug to see if check ping packets arrive (we could use debug ip icmp however that presents less detail):

R1(config-if)#access-list 101 permit icmp any any
R1(config)#do deb ip pack detail 101
IP packet debugging is on (detailed) for access list 101
R1#end
*Mar  1 00:25:49.379: %SYS-5-CONFIG_I: Configured from console by console

R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:05:42/00:02:14, RP 3.3.3.3, flags: SJCL
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:05:42/00:02:14

R1 has R2 as the RPF neighbor for *,239.1.1.1

R2#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:04:01/00:03:25, RP 3.3.3.3, flags: S
  Incoming interface: Serial0/0.23, RPF nbr 10.1.23.3
  Outgoing interface list:
    Serial0/0.21, Forward/Sparse, 00:04:01/00:03:25

R2 has R3 as the RPF neighbor for *,239.1.1.1

R3#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:04:27/00:02:57, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:04:27/00:02:57

R3 has nothing as the RPF neighbor for *,239.1.1.1

When R6 pings 239.1.1.1 it's RP (R4) will discover it as a new multicast source and advertise it to its MSDP peer (R3)

R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 0 entries
R3#deb ip msdp routes
MSDP Routes debugging is on

R6#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
.


Well that was unsuccessful let's see if R3 learnt about our multicast sources:

R3#
*Mar  1 00:04:42.431: MSDP(0): (6.6.6.6/32, 239.1.1.1), accepted
*Mar  1 00:04:42.479: MSDP(0): (10.1.56.6/32, 239.1.1.1), accepted

Yes it did - what did we see on R1?

R1#
*Mar  1 00:04:50.315: IP: s=10.1.12.1 (local), d=6.6.6.6, len 100, unroutable
*Mar  1 00:04:50.319:     ICMP type=0, code=0
*Mar  1 00:04:50.379: IP: s=10.1.12.1 (local), d=10.1.56.6, len 100, unroutable
*Mar  1 00:04:50.379:     ICMP type=0, code=0

We can see that R1 must have recieved the ping because it's attempting to respond, however R6 didn't obtain a reply since R1 doesn't know how to get back to it

R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:07:35/00:02:42, RP 3.3.3.3, flags: SJCL
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:07:35/00:02:19
(10.1.56.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42
(6.6.6.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42

We can even see that R1 is trying to build a specific path to get to the multicast sources 10.1.56.6 (R6 S0/0.65) and 6.6.6.6 (R6 Lo0) but is failing the RPF checks

R2#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:05:39/00:03:11, RP 3.3.3.3, flags: S
  Incoming interface: Serial0/0.23, RPF nbr 10.1.23.3
  Outgoing interface list:
    Serial0/0.21, Forward/Sparse, 00:05:39/00:02:46

R2 is able to use R3 as its RPF neighbor and pass traffic destined to 239.1.1.1 out to R1

R3#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:05:41/00:03:02, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:05:41/00:02:41

R3 knows that someone at R2 or further downstream is subscribed to group 239.1.1.1

R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 2 entries
(6.6.6.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 0, 00:02:20/00:05:10, Peer 34.34.34.4
(10.1.56.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 0, 00:02:20/00:05:10, Peer 34.34.34.4

So R3 knows about the sources and that the RP is Lo0 on R4 but doesn't know where the sources came from (BGP/AS 0)

Lets fix this by putting the sources into BGP

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router bgp 4
R4(config-router)#redistribute ospf 1
R4(config-router)#end

Let's see if that's resolved things:

R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 2 entries
(6.6.6.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 4, 00:05:40/00:05:31, Peer 34.34.34.4
(10.1.56.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 4, 00:05:40/00:05:31, Peer 34.34.34.4

R3 has determined these source are via BGP and can establish paths back to the sources

R3#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:08:03/00:03:17, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:08:03/00:03:17
(6.6.6.6, 239.1.1.1), 00:00:19/00:02:40, flags: M
  Incoming interface: Serial0/0.34, RPF nbr 10.1.34.4
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:00:19/00:03:17
(10.1.56.6, 239.1.1.1), 00:00:19/00:02:40, flags: M
  Incoming interface: Serial0/0.34, RPF nbr 10.1.34.4
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:00:19/00:03:17

This doesn't work for R1 though as it's not aware of how to get to these sources (RPF nbr 0.0.0.0)

R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:07:35/00:02:42, RP 3.3.3.3, flags: SJCL
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:07:35/00:02:19
(10.1.56.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42
(6.6.6.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42

So we need to redistribute those routes into eigrp

R3#conf t
R3(config)#router eigrp 123
R3(config-router)#redistribute bgp 3 metric 1 1 1 1 1
R3(config-router)#end

This should give us a return route for the ping and resolve the RPF for the shortest path to the sources

R1#sh ip route eigrp | i EX 

D EX    34.34.34.3 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
D EX    34.34.34.4 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
D EX    6.6.6.6 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
D EX    10.1.56.0 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:13:44/stopped, RP 3.3.3.3, flags: SJCL
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:13:44/00:02:18
(10.1.56.6, 239.1.1.1), 00:00:05/00:02:56, flags: LJT
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:05/00:02:54
(6.6.6.6, 239.1.1.1), 00:00:05/00:02:56, flags: LJT
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:05/00:02:54

So lets give it another shot:

R6#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.1.12.1, 32 ms
Reply to request 0 from 10.1.12.1, 32 ms

On R1 we see
R1#
*Mar  1 00:12:47.815: IP: tableid=0, s=10.1.12.1 (local), d=10.1.56.6 (Serial0/0.12), routed via FIB
*Mar  1 00:12:47.815: IP: s=10.1.12.1 (local), d=10.1.56.6 (Serial0/0.12), len 100, sending
*Mar  1 00:12:47.815:     ICMP type=0, code=0
*Mar  1 00:12:47.823: IP: tableid=0, s=10.1.12.1 (local), d=6.6.6.6 (Serial0/0.12), routed via FIB
*Mar  1 00:12:47.827: IP: s=10.1.12.1 (local), d=6.6.6.6 (Serial0/0.12), len 100, sending
*Mar  1 00:12:47.827:     ICMP type=0, code=0

Success!