CCIE - Internetwork Expert's Online Community

Can someone shed some other options that could work here. I did a distribute-list out the next-hop routers R3 and R6  filtering towards the backbones.

Would this solution be valid?

Thanks,

I used this method too, applying distribute-list on both R3 and R6, filtering towards Backbones. I ran debugging, noticed that all the Backbone routes going towards each other are suppressed.

Debugging on R6 (Using Dynamics workbook)

Rack1R6#
*Mar  1 00:54:07.599: RIPng: Output filter suppresses 2001:220:20:3::/64
*Mar  1 00:54:07.603: RIPng: Output filter suppresses 2001:222:22:2::/64
*Mar  1 00:54:07.607: RIPng: Output filter suppresses 2001:205:90:31::/64
*Mar  1 00:54:07.611: RIPng: Sending multicast update on Serial1/0 for RIP1
*Mar  1 00:54:07.611:        src=FE80::CE0A:EFF:FEB0:0
*Mar  1 00:54:07.615:        dst=FF02::9 (Serial1/0)
*Mar  1 00:54:07.615:        sport=521, dport=521, length=112
*Mar  1 00:54:07.615:        command=2, version=1, mbz=0, #rte=5
*Mar  1 00:54:07.615:        tag=0, metric=1, prefix=2001:CC1E:1::/64
*Mar  1 00:54:07.615:        tag=0, metric=1, prefix=2001:54:1:2::/64
*Mar  1 00:54:07.615:        tag=0, metric=2, prefix=2001:CC1E:1:23::2/127
*Mar  1 00:54:07.615:        tag=0, metric=3, prefix=2001:CC1E:1:2::/64
*Mar  1 00:54:07.615:        tag=0, metric=2, prefix=2001:192:10:1::/64

SG solution makes sense too, by applying a metric-offset of 13, by the time the BB2 RIPNG routes reach BB1, they will incur a metric of 16 which becomes invalid. Maybe SG is trying to show us 2 ways of doing it? So we can apply metric-offset of 13 on R6's s1/0 too.

Next instead of using distribute-list on both R3 and R6, i used metric-offset on both R3 and R6, it worked too!

nitrodrops:

SG solution makes sense too, by applying a metric-offset of 13, by the time the BB2 RIPNG routes reach BB1, they will incur a metric of 16 which becomes invalid. Maybe SG is trying to show us 2 ways of doing it? So we can apply metric-offset of 13 on R6's s1/0 too.

 

Next instead of using distribute-list on both R3 and R6, i used metric-offset on both R3 and R6, it worked too!

The SG solution does however break the rules of the Lab, as using that solution R2 will not have full reachability of all the IPv6 routes. The same as R3 does not advertse routes from BB1 to BB2 it will also not advertise them out to R2 for the same reason:

Rack11R3#sh ipv6 rip da
RIP process "RIPng", local RIB
 2001:205:90:31::/64, metric 14, installed
     FastEthernet0/1/FE80::200:CFF:FE3F:375A, expires in 162 secs
 2001:220:20:3::/64, metric 14, installed
     FastEthernet0/1/FE80::200:CFF:FE3F:375A, expires in 162 secs
 2001:222:22:2::/64, metric 14, installed
     FastEthernet0/1/FE80::200:CFF:FE3F:375A, expires in 162 secs
 2001:254:0:112::/64, metric 15, installed
     FastEthernet0/0/FE80::211:20FF:FE0A:F001, expires in 166 secs
 2001:254:0:113::/64, metric 15, installed
     FastEthernet0/0/FE80::211:20FF:FE0A:F001, expires in 166 secs
 2001:254:0:114::/64, metric 15, installed
     FastEthernet0/0/FE80::211:20FF:FE0A:F001, expires in 166 secs
 2001:254:0:115::/96, metric 15, installed
     FastEthernet0/0/FE80::211:20FF:FE0A:F001, expires in 166 secs
...

Which gives a RIPng Database on R2 of:

Rack11R2#sh ipv6 rip da
RIP process "RIPng", local RIB
 2001:54:11:2::/64, metric 3, installed
     Serial0/1/FE80::20F:90FF:FED2:7980, expires in 175 secs
 2001:192:10:11::/64, metric 2, installed
     Serial0/1/FE80::20F:90FF:FED2:7980, expires in 175 secs
 2001:205:90:31::/64, metric 15, installed
     Serial0/1/FE80::20F:90FF:FED2:7980, expires in 175 secs
 2001:220:20:3::/64, metric 15, installed
     Serial0/1/FE80::20F:90FF:FED2:7980, expires in 175 secs
 2001:222:22:2::/64, metric 15, installed

So using a distribute list to filter the routes towards BB2 would be a better solution to ensure that R2 has full connectivity.

Using the metric-offset inbound from BB2 to stop the routes being advertised to BB1 does work as R2 & R6 are the same number of hops from BB2 so both get the routes.