Our BGP class is coming up!  This class is for learners who are pursuing the CCIP track, or simply want to really master BGP.  I have been working through the slides, examples  and demos that we’ll use in class, and it is going to be excellent.  If you can’t make the live event, we are recording it, so it will be available as a class on demand, after the live event.    More information, can be found by clicking here.

One of the common questions that comes up is “Why does the router choose THAT route?

We all know, (or at least after reading the list below, we will know), that BGP uses the following order, to determine the “best” path.

So now for the question.   Take a look at the partial output of the show command below:

Regarding the 2.2.2.0/24 network, why did this router select the 192.168.68.8 next hop route, over the one just below it?

Post your ideas, and we will have a drawing next week, before the BGP class begins.   We’ll give 1 lucky winner some rack tokens for our preferred rack vendor, Graded Labs.   Everyone who comments, will be entered into the drawing.  I will update the post with the lucky winner.

Thanks for your ideas, and happy learning,

Keith Barker

Thank you to all who responded.  eBGP is preferred over iBGP, and that is what it came down to.

The winner of the graded labs tokens is Jon!  Congratulations.

As you may have noticed, INE does a wide variety of training in the Cisco space.      This blog post goes out to all those folks who have recently begun their Cisco training.

This month we delivered new live classes on CCNA and CCNP. We are excited for and encourage our students at every level in their journey.   In that light, we have gathered a collection of Videos Answers, targeted at the CCNA level, with a few topics leaking into security and CCNP.   These videos were primarily created as quick (under 10 minutes each) Video Answers to questions that various learners have had.

Take a look at the list of topics, and if there are 1 or 2 you feel you would benefit from, feel free to enjoy them.

Here are a few of the topics (in no particular order):

• How the network statement really works in IOS
• Setting up SSH
• Initial commands for sanity sake
• NAT with overload
• Router on a stick
• VRFs
• SDM Security Audit
• Adding your own PC to interact with GNS3 routers
• IPv6 basic implementation
• Converting Multicast address to MAC address for that group
• Frame relay mappings
• VLSM implementation
• SVIs
• HUBs Swtiches and Routers comparison
• Configure IOS to be a Frame Switch
• EIGRP offset lists
• Multicast GET VPN
• Context Based Access Control
• Zone Based Firewalls
• Dot1q Trunking
• ARP cache tutorial

and more…

You can view them using this link here on YouTube

You may also use this link:  http://www.youtube.com/user/Keith6783

If you want to look further into learning, we offer a full suite of self-paced workbooks, videos, and interactive learning tools.

Best wishes, and happy studies-

Keith

As I mentioned in a blog article a few months back, INE installed 7961 phones in all of our Voice Racks used for customer rental, and simultaneously struck up an exclusive deal with the company called VoIP Integration so that our students could buy their fantastic Remote Phone Control Software at quite a significant discount. More students than I ever imagined would, have contacted me and received the INE Student Edition of this software for use during their studying sessions. In fact, many that already have phones of their own, bought the software just so that they could travel and stil practice labs – while on the road – with their phones and without having to pack up and take their phones with them.

This is the very tool we use during all of the live online and recorded CCIE Voice Deep Dive’s to show you exactly what is happening in real-time on the actual phones (which happen to be in front of me so that you can hear what is going on as well) for any given task we are all working through configuring or testing & troubleshooting.

Well, now VoIP Integration has updated their Remote Phone software to version 2.1 and brought quite a significant update in features. Standing out clearly in front of all of them – even in front of the great performance improvements – is support for IP Phones registered to Cisco Unified Communications Manager Express and IOS CME as SRST!

I have provided the basic configuration here that you would need to support them in CME.  Important NOTE: Don’t forget the “type” command on your ephone. Without it, CME doesn’t actually build the CNF files for that phone, and while they will register using the Default.cnf.xml file, that file doesn’t contain the necessary Authentication URL.

!
ip http server
no ip http secure-server
ip http path flash:gui
!
ixi transport http
 response size 4
 no shutdown
 request outstanding 1
!
ixi application cme
 no shutdown
!
telephony-service
 max-ephones 1
 max-dn 1
 ip source-address 177.1.254.3 port 2000
 url authentication http://177.1.254.3/CCMCIP/authenticate.asp admin cciecisco
 log password cciecisco
 create cnf-files
!
!
ephone-dn  1 dual-line
 number 3001
!
!
ephone  1
 mac-address 001B.5452.D7BD
 type 7961
 button  1:1
!

Download it and give it a spin, and read more about the support (found in Appendix C) of their latest Administration Guide.

Also, If you would care to purchase a copy of INE’s Student Edition of the VoIP Integration Remote Control software, please ping me at msnow at ine dot com.

It isn’t my fault, they configured it that way before I got here! That was the entry level technician’s story Monday morning, and he was sticking to it. 

Here is the rest of the story.   Over the weekend, some testing had been done regarding a proposed BGP configuration.   The objective was simple, R1 and R3 needed to ping each others loobacks at 1.1.1.1 and 3.3.3.3 respectively, with those 2 networks, being carried by BGP.  R2 is performing NAT.    The topology diagram looks like this:

The ping between loopbacks didn’t work, but R1 and R3 had these console messages:

R1#
%TCP-6-BADAUTH: No MD5 digest from 10.0.0.3(179) to 10.0.0.1(28556) (RST)
R1#
%TCP-6-BADAUTH: No MD5 digest from 10.0.0.3(179) to 10.0.0.1(28556) (RST)
R1#

R3#
%TCP-6-BADAUTH: No MD5 digest from 23.0.0.1(179) to 23.0.0.3(59922) (RST)
R3#
%TCP-6-BADAUTH: No MD5 digest from 23.0.0.1(179) to 23.0.0.3(59922) (RST)
R3#

The senior engineer looked at the configurations for R1, R2 and R3 and found 5 specific items, each of which was independently causing a failure.

Here is the challenge:  Can you find 1 or more of them?

Let us know what your troubleshooting skills can find, and post your comments here on the blog.

Here are the configurations for the 3 routers:

R1#show run
version 12.4
hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
!
router ospf 1
 network 10.0.0.0 0.0.0.255 area 0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.0.0.3 remote-as 3
 neighbor 10.0.0.3 password cisco
 no auto-summary
!
end
R1#

R2#show run
version 12.4
hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
interface FastEthernet0/1
 ip address 23.0.0.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 10.0.0.2 0.0.0.0 area 0
 network 23.0.0.2 0.0.0.0 area 0
!
ip nat inside source static 10.0.0.1 23.0.0.1
ip nat outside source static 23.0.0.3 10.0.0.3
!
end

R3#show run
version 12.4
hostname R3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
!
interface FastEthernet0/1
 ip address 23.0.0.3 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 23.0.0.0 0.0.0.255 area 0
!
router bgp 3
 no synchronization
 bgp log-neighbor-changes
 network 3.3.3.3 mask 255.255.255.255
 neighbor 23.0.0.1 remote-as 1
 neighbor 23.0.0.1 password cisco123
 no auto-summary
!
end
R3#

Let us know what you find!

Best wishes,

Keith

UPDATE:   ANSWERS

Your contributions and input is great.  You ROCK!

I have summarized the 5 specific errors/issues with the configuration, and here they are:

• R2: NAT isn’t fully baked. Can fix with  “ip nat outside source static 23.0.0.3 10.0.0.3 add-route” (or we could manually add the route as well).
• R1 & R3: The BGP passwords don’t match, but it doesn’t matter. BGP authentication doesn’t work between NAT’d BGP neighbors, so it would have to be removed.
• R1 & R3: Incorrect network statements for loopback addresses on both BGP routers (incorrect mask)
• R1 & R3: Ebgp-multihop statements are needed on both neighbors (not directly connected EBGP)
• R2: R2 doesn’t know how to reach 1.1.1.1 or 3.3.3.3 (non-BGP routing issue)

Again, thanks for the time and effort invested in this solution, and in learning in general.   I appreciate you!

Best wishes,

Keith

Question #1

Can anyone please advise what is the recommended laptop hardware configuration for CCIE R&S Lab prep. I have read many blogs, posts and advices but unable to figure out the appropriate answer. While advising,please consider the GNS3 is the only option I have.
Many thanks in advance,
Asif Irfan

If you are looking for an appropriate hardware to run complete IEWB-RS topology (6 routers, 4 switches, 3 backbone routers) than your minimum would be Core 2 Duo 2,5Ghz with 2 Gb of RAM. That the bare minimum, and you should look toward expanding memory at least to 3-4Gb to have more room for other applications (if you have any). The largest benefit of this solution is it’s low cost, as Core 2 Duo processors are now “past generation”. If you could, you may get two Core 2 Duo laptops, each with 2Gb of RAM and run Dynamips on both systems in distributed fashion. This is still a budget solution.

If you are not restrictred by your budget, look for quad-core processors, such as I7 and memory base of at least 4Gb. This is enough to run the whole IEWB-RS topology, provided that you are using optimal IdlePC values.

Here are some hints to improve Dynamips performace (aside from tuning IdlePC)

1) Shutdown all currently unused routers, e.g. backbones, if you are working through IGP. Only bring them up for testing temporarily.
2) When you’re done with layer 2 scenarios, reconfigure your switched in a hub-and-spoke topology (start) say with SW1 being the center switch. After this, disable STP for all VLANs. This will save you a lot of CPU cycles “wasted” on Spanning-Tree processing.
3) Linke I said before, try using distributed systems, running dynamips on multiple “less powerfule” laptops.

Answered by: Petr Lapukhov CCIE #16379

Question #2

Hi,
I would like to know the difference between maximum-path ibgp and maximum-path ibgp import command under a address-family.
Thanks
naman

Hello Naman.

Both commands are used for equal or unequal cost load sharing for iBGP sessions.

The import keyword is used when you are configuring the command under a VRF. Here are examples of usage from the Cisco Command Reference.

The following example configuration installs three parallel iBGP paths in a non-MPLS topology:
Router(config)# router bgp 100
Router(config-router)# maximum-paths ibgp 3

The following example configuration installs two parallel routes in the VRF table:
Router(config)# router bgp 100
Router(config-router)# address-family ipv4 vrf vrf-B
Router(config-router-af)# maximum-paths ibgp 2 import 2
Router(config-router-af)# end

Thanks so much for using blog.ine.com!

Answered by: Anthony Sequeira CCIE #15626

Question #3

Dear Valuable Technical Teachers and Friends,

First of all , i wish and thank you for your great support to those who are
all preparing Network studies. I’ve completed my CCNA two years back.Now am
preparing for next step. At this point, i have bit confusion of deciding
whether can i do CCNP or CCIE(R&S). I would like to reach a top level in
Cisco Networking technology.So am requesting your suggestions, which is best
for me.

Also can you suggest any good simulators to improve my practical skills.

–
Thanks,
K.Saleem Jaffer

Thanks for the question.   Having the CCIE certification makes for an excellent stepping stone in a technical career.   An important aspect to successfully passing the CCIE lab exam, is a very solid understanding of all the technologies involved.    A great way to prepare for this is through the CCNP level of studies.   If a person chooses that path, they would do well to take time to learn the technologies while studying CCNP, and not have the feeling of just learning enough to pass a CCNP written exam.  By truly  learning the core technologies in CCNP, it will serve as a springboard into the CCIE studies.   Many candidates waste large amounts of time in complex configurations, because they are lacking the basic understanding of the protocols and technologies that make up the scenario.    I would recommend a 1-2 yr plan, that begins with CCNP, carries into CCIE studies, and end with you attaining your CCIE.    Best wishes in your studies and journey.

Keith Barker CCIE #6783

Comment:

INE,

I absolutely love your version 4 COD videos for the R&S track. I love them
so much that I am dying to get more. When do you believe the videos will
get posted. Been stuck at EIGRP for over 2 weeks now. Would like to see
these added at a quicker pace.

My current study plan is to read about a technology, watch the videos for
that technology and then do the volume 1 labs for that technology. This is
working very well for me and want to continue without having to watch
previous versions of the COD.

The reason I like the version 4 COD classes is they seem more scripted. I
am watching the MPLS videos from the 10 day bootcamp and I see the
instructor looking around for the right command to show something. I find
this confusing and distracting from learning the material. The scriptedness
and complete mastery of what we are doing and what you are trying to show in
version 4 is great and want more of it.

Also, from a technology viewpoint I find it much easier to pause the v4
videos and write down the configurations or configure the dynamips session I
am using to follow along, than with the v3 technology. The v4 seems like it
downloads the entire video and you can pause, move forwards and backwards
and the screen doesn’t “refresh”. The v3 technology blanks the screen and
then kind of fastforwards the screen for a little bit while the audio is
normal pace when you move around. Another reason I want more v4!

Also, one tiny suggestion. I like being able to forecast how much time I
need to spend watching the vidoes. I don’t see any time counter on the v4
or listing of how long the video is. Would love to see a time value in
parentheses after the title of each video to be able to know how much time
to allot to each video.

Keep up the good work, my CCIE journey would be perilous without you guys.

Thanks,

Thomas Holincheck

Keep submitting your questions and comments!

In this post, we will address the RIP process level timers for update, invalid, hold down and flush. I don’t want you to sleep during this, so we will save that one for later.

Timers Basic, all in seconds:
Update: how often to send updates in seconds
Invalid: how many seconds, since seeing a valid update, to consider the route invalid, and placing the route into hold down
Hold Down: Once in hold down, how long (in seconds) to “not believe” any equal or less impressive (worse) route updates for routes that are in hold down
Flush: how many seconds, since the last valid update, until we throw that route in the trash (garbage collection for un-loved non-updated routes)

Here is our topology.  Keep your attention on R2, and that will be the focal point for this lesson.

Let’s set up some unique values, so we can see the results.
Defaults are:

Update: 30
Invalid: 180
Hold Down: 180
Flush: 240

We will use 30,  40, 10 and 90 respectively.

R2(config)#router rip
R2(config-router)#timers basic 30 40 10 90

We can see the results of our changes with show ip protocols.

R2#show ip protocols
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 23 seconds
  Invalid after 40 seconds, hold down 10, flushed after 90
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    FastEthernet0/1       2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.23.0.3            120      00:00:03
  Distance: (default is 120)

We can see that R2 is learning 2 routes from R3, the 10.33.0.0/24 and 10.77.0.0/24 R2 received the last update 7 seconds ago, based on the output.

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 4 subnets
C       10.12.0.0 is directly connected, FastEthernet0/1
C       10.23.0.0 is directly connected, FastEthernet0/0
R       10.34.0.0 [120/1] via 10.23.0.3, 00:00:07, FastEthernet0/0
R       10.77.0.0 [120/8] via 10.23.0.3, 00:00:07, FastEthernet0/0

Let’s enable debugging so we can see the play by play.

R2#debug ip routing
IP routing debugging is on
R2#debug ip rip
RIP protocol debugging is on

Here is an update from R3. Notice the time stamp of 1:24:23. This will be the last one sent from R3. (Because we’ll configure R3 to go passive in a moment). Also, notice that we are sending and update as well. An update schedule of 30 seconds, based on the RFC for RIP, may be 30 seconds, + or – 5 seconds, to avoid synchronization. Let’s focus on the learned 10.77.0.0 network with a hop count of 8.

R2#
01:24:23: RIP: received v2 update from 10.23.0.3 on FastEthernet0/0
01:24:23:      10.34.0.0/24 via 0.0.0.0 in 1 hops
01:24:23:      10.77.0.0/24 via 0.0.0.0 in 8 hops
R2#
01:24:24: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:24:24: RIP: build update entries
01:24:24:       10.23.0.0/24 via 0.0.0.0, metric 1, tag 0
01:24:24:       10.34.0.0/24 via 0.0.0.0, metric 2, tag 0
01:24:24:       10.77.0.0/24 via 0.0.0.0, metric 9, tag 0
R2#
01:24:27: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:24:27: RIP: build update entries
01:24:27:       10.12.0.0/24 via 0.0.0.0, metric 1, tag 0

After the update from R3, learned on Fa0/0, I used the passive-interface default command on R3 inside of the router rip process.   While we wait for the invalid time to occur, due to the missing routes, we can entertain ourselves by seeing  updates being sent from R2, at 30 second intervals.

R2#
01:24:53: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:24:53: RIP: build update entries
01:24:53:       10.23.0.0/24 via 0.0.0.0, metric 1, tag 0
01:24:53:       10.34.0.0/24 via 0.0.0.0, metric 2, tag 0
01:24:53:       10.77.0.0/24 via 0.0.0.0, metric 9, tag 0
R2#
01:24:56: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:24:56: RIP: build update entries
01:24:56:       10.12.0.0/24 via 0.0.0.0, metric 1, tag 0

It has been 40 seconds since the last updates from R3, and 40 seconds was our invalid timer setting. (Our last update was 1:24:23, and now it is 1:25:03). The routes enter hold down, which means the router will not believe any new updates regarding these routes. Hold down is intended to assist in avoiding inaccurate routing by rumor information while the network converges. The exception would be if a route with a better (lower) metric was received by R2  for the 10.77.0.0, R2 would use it. (In our example, 10.77.0.0 had a metric of 8. If R2 learned about the 10.77.0.0 with a metric of 7 or lower from a neighbor, it would use it if learned during the hold down.)

R2#
01:25:03: RT: delete route to 10.34.0.0 via 10.23.0.3, rip metric [120/1]
01:25:03: RT: no routes to 10.34.0.0, entering holddown
01:25:03: RT: NET-RED 10.34.0.0/24
01:25:03: RT: delete route to 10.77.0.0 via 10.23.0.3, rip metric [120/8]
01:25:03: RT: no routes to 10.77.0.0, entering holddown
01:25:03: RT: NET-RED 10.77.0.0/24

R2 advertises a poisoned route for the networks in hold down. This is a triggered update, and not based on the normal 30 second update timer.

R2#
01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:25:05: RIP: build flash update entries
01:25:05:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:05:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:25:05: RIP: build flash update entries
01:25:05:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:06:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0

R1, sends us a poison-reverse update, regarding the same networks. This intentionally overrides the split horizon rule which is in place on Ethernet interfaces by default.

R2#
01:25:08: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1
01:25:08:      10.34.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
01:25:08:      10.77.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
R2#
01:25:10: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1
01:25:10:      10.34.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
01:25:10:      10.77.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)

Another normal update, being sent by R2, including the poisoned routes.

R2#
01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:25:22: RIP: build update entries
01:25:22:       10.23.0.0/24 via 0.0.0.0, metric 1, tag 0
01:25:22:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:22:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:25:22: RIP: build update entries
01:25:22:       10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
01:25:22:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:22:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0

While the routes are in hold down, the router still forwards packets to those networks, based on the last information that it last learned about how to reach those networks. The routes will show up as “possibly down”.

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 4 subnets
C       10.12.0.0 is directly connected, FastEthernet0/1
C       10.23.0.0 is directly connected, FastEthernet0/0
R       10.34.0.0/24 is possibly down,
          routing via 10.23.0.3, FastEthernet0/0
R       10.77.0.0/24 is possibly down,
          routing via 10.23.0.3, FastEthernet0/0

So were is the removal of the hold down. The timer was only 10 seconds? Better late than never. Even though the hold down timer was set to 10 seconds, the hold down timer has to expire and then the next poisoned route received causes the routes to be removed from hold down. Our routes went into hold down at 25:03, it is now 25:36. Regardless of the hold down timer setting, if we didn’t receive any poisoned updates from neighbors, the hold down would stay until the flush timer removes the route completely.

R2#
01:25:36: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1
01:25:36:      10.34.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
01:25:36: RT: 10.34.0.0 came out of holddown
01:25:36:      10.77.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
01:25:36: RT: 10.77.0.0 came out of holddown

Even though the routes are done with their hold down, R2 still will show the route as possibly down, and will continue to do so until the flush timer expires.

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 4 subnets
C       10.12.0.0 is directly connected, FastEthernet0/1
C       10.23.0.0 is directly connected, FastEthernet0/0
R       10.34.0.0/24 is possibly down,
          routing via 10.23.0.3, FastEthernet0/0
R       10.77.0.0/24 is possibly down,
          routing via 10.23.0.3, FastEthernet0/0

Another update clicks off, and then we approach the 90 second flush timer

R2#
01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:25:49: RIP: build update entries
01:25:49:       10.23.0.0/24 via 0.0.0.0, metric 1, tag 0
01:25:49:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:49:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:25:49: RIP: build update entries
01:25:49:       10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
01:25:49:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:49:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0

Based on the last valid update of 1:24:23, and now that it is 1:25:53, 90 seconds are up (flush timer) and the routes are deleted.

R2#
01:25:53: RT: delete subnet route to 10.34.0.0/24
01:25:53: RT: NET-RED 10.34.0.0/24
01:25:53: RT: delete subnet route to 10.77.0.0/24
01:25:53: RT: NET-RED 10.77.0.0/24

Now the routes don’t show up in the routing table either.

R2# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 2 subnets
C       10.12.0.0 is directly connected, FastEthernet0/1
C       10.23.0.0 is directly connected, FastEthernet0/0

If we use context sensitive help, we find one more parameter for the timers:

R2(config-router)#timers basic 30 40 10 90 ?

<1-4294967295>  Sleep time, in milliseconds

And we’ll save that one for another blog.

Best wishes,

Keith

Bookmark the vSeminar page now: http://www.ine.com/free-ccie-vseminar.htm.

Reader’s Digest version: MPLS networks aren’t free. If a customers is using OSPF to peer between the CE and PE routers, and also has an OSPF CE to CE neighborship, the CE’s will prefer the Intra-Area CE to CE routes (sometimes called the “backdoor” route in this situation), instead of using the Inter-Area CE to PE learned routes that use the MPLS network as a transit path. OSPF sham-links correct this behavior.

This blog post walks through the problem and the solution, including the configuration steps to create and verify a sham-link.

To begin, MPLS is set up in the network as shown with R2 and R4 acting as Provider Edge (PE) routers, and MPLS is enabled throughout R2-R3-R4.

R1 and R5 are Customer Edge (CE) routers, and the Serial0/1.15 interfaces of R1 and R5 are temporarily shut down, (this means the backdoor route isn’t in place yet, and at the moment, there is no problem).

Currently, R1 and R5 see the routes to each others local networks through the VPNv4 MPLS network, and the routes show up as Inter-Area OSPF routes with the PE routers as the next hop.

Let’s do some testing and verification of what is currently in place. Notice that R1 and R5 can see each others Fa0/0 and Fa0/1 connected networks. These routes show up as Inter-Area (IA) routes.

R1#show ip route ospf
10.0.0.0/24 is subnetted, 2 subnets
O IA    10.45.0.0 [110/2] via 10.12.0.2, 00:00:58, FastEthernet0/0
O IA 192.168.1.0/24 [110/3] via 10.12.0.2, 00:00:43, FastEthernet0/0

R5#show ip route ospf
172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.0.0 [110/3] via 10.45.0.4, 00:01:49, FastEthernet0/1
10.0.0.0/24 is subnetted, 2 subnets
O IA    10.12.0.0 [110/2] via 10.45.0.4, 00:01:49, FastEthernet0/1

Next, we will enable the Serial0/1.15 interfaces of R1 and R5. When we enable these interfaces, R1 and R5 will become neighbors, and see each others routes to the Fa0/0 and Fa0/1 networks as Intra-Area routes. Even though the OSPF cost will be worse via the serial interfaces, take a close look at what happens and which routes end up in the routing table.

R1(config)#int ser 0/1.15
R1(config-subif)#no shut

R5(config)#int ser 0/1.15
R5(config-subif)#no shut

We’ll wait a few moments, to give the network  time to converge, then take a look at the OSPF routes on the CE routers R1 and R5, just as we did earlier, and see if the routes are different.

R1#show ip route ospf
10.0.0.0/24 is subnetted, 3 subnets
O       10.45.0.0 [110/65] via 10.15.0.5, 00:02:52, Serial0/1.15
O    192.168.1.0/24 [110/65] via 10.15.0.5, 00:02:52, Serial0/1.15

R5#show ip route ospf
172.16.0.0/24 is subnetted, 1 subnets
O       172.16.0.0 [110/65] via 10.15.0.1, 00:03:19, Serial0/1.15
10.0.0.0/24 is subnetted, 3 subnets
O       10.12.0.0 [110/65] via 10.15.0.1, 00:03:19, Serial0/1.15

Notice, that the remote customer networks attached to Fa0/0 and Fa0/1 are now reachable via the serial 0/1.15 interface, and they appear as Intra-Area routes. Even though the metric of 65 is worse than before, and using the slower serial link, the routers prefer these routes instead of using the PE learned routes, because Intra-Area routes are preferred over  Inter-Area routes. Now the Service Provider’s MPLS network will only be used as a backup in the event the serial connection fails. (I don’t think they will be providing a price break either).

To train the network to use the MPLS network as the primary transit path, we need to make the remote Ethernet customer networks look like Intra-Area routes via the PE routers, with a better metric than the serial interfaces, so they can be used instead of the slower serial link. We are actually going to pull a fast one, or a “sham”, on OSPF because the MPLS network is really acting as a “superbackbone” for OSPF, and therefore routes between the CEs are indeed Inter-Area by default. To create the illusion of the CEs not being separated by a backbone, we will create an OSPF sham-link. We will create a couple loopback interfaces in the VRFs on both PEs, and make sure those loopbacks are originated and advertised via BGP. We will use those loopbacks as the source/destination of the OSPF sham-link.

Because the sham-link is seen as an Intra-Area link between PE routers (R2 and R4), an OSPF adjacency is created and database exchange takes place across the sham-link. The two PE routers can then flood LSAs between sites from across the MPLS VPN backbone. As a result, the desired Intra-Area routes are created.

Enough chat, lets create this sham-link!

R2(config)#int loop 100
R2(config-if)#ip vrf forwarding Vrf1
R2(config-if)#ip address 11.11.11.2 255.255.255.255
R2(config-if)#router bgp 24
R2(config-router)#address-family ipv4 vrf Vrf1
R2(config-router-af)#network 11.11.11.2 mask 255.255.255.255
R2(config-router-af)#exit
R2(config-router)#router ospf 1 vrf Vrf1
R2(config-router)#area 1 sham-link 11.11.11.2 11.11.11.4 cost 5

R4(config)#int loop 100
R4(config-if)#ip vrf forwarding Vrf1
R4(config-if)#ip address 11.11.11.4 255.255.255.255
R4(config-if)#router bgp 24
R4(config-router)#address-family ipv4 vrf Vrf1
R4(config-router-af)#network 11.11.11.4 mask 255.255.255.255
R4(config-router-af)#exit
R4(config-router)#router ospf 1 vrf Vrf1
R4(config-router)#area 1 sham-link 11.11.11.4 11.11.11.2 cost 5
%OSPF-5-ADJCHG: Process 1, Nbr 10.12.0.2 on OSPF_SL0 from LOADING to FULL, Loading Done

Looks like the sham-link came up.  Let’s take a closer look at the sham link with a show command made just for that purpose.

R4#show ip ospf sham-links
Sham Link OSPF_SL0 to address 11.11.11.2 is up
Area 1 source address 11.11.11.4
Run as demand circuit
DoNotAge LSA allowed. Cost of using 5 State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40,
Hello due in 00:00:06
Adjacency State FULL (Hello suppressed)
Index 2/2, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec

Looks like it is in place, but is it creating the desired result, of having the CE routers R1 and R5 see the Ethernet remote networks as reachable through the PE routers R2 and R4? Let’s go to R1 and see!

R1#show ip route ospf
10.0.0.0/24 is subnetted, 3 subnets
O       10.45.0.0 [110/7] via 10.12.0.2, 00:06:02, FastEthernet0/0
11.0.0.0/32 is subnetted, 2 subnets
O E2    11.11.11.2 [110/1] via 10.12.0.2, 00:06:43, FastEthernet0/0
O E2    11.11.11.4 [110/1] via 10.12.0.2, 00:06:13, FastEthernet0/0
O    192.168.1.0/24 [110/8] via 10.12.0.2, 00:06:02, FastEthernet0/0

That looks perfect! How about R5?

R5#show ip route ospf
172.16.0.0/24 is subnetted, 1 subnets
O       172.16.0.0 [110/8] via 10.45.0.4, 00:06:27, FastEthernet0/1
10.0.0.0/24 is subnetted, 3 subnets
O       10.12.0.0 [110/7] via 10.45.0.4, 00:06:27, FastEthernet0/1
11.0.0.0/32 is subnetted, 2 subnets
O E2    11.11.11.2 [110/1] via 10.45.0.4, 00:07:05, FastEthernet0/1
O E2    11.11.11.4 [110/1] via 10.45.0.4, 00:06:45, FastEthernet0/1

And just to be sure, a ping to verify connectivity. We will ping the remote Fa0/1 interface of CE router R1 from CE router R5.

R5#ping 172.16.0.1

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

That’s cool, so we know we have connectivity, and based on the routing table output, we believe it is going through the SP MPLS network. Let’s do one more test to prove that as well. A traceroute.

R5#trace 172.16.0.1

Type escape sequence to abort.
Tracing the route to 172.16.0.1

1 10.45.0.4 48 msec 92 msec 12 msec
2 10.34.0.3 [MPLS: Labels 16/24 Exp 0] 136 msec 180 msec 228 msec
3 10.12.0.2 [MPLS: Label 24 Exp 0] 124 msec 80 msec 88 msec
4 10.12.0.1 112 msec *  176 msec

Tags and all!  I still love it when a plan comes together.   Now our transit traffic is moving through the MPLS network, and the serial 0/1.15 interfaces are available as a backup.

More fun times regarding MPLS, OSPF and MPBGP can be found in our workbooks for RS and SP.

Best wishes, and enjoy the journey!

Keith

A student from a past Reno class, named Michal, asked if I would create a blog post regarding BGP proportional load balancing based on the bandwidth of the links to EBGP peers. It has been on my list of things to do, and here it is. Thanks for the request Michal.

The secret to this trick is to pay attention to the links between directly connected external BGP neighbors, (in this case between R6-R5 and R2-R3), and send the link bandwidth extended community attribute to iBGP peer R1.  It is enabled by entering the bgp dmzlink-bw command and using extended communities to share the information.  To summarize: routes learned from directly connected external neighbor are advertised to IBGP peers including the bandwidth of the external link where the routes were learned, and then the IBGP router (R1) can proportionally load balance between the two paths.

Here is the diagram we will use.

We’ll use loobpacks for our IBGP connections, so let’s verify that we have connectivity between loopbacks in AS 123.

R1#ping 6.6.6.6 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/43/76 ms
R1#
R1#ping 2.2.2.2 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/40/72 ms

Ok, that looks good, so let’s configure R1 to be an IBGP peer with R6 and R2.  The dmzlink-bw feature is implemented as part of the IPv4 address family configuration.

R1(config)#router bgp 126
R1(config-router)#neighbor 6.6.6.6 remote-as 126
R1(config-router)#neighbor 2.2.2.2 remote-as 126
R1(config-router)#neighbor 6.6.6.6 update-source lo0
R1(config-router)#neighbor 2.2.2.2 update-source lo0

R1(config-router)#address-family ipv4
R1(config-router-af)#bgp dmzlink-bw
R1(config-router-af)#neighbor 6.6.6.6 activate
R1(config-router-af)#neighbor 2.2.2.2 activate
R1(config-router-af)#neighbor 6.6.6.6 send-community both
R1(config-router-af)#neighbor 2.2.2.2 send-community both
R1(config-router-af)#maximum-paths ibgp 2
R1(config-router-af)#end

Next, we will configure R6, and R2 to be IBGP neighbors with R1, and EBGP neighbors with R5 and R3 respectively. We are going to manipulate the external interfaces on R6 and R2 to reflect a bandwidth of 6000k and 5000k respectively using the bandwidth command.  BGP can originate the link bandwidth community only for directly connected links to eBGP neighbors.  In our example, this will be originated from R6 and R2.

R6(config)#router bgp 126
R6(config-router)#neighbor 1.1.1.1 remote-as 126
R6(config-router)#neighbor 1.1.1.1 update-source lo0
R6(config-router)#neighbor 10.56.0.5 remote-as 345
R6(config-router)#address-family ipv4
R6(config-router-af)#bgp dmzlink-bw
R6(config-router-af)#neighbor 1.1.1.1 activate
R6(config-router-af)#neighbor 1.1.1.1 next-hop-self
R6(config-router-af)#neighbor 1.1.1.1 send-community both
R6(config-router-af)#neighbor 10.56.0.5 activate
R6(config-router-af)#neighbor 10.56.0.5 dmzlink-bw
R6(config-router-af)#int fa 0/0
R6(config-if)#bandwidth 6000

Now, on to R2, with virtually the same configuration.

R2(config)#router bgp 126
R2(config-router)#neighbor 1.1.1.1 remote-as 126
R2(config-router)#neighbor 1.1.1.1 update-source lo0
R2(config-router)#neighbor 10.23.0.3 remote-as 345
R2(config-router)#address-family ipv4
R2(config-router-af)#bgp dmzlink-bw
R2(config-router-af)#neighbor 1.1.1.1 activate
R2(config-router-af)#neighbor 1.1.1.1 next-hop-self
R2(config-router-af)#neighbor 1.1.1.1 send-community both
R2(config-router-af)#neighbor 10.23.0.3 activate
R2(config-router-af)#neighbor 10.23.0.3 dmzlink-bw
R2(config-router-af)#int ser 0/1.23
R2(config-subif)#bandwidth 5000

Now we will configure R5 and R3 as the EBGP neighbors of R6 and R2 respectively.  These EBGP peers don’t need any special configuration, other than standard BGP.

R5(config)#router bgp 345
R5(config-router)#neighbor 10.56.0.6 remote-as 126
R5(config-router)#neighbor 4.4.4.4 remote-as 345
R5(config-router)#neighbor 4.4.4.4 update-source lo0
R5(config-router)#neighbor 4.4.4.4 next-hop-self

R3(config)#router bgp 345
R3(config-router)#neighbor 10.23.0.2 remote-as 126
R3(config-router)#neighbor 4.4.4.4 remote-as 345
R3(config-router)#neighbor 4.4.4.4 update-source lo0
R3(config-router)#neighbor 4.4.4.4 next-hop-self

Last, but not least we configure R4 as an IBGP peer to R5 and R3. In addition, we will create a loopback and add it into BGP.  We will use the loopack as a target destination from R1 to verify the load balancing in a later step, so watch for that coming up.

R4(config)#int loop 44
R4(config-if)#ip add 44.44.44.44 255.255.255.0
R4(config-if)#router bgp 345
R4(config-router)#neighbor 5.5.5.5 remote-as 345
R4(config-router)#neighbor 3.3.3.3 remote-as 345
R4(config-router)#network 44.44.44.0 mask 255.255.255.0

Now let’s verify. Because we are on R4, let’s verify the BGP neighborships it has.

R4#show ip bgp summary
BGP router identifier 44.44.44.44, local AS number 345
BGP table version is 2, main routing table version 2
1 network entries using 120 bytes of memory
1 path entries using 52 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
BGP using 452 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
3.3.3.3         4   345       4       5        2    0    0 00:00:41        0
5.5.5.5         4   345       4       5        2    0    0 00:00:35        0

! Note:  we can easily verify what routes are being advertised out from R4.

R4#show ip bgp neighbors 5.5.5.5 advertised-routes
BGP table version is 2, local router ID is 44.44.44.44
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
*> 44.44.44.0/24    0.0.0.0                  0         32768 i

Total number of prefixes 1
R4#show ip bgp neighbors 3.3.3.3 advertised-routes
BGP table version is 2, local router ID is 44.44.44.44
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
*> 44.44.44.0/24    0.0.0.0                  0         32768 i

Total number of prefixes 1
R4#

Looks like AS 345 is fine. Let’s jump to R1, in AS 126, and verify from there.

R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 126
BGP table version is 3, main routing table version 3
1 network entries using 120 bytes of memory
2 path entries using 104 bytes of memory
1 multipath network entries and 2 multipath paths
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 496 total bytes of memory
BGP activity 1/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4   126      10       9        3    0    0 00:06:39        1
6.6.6.6         4   126      11      10        3    0    0 00:07:14        1
R1#show ip bgp
BGP table version is 3, local router ID is 1.1.1.1
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
* i44.44.44.0/24    6.6.6.6                  0    100      0 345 i
*>i                 2.2.2.2                  0    100      0 345 i

! Note:  Looks like we have the neighbors, and the 44.44.44.0/24 prefix.
! To see more detail on the 44.44.44.0 network, we can use a couple additional commands.

R1#show ip bgp 44.44.44.0
BGP routing table entry for 44.44.44.0/24, version 3
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: iBGP
Flag: 0x820
  Not advertised to any peer
  345
    6.6.6.6 (metric 1) from 6.6.6.6 (6.6.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal, multipath
      DMZ-Link Bw 750 kbytes
  345
    2.2.2.2 (metric 1) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, multipath, best
      DMZ-Link Bw 625 kbytes

! Note: Let's see what the routing table has to say about this network.

R1#show ip route 44.44.44.0
Routing entry for 44.44.44.0/24
  Known via "bgp 126", distance 200, metric 0
  Tag 345, type internal
  Last update from 2.2.2.2 00:02:56 ago
  Routing Descriptor Blocks:
  * 6.6.6.6, from 6.6.6.6, 00:02:56 ago
      Route metric is 0, traffic share count is 6
      AS Hops 1
      Route tag 345
    2.2.2.2, from 2.2.2.2, 00:02:56 ago
      Route metric is 0, traffic share count is 5
      AS Hops 1
      Route tag 345

! Note: We can also get the information from the CEF table.

R1#show ip cef 44.44.44.0
44.44.44.0/24, version 47, epoch 0, per-destination sharing
0 packets, 0 bytes
  via 6.6.6.6, 0 dependencies, recursive
    traffic share 6
    next hop 10.16.0.6, FastEthernet0/1 via 6.6.6.0/24
    valid adjacency
  via 2.2.2.2, 0 dependencies, recursive
    traffic share 5
    next hop 10.12.0.2, FastEthernet0/0 via 2.2.2.0/24
    valid adjacency
  0 packets, 0 bytes switched through the prefix
  tmstats: external 0 packets, 0 bytes
           internal 0 packets, 0 bytes

So now that the route is there, how do we test the load balancing? One option is to do an extended ping, and record the path. We are expecting a 6 to 5 ratio for outbound traffic favoring the R6 path more than the R2 path. Let’s send 30 ping requests, and show the full response for the benefit of verification.

R1#ping
Protocol [ip]:
Target IP address: 44.44.44.44
Repeat count [5]: 30
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: loopback0
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]: 4
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 30, 100-byte ICMP Echos to 44.44.44.44, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
Packet has IP options:  Total option bytes= 19, padded length=20
 Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)

Reply to request 0 (204 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 1 (156 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

! Note: the path changes on the next ping request, and begins to use R6 as the next hop.

Reply to request 2 (160 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 3 (128 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 4 (156 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 5 (172 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 6 (108 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 7 (136 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 8 (180 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 9 (152 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 10 (80 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 11 (308 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 12 (204 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 13 (108 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 14 (160 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 15 (140 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 16 (140 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 17 (104 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 18 (84 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 19 (192 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 20 (232 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 21 (220 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 22 (168 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 23 (140 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.12.0.1)
   (10.23.0.2)
   (10.34.0.3)
   (44.44.44.44)
   <*>
 End of list

Reply to request 24 (88 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 25 (224 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 26 (484 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 27 (128 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 28 (108 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Reply to request 29 (136 ms).  Received packet has options
 Total option bytes= 20, padded length=20
 Record route:
   (10.16.0.1)
   (10.56.0.6)
   (10.45.0.5)
   (44.44.44.44)
   <*>
 End of list

Success rate is 100 percent (30/30), round-trip min/avg/max = 80/166/484 ms
R1#

The first 2 requests, numbered 0-1, used the path of R2-R3-R4. The next 6 requests, numbered 2-7, used the path of R6-R5-r4. The next 5, numbered 8-12, use the R2-R3-R4 path again, and then the next 6 use the R6-R5-R4 path.

Happy studies-

Keith

You may want to visit the 2 previous posts on IPv6 multicast using static RPs using this link, or BSR mapped RPs using this link.

Here is the topology we are using, which matches the one from the previous posts:

To facilitate the embedding of an RP address int the multicast group address, there are some rules to follow. These are listed in RFC 3956.
First of all, to indicate that a multicast group contains an embedded RP in it, bits 9, 10, 11 and 12, from the left, need to be 0111. Because the first 8 bits are all 1s, an embedded RP multicast address would always begin with FF70::/12 or 1111 1111 0111

To determine an embedded RP from a multicast group address, we include an example from RFC 3956.
“The network administrator of 2001:DB8::/32 wants to set up an RP for the network and all the customers, by placing it on an existing subnet, e.g., 2001:DB8:BEEF:FEED::/64.

In that case, the group addresses would be something like “FF7x:y40:2001:DB8:BEEF:FEED::/96″, and then their RP address would be “2001:DB8:BEEF:FEED::y”. There are still 32 bits of multicast group-ids to assign to customers and self (”y” could be anything from 1 to F, as 0 must not be used).”

In our lab example, if we wanted R6 to be an RP, using 2002:6666::6 as the RP address, we could reverse engineer a multicast group to be FF7x:y40:2002:6666::1 (x=scope), or FF7e:640:2002:6666::1. The only configuration that would need to be done is to hard code R6 locally, to tell it that it is a RP, and then all the other routers would extract the RP from the multicast group address.

Here is the breakdown to determine the RP address from the group FF7e:0640:2002:6666::1
This example includes the roles of all 128 bits in the IPv6 embedded RP address, which will assist in understanding it.

8 bits = Multicast (0xFF)
1111 1111

4 bits = Flags (0×7)
0111

4 bits = Scope (0xE)
1110

4 bits Reserved (0)
0000

4 bits RIID (RP Interface Identifier) (0×6)
0110

8 bits Prefix Length (0×40) decimal 64
0100 0000

64 bits Network Prefix (0×2002:6666:0:0)

32 bits group ID (0×0:1)

To determine the RP, is simple.
It is the value of the Network Prefix, with the RIID (4bits) tagged on at the end. Thats it.

Since the prefix length says it is 64 (0×40), we take those 64 bits as the high
order bits of the RP, and add the RIID (4bits) to the low order position, and we are done!

Our final RP address would then be 2002:6666:0:0::6, or 2002:6666::6

Let’s configure R6 locally first.

R6(config)#ipv6 pim rp-address 2002:6666::6
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

Next we will have R3 join that group, but before we do, let’s see if R3 knows of a RP for the group.   After we join the group, R3 will automagically know who the RP is.  (Not really magic, it just extracted the RP from the group address).

R3#show ipv6 pim group-map ff7e:640:2002:6666::1
IP PIM Group Mapping Table
(* indicates group mappings being used) 

FF00::/8*
    SM
    Info source: Default
    Uptime: 00:00:17, Groups: 0

R3(config)#int lo 0
R3(config-if)#ipv6 mld join-group ff7e:640:2002:6666::1
R3#show ipv6 pim group-map ff7e:640:2002:6666::1
IP PIM Group Mapping Table
(* indicates group mappings being used) 

FF7E:640:2002:6666::/96*
    SM, RP: 2002:6666::6
    RPF: Fa0/0,FE80::244:44FF:FE44:4444
    Info source: Embedded
    Uptime: 00:00:02, Groups: 1

Let’s take a look at R6,  who is the RP

R6#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF7E:640:2002:6666::1), 00:05:57/00:02:33, RP 2002:6666::6, flags: S
  Incoming interface: Tunnel2
  RPF nbr: 2002:6666::6
  Immediate Outgoing interface list:
    FastEthernet0/0, Forward, 00:05:57/00:02:33

Now we will generate some multicast traffic, destined for that group, from R5.

R5#   ping ff7e:640:2002:6666::1
Output Interface: fastethernet0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF7E:640:2002:6666::1, timeout is 2 seconds:
Packet sent with a source address of 2002:45::5

Reply to request 0 received from 2002:3333::3, 272 ms
Reply to request 1 received from 2002:3333::3, 64 ms
Reply to request 2 received from 2002:3333::3, 104 ms
Reply to request 3 received from 2002:3333::3, 80 ms
Reply to request 4 received from 2002:3333::3, 84 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/120/272 ms
5 multicast replies and 0 errors.
R5#

Looks like it worked.  While the ping requests are being sent via multicast to the group, the replies from R3 are unicast. Let’s take a peek at R4 who is in the transit path between R5 (the server) and the listener R3.

R4#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF7E:640:2002:6666::1), 00:05:35/00:02:56, RP 2002:6666::6, flags: S
  Incoming interface: FastEthernet0/1
  RPF nbr: FE80::255:55FF:FE55:5555
  Immediate Outgoing interface list:
    FastEthernet0/0, Forward, 00:05:35/00:02:56

(2002:45::5, FF7E:640:2002:6666::1), 00:02:32/00:00:56, flags: ST
  Incoming interface: FastEthernet0/1
  RPF nbr: FE80::255:55FF:FE55:5555
  Immediate Outgoing interface list:
    FastEthernet0/0, Forward, 00:02:32/00:02:56

 

R4#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used) 

FF7E:640:2002:6666::/96*
    SM, RP: 2002:6666::6
    RPF: Fa0/1,FE80::255:55FF:FE55:5555
    Info source: Embedded
    Uptime: 00:17:31, Groups: 1

For more information on embedded RP with IPv6 multicast, check out our workbooks as well as RFC3956.

Happy studies-

Keith.