Wednesday, February 12, 2014

The chronicle of success

I want to start with a simple but important statement [and i hope i am not sued for breaking the NDA]: If there is one thing i enjoyed from the lab [how can someone enjoy a CCIE lab?], that is the appearance of IPv6 in so many tasks! It's refreshing to see it being used in so many imaginative ways.


Anyway, this is my complete story...

24/Oct/2013 - The experiment
It all started on 24th of October 2013 as an experiment. Some days later i was looking for excuses and i managed to find three of those. So i created my own CCIE SP Checklist and i decided to keep track of my progress through it.

04/Nov/2013 - Written exam
On 4th of November 2013 i took the written exam and i passed with one week of studying. Then i decided to take a one month break, during which i would deal with the projects at work that would run the following months in order to free some time later on, prepare the lab environment at home, book the lab exam, and most importantly create a schedule to follow until the lab exam. At the same time i would need to fix various open matters.

12/Dec/2013 - Lab study starts
This is the day i officially started my lab preparation and i added a poll just to get the feeling from people about my upcoming challenge. I also created a countdown/readiness gadget on the right, which would help me keep track of the deadline and my progress towards it. At the same time i created a page with what i consider the trio of success. The target was set from the beginning: pass. My initial readiness score was 46,5%.

15/Dec/2013 - Lab week #1
This was actually a three days week. Due to matters at work, i didn't manage to start at the scheduled day. Nevertheless, after an exhausting 11 hour lab, my readiness score increased up to 48,9%.

22/Dec/2013 - Lab week #2
This was the first full week spent on studying. Although my readiness score went up only to 50,6%, i spent a lot of time on GNS3 configurations.

29/Dec/2013 - Lab week #3
I used the Christmas period as an advantage of having extra days off from work for studying. My readiness score saw a major increase up to 54,2%.

05/Jan/2014 - Lab week #4
This was the most intense week of my studying. I used every possible time available during holidays to speed up my progress and i managed to increase my readiness score to 60,6%.

12/Jan/2014 - Lab week #5
This week i finished my GNS3 labs and i started my rack rentals sessions. Readiness score increased up to 64,5%.

19/Jan/2014 - Lab week #6
This week i started my PEC Gold Labs and i spent a lot of time on reading about areas that i felt i needed to improve my knowledge. My readiness score increased slightly up to 67,8%.

26/Jan/2014 - Lab week #7
I finished all full scale labs on rack rentals and all scheduled Gold Lab sessions, making my readiness score increase up to 70,3%.

02/Feb/2014 - Lab week #8
This was a week that i used to focus on core topics that i needed to gain more practice. As a result my readiness score increased up to 74,0%.

07/Feb/2014 - Lab week #9
This was the last week of my lab preparation. I slowed down my daily study and i focused on topics that i needed to boost in order to get that 60% score. The last two days i updated (aesthetically) all my NTS pages, i created a pdf from all of these and i recorded the critical ones in my mp3 player.

08/Feb/2014 - Flight to Brussels
In the morning i took the flight to Brussels. I took my mp3 player with me and two books that i found the most useful during my preparation. I arrived at the hotel just for lunch and then i had a visit at Cisco offices and the surrounding area. I spent the evening hours mainly doing a review of my NTS.

09/Feb/2014 - Review day
I spent the whole day in reviewing and listening to my notes, with various GNS3 breaks in between just to get my head cleared. My readiness score reached 77,3%, which is the one i went with to take the lab exam.


10/Feb/2014 - Lab exam

06:00
Wake up time. I have a quick shower and then i go downstairs and take my breakfast.

07:45
Time to leave the hotel and visit the Cisco offices. Outside Cisco another 10 people are also waiting for the door to open. After 5 minutes we all enter the building, we get our guest stickers and we wait for the proctor.

08:10
The proctor arrives (running late) and guides us to the exam room. He gives some introductory instructions and then we sign for our presence and we get our seat.

08:22 - Lab starts
I login and the first picture of the topology is shocking! I think i am going to have a hard time with so many devices. Then i click on the instructions and i am double shocked! The list of tasks seems endless. I start reading and taking notes on the scrap paper. Initial instructions say to verify various things before doing anything else, but as i do so, i notice some things that don't agree. Then looking at the topology i realize that this is probably going to be fixed later on by some other tasks, so i ignore it [first risk that proved correct]. While i keep writing down notes based on the instructions, i feel that this will take for ever. Time is close to 9:00 and i am still taking notes, while opening putty connections to devices, applying some config defaults and fixing the annoying putty defaults [whoever though of that putty defaults must be a psycho!]. At 9:20 i decide to stop reading all the details on the instructions; just write down the task subject, the technologies involved and the task points. While connecting to the IOS-XR boxes, i start getting an annoying (MPP related) message, the same one every minute on all of them. I inform the proctor of this, but he insists that this should be considered as part of the exam [sure, if you give me admin access then i could probably fix it]. So i have to choose: either stop the console messages of a specific priority or live with that message till the end of the exam [i didn't even think of filtering it at that time]. I decide to let it continue, since i need to keep an eye on every log produced in realtime to speed up my verification while configuration happens. I also open a notepad window which i will use for creating the IPv4/IPv6 TCL scripts and for creating/copying/pasting the configurations [as it proved out later, the second usage ended up being minimal].

09:30
I have started the first tasks, which can be considered as the silliest [when can a task be silly?] ones ever met. I couldn't find any real purpose of having them in the lab (especially in the form i met them), besides of somehow spending the candidate's time and making it easier to fail from the start of the exam. The initial configuration of all the devices is quite full, which might make things easier for some people and harder for others [including me]. Then i start moving on to the core topics. I draw a quick diagram of the complete core topology and i use that as a base for my protocol interaction mappings which are to follow on next tasks. Now, this is getting more interesting [at last something good about the exam]. Nothing difficult here, besides many lines of configurations on many devices on each task. Copy-paste doesn't seem very helpful in many tasks, because IOS & IOS-XR have different configuration formats. Also many tasks are worded in such a way that copy-paste wouldn't really help you a lot (it's like they made the exam in such a way that you need to type different things on many different devices). A later task requires clarification from the proctor, but again his answer isn't helpful at all [and he keeps on smiling]. I proceed with my own understanding of the requirements, which although longer in completion time, it's safer in results. For every task i configure, i have enabled all possible loggings in order to get realtime verification (at least from control-plane perspective). That way i am skipping data-plane verification from some devices, especially in tasks that TCL scripts cannot help. If i get the control-plane verified (from logging plus a single cli command) in 2/3 of the devices including at least half the IOS-XR boxes, then i can proceed with the next task. After all, if the tasks are known to me, i don't expect any surprises. While i think i'm moving with a good pace, the proctor's voice arrives from the far left to tear down that thought [and that was a shock].

11:50 - Lab break & lunch 
The proctor informs us 10 minutes before the break that we should all go for lunch and we should save our configurations before leaving the room. I have completed almost half of the tasks (<50 in points) and now i'm getting really nervous [and that's a rarely appearing feeling]. Based on my previous CCIE experience, i should have been way ahead (>60) in progress before the break for lunch. I stop completing tasks sequentially and i decide to immediately change my tactic. I quickly scan all the remaining tasks, i find the ones that seem the least dependent on others and require configuration mostly on non-core devices (based on the technologies/devices referred) and i decide to proceed with them after i return from the lunch. I count the points given by these tasks and if i don't make any mistakes, then i increase by a good amount my chances of passing. During the lunch [with limited mood and appetite] i'm thinking of other ways to speed up my progress too, especially in regards to task verification.

12:20 - Lunch ends & lab continues
I have already marked some tasks that can be completed independently of the others (assuming core functionality works fine, which it does), so i start working on them. Most of them are completed very fast, since they involved only [only?] four devices each. The last one although completed, its verification doesn't seem to work. I try some other variations, still no positive result. I decide to have a glimpse in the documentation for any hints that i may be missing, but i cannot find the documentation link (although i didn't actually spend more than 30 seconds looking for it [no way i was going to ask the proctor again]). I return to my initial configuration [the one i knew i should work] and then i try another method of verification (by the means of extra configuration). This time it works. At the same time the initial verification works too, even after i remove the extra configuration. Bug or feature? [what a surprise!] What matters is that now i am quite close to passing the lab and these "easy" tasks were a nice boost.

14:45
I am two hours before the lab ends and i have some more unresolved tasks to complete. I need to choose whether to verify the already completed tasks (and secure the existing points) or go for the unresolved ones (and get extra points, adding also the risk to lose points). I choose the second option [risky?], because i feel quite sure about most of my configurations (based on the initial verifications) and i want to get as many points as possible (to be honest i was also a little bit bored [how can someone be bored in a CCIE exam?] to try to verify again everything from the beginning). I feel like being on the edge with the current points and i need to increase them further. So i take all of the unresolved tasks from the beginning. There are three to four technologies involved in every task, with some very imaginative scenarios combining all of them in two point-critical tasks. All the tasks seem quite similar in terms of functionality to be implemented, and after examining thoroughly the provided topologies, i find an intriguing [almost diabolic] trap in the last one [damn you labels!]. This is the first task met that i hadn't practiced on during my two months preparation. This by itself is a challenge and an inner force is telling me to try it [ok, cut the crap obi wan]. But i don't have enough time left and there are other tasks that must be completed too. First priority is passing the exam, then accepting the challenge. So i focus on the tasks that i know well, leaving the challenge for the end.

16:00
Almost one hour before the end, i am finally starting to smile [that's the feeling i like]. I completed a few more tasks, did a quick semi-verification on them, IOS-XR doesn't work as expected, but i don't care. I know my solution is the correct one and the proctors can blame the IOS-XR software for its buginess [or do they expect me to open an SR?]. And now it's challenge time! [someone must be kidding] I already know what needs to be done in terms of separate technologies, so i just need to combine all the involved technologies, think of the gotchas and proceed to the configuration. 20 minutes later i have finished my initial configuration, but the verification isn't successful. That seems even trickier than i first though [well, i asked for it]. Second try and i change only a small part of the configuration. Now i am getting something towards the correct behavior, but still the verification isn't fully successful. Ok, now i am anxious again [but i'm smiling from the inside]. There are only 15 minutes left and this is the only task i haven't managed to tackle or even come near to a solution. But i'm not going to give up. Third try and a crazy idea comes to my mind [which is a little bit worrying]. I'll try a completely new approach. I just need to be sure that it won't affect my existing "underground" configuration. I bring the windows from all core routers in front of everything else, logging is always enabled (from the beginning of the exam) and i start configuring like a mad typist trying to break the world record [i must apologize to all other candidates if my typing these last minutes was annoying]. At 16:40 the proctor warns us that we must start saving the configurations because the lab ends in 12 minutes. I keep on typing and i complete my configuration some seconds after the proctor informs us that we should start exiting the lab environment. No time to verify it, copy/paste "wr" on every router and i click on "end lab" before the proctor starts giving warnings [and yellow cards].

16:52 - Lab ends
I feel quite sure about all my answers, except the one i didn't manage to verify. I just don't know if somehow later on (especially with the last task) i broke something that i had configured correctly in the beginning. This is a risk i took, but i don't know if i would do that again [no way i would do that again]. I didn't have time to double verify anything, so i trusted my initial semi-verification while completing each task. The lab structure is quite different from the R&S, because in most tasks you're asked to build blocks on top of other blocks and so on. So if something breaks in the initial tasks because of a change you made according to a latter task, you'll probably notice it from things not working in most of your tasks (assuming you have logging enabled for every possible technology); multicast might be an exception here. So besides two tasks that i didn't know whether my solution was according to the rules [thanks to proctor for giving vague answers], everything else was following strictly the lab instructions. Even if i was about to miss these two tasks (plus the one i couldn't verify at all, which was worth enough points), points collected from all other tasks would allow me to pass. Unless i missed completely something important and i didn't even notice it [or i messed everything up in the end].

17:00
I leave the Cisco building and i head to my hotel. Although it's now raining outside, i somehow don't feel annoyed by it [i didn't have an umbrella with me so the choices were limited]. Now i just have to wait for the ccie score email [and for my heart to calm down from the exam shock].

20:35 - Success
The much-awaited email arrives. That's probably a good sign, because it's been less than 4 hours after the end of my exam and i already got the results. Either everything went fine, or everything was screwed up; no middle choices in such a short time [this is something i invented while waiting]. I login to the CCIE portal and i see the PASS result (i still keep my CCIE page clear from fails, both in written and lab exams). Another amazing journey has come to an and. After half an hour looking at the result, i submit my lab critique describing my experience with this lab exam [and believe me it's wasn't nice].


So, what were the major differences from my previous CCIE, besides the minus one month of preparation?

First of all, the exam difficulty (in terms of technologies involved) was about the same, maybe a little bit harder; it was easier than what i was prepared for, but definitely not something i would consider as generally easy; i would give it an 8-8,5 out of 10.  The large difference was that this time the devices were more, the tasks were more, the configurations were more...but the time was exactly the same. I can't remember a single task that required configuration on one or even two devices and that with just a few lines on each.

This time i decided to keep my lab preparation notes on a public place; and what's better than the same blog i am publishing my progress? You can find all of them under the NTS page. By making public something of technical nature you feel obliged to the people that read you to provide useful and (hopefully) concise information. It may have cost me quite a few of hours doing it on a daily basis, but i don't regret it at all. It proved very useful to me too and it made the recording process much easier.

Also i decided to keep track of my study and progress in various xls files, as you can see in the exam progress page. This helped me continuously evaluate my knowledge and focus on specific things that i needed to improve. It was like a project that i needed to complete in a very specific time. Also it's always interesting to study graphs instead of numbers that alone might not say too much. I knew which were the core topics and i spent most of time on them; but i wanted to be sure that i won't miss anything non-core because i had no idea of how to use it. So 60% became my need-to-pass base on every topic, while core topics should range even higher, from 70% to 90%.

Regarding the lab preparation, as already described in my home/virtual labs page, since i couldn't find any interesting grading labs, i did the grading myself. And if i wanted to offer a hint for this, i would say that you have to try to be as honest and strict as possible with yourself. Believe me, it will pay you back. I mainly used INE's topology of full scale labs customized for GNS3 and the PEC Gold Labs for this type of preparation, while in my previous CCIE i had used INE's mock labs and Cisco's assessor labs.

Last but not least, while being in preparation, i configured almost every possible scenario and technology included in the CCIE blueprint in IOS and IOS-XR devices. I knew that IOS-XR was important in the CCIE SP lab and i wanted to test everything on that too. I didn't actually try everything in full, i.e. check the produced outputs and all this staff, but i did study and configure everything just to get an idea of what i should do if that topic was included in the exam. It's obvious that core topics were configured and tested as thoroughly as possible. And this is where the PEC Gold Labs helped me a lot. For the last 3 Gold Labs, i was able to finish my Gold Lab in a very short time, so for the rest of the lab time i used the IOS-XR equipment just to test my own scenarios. I did something similar with INE's rack rentals too, after i finished all full scale labs. Although i did have access to IOS-XR devices in my work, for personal reasons i didn't want to use them for testing things.

Before closing this long post, there is one question that comes to my mind the last few hours: Would i pass if i had studied for only one month? I will avoid giving a definite answer, but if i knew that configuration speed played such an important role from the beginning of my preparation, then i would have focused more on that and less on technology inners (which i find annoying if being promoted by Cisco).

What is my advice to everyone thinking of trying the current CCIE SP lab? Learn the core technologies (IGPs, MP-BGP, MPLS/TE, Multicast, IPv6) inside-out, combine and test them in all possible scenarios (one above the other, one combined with the other, multiple combinations above or below other technologies, etc.) and then focus on configuration speed. Think fast, act faster. When you become a master on that, spend some time on every other topic too. And don't risk any challenges, unless you're crazy like me!

Total lab cost: 2.663€


PS: Did i say i enjoyed IPv6 too much?


And some interesting numbers from my exam progress page:

Written study days: 7
Written study hours: 37 
Lab study days: 59
Lab study hours: 354,5
Total study days: 66
Total study hours: 391,5
Average lab study hours per day: 6 (from which ~1,5 hours on avg were spent daily on this blog)



My proposed hints for passing the CCIE SP lab:
  • Read the RFCs, participate in IETF WGs
  • Use GNS3 for your IOS (and soon IOS-XR) needs
  • Use INE's rack rentals or PEC Gold Labs or your work's lab for your IOS-XR needs
  • Use INE's full scale labs for testing and improving your readiness
  • Keep track of your progress, rate yourself as much as possible but always be honest
  • Enable IPv6 on something every day [and disable IPv4 on something every day]
  • Live with MPLS, sleep with MPLS, eat with MPLS, dream of MPLS [is that a female?]
  • Master the trio of success
  • Don't be afraid of changing early your lab tactic if it doesn't work for you
  • Take typing lessons [at least you should easily get another job after that]

Monday, February 10, 2014

...wtf was that?

This must have been the nastiest, wickedest, tightest, weirdest, unfriendliest, and fullest of devices exam ever encountered. If someone was able to count the number of configuration lines and outputs produced in only 8 hours in so many devices in such a unsuitable working environment, he would be shocked by that number. You have very little time to think your options about any possible answers, so you must be fast and accurate on every topic.

So, despite of:
  • spending almost one hour reading the lengthy lab instructions and fixing the silly putty defaults on all devices
  • getting continuous error (os-related) messages filling my console on all IOS-XR boxes during my whole exam
  • having an unhelpful proctor giving unclear answers to two questions of mine
  • not verifying anything at the end due to time pressure

...i managed to PASS!!!

I will post more details in the next few days, after i recover from today's shock.

PS: For anyone wondering what was the first thing i did after i saw the results (besides screaming and jumping up and down), it was to submit my comments under the "Lab Critique" field.

Sunday, February 9, 2014

Lab Week #9

From 03/Feb/2014 to 09/Feb/2014


This was the ninth (and last) week of my lab preparation. Besides focusing on topics which needed a boost, i did a review of all topics according to my NTS, i recorded most of them to my mp3 player and i also created a (300 page!) pdf from all of them (i still can't believe the size of that).

Total average has increased from 74% to 77,3%, with noticeable difference in MPLS TE, VPLS, QoS, CsC & Multicast.



Friday, February 7, 2014

Countdown continues...3 days left...

This is my last post before flying to Brussels (tomorrow) and having the lab exam (on Monday). I'm going to spend the next two days solely on reading & hearing my notes, plus a quick verification of some corner cases on Rack Rentals later today.

I feel quite confident about most topics, but there are some minor ones that i would prefer to have tested a little bit more. Unfortunately my work projects are haunting me and there is no way i could have found more time to be 100% ready on everything.

I'm guessing that my readiness score will be somewhere below 80% at the time of lab exam, which is what i was heading to when i started my study and this blog. As a reminder, this number refers solely to my perceived readiness (ranging from 10% to 90%) regarding specifically the CCIE SP lab topics, so it's not a general knowledge/experience score.

Next post will be on Tuesday 11/Feb/2014...hopefully with some good news.


Thursday, February 6, 2014

Lab Week #8

From 27/Jan/2014 to 02/Feb/2014


This was the eighth week of my lab preparation; just one week remains before the lab exam. I focused mostly on things that i felt i needed more practice (i.e. Multicast, mVPN) and i also checked various subjects that i needed to refresh my knowledge (i.e. QoS & Frame-Relay).

Total average has increased from 70,3% to 74,0%, with noticeable difference in MPLS, BGP & Multicast.



NTS: Advanced Multicast

Advanced Multicast




RPF (Reverse Path Forwarding)

In an RPF check, the router looks in a routing table to determine its RPF interface, which is the interface closest to the root (the source or the RP). The RPF interface is also the incoming interface for the multicast data. RPF checks happen in the control-plane (PIM, MSDP) and in the data-plane (multicast data).

The routing table used for RPF checks can be the global unicast routing table or a separate multicast routing table. In any case, the RPF table contains only unicast routes (the multicast source or the RP).

MP-BGP and M-ISIS can be used to create separate unicast and multicast routing tables.

MP-BGP updates can include IPv4 multicast RPF routes along with IPv4 unicast routes, totally separated (different path attributes) from each other.

You can use "sh ip mroute count" to check for increasing RPF counts.


Fixing RPF issues

If you have IP connectivity over a TE tunnel and require PIM connectivity too, then extra care must be taked. Since you cannot activate PIM on a TE tunnel, you must somehow fix the possible RPF issue on the head-end. The same must be done in every other case where unicast and multicast forwarding do not agree.

Solutions
  • static mroute
  • multicast BGP
  • multicast topology in IS-IS
  • mpls traffic-eng multicast-intact (for IGP routes)

You can use the command "sh ip rpf" in order to verify RPF issues.

Before

IOS
R2#sh ip rpf 19.19.19.19
 failed, no route exists



IOS-XR
GSR#sh pim rpf 2.2.2.2
Table: IPv4-Unicast-default
* 2.2.2.2/32 [115/30]
    via Null with rpf neighbor 0.0.0.0



In IOS-XR, the command "sh pim rpf" provides an output only if the address provided is already used as a multicast source. Use "sh pim rpf hash" to check in advance.

After fixing the RPF issue:

IOS
R2#sh ip rpf 19.19.19.19
RPF information for ? (19.19.19.19)
  RPF interface: FastEthernet1/0.24
  RPF neighbor: ? (26.2.4.4)
  RPF route/mask: 19.19.19.19/32
  RPF type: unicast (isis)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base


IOS-XR
GSR#sh pim rpf 2.2.2.2
Table: IPv4-Multicast-default
* 2.2.2.2/32 [115/30]
    via GigabitEthernet0/1/0/1 with rpf neighbor 26.3.19.3



static mroute

IOS
ip mroute 2.2.2.2 255.255.255.255 Tunnel0

IOS-XR
multicast-routing
 address-family ipv4
  static-rpf 2.2.2.2 32 tunnel-te0 3.3.3.3



multicast-intact

When enabled on an IGP, the IGP automatically publishes to the RIB a parallel (or alternate) set of equal-cost next-hops for all IPv4 destinations learned through LS advertisements, for use solely by PIM. These next-hops are called mcast-intact next-hops. The mcast-intact next-hops have the following characteristics:

  • They are guaranteed not to contain any IGP shortcuts (like TE tunnels).
  • They are not used for unicast routing, but are used only by PIM to look up an IPv4 next-hop to a PIM source.
  • They are not published to the FIB.
  • When multicast-intact is enabled on an IGP, all IPv4 destinations that were learned through link-state advertisements are published with a set of equal-cost mcast-intact next-hops to the RIB. This attribute applies even when the native next-hops have no IGP shortcuts.

IOS
router ospf 1
 mpls traffic-eng multicast-intact
router isis 1
 mpls traffic-eng multicast-intact

IOS-XR
router ospf 1
 mpls traffic-eng multicast-intact
!

router isis 1
 address-family ipv4 unicast
  mpls traffic-eng multicast-intact



Multicast-intact doesn't work with TE forwarding-adjacency, use multicast BGP or static mroute.

multicast-intact vs static mroute in TE tunnels
  • use multicast-intact to accept multicast traffic coming from outside a TE tunnel, when the unicast route is pointing inside the TE tunnel
  • use static mroute to accept multicast traffic coming from inside a TE tunnel, when the unicast route is pointing outside the TE tunnel

IS-IS Multicast Topology

Multicast topology for ISIS allows the configuration of a separate IS-IS multicast topology for IPv4 or IPv6 routing, which runs a separate SPF.

IS-IS multicast inserts routes from the IS-IS multicast topology into the multicast-unicast table in the RIB for the corresponding address family. Since PIM uses this table, PIM uses routes from the multicast topology instead of routes from the unicast topology.


Multicast BGP

The multicast BGP database can be used by a a multicast routing protocol (i.e. PIM) to perform RPF lookups for multicast-capable sources. Thus, packets can be sent and accepted based on the multicast topology and not on the unicast topology.

This is an easy way to change the multicast routing without affecting unicast too. Static mroutes can also be used.

IOS
router bgp 65000
 no bgp default ipv4-unicast
 neighbor 7.7.7.7 remote-as 65000
 !
 address-family ipv4 multicast
  neighbor 7.7.7.7 activate

  network 192.168.7.0
 exit-address-family


IOS-XR
router bgp 65000
 address-family ipv4 multicast
  network 192.168.7.0/24
 !
 neighbor 7.7.7.7
  address-family ipv4 multicast



IOS
R8#sh ip rpf 192.168.7.0
RPF information for ? (192.168.7.0)
  RPF interface: FastEthernet0/0
  RPF neighbor: ? (192.168.78.7)
  RPF route/mask: 192.168.7.0/24
  RPF type: mbgp
  RPF recursion count: 0
  Doing distance-preferred lookups across tables



Changing of BGP distance might be needed on the remote peer, if an IGP already provides a better route.

When you enable the multicast address-family under BGP, then these prefixes take precedence over the prefixes learned in the BGP unicast address-family; only the BGP prefixes learned in the multicast address-family are used for any multicast routing. Use "show route ipv4 multicast" in IOS-XR to display the ipv4 multicast routes.

You might need to also advertise a specific next-hop for the RPF route, if the default next-hop doesn't satisfy the RPF needs (recursive lookup might not be supported).



MSDP & Anycast RP

MSDP provides a way to connect multiple PIM-SM domains, so that RPs can exchange information about active multicast sources. It uses

MSDP sessions are formed between the RPs of various PIM domains, which are called MSDP peers.

MSDP is also used between Anycast RPs within a single PIM domain to synchronize information about the active sources being served by each Anycast-RP peer. Anycast RPs will each have the same IP address configured on a Loopback interface (making this the Anycast address) and will MSDP peer with each other using a separate loopback interface.

With Anycast RP, RP failover depends only on IGP convergence

MSDP RPs send SA (Source-Active) messages in order to notify each other of active multicast sources.

An MSDP RP sends an SA message to its peers each time it receives a PIM Register or Null-Register message from a Source DR about a new/active source. MSDP SA messages include the same multicast data that is also encapsulated in PIM Register or Null-Register messages.


IOS
interface Loopback99
 ip address 99.99.99.99 255.255.255.255
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
ip msdp peer 1.1.1.1 connect-source Loopback0
ip msdp originator-id Loopback0

!
ip pim rp-address 99.99.99.99



IOS-XR
interface Loopback99
  ipv4 address 99.99.99.99 255.255.255.255
!

interface Loopback0
  ipv4 address 1.1.1.1 255.255.255.255
!
router msdp
 originator-id Loopback0
 peer 2.2.2.2
  connect-source Loopback0
!
router pim
 address-family ipv4
  rp-address 99.99.99.99



The address on the interface used as anycast RP must be advertised into an IGP (preferably as external route to be able to play easily with the metric).

When using anycast IPv4 addresses in Loopbacks, it's good practice to hardcode all the protocol router-ids manually in order to avoid using the anycast address as router-id for a protocol.

In some software releases originator-id might not be required, but it's always good practice to configure it (especially in anycast topologies).

In current releases, when running Inter-AS MSDP, the peer/source IPs must agree with the BGP update source on each neighbor. If you also have a BGP peering session with an MSDP peer, you should use the same IP address for MSDP (peer/connect-source) as you do for BGP (update-source). If MDT is using a non-loopback interface due to eBGP with directly connected neighbor, you might get the message "%MDT-4-LBSRC: VRF ABC: MDT X uses source address x.x.x.x from a non-loopback interface". Besides changing the update-source of the eBGP peering, you can also use the "bgp next-hop loopback X" command under the appropriate vrf.

Use "default-peer" in IOS-XR when the peer address isn't in BGP.

If there is a single MSDP peer, then no RPF check takes place about the originator-id. If there are multiple MSDP peers, then you can put them under a mesh-group in order to disable the RPF check on them.


Links




Multicast Filtering

Setting an interface to PIM v1 at the border of a PIM domain prevents v2 Bootstrap messages from leaking to the neighboring PIM domain.

Use "ip pim passive" under an interface if you want to block the forwarding of PIM control plane traffic; only IGMP traffic will pass.

BSR filtering

IOS
interface X
 ip pim bsr-border



IOS-XR
router pim
 address-family ipv4
  interface X
   bsr-border




Auto-RP filtering

IOS-XR
multicast-routing
 address-family ipv4
  interface TenGigE0/2/0/0
   boundary MCAST-ACL

!
ipv4 access-list MCAST-ACL
 deny host 224.0.1.39
 deny host 224.0.1.40
 permit any



IGMP filtering

IOS
interface X
 ip igmp access-group IGMP-ACL


! match (*,G)
ip access-list extended IGMP-ACL
 permit ip host 0.0.0.0 host GROUP


! match (S,G) and (*,G)
ip access-list extended IGMP-ACL
 permit ip any host GROUP





Multicast Admission Control


  • Global or per VRF
    • limit the number of mroutes that can be added to the global table
      • ip multicast route-limit MAX-MROUTES THRESHOLD
    •  limit the number of mroutes that can be added to a particular MVRF table
      • ip multicast vrf MVRF route-limit MAX-MROUTES THRESHOLD
    • limit the number of mroute states created from IGMP membership reports
      • ip igmp limit MAX-IGMPS
  • Per interface
    • limit the number of mroute states
      • ip multicast limit MCAST-ACL MAX-MROUTES
    • limit the number of mroutes states created from  IGMP membership reports
      • ip igmp limit MAX-IGMPS
  • Per neighbor
    • Limits the number of SA messages allowed in the SA cache from an MSDP peer
      • ip msdp sa-limit MSDP-PEER MAX-SA-MESSAGES
         
Check "Multicast Filtering" above for the format of MCAST-ACL.


Rate-limit

The "ip multicast rate-limit" interface command is not supported any more.

You need to use the the MQC syntax to define multicast traffic and then police it accordingly.




Multicast Fast Convergence

  • tune PIM hellos (queries)
  • tune RPF check interval/backoff
  • MoFRR


Multicast-only FRR

The basic idea of MoFRR is to send a secondary PIM join from the receiver toward the source on a backup path to a different upstream interface. The network then receives two copies of the multicast stream over two separate and redundant paths through the network, but the redundant packets are discarded at topology merge points due to RPF checks. When the primary path fails, it can switch over to the backup path instantly without issuing a new PIM join. 

Actually MoFRR is pre-building an alternate multicast tree in order to achieve faster convergence.

  • RIB-based MoFRR
    • Supported on CRS and XR12000 series routers
    • Based on routing convergence
  • Flow-based MoFRR
    • Supported ASR9k
    • Based on packet count per 30ms


IOS (15.2)

ip multicast rpf mofrr MOFRR-SG-ACL
!
ip access-list standard MOFRR-SG-ACL
 permit 10.10.10.0 0.0.0.255


IOS > 15.2 is required for MoFRR.


IOS-XR
router pim
 address-family ipv4
  mofrr rib MOFRR-SG-ACL
!

ipv4 access-list MOFRR-SG-ACL
 10 permit ipv4 host 1.1.1.1 host 239.3.3.3



Links



Troubleshooting

Enable "debug ip mfib fs" and "debug ip mfib ps" on the receiver, and then send some pings from a source to an igmp join group on the receiver to check the results.



IPv6 Multicast


IOS
ipv6 multicast-routing

IOS-XR
multicast-routing
 address-family ipv6
  interface all enable



In IOS, all IPv6 interfaces are PIM enabled by default after enabling ipv6 multicast-routing.


IPv6 RP definition

IOS

ipv6 pim bsr candidate bsr 2002:2:2::2
ipv6 pim bsr candidate rp 2002:2:2::2

!
ipv6 pim rp-address 2002:2:2::2

IOS-XR
router pim
 address-family ipv6
  rp-address 2002:2:2::2
  bsr candidate-rp 2002:2:2::2 

  bsr candidate-bsr 2002:2:2::2


MLD

IOS
ipv6 multicast-routing
!interface Loopback0
 ipv6 mld join-group FF99::99


IOS-XR
multicast-routing
 address-family ipv6
  interface all enable
!

router mld
 interface Loopback0
  join-group ff99::99


MLDv2 is used by default.


Verification

R2#sh 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

(*, FF99::99), 00:00:08/00:03:21, RP 2002:2:2::2, flags: S
  Incoming interface: Tunnel4
  RPF nbr: 2002:2:2::2
  Immediate Outgoing interface list:
    Ethernet0/2, Forward, 00:00:08/00:03:21


R2#ping FF99::99
Output Interface: Ethernet0/2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF99::99, timeout is 2 seconds:
Packet sent with a source address of 2002:2:2:27::2

Reply to request 0 received from 2002:2:2::7, 60 ms
Reply to request 1 received from 2002:2:2::7, 0 ms
Reply to request 2 received from 2002:2:2::7, 4 ms
Reply to request 3 received from 2002:2:2::7, 4 ms
Reply to request 4 received from 2002:2:2::7, 0 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/13/60 ms
5 multicast replies and 0 errors.



Almost everything cli-wise is similar to IPv4.


Static mroutes

IOS
ipv6 route 2002:2:2::2/128 Tunnel0 multicast

IOS-XR
multicast-routing
 address-family ipv6
  static-rpf 2002:2:2::2 128 tunnel-te0 2002:3::1







NSF

IOS-XR
router pim
 nsf lifetime 30
!

router igmp
 nsf lifetime 30
!
router mld
 nsf lifetime 30



Generally, configure the IGMP NSF and PIM NSF lifetime values to be equal or larger than the query or join query interval, but less than the holdtime




Multipath

By default, if ECMP paths are available, the RPF for multicast traffic will be based on the highest IP address (aka highest PIM neighbor).

When the 'ip multicast multipath' command is configured, the multicast load splitting will be based on the source address of the stream. PIM Joins will be distributed over the different ECMP links based on a hash of the source address.

Multicast multipath must be enabled on the receiver side of the ECMP path.

IOS
ip multicast multipath

IOS
R2#sh ip rpf 19.19.19.19
RPF information for ? (19.19.19.19)
  RPF interface: FastEthernet0/0.24
  RPF neighbor: ? (20.2.4.4)
  RPF route/mask: 19.19.19.19/32
  RPF type: unicast (ospf 1)
  Doing distance-preferred lookups across tables
  Multicast Multipath enabled.
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base


By default only the source address is used in the calculation. Better load-splitting can be achieved by using the "s-g-hash next-hop-based" options.

When the ip multicast multipath command is enabled, the presence of PIM hello message from neighbors is not considered; that is, the chosen RPF neighbor does not depend on whether or not PIM hello messages are received from that neighbor; it only depends on the presence or absence of an equal-cost route entry.

If using BGP and multicast, then you must also enable multipath on BGP.

If using static mroutes, then you need to somehow create two (or more) different static mroutes because only one is accepted. You can use a dummy ip address and two (or more) static ip routes in order to achieve this.


IOS
ip route 192.168.1.1 255.255.255.255 20.2.3.3
ip route 192.168.1.1 255.255.255.255 20.2.4.4

!
ip mroute 19.19.19.19 255.255.255.255 192.168.1.1


In the above example, multicast load-balancing occurs between 20.2.3.3 and 20.2.4.4 for source 19.19.19.19 (192.168.1.1 is the dummy address used).

Use "sh ip multicast rpf tracked" to verify the multiple rpf paths.



NTS: Advanced MPLS-TE

Advanced MPLS-TE




FRR (Fast ReRoute) extensions for RSVP-TE are defined in RFC 4090.
Inter-Area MPLS TE is described in RFC 4105.
Inter-AS MPLS TE is described in RFC 4216.



LSP Protection

  • path protection - long term
  • local protection (FRR) - short term
    • link protection
    • node protection

Backup tunnels are usually used for a short period of time, until the head-end recomputes and signals a new path. When the new path is established and traffic is switched over to it, the backup path is torn down.

PLR = Point of Local Repair
MP = Merge Point

The constraints of the backup path are signaled by the head-end to the PLR using the Fast Reroute Object (FRO) of RSVP.

  • many-to-one backup (facility backup)
    • an extra label is pushed by the PLR
    • MP advertises an implicit-null label (PHP)
    • traffic arrives at the MP with the same label as the main path
  • one-to-one backup (detour backup)
    • the top label is swapped by the PLR
    • MP advertises a normal label (label swap)
    • traffic arrives at the MP with a different label from the main path

Expect to see only the many-to-one backup being used.

The failure and the local restoration of a main path are signaled by the PLR to the head-end using an RSVP Path-Error message (code="Notify", subcode="Tunnel locally repaired") and an RRO flag.



FRR (Fast Reroute)

MPLS-TE/FRR is a mechanism for protecting MPLS TE LSPs from link and node failures by locally repairing the LSPs at the point of failure.  It allow traffic to continue to flow on the LSPs, while their head-end routers attempt to establish new end-to-end LSPs to replace them.

FRR repairs locally the protected LSPs by rerouting them over backup tunnels that bypass these failed links or nodes.

  • NHOP backup tunnels
    • backup tunnels that bypass only a link of the LSP's path 
    • they provide link protection by rerouting the LSP's traffic to the next-hop
    • can be specified by simply excluding the protected link (interface address)
  • NNHOP backup tunnels 
    • backup tunnels that bypass a node of the LSP's path
    • they provide node (& link) protection by rerouting the LSP's traffic to the next-next-hop
    • can be specified by simply excluding the protected node (loopback address)

FRR prefers NNHOP over NHOP backup tunnels, when both are available.


Configuration Steps
  • PE (head-end)
    • enable FRR under the tunnel
  • PLR (point of local repair)
    • configure a backup tunnel with a path that avoids the link/node to be protected
    • enable the backup tunnel under the link to be protected
    • enable RSVP hellos or BFD under the link to be protected (for faster detection)


PE (head-end)

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 19.19.19.19
 tunnel mpls traffic-eng path-option 1 explicit name X
 tunnel mpls traffic-eng fast-reroute


IOS-XR
interface tunnel-te0
 ipv4 unnumbered Loopback0
 destination 19.19.19.19
 fast-reroute
 path-option 1 explicit name X



You also have the following options if you want to influence the backup tunnel selection on the PLR:

IOS
R2(config-if)#tunnel mpls traffic-eng fast-reroute ?
  bw-protect    bandwidth protection desired
  node-protect  node protection desired


IOS-XR
CRS(config-if)#fast-reroute protect ?
  bandwidth  Enable bandwidth protection request
  node       Enable node protection request



IOS-XR by default tries to provide the best available protection, even if the above two options aren't activated.


PLR (point of local repair)

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 5.5.5.5
 tunnel mpls traffic-eng path-option 1 explicit name AVOID-X
!

ip explicit-path name AVOID-X enable
 exclude-address x.x.x.x
!

interface FastEthernet0/0
 mpls traffic-eng backup-path Tunnel0
 ip rsvp signalling hello




IOS-XR
interface tunnel-te0
 ipv4 unnumbered Loopback0
 destination 5.5.5.5
 path-option 1 explicit name AVOID-X

!
explicit-path name AVOID-X
 index 1 exclude-address ipv4 unicast x.x.x.x

!
mpls traffic-eng
 interface TenGigE0/0/0/0
  backup-path tunnel-te 0



The same "rsvp signalling hello" type (RSVP hellos or BFD) must be configured on the other side too for fast detection to take place.


IOS-XR supports only BFD for fast detection (< 1sec). RSVP hellos can be used for simple reroute (detection > 10sec) or GR.


Verification


PE (head-end)

IOS
R2#sh mpls traffic-eng tunnels protection
P2P TUNNELS:
R2_t0
  LSP Head, Tunnel0, Admin: up, Oper: up
  Src 2.2.2.2, Dest 19.19.19.19, Instance 46
  Fast Reroute Protection: Requested
    Outbound: Unprotected: no backup tunnel assigned
      LSP signalling info:
        Original: out i/f: Fa0/0.23, label: 18, nhop: 20.2.3.3
                  nnhop: 4.4.4.4; nnhop rtr id: 4.4.4.4
  Path Protection: None



PLR (point of local repair)

before the activation of the backup tunnel

IOS
R4#sh mpls traffic-eng tunnels backup
R4_t0
  LSP Head, Admin: up, Oper: up
  Tun ID: 0, LSP ID: 3, Source: 4.4.4.4
  Destination: 5.5.5.5
  Fast Reroute Backup Provided:
    Protected i/fs: Fa0/0.45
    Protected LSPs/Sub-LSPs: 1, Active: 0
    Backup BW: any pool unlimited; inuse: 0 kbps
    Backup flags: 0x0



R4#sh mpls traffic-eng fast-reroute database role middle

P2P LSP midpoint frr information:
LSP identifier                 In-label Out intf/label   FRR intf/label   Status
---------------------------    -------- --------------   --------------   ------
2.2.2.2 0 [46]                 16       Fa0/0.45:18      Tu0:18           Ready



R4#sh mpls traffic-eng fast-reroute database role middle detail
FRR Database Summary:
  Protected interfaces    : 1
  Protected LSPs/Sub-LSPs : 1
  Backup tunnels          : 1
  Active interfaces       : 0

P2P LSPs:

 Tun ID: 0, LSP ID: 46, Source: 2.2.2.2
 Destination: 19.19.19.19
  State        : Ready
  InLabel      : 16
  OutLabel     : Fa0/0.45:18
  FRR OutLabel : Tu0:18



after the the activation of the backup tunnel

R4#sh mpls traffic-eng tunnels backup
R4_t0
  LSP Head, Admin: up, Oper: up
  Tun ID: 0, LSP ID: 3, Source: 4.4.4.4
  Destination: 5.5.5.5
  Fast Reroute Backup Provided:
    Protected i/fs: Fa0/0.45
    Protected LSPs/Sub-LSPs: 1, Active: 1
    Backup BW: any pool unlimited; inuse: 0 kbps
    Backup flags: 0x0



R4#sh mpls traffic-eng fast-reroute database role middle

P2P LSP midpoint frr information:
LSP identifier                 In-label Out intf/label   FRR intf/label   Status
---------------------------    -------- --------------   --------------   ------
2.2.2.2 0 [46]                 16       Fa0/0.45:18      Tu0:18           Active


R4#sh mpls traffic-eng fast-reroute database role middle detail
FRR Database Summary:
  Protected interfaces    : 1
  Protected LSPs/Sub-LSPs : 1
  Backup tunnels          : 1
  Active interfaces       : 1


P2P LSPs:

 Tun ID: 0, LSP ID: 46, Source: 2.2.2.2
 Destination: 19.19.19.19
  State        : Active
  InLabel      : 16
  OutLabel     : Fa0/0.45:18
  FRR OutLabel : Tu0:18



When using MPLS-TE/FRR for node protection, a label_recording flag is included into the SAO in order to signal that the RRO should also include labels (because these labels are actually used by the PLR for NNHOP backup tunnels), although it's not shown in the tunnel config.


IOS
R2#sh mpls traffic-eng tunnels | b Resv
    RSVP Resv Info:
      Record   Route:  3.3.3.3(20) 4.4.4.4(20)
                       5.5.5.5(20) 19.19.19.19(0)


If you explicitly enable it in the config, then you get the address of the physical interfaces too.

R2#sh mpls traffic-eng tunnels | b Resv
    RSVP Resv Info:
      Record   Route:  3.3.3.3(21) 20.3.4.3(21)
                       4.4.4.4(21) 20.4.5.4(21)
                       5.5.5.5(21) 20.5.19.5(21)
                       19.19.19.19(0) 20.5.19.19(0)


The path when using the backup tunnel is not reflected in the above output.


You can also use the following command on the PLR in order to verify the FRR operation.

IOS
R4#sh ip rsvp sender detail
...
  Tun Dest:   19.19.19.19  Tun ID: 0  Ext Tun ID: 2.2.2.2
  Tun Sender: 2.2.2.2  LSP ID: 25
...
  Fast-Reroute Backup info:
    Inbound  FRR: Not active
    Outbound FRR: Ready -- backup tunnel selected
      Backup Tunnel: Tu1        (label 19)
      Bkup Sender Template:
        Tun Sender: 20.3.4.4  LSP ID: 25
      Bkup FilerSpec:
        Tun Sender: 20.3.4.4, LSP ID: 25



or the following command on the head-end.

R2#sh ip rsvp reservation detail
...
Reservation:
  Tun Dest:   19.19.19.19  Tun ID: 0  Ext Tun ID: 2.2.2.2
  Tun Sender: 2.2.2.2  LSP ID: 25
  Next Hop: 20.2.3.3 on FastEthernet0/0.23
  Label: 20 (outgoing)
  Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
  Resv ID handle: 0A000415.
  Created: 13:32:42 UTC Sat Jan 11 2014
  Average Bitrate is 20M bits/sec, Maximum Burst is 1K bytes
  Min Policed Unit: 0 bytes, Max Pkt Size: 1500 bytes
  RRO:
    3.3.3.3/32, Flags:0x20 (No Local Protection, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 20
    20.3.4.3/32, Flags:0x0 (No Local Protection)
      Label subobject: Flags 0x1, C-Type 1, Label 20
    4.4.4.4/32, Flags:0x25 (Local Prot Avail/Has BW/to NHOP, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 19
    20.4.5.4/32, Flags:0x5 (Local Prot Avail/Has BW/to NHOP)
      Label subobject: Flags 0x1, C-Type 1, Label 19
    5.5.5.5/32, Flags:0x20 (No Local Protection, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 19
    20.5.19.5/32, Flags:0x0 (No Local Protection)
      Label subobject: Flags 0x1, C-Type 1, Label 19
    19.19.19.19/32, Flags:0x20 (No Local Protection, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 0
    20.5.19.19/32, Flags:0x0 (No Local Protection)
      Label subobject: Flags 0x1, C-Type 1, Label 0
  Status:
  Policy: Accepted. Policy source(s): MPLS/TE



Then the backup tunnel gets activated, the output will change to:

IOS
R2#sh ip rsvp reservation detail
...

    4.4.4.4/32, Flags:0x23 (Local Prot Avail/In Use/to NHOP, Node-id)
      Label subobject: Flags 0x1, C-Type 1, Label 16
    20.3.4.4/32, Flags:0x3 (Local Prot Avail/In Use/to NHOP)
      Label subobject: Flags 0x1, C-Type 1, Label 16






Path Protection

Apart from having link & node protection using FRR, you also have the option of enabling path protection end-to-end for a tunnel. You can have multiple backup path options per primary path option.

It's not as fast as FRR, but it's still faster than having a second path-option or relying on IGP, because it pre-calculates the whole backup path (like FRR).

It can be used with intra-area, inter-area and inter-AS scenarios.

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 2.2.2
 tunnel mpls traffic-eng path-option 1 explicit name PATH1
 tunnel mpls traffic-eng path-option protect 1 explicit name PATH1-BAK



R1#sh mpls traffic-eng tunnels protection

P2P TUNNELS:
R1_t0
  LSP Head, Tunnel0, Admin: up, Oper: up
  Src 1.1.1.1, Dest 2.2.2.2, Instance 3
  Fast Reroute Protection: None
  Path Protection: Requested



You can also view the details about SRLGs:

R1#sh mpls traffic-eng tunnels tunnel0

Name: R1_t0                             (Tunnel0) Destination: 2.2.2.2
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
    path option 1, type explicit PATH1 (Basis for Setup, path weight 20)
    Path Protection: 2 Common Link(s), 1 Common Node(s)
      Link Sharing Detail:
        P2P Links:             0
        Multiacces Links:      2
           Both interfaces:         2
           1 interface:             0
           0 interfaces:            0 (only media is shared)
    path protect option 1, type explicit PATH1-BAK (Basis for Protect, path weight 20)


Latest IOS software releases support enhanced path protection (up to 8 secondary path options).


IOS-XR
interface tunnel-te0
 path-protection
 path-option 1 explicit name R2-R3-R4
 path-option 2 dynamic
 
!
interface tunnel-te1

 path-protection
 path-option 1 explicit name R2-R3-R4 protected-by 2
 path-option 2 explicit name R2-R5-R6



Path-protection is not supported on C12k platform for IOS-XR.

In IOS-XR you can either have explicit path as primary and dynamic as backup, or explicit path as primary and backup. IOS-XR provides automatic path diversity.



Backup Tunnel Selection

You can have multiple backup tunnels protecting the same or different LSPs, each one terminating on the same destination or a different one.

The backup tunnel is configured on the PLR, under the physical interface to be protected.

IOS
interface X
 mpls traffic-eng backup-path Tunnel0
 mpls traffic-eng backup-path Tunnel1



IOS-XR
mpls traffic-eng
 interface X
  backup-path tunnel-te 0
  backup-path tunnel-te 1



The selection priority between multiple backup tunnels is based on the following table.


Preference Backup Tunnel Destination Bandwidth Pool Bandwidth Amount
1 (Best) Next-next hop Sub-pool or global-pool Limited
2Next-next hop Any Limited
3Next-next hop Sub-pool or global-pool Unlimited
4Next-next hop Any Unlimited
5Next-hop Sub-pool or global-pool Limited
6Next-hop Any Limited
7Next-hop Sub-pool or global-pool Unlimited
8 (Worst) Next-hop Any Unlimited


The general idea is the following:
  • NNHOP tunnels have priority over NHOP tunnels
  • backup-bw tunnels have priority over no backup-bw tunnels
  • specific pool tunnels have priority over any pool tunnels

After a backup tunnel has been chosen for an LSP, various conditions may change on the network, that will cause the router to reevaluate this choice. This promotion can happen immediately in case of a backup tunnel going up/down, or periodically every 5 mins. This time be changed by using the command "mpls traffic-eng fast-reroute timers". Set it to 0 if you want to disable promotion for LSPs.


backup protection algorithm

If the main tunnel doesn't have any bandwidth configured, then it can use only backup tunnels that don't have any backup-bandwidth configured.

In the following example, main tunnel (that doesn't have any signaled bandwidth configured) can use only backup tunnel #2.

main tunnel
interface Tunnel0

backup tunnel #1
interface Tunnel1
 tunnel mpls traffic-eng backup-bw 30000

backup tunnel #2
interface Tunnel2


If the main tunnel has a bandwidth configured, then it can use only backup tunnels that either don't have any backup-bandwidth configured or have sufficient backup-bandwidth configured.

In the following example, main tunnel (that has a bandwidth of 35M configured) can use only backup tunnel #2 and #3.

main tunnel
interface Tunnel0
 tunnel mpls traffic-eng bandwidth 35000


backup tunnel #1
interface Tunnel1
 tunnel mpls traffic-eng backup-bw 30000

backup tunnel #2
interface Tunnel2

backup tunnel #3
interface Tunnel3
 tunnel mpls traffic-eng backup-bw 40000


Generally, the backup-bandwidth is assumed to be unlimited when it's not configured. Is this case no bandwidth protection is provided.

If you don't configure a global-pool or a sub-pool, then any pool is assumed.

When using global-pool or sub-pool in order to limit the type of backup-bandwidth (and not the amount), then you have to explicitly define as unlimited the backup-bandwidth, like below:

IOS
interface Tunnel1
 tunnel mpls traffic-eng backup-bw global-pool unlimited
 tunnel mpls traffic-eng backup-bw sub-pool unlimited

IOS-XR
interface tunnel-te1
 backup-bw global-pool unlimited
 backup-bw sub-pool unlimited


If there are two or more backup tunnels with backup-bandwith configured that have sufficient available backup-bandwith, then the one with the least amount of currently available backup bandwidth is chosen, in order to keep the largest amount available for other LSPs (main tunnels) with bigger needs.

If there are two or more backup tunnels with no backup-bandwith configured, then the one with the least amount of currently used backup bandwidth is chosen, in order to distribute the LSPs (main tunnels) as evenly as possible. If the LSP (main tunnel) doesn't have any bandwidth configured, the backup tunnel with the fewest protecting LSPs is chosen.

If you want to change the above backup protection preemption algorithm, you can use the following command on the PLR:

IOS
R2(config)#mpls traffic-eng fast-reroute backup-prot-preempt ?
  optimize-bw  Reduce bandwidth wastage (default: minimize LSPs preempted)



Keep in mind that backup tunnels can have their signaled-bandwidth configured, just like any other tunnel, in order to have the LSRs on the backup path do the appropriate admission control (in production networks this might not be recommended in order to avoid reservation of resources for a tunnel rarely used). On the other hand, the backup-bandwidth is used solely by the PLR (head-end of he backup tunnel) locally. Theoretically, both signaled-bandwidth and backup-bandwidth should be the same for proper operation.

In general:
  • signaled-bandwidth on the main tunnel
    • xxx (global pool is assumed)
    • sub-pool xxx
  • backup-bandwidth on the backup tunnel
    • xxx (any pool is assumed)
    • global-pool xxx
    • sub-pool xxx

You need to enable RDM for RSVP if you are using sub-pools.



TE auto-bandwidth

TE auto-bandwidth samples the average output rate for each tunnel configured for automatic bandwidth adjustment and periodically (i.e. once per day) adjusts the tunnel’s signaled-bandwidth to be the largest sample for the tunnel since the last adjustment.

Auto-bandwidth basically performs the following steps:
  • every X interval, traffic over a tunnel is measured
  • every Y interval, the largest sample from the above measurement is collected
  • if this sample value exceeds a Z threshold, then it's used to set the new tunnel bandwidth

Configuration Steps
  • globally
    • enable statistics collection & auto-bw adjustments (enabled by default)
    • frequency: define the interval between tunnel bw statistics collection (5m by default)
  • per tunnel
    • frequency: define the interval between auto-bw adjustments (24h by default)
    • max-bw: define the max auto-bw allowed (no limit by default)
    • min-bw: define the min auto-bw allowed (no limit by default)
    • adjustment-threshold: define the delta threshold over which the new bw is actually signaled/used (10% by default)


IOS
mpls traffic-eng auto-bw timers frequency 60
!
interface Tunnel0
 load-interval 30
 tunnel mpls traffic-eng bandwidth 20
 tunnel mpls traffic-eng auto-bw frequency 300 adjustment-threshold 1 max-bw 100 min-bw 1


IOS-XR
mpls traffic-eng
 auto-bw collect frequency 1

!
interface tunnel-te0
 load-interval 30
 signalled-bandwidth 20
 auto-bw
  bw-limit min 1 max 100
  adjustment-threshold 1
  application 5



IOS-XR auto-bw intervals are defined in mins, while IOS ones are defined in secs.

It's good practice to have: tunnel load-interval < global sampling frequency < tunnel adjust frequency.

IOS
R2#sh mpls traffic-eng tunnels
...
  Config Parameters:
    Bandwidth: 20    kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute announce: enabled  LockDown: disabled Loadshare: 1        bw-based
    auto-bw: (300/155) 7  Bandwidth Requested: 1

          Adjustment Threshold: 1%
          Samples Missed: 0  Samples Collected: 2



after the auto-bw adjustment interval timer expires, the largest sample (7) is now requested/used

R2#sh mpls traffic-eng tunnels
...

  Config Parameters:
    Bandwidth: 20    kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute announce: enabled  LockDown: disabled Loadshare: 7        bw-based
    auto-bw: (300/283) 0  Bandwidth Requested: 7
          Adjustment Threshold: 1%
          Samples Missed: 0  Samples Collected: 0



Don't forget to also configure the load-interval on the tunnel interface accordingly.

Traffic samples for tunnels that were down during the sampling period, are ignored.

If auto-bw is configured for a tunnel, the "tunnel mpls traffic-eng bandwidth" command sets only the initial tunnel bandwidth. Setting the initial bandwidth is not required for auto-bw to work.

The latest requested/signaled bandwidth is automatically saved to the tunnel running config.

In latest software releases you can also set an overflow or underflow threshold in order to make the bandwidth adjustment earlier than the configured interval (so you don't have to wait for all the samples to be collected). That way you can set a large auto-bw adjustment frequency and use these two thresholds in such a way that you can react quickly to traffic changing conditions.




Auto-Tunnels


3 types:
  • backup auto-tunnels
    • no need to configure manual backup tunnels
    • no need to assign backup tunnels to a protected interface
  • primary one-hop auto-tunnels
    • no need to configure tunnels to directly connected neighbors with FRR for protection
  • mesh-group auto-tunnels
    • no need to configure tunnel to all interested PEs with FRR for protection


backup auto-tunnels

It must be configured on the PLR, like normal backup tunnels.  After activation, dynamic backup NHOP/NNHOP tunnels are created automatically whenever an LSP requests FRR protection.

If there is a static configured backup tunnel for a specific interface, then backup auto-tunnels won't be created for this.

IOS
mpls traffic-eng auto-tunnel backup


IOS-XR (4.0.0)
mpls traffic-eng
 auto-tunnel backup


Extra options available:

IOS
R3(config)#mpls traffic-eng auto-tunnel backup ?
  config      Config commands to apply to all backup auto-tunnels
  nhop-only   Automatically create n-hop backup tunnels only
  srlg        Shared Risk Link Groups influence backup tunnel path selection
  timers      Configure timers for backup auto-tunnels
  tunnel-num  Configure tunnel I/F numbers for backup auto-tunnels



You can enable "debug mpls traffic-eng auto-tunnel backup all" if you want to see the actual cli commands used to create the backup auto-tunnels.

IOS
R3#debug mpls traffic-eng auto-tunnel backup all
MPLS TE Auto-Tunnel Backup all debugging is on

TE_AUTO_TUN: backup CLI command:
interface tunnel65436
no logging event link-status
ip unnumbered Loopback0
tunnel destination 6.6.6.6
tunnel mode mpls traffic-eng
end

TE_AUTO_TUN: CLI command:
ip explicit-path name __dynamic_tunnel65436
  index 1 exclude-address 20.3.6.3

TE_AUTO_TUN: backup CLI command:
interface tunnel65436
tunnel mpls traffic-eng path-option 1 exp name __dynamic_tunnel65436
end

TE_AUTO_TUN: backup CLI command:
interface tunnel65437
no logging event link-status
ip unnumbered Loopback0
tunnel destination 5.5.5.5
tunnel mode mpls traffic-eng
end

TE_AUTO_TUN: CLI command:
ip explicit-path name __dynamic_tunnel65437
  index 1 exclude-address 6.6.6.6

TE_AUTO_TUN: backup CLI command:
interface tunnel65437
tunnel mpls traffic-eng path-option 1 exp name __dynamic_tunnel65437
end



R3#sh mpls traffic-eng tunnels backup
R3_t65436
  LSP Head, Admin: up, Oper: up
  Tun ID: 65436, LSP ID: 1, Source: 3.3.3.3
  Destination: 6.6.6.6
  Fast Reroute Backup Provided:
    Protected i/fs: Fa0/0.36
    Protected LSPs/Sub-LSPs: 0, Active: 0
    Backup BW: any pool unlimited; inuse: 0 kbps
    Backup flags: 0x0
R3_t65437
  LSP Head, Admin: up, Oper: up
  Tun ID: 65437, LSP ID: 1, Source: 3.3.3.3
  Destination: 5.5.5.5
  Fast Reroute Backup Provided:
    Protected i/fs: Fa0/0.36
    Protected LSPs/Sub-LSPs: 1, Active: 0
    Backup BW: any pool unlimited; inuse: 0 kbps
    Backup flags: 0x0




primary one-hop auto-tunnels

It must be configured on every router you want to create a TE tunnel to all the TE-enabled routers that are one hop away. Each auto-tunnel has "autoroute announce" and "fast-reroute" activated by default, but you can add some extra configuration too.

That way you can create automatically multiple tunnels covering all possible paths in a network.

IOS
mpls traffic-eng auto-tunnel primary onehop

IOS-XR
not supported


Extra options available:

IOS
R1(config)#mpls traffic-eng auto-tunnel primary ?
  config      Config commands to apply to all primary auto-tunnels
  onehop      Automatically create tunnel to all next-hops
  timers      Configure timers for backup auto-tunnels
  tunnel-num  Configure tunnel I/F numbers for primary auto-tunnels



You can enable "debug mpls traffic-eng auto-tunnel primary all" if you want to see the actual cli commands used to create the primary one-hop auto-tunnels.

IOS
R1#debug mpls traffic-eng auto-tunnel primary all
MPLS TE Auto-Tunnel Primary all debugging is on
 

TE_AUTO_TUN: Found a new router id 2.2.2.2 off of FastEthernet0/0
TE_AUTO_TUN: primary CLI command:
interface tunnel65336
no logging event link-status
ip unnumbered Loopback0
tunnel destination 2.2.2.2
tunnel mode mpls traffic-eng
end

TE_AUTO_TUN: primary CLI command:
interface tunnel65336
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng fast-reroute
end

TE_AUTO_TUN: CLI command:
ip explicit-path name __dynamic_tunnel65336
  index 1 next-address 10.1.2.1

TE_AUTO_TUN: primary CLI command:
interface tunnel65336
tunnel mpls traffic-eng path-option 1 exp name __dynamic_tunnel65336
end

TE_AUTO_TUN: Found  Down Tunnel65336 to router id 2.2.2.2 out FastEthernet0/0



auto-tunnel mesh groups

It must be configured on the PE routers. After activation, it creates a mesh of TE tunnels to all the PE routers which are either configured for the same mesh-group (assuming OSPF is used), or their TE Id is matched by an ACL. The address that are used in the ACL must exist in the TE database in order to have the auto-tunnel created..

IOS
mpls traffic-eng auto-tunnel mesh
!
access-list 1 permit 20.20.20.20

access-list 1 permit 30.30.30.30
!
interface Auto-Template1
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination access-list 1
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 1 dynamic



The interface auto-template is configured like a normal TE tunnel.

You can also use explicit paths, which use the exclude-address keyword.


IOS-XR (4.1.1)
mpls traffic-eng
 auto-tunnel mesh
  group 99

   destination-list 1
!
ipv4 prefix-list 1
 10 permit 20.20.20.20/32

 20 permit 30.30.30.30/32

You cannot configure Inter-Area or Inter-AS tunnels for auto-tunnel mesh groups.

You cannot configure a static route to route traffic over auto-tunnel mesh group TE tunnels. You should use only the autoroute for tunnel selection. 

In IOS-XR there is no need to configure a dynamic path-option; it's enabled by default.

When using mesh-group numbers (instead of an ACL) to match the PEs, you have to enable IGP flooding of mesh information under the IGP of the PEs.

IOS
interface Auto-Template1
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination mesh-group 99
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 1 dynamic
!

router ospf 1
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 mpls traffic-eng mesh-group 99 Loopback0 area 0



R2#sh mpls traffic-eng topology | i mg
Area mg-id's:
: mg-id 99    1.1.1.1 :


R2#sh mpls traffic-eng auto-tunnel mesh

Auto-Template1:

 Using mesh-group 99 to clone the following tunnel interfaces:

  Destination         Interface
  -----------         ---------

  1.1.1.1             Tunnel64336

Mesh tunnel interface numbers: min 64336 max 65335



IS-IS does not support IGP distribution of mesh group information.You have to use ACLs in this case.

You can also define manually the min/max tunnel numbers used.



SRLG (Shared Risk Link Groups)

When enabled it allows you to define links that belong to the same group, because they share a risk (i.e two links using the same fiber path).

The idea is to have backup tunnels avoid using links in the same SRLG as the interfaces they are protecting. Otherwise, when the protected link fails the backup tunnel will fail too.


Configuration
  • assign interfaces to SRLGs
  • enable backup auto-tunnels globally (IOS) or per interface (IOS-XR)
  • configure backup auto-tunnels to avoid SRLGs (always or if possible)


IOS
interface X
 mpls traffic-eng srlg 1

 mpls traffic-eng srlg 2
!
interface Y
 mpls traffic-eng srlg 2
 mpls traffic-eng srlg 3

!
mpls traffic-eng auto-tunnel backup

mpls traffic-eng auto-tunnel backup srlg exclude force



IOS-XR (4.1.0)
srlg
 interface X
  value 1
  value 2
 !
 interface Y
  value 2
  value 3

!
mpls traffic-eng
 interface X
  auto-tunnel backup
   exclude srlg preferred
 


You can have multiple SRLG values per interface.

IOS default is "preferred", while IOS-XR default is "force".

Only backup auto-tunnels can be used.


Links



Inter-Area MPLS TE

Inter-Area MPLS TE Tunnels are not supported by the default configuration.

Two solutions:
  • per domain: ERO loose-hop expansion
  • distributed: Path Computation Element (PCE)

ERO loose-hop expansion

A loosely routed explicit path must be defined for the tunnel LSP that identifies each ABR the LSP should traverse using the "next-address loose" command. The head-end router and the ABRs along the specified explicit path expand automatically the loose hops, each one computing the strict path segment to the next ABR or tunnel destination.

MPLS TE is configured as usually, with the following change:
  • You have to use loose next-hops on the TE Tunnels towards the ABRs

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 4.4.4.4
 tunnel mpls traffic-eng path-option 1 explicit name EXPPATH

!
ip explicit-path name EXPPATH enable
 next-address loose 2.2.2.2

 next-address loose 3.3.3.3


IOS-XR
interface tunnel-te0
 ipv4 unnumbered Loopback0
 destination 4.4.4.4
 path-option 1 explicit name EXPPATH
!

explicit-path name EXPPATH
 index 1 next-address loose ipv4 unicast 2.2.2.2

 index 2 next-address loose ipv4 unicast 3.3.3.3


Specifying the tunnel tail-end in a loosely routed path is optional. You need to define only the ABRs as next-address loose and each ABR will automatically find the strict next-address for the next ABR or for the final destination.

You can use "debug mpls traffic-eng path" and "debug mpls traffic-eng tunnels" debugs on the head-end and the ABRs to troubleshoot any issues.

IOS
R1#debug mpls traffic-eng path ?
  <0-65535>  Show debug output for this tunnel only
  api        Path calculation API events
  dump       Path calculation detail info
  errors     Path calculation errors events
  lookup     Path calculation lookup events
  spf        Path calculation SPF events
  verify     Path calculation verify events


R1#debug mpls traffic-eng tunnels ?
  auto-bw          MPLS Traffic Engineering tunnel auto-bw
  errors           MPLS Traffic Engineering tunnel errors
  events           MPLS Traffic Engineering tunnel system events
  fast-reroute     MPLS Traffic Engineering tunnel fast reroute
  labels           MPLS Traffic Engineering tunnel labels
  path-protection  MPLS Traffic Engineering tunnel path protection
  reoptimize       MPLS Traffic Engineering tunnel reoptimization
  signalling       MPLS Traffic Engineering tunnel signalling
  state            MPLS Traffic Engineering tunnel state machine
  timers           MPLS Traffic Engineering tunnel timers



As an alternative for an inter-area tunnel crossing different areas, you could configure a sequence of intra-area tunnels, each one crossing one of the areas between source and destination routers, in such a way that the traffic arriving on one tunnel is forwarded into the next tunnel and so on.


OSPF

  • An ABR has visibility into the TE topology of all areas where it's attached to.
  • An area 0 router has visibility into the TE topology of area 0 only.
  • An non-transit area router has visibility into the TE topology of that area only.

Always keep in mind that first you have to enable MPLS TE for all interested areas.

You can use the following abbreviations when filtering the output in order to quickly verify the OSPF area & TE topology per router. Just compare the number of nodes and links on the output vs the ones on the diagram.

IOS
R3#sh mpls traffic-eng top | i TE Id
IGP Id: 1.1.1.1, MPLS TE Id:1.1.1.1 Router Node  (ospf 1  area 1)
IGP Id: 2.2.2.2, MPLS TE Id:2.2.2.2 Router Node  (ospf 1  area 1)
IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3 Router Node  (ospf 1  area 0)
IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3 Router Node  (ospf 1  area 1)
IGP Id: 4.4.4.4, MPLS TE Id:4.4.4.4 Router Node  (ospf 1  area 0)
IGP Id: 4.4.4.4, MPLS TE Id:4.4.4.4 Router Node  (ospf 1  area 1)
IGP Id: 5.5.5.5, MPLS TE Id:5.5.5.5 Router Node  (ospf 1  area 0)
IGP Id: 6.6.6.6, MPLS TE Id:6.6.6.6 Router Node  (ospf 1  area 0)


R1#sh mpls traffic-eng top | i TE Id|Address
IGP Id: 1.1.1.1, MPLS TE Id:1.1.1.1 Router Node  (ospf 1  area 1)
          frag_id 1, Intf Address:10.1.2.1
IGP Id: 2.2.2.2, MPLS TE Id:2.2.2.2 Router Node  (ospf 1  area 1)
          frag_id 9, Intf Address:20.2.3.2
          frag_id 10, Intf Address:20.2.4.2
          frag_id 2, Intf Address:10.1.2.2
IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3 Router Node  (ospf 1  area 1)
          frag_id 5, Intf Address:20.2.3.3
IGP Id: 4.4.4.4, MPLS TE Id:4.4.4.4 Router Node  (ospf 1  area 1)
          frag_id 5, Intf Address:20.2.4.4




ISIS

In case of ISIS & MPLS TE, the L1/L2 router is considered as the ABR.
  • A L1 router has visibility into the TE topology of L1 only
  • A L2 router has visibility into the TE topology of L2 only
  • A L1/L2 router has visibility into the TE topology of both L1/L2 

Always keep in mind that first you have to enable MPLS TE for all interested levels.

You can use the following abbreviations when filtering the output in order to quickly verify the ISIS L1/L2 and TE topology per router. Just compare the number of nodes and links on the output vs the ones on the diagram.

IOS
R5#sh mpls traffic-eng top | i TE Id
IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node  (isis  level-1)
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-1)
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-2)
IGP Id: 0000.0000.0019.00, MPLS TE Id:10.0.0.19 Router Node  (isis  level-2)
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-1)
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-2)


R5#sh mpls traffic-eng top | i TE Id|Address
IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.220.2
          frag_id 0, Intf Address:10.0.25.2
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.25.5
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-2)
          frag_id 0, Intf Address:10.0.195.5
          frag_id 0, Intf Address:10.0.205.5
IGP Id: 0000.0000.0019.00, MPLS TE Id:10.0.0.19 Router Node  (isis  level-2)
          frag_id 0, Intf Address:10.0.195.19
          frag_id 0, Intf Address:10.19.20.19, Nbr Intf Address:10.19.20.20
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.220.20
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-2)
          frag_id 0, Intf Address:10.0.205.20
          frag_id 0, Intf Address:10.19.20.20, Nbr Intf Address:10.19.20.19



IOS-XR
R2#sh mpls traffic-eng topology | i TE Id
IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node  (isis  level-1)
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-1)
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-1)


R2#sh mpls traffic-eng topology | i TE Id|Address
IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.220.2
          frag_id 0, Intf Address:10.0.25.2
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.25.5
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node  (isis  level-1)
          frag_id 0, Intf Address:10.0.220.20, Nbr Intf Address:10.0.220.2



Links



Inter-AS MPLS TE

Inter-AS MPLS TE Tunnels are not supported by the default configuration. A loosely routed explicit path must be defined for the tunnel LSP that identifies each ASBR the LSP should traverse using the "next-address loose" command. The head-end router and the ASBRs along the specified explicit path expand automatically the loose hops, each one computing the strict path segment to the next ASBR or tunnel destination.

MPLS TE is configured as usually, with the following two changes:
  • You have to use loose next-hops on the TE Tunnels
  • You have to define some manual TE parameters on the ASBRs for their neighbors
ASBR Forced Link Flooding is the process that allows links to be installed (as point-to-point) into the TE database, although no IGP is running on them. In order to activate that functionality you just need to configure a link as passive for MPLS TE and provide the neighbor's TE-Id and ip address.

  • OSPF
    • uses opaque LSAs (Type 10) containing a single link TLV
    • only information about the link that has changed is flooded
  • IS-IS
    • uses Type 22 TLVs
    • information about all links on a node is flooded

There is no need for full communication (i.e. eBGP, static) to exist between the AS for an Inter-AS LSP to become functional, unless a backup LSP is required too.


Head-end

IOS
interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 9.9.9.9
 tunnel mpls traffic-eng path-option 1 explicit name R4-R5-EXPPATH
!

ip explicit-path name R4-R5-EXPPATH enable
 next-address loose R4
 next-address loose R5


IOS-XR
interface tunnel-te0
 ipv4 unnumbered Loopback0
 destination 9.9.9.9
 path-option 1 explicit name R4-R5-EXPPATH
!

explicit-path name R4-R5-EXPPATH
 index 1 next-address loose ipv4 unicast R4
 index 2 next-address loose ipv4 unicast R%




ASBR #1

IOS
interface FastEthernet0/0
 ip address 10.4.5.4 255.255.255.0
 mpls traffic-eng tunnels
 mpls traffic-eng passive-interface nbr-te-id 5.5.5.5 nbr-if-addr 10.4.5.5
 ip rsvp bandwidth


IOS-XR
PCE or verbatim option required


ASBR#2

IOS
interface FastEthernet0/0
 ip address 10.4.5.5 255.255.255.0
 mpls traffic-eng tunnels
 mpls traffic-eng passive-interface nbr-te-id 4.4.4.4 nbr-if-addr 10.4.5.4
 ip rsvp bandwidth


IOS-XR
PCE or verbatim option required


Don't forget to enable "mpls traffic-eng tunnels" and "ip rsvp bandwidth" under the inter-as interfaces, like in intra-as MPLS TE scenarios.

You cannot configure IGP enabled interfaces as MPLS-TE passive interfaces.

You can configure multiple passive neighbors under the same interface. If there are multiple neighbors and the AS use different IGPs, then you need to also use the "nbr-igp-id" keyword.

The TE topology should include all MPLS TE enabled interfaces and for the inter-as links the nbr-te-id should be shown as "Nbr Intf Address", like in all p2p links.

IOS
R1#sh mpls traffic-eng topology | i Address
...
          frag_id 0, Intf Address:10.2.4.4
          frag_id 0, Intf Address:10.3.4.4
          frag_id 0, Intf Address:10.4.5.4, Nbr Intf Address:5.5.5.5



The IGP metrics are set to max (shown as "invalid" for ISIS and "MaxLinkMetric" for OSPF), because these routes aren't into RIB, but only into MPLS TE.

IOS sets the TE metric the same as the IGP metric, IOS-XR doesn't.

Configure a TE metric if you want to enable reoptimization for this tunnel.

IOS
R9#sh mpls traffic-eng top | i Addr|metric
...
          frag_id 7, Intf Address:10.5.6.6
          TE metric:1, IGP metric:1, attribute flags:0x0
          frag_id 6, Intf Address:10.4.5.5, Nbr Intf Address:4.4.4.4
          TE metric:invalid, IGP metric:invalid, attribute flags:0x0


R1#sh mpls traffic-eng top | i Addr|metric
...
          frag_id 0, Intf Address:10.3.4.4
          TE metric:10, IGP metric:10, attribute flags:0x0
          frag_id 0, Intf Address:10.4.5.4, Nbr Intf Address:5.5.5.5
          TE metric:MaxLinkMetric, IGP metric:MaxLinkMetric, attribute flags:0x0




Use "sh ip ospf database opaque-area" and "sh isis database verbose" to view the IGP details about the MPLS TE passive links.

You can also use the following commands on the ASBRs to verify the inter-as link.

IOS
R4#show mpls traffic-eng link-management igp-neighbors
...
Link ID::  Fa0/0.45
    Neighbor ID:  5-5-5-5-0-0-0 (force, non-igp IP: 20.4.5.5)
                  up, Sources: Passive
...
Link ID::  Fa0/0.24
    Neighbor ID:  0000.0000.0004.01 (area: isis  level-2, IP: 0.0.0.0)
                  up, Sources: IGP



R4#show mpls traffic-eng link-management advertisements | i Address
    Link IP Address:      20.3.4.4
    Link IP Address:      20.4.5.4
    Link IP Address:      20.4.6.4
    Link IP Address:      20.2.4.4



When viewing the Explicit Route (under the RSVP Path information) of an Inter-AS TE tunnel, loose hops that belong to other AS will be shown with a "*" next to them.

IOS
R1#sh mpls traffic-eng tunnels
...
    RSVP Path Info:
      My Address: 10.1.2.1
      Explicit Route: 10.1.2.2 20.2.3.2 20.2.3.3 3.3.3.3
                      6.6.6.6*



FRR & backup tunnels

Local protection within a domain operates like intra-domain in the Inter-AS LSPs.

When using FRR on the primary Inter-AS tunnel and an Inter-AS backup tunnel for ASBR link/node protection:
  • The explicit path of the backup tunnel must also use loose hops
  • The backup tunnel destination must be included in the RRO of the primary tunnel
  • You need to somehow (i.e. eBGP, static) create a route on the MP router (and all other intra-as routers towards the ASBR) for the backup tunnel's egress ip address, so the RESV messages can be sent from the MP (tail-end of the backup tunnel in one domain) to the PLR (head-end of the backup tunnel in the other domain)

When you're having ip connectivity issues, it might be good practice to enable "debug ip icmp" and watch out for "host unreachable" messages.


Links



MPLS DiffServ-TE

DiffServ-TE allows bandwidth reservations on a per-class basis.

8 Class Types: CT0 - CT7 (CT0 and CT1 are currently used)

These 8 CTs can be combined with the 8 setup/hold priorities creating 64 possible combinations (called TE classes), from where only 8 are actually used (TE0 - TE7). All routers in a network must have a consistent configuration of all the TE classes.


IOS
mpls traffic-eng ds-te te-classes
 te-class 0 class-type 0 priority 0
 te-class 1 class-type 1 priority 7


IOS-XR
mpls traffic-eng
 ds-te te-classes
  te-class 0 class-type 0 priority 0
  te-class 1 class-type 1 priority 7



CT0 is usually used for best effort or pre-DE-TE LSPs and is implicitly signaled
CT1 is usually used for special classes like voice and video and is explicitly signaled

Usually CTs map to scheduler queues for the appropriate QoS actions.

CSPF is enhanced to handle per-CT reservation requirements
IGP is enhanced to carry per-CT available bandwidth at different priorities
RSVP is enhanced to carry a new Class Type Object (CTO) in the PATH message


Bandwidth Constraint Models

BC (Bandwidth Constraint) = the percentage of a link's bandwidth that a CT can use

BC0 = global pool (for best-effort & DiffServ traffic)
BC1 = sub-pool (for strict bandwidth guarantee traffic)

The BC model determines the available bandwidth for each CT at each priority.

Two BC models:
  • MAM (Maximum Allocation Model)
    • RFC 4125
    • the link bandwidth is divided among the different CTs
    • it completely isolates the different CTs
    • different priorities on different CTs do not have any effect
    • bandwidth is wasted due to not being able to share unused bandwidth between CTs
  • RDM (Russian Dolls Model)
    • RFC 4127
    • CTs can share bandwidth on a link
    • no isolation between CTs
    • preemption (using priorities) is required to guarantee bandwidth to a CT
    • bandwidth is utilized more efficiently between CTs

RDM is the default BC model, after enabling IETF DS-TE.

IOS
mpls traffic-eng ds-te mode ietf


IOS-XR
mpls traffic-eng
 ds-te mode ietf


The same mode should be used in all MPLS-TE routers.

IOS
R3#sh mpls traffic-eng top | i BC
BC Model Id: RDM
          BC Model Id: RDM
          BC0 (max_reservable): 75000 (kbps)
          BC0 (max_reservable_bw_global): 0 (kbps)
          BC1 (max_reservable_bw_sub): 0 (kbps)


IOS-XR
GSR#sh mpls traffic top | i BC
My_BC_Model_Type: RDM
      BC Model ID:RDM
      BC0:50000 (kbps) BC1:0 (kbps)
      BC Model ID:RDM
      BC0:50000 (kbps) BC1:0 (kbps)
      BC Model ID:RDM
      BC0:50000 (kbps) BC1:0 (kbps)



Configuration Steps
  • sub-pool (BC1) tunnel
    • choose a specific PHB for classifying the strict guarantee traffic
    • limit the traffic before it enters the tunnel in order to avoid oversubscription
    • mark the traffic with the right EXP while entering the tunnel
    • map the EXP into the appropriate queue at each outgoing interface of every tunnel hop
    • reserve the right percentage of the total sub-pool bandwidth on each outgoing link
  • global pool (BC0) tunnel
    • choose a specific PHB for each class
    • mark each class with the right EXP while entering the tunnel
    • map each EXP into the appropriate queue at each outgoing interface of every tunnel hop
    • reserve the right percentage of the total global pool bandwidth on each outgoing link

IOS
interface Tunnel1
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 6.6.6.6
 tunnel mpls traffic-eng priority 0 0
 tunnel mpls traffic-eng bandwidth sub-pool 444
 tunnel mpls traffic-eng path-option 1 explicit name R4-R5
!
interface FastEthernet0/0
 mpls traffic-eng tunnels
 ip rsvp bandwidth 99999 sub-pool 9999



After switching to IETF DS-TE the above configuration becomes:

IOS
interface Tunnel1
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 6.6.6.6
 tunnel mpls traffic-eng priority 0 0
 tunnel mpls traffic-eng bandwidth 444 class-type 1
 tunnel mpls traffic-eng path-option 1 explicit name R4-R5

!
interface FastEthernet0/0
 mpls traffic-eng tunnels
 ip rsvp bandwidth rdm bc0 99999 bc1 9999



IOS-XR supports either sub-pool or class-type configuration by default.


Links



P2MP LSPs

  • One ingress router
  • Many egress routers
  • Replication (one=>many) happens at branch routers (ingress router can be a branch router too)
  • The path of the P2MP LSP is determined by the branch routers
  • All sub-LSPs of the same P2MP LSP employ the same constraints/policies
  • Traffic is unidirectional, like in P2P LSPs
Two options in control plane:
  • LDP
    • no TE support
    • LSP is initiated by the egress routers
    • Egress routers advertise each one a label for the P2MP FEC towards the branch router
    • Branch routers advertise a single label for the P2MP FEC (for multiple received labels from egress routers) toward the ingress router
    • Ingress routers need to keep state only for the directly connected routers
  • RSVP
    • TE support
    • LSP is initiated by the ingress router
    • Sub-LSPs (like normal LSPs) are created from the ingress router towards each egress router
    • Each sub-LSP has its own PATH/RESV messages, which contain the P2MP Session Object (so that all intermediate routers know the parent LSP where these sub-LSPs belong to)
    • Ingress router sends a PATH message (hop-by-hop) to each egress router (towards the branch router)
    • Branch routers send multiple PATH messages (one for each sub-LSP) towards the multiple egress routers
    • Egress routers receive the PATH messages and each one sends a RESV message towards the branch router
    • Branch routers receive multiple RESV messages (one for each sub-LSP) from each egress router (of a different branch), each one with a different label
    • Branch routers send multiple RESV messages (one for each sub-LSP) towards the ingress router, each one with the same label (since they belong to the same parent P2MP LSP).
    • Ingress router receives multiple RESV messages with the same label from each branch router
    • Ingress routers need to keep state for all egress routers (due to sub-LSPs)


P2MP TE

Limitations
  • Inter-area and inter-as topologies are not supported, only intra-as
  • Node and path protection are not supported, only link protection
  • PIM Sparse is not supported, only SSM
  • Many OAM features are not supported
  • Multiple path-options per destination are not supported, one one path-option per destination
  • PHP is not supported on the tail-end, explicit-null or a normal label must be used
  • Only one backup auto-tunnel is created, to be used for link-protection

Multicast
  • Head-end router and tail-end routers exchange PIM messages with the locally attached CEs
  • MPLS core doesn't need to run PIM
  • PIM doesn't need to be enabled across the MPLS TE tunnel

You can use dynamic paths or explicit paths. If you configure expicit paths that lead to multiple sub-LSPs entering a middle router through different interfaces but exiting through a common interface, then the sub-LSP won't be established (remerge event).

The following apply to all sub-LSPs of the same P2MP LSP:
  • andwidth parameters 
  • hold/setup priorities
  • administrative weight
  • attributes/affinity

Because a sub-LSP cannot be represented as a regular interface on the tail-end router, a special LSP virtual interface (LSPVIF) is automatically created. The LSPVIF represents the originating interface for all IP multicast traffic arriving to the P2MP TE tail-end router. This LSPVIF interface is used for the RPF check.

MPLS-TE should be configured and working between all routers being involved in the P2MP LSPs.


head-end (IOS)
ip multicast-routing
!
ip pim ssm default
!

interface Tunnel0
 ip unnumbered Loopback0
 ip pim passive
 ip igmp static-group 232.20.20.20 source 7.7.7.7
 ip igmp static-group 232.19.19.19 source 7.7.7.7
 ip igmp static-group 232.8.8.8 source 7.7.7.7
 ip igmp static-group 232.2.2.2 source 7.7.7.7
 tunnel mode mpls traffic-eng point-to-multipoint
 tunnel destination list mpls traffic-eng name TAIL-END-ACL

!
mpls traffic-eng destination list name TAIL-END-ACL
 ip 2.2.2.2 path-option 1 dynamic
 ip 19.19.19.19 path-option 1 dynamic
 ip 20.20.20.20 path-option 1 dynamic


For every multicast group you'll need a static igmp under the TE tunnel.

Path-option per sub-LSP can be either dynamic or explicit.


mid-point (IOS)
just normal MPLE-TE config, no multicast required
support of signaling extensions is required 


tail-end (IOS)
ip multicast-routing
ip multicast mpls traffic-eng

!
ip pim ssm default
!
ip mroute 7.7.7.7 255.255.255.255 1.1.1.1

In order to avoid failing on the RPF check on the tail-end router, you must configure a static mroute for the multicast source pointing to the head-end router.


In IOS-XR, the interface "tunnel-mte" is used for P2MP LSPs.

head-end (IOS-XR)
multicast-routing
 address-family ipv4
  interface tunnel-mte0
   enable
!
router igmp
 interface tunnel-mte0
  static-group 232.2.2.2 7.7.7.7
  static-group 232.8.8.8 7.7.7.7
  static-group 232.19.19.19 7.7.7.7
  static-group 232.20.20.20 7.7.7.7
!

interface tunnel-mte0
 ipv4 unnumbered Loopback0
 destination 1.1.1.1
  path-option 1 dynamic
 !
 destination 2.2.2.2
  path-option 1 dynamic
 !
 destination 19.19.19.19
  path-option 1 dynamic



mid-point (IOS-XR)
just normal MPLE-TE config, no multicast required
support of signaling extensions is required


tail-end (IOS-XR)
multicast-routing
 address-family ipv4

  core-tree-protocol rsvp-te
  static-rpf 7.7.7.7 32 mpls 1.1.1.1



IOS-XR 4.2 is required for P2MP LSPs. IOS-XR on C12k doesn't support P2MP LSPs.

IOS-XR doesn't support pings on loopbacks belonging to VRFs under a mVPN topology. Use a physical interface instead.

"multicast-intact" might be required if P2MP and P2P LSPs are created between two nodes.

For P2MP TE FRR protection, the "ip routing protocol purge interface" command is recommended on every penultimate hop router. Otherwise, the traffic can be lost for a few seconds during a FRR cutover event.  


It is assumed that all routers outside the MPLS-TE core are using multicast as usual. So the head-end is having a normal PIM connectivity to the source and the tail-ends are having normal PIM connectivity to the receivers.

Verification

Keep all possible loggings enabled in order to aid in troubleshooting.

IOS
mpls traffic-eng logging lsp path-errors
mpls traffic-eng logging lsp reservation-errors
mpls traffic-eng logging lsp preemption
mpls traffic-eng logging lsp setups
mpls traffic-eng logging lsp teardowns
mpls traffic-eng logging tunnel path change


When the tail-end router creates the LSPVIF interface, you'll get the following log:

%MPLS_TE-5-LSP: Sub-LSP 1.1.1.1[1:3]->2.2.2.2_0: UP
%LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up



head-end (IOS)
R1#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

P2MP TUNNELS:

Tunnel0     (p2mp),  Admin: up, Oper: up
  Name: R1_t0

  Tunnel0 Destinations Information:

    Destination     State SLSP UpTime
    2.2.2.2         Up    01:47:12
    19.19.19.19     Up    01:47:28
    20.20.20.20     Up    01:48:35


    Summary: Destinations: 3 [Up: 3, Proceeding: 0, Down: 0 ]
      [destination list name: TAIL-TE-ACL]

  History:
    Tunnel:
      Time since created: 1 hours, 51 minutes
      Time since path change: 1 hours, 48 minutes
      Number of LSP IDs (Tun_Instances) used: 1
    Current LSP: [ID: 1]
      Uptime: 1 hours, 48 minutes

  Tunnel0 LSP Information:
    Configured LSP Parameters:
      Bandwidth: 0        kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
      Metric Type: TE (default)

  Session Information
    Source: 1.1.1.1, TunID: 0

    LSPs
      ID: 1 (Current), Path-Set ID: 0xA2000001
        Sub-LSPs: 3, Up: 3, Proceeding: 0, Down: 0

      Total LSPs: 1

P2MP SUB-LSPS:

 LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
     P2MP ID: 0, Subgroup Originator: 1.1.1.1
     Name: R1_t0
     Bandwidth: 0, Global Pool

  Sub-LSP to 20.20.20.20, P2MP Subgroup ID: 1, Role: head
    Path-Set ID: 0xA2000001
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3
    Explicit Route: 12.1.3.3 12.3.4.4 12.4.20.20 20.20.20.20
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

  Sub-LSP to 19.19.19.19, P2MP Subgroup ID: 2, Role: head
    Path-Set ID: 0xA2000001
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3
    Explicit Route: 12.1.3.3 12.3.5.5 12.5.6.6 12.6.19.19
                    19.19.19.19
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

  Sub-LSP to 2.2.2.2, P2MP Subgroup ID: 3, Role: head
    Path-Set ID: 0xA2000001
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3
    Explicit Route: 12.1.3.3 12.3.5.5 12.5.6.6 12.2.6.2
                    2.2.2.2
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE



head-end (IOS)
R1#show mpls traffic-eng tunnels brief
Signalling Summary:
    LSP Tunnels Process:            running
    Passive LSP Listener:           running
    RSVP Process:                   running
    Forwarding:                     enabled
    Periodic reoptimization:        every 3600 seconds, next in 3463 seconds
    Periodic FRR Promotion:         Not Running
    Periodic auto-bw collection:    every 300 seconds, next in 163 seconds

P2P TUNNELS/LSPs:
Displayed 0 (of 0) heads, 0 (of 0) midpoints, 0 (of 0) tails

P2MP TUNNELS:
                         DEST        CURRENT
INTERFACE   STATE/PROT  UP/CFG     TUNID  LSPID
Tunnel0     up/up       3/3        0      1
Displayed 1 (of 1) P2MP heads

P2MP SUB-LSPS:
SOURCE        TUNID  LSPID  DESTINATION   SUBID  STATE UP IF      DOWN IF
1.1.1.1       0      1      20.20.20.20   1      Up    head       Fa0/0.13
1.1.1.1       0      1      19.19.19.19   2      Up    head       Fa0/0.13
1.1.1.1       0      1      2.2.2.2       3      Up    head       Fa0/0.13

Displayed 3 P2MP sub-LSPs:
          3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails




head-end (IOS)
R1#show mpls traffic-eng forwarding path-set brief
Sub-LSP Identifier
src_lspid[subid]->dst_tunid              InLabel Next Hop      I/F    PSID
---------------------------              ------- ------------- ------ ----
1.1.1.1_1[1]->20.20.20.20_0              none    12.1.3.3      Fa0/0. A2000001
1.1.1.1_1[2]->19.19.19.19_0              none    12.1.3.3      Fa0/0. A2000001
1.1.1.1_1[3]->2.2.2.2_0                  none    12.1.3.3      Fa0/0. A2000001



head-end (IOS)
R1#show mpls traffic-eng forwarding path-set detail

  LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
  Destination: 20.20.20.20, P2MP Subgroup ID: 1
    Path Set ID: 0xA200000
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3

  LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
  Destination: 19.19.19.19, P2MP Subgroup ID: 2
    Path Set ID: 0xA200000
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3

  LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
  Destination: 2.2.2.2, P2MP Subgroup ID: 3
    Path Set ID: 0xA200000
    OutLabel : FastEthernet0/0.13, 29
    Next Hop : 12.1.3.3


The same commands can also be used on all the intermediate routers.


head-end (IOS)
R1#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(7.7.7.7, 232.20.20.20), 01:03:22/stopped, flags: sTI
  Incoming interface: Serial2/0.100, RPF nbr 192.168.78.7
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 01:03:22/00:02:59

(7.7.7.7, 232.2.2.2), 01:17:17/stopped, flags: sTI
  Incoming interface: Serial2/0.100, RPF nbr 192.168.78.7
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 01:17:17/00:02:59

(7.7.7.7, 232.19.19.19), 01:17:11/stopped, flags: sTI
  Incoming interface: Serial2/0.100, RPF nbr 192.168.78.7
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 01:17:11/00:02:59

(7.7.7.7, 232.8.8.8), 01:17:27/stopped, flags: sTI
  Incoming interface: Serial2/0.100, RPF nbr 192.168.78.7
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 01:17:27/00:02:59



mid-point (IOS)
R3#sh mpls forwarding-table | i 1.1.1.1|Prefix
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
23         Pop Label  1.1.1.1/32       41241         Fa0/0.13   12.1.3.1
29         29         1.1.1.1 0 [1]    2684          Fa0/0.34   12.3.4.4
           16         1.1.1.1 0 [1]    2684          Fa0/0.35   12.3.5.5


On every mid-point router you should see more than one label for the same TE LSP, each one pointing to a different outgoing interface.

mid-point (IOS)
R3#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

P2MP TUNNELS:

P2MP SUB-LSPS:

 LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
     P2MP ID: 0, Subgroup Originator: 1.1.1.1
     Name: R1_t0
     Bandwidth: 0, Global Pool

  Sub-LSP to 20.20.20.20, P2MP Subgroup ID: 1, Role: midpoint
    Path-Set ID: 0x84000001
    InLabel  : FastEthernet0/0.13, 29
    Prev Hop : 12.1.3.1
    OutLabel : FastEthernet0/0.34, 29
    Next Hop : 12.3.4.4
    Explicit Route: 12.3.4.4 12.4.20.20 20.20.20.20
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

  Sub-LSP to 19.19.19.19, P2MP Subgroup ID: 2, Role: midpoint
    Path-Set ID: 0x84000001
    InLabel  : FastEthernet0/0.13, 29
    Prev Hop : 12.1.3.1
    OutLabel : FastEthernet0/0.35, 16
    Next Hop : 12.3.5.5
    Explicit Route: 12.3.5.5 12.5.6.6 12.6.19.19 19.19.19.19
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE

  Sub-LSP to 2.2.2.2, P2MP Subgroup ID: 3, Role: midpoint
    Path-Set ID: 0x84000001
    InLabel  : FastEthernet0/0.13, 29
    Prev Hop : 12.1.3.1
    OutLabel : FastEthernet0/0.35, 16
    Next Hop : 12.3.5.5
    Explicit Route: 12.3.5.5 12.5.6.6 12.2.6.2 2.2.2.2
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE


Sub-LSPs following the same branch (egress interface) will use the same label.


tail-end (IOS)
R2#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(7.7.7.7, 232.2.2.2), 00:28:39/stopped, flags: sLTI
  Incoming interface: Lspvif0, RPF nbr 1.1.1.1, Mroute
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse-Dense, 00:28:39/00:01:20



tail-end (IOS)
R2#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs:

P2MP TUNNELS:

P2MP SUB-LSPS:

 LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1
     P2MP ID: 0, Subgroup Originator: 1.1.1.1
     Name: R1_t0
     Bandwidth: 0, Global Pool

  Sub-LSP to 2.2.2.2, P2MP Subgroup ID: 3, Role: tail
    Path-Set ID: 0x40000001
    InLabel  : FastEthernet0/0.26, 33
    Prev Hop : 12.2.6.6
    OutLabel :  -
    Explicit Route:  NONE
    Record   Route (Path):  NONE
    Record   Route (Resv):  NONE



Links