cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10874
Views
0
Helpful
34
Replies

MPLS TE FA query

ulatif
Level 1
Level 1

MPLS TE FA requires bidirectional LSPs but I havent been able to get sufficient reasoning as to why it needs bidir LSPs

(I read that CSPF does some bidir checks before installing it but I need some more insight into this)

Anyone has more detailed knowledge on why FA requires bidir LSPs ?

1 Accepted Solution

Accepted Solutions

You should consider two scenarios:

(A) The tail-end LSR advertises point-to-point adjacency to head-end LSR without having an actual transport path. This is plain stupid and it's not hard to build a scenario resulting in a routing loop.

(B) The head-end LSR adverises point-to-point link to the tail-end LSR in its LSA, the tail-end LSR doesn't advertise the adjacency, but other routers still consider the unidirectional adjacency in their SPF algorithm. In OSPF case, this is a clear violation of step 2.b of algorithm described in Section 16.1 of RFC 2328 (page 163 of the RFC).

There are very good reasons why the bidirectional check is in mandated in the SPF algorithm and even if a vendor X might decide it's time to break the RFC rules (and maybe even call that "innovation") the third-party routers (from vendors still believing in following the RFCs) in a mixed-vendor network would ignore such "adjacencies".

Fixed an obvious stupidity: I write about "LSRs" not "LSPs"

View solution in original post

34 Replies 34

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Ulatif,

I made some search on the web and I've found two recent RFCs

http://tools.ietf.org/html/rfc5439

http://tools.ietf.org/html/rfc4206

here FA means Forwarding Adjacencies.

the RFCs describe possible multi-level approaches for MPLS TE scalability something like PE to PE tunnels that are not setup over physical links but over a full mesh of these FA MPLS TE tunnels.

From this hierarchical approach can come this need for bidirectional tunnels that is something new to me too.

Hope to help

Giuseppe

Hi Giuseppe,

It was more of a Cisco restriction that bidir LSPs must be established for FA to work so I was not sure if this was a Cisco restriction, RFC requirement or more of a necessity. Just need more insight into why?

Cisco talks about this restriction here:

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fstefa_3.html#wp1029775

thanks

Usman

Hi Usman,

I have never used this feature myself, but reading the configuration guide you quoted, this says not to use "autoroute announce" in the tunnel configs. This would indicate to me that it could be more to do with CEF and the LSP hops in the CEF adjacencies.

This is just a general thought, i'll be reading up on this for sure now!

Regards,

Joe.

Thanks Joe

[We need to catchup (my MSN is stuffed these days).]

Hi Usman,

Yes we do need to catch up mate.

I have done some further reading and would like to explain what I understand to you, for yours and my benefit.

If we consider the following topology:

R1--------R2--------R4-------------R5-------R7

R1--------R3-------------------------R6-------R7

If we build a TE tunnel between R2->R5 and then also between R3->R6 for R1 to get to R7 it doesn't know about the TE tunnels, it only knows and bases its SPF decisions based on the IGP metrics. So, to get the TE tunnel considered in SPF calculations we need to use the FA command under the tunnel configurations and Ra can take advantage of the dual paths (as to why we use TE in the first place). So because of this, the tunnels need to be bidir as from the perspective of R1 and R7, who don't know or care about the TE tunnels and only care about IP Link connectivity, they need to make sure there is a LSP for their packets/labels to travel over to get to their destinations within the other POP/AS.

During this process, IS-IS still runs bidirectional checks. This means that if you have a TE tunnel from R2 to R5 that you've configured with you
also need to have a similarly configured tunnel from R5 to R2 in order for forwarding adjacency to be considered in R1's IGP SPF. If you don't, even after receiving IS-IS LSPs about the tunnel link, R1 will not install it in the routing table because only one of the links is up.

HTH

Cheers,

Joe.

Joe,

Remember (in your example), R2 -> R5 tunnel is one entity and R5 -> R2 tunnel is a separate entity - they dont have any direct interaction.

So why would OSPF/ISIS care about a forward path through a TE LSP and reverse path through an LDP LSP etc ?

If a bidirectional check is performed, but I need to know why?

Hey Usman,

Well the only reason I can see why is because once the FA is advertised in the IGP its treated as an IP Link and not a TE Tunnel, and therefore you cannot send TE reservation messages across/over it. So because of this, your TE Tunnel will not come up, so there has to be a way for the IGP to see the link as up and that is done by IS-IS bidir checks. OSPF doesn't support FA, only IS-IS

Remember in my example R1 and R7 are P routers and the PE(ASBRs) are R2, R3 and R5, R6. TE was formed between the ASBRs and then advertised to the P routers.

Cheers,

Joe.

Hi Joe,

Answers/questions inline -

"Well the only reason I can see why is because once the FA is advertised in the IGP its treated as an IP Link and not a TE Tunnel, and therefore you cannot send TE reservation messages across/over it. So because of this, your TE Tunnel will not come up, "

USMAN>> TE tunnel does come up, it always comes up and is treated as TE tunnel i.e. you can reserve bandwidth etc over it.

"so there has to be a way for the IGP to see the link as up and that is done by IS-IS bidir checks. OSPF doesn't support FA, only IS-IS"

USMAN>> OSPF supports FA.

regards

Usman

Hi Usman,

I know its a TE tunnel and therefore does the reservation messages and so forth. I was more talking about from the perspective of R1 and R7 where TE isn't configured and just see's the route in its routing table/ IGP database.

Yes OSPF does support FA, the Cisco Press book I was reading over needs to be updated as it says only IS-IS and not OSPF.

We should discuss this over the phone.

Cheers,

Joe.

ISIS or the common OSPF protocol doesnt perform bidirectional checks.

I think this bidirectional check is made by CSPF. But still dont know why :)

Hi Usman,

Yes it is only for SPF. Like I explained above, SPF only see's the link as an IP Link and not as a TE Tunnel. So, for SPF to advertise the link into the IGP it has to know its path to and from the destination for the link to be up in the SPF database. If you think of basic LSP FECs, you need a FEC to go over the tunnel in 1 direction, and a FEC to come back over the link in the opposite direction. If we only configure a TE Tunnel Uni-directionally, traffic R1 sends to R7 will go over the TE tunnel R2 to R5 but if there is no TE Tunnel from R5 to R2 then SPF will decide on a different path based on the IGP Metrics. By nature, TE LSP's are bidirectional as CSPF requires reservation messages towards the destination, and on its return path. But for TE FA to work in both ways, there needs to be 2 tunnels, 1 in each direction so return traffic will go over the TE Tunnel.

HTH.


Cheers,

Joe.

Joe,

"Yes it is only for SPF. Like I explained above, SPF only see's the link as an IP Link and not as a TE Tunnel. So, for SPF to advertise the link into the IGP it has to know its path to and from the destination for the link to be up in the SPF database. If you think of basic LSP FECs, you need a FEC to go over the tunnel in 1 direction, and a FEC to come back over the link in the opposite direction. If we only configure a TE Tunnel Uni-directionally, traffic R1 sends to R7 will go over the TE tunnel R2 to R5 but if there is no TE Tunnel from R5 to R2 then SPF will decide on a different path based on the IGP Metrics"

USMAN>> If that was the case, why can't SPF see the return path as a normal link (instead of TE) which would be there already.

By nature, TE LSP's are bidirectional as CSPF requires reservation messages towards the destination, and on its return path. But for TE FA to work in both ways, there needs to be 2 tunnels, 1 in each direction so return traffic will go over the TE Tunnel.

USMAN>> By nature, TE LSPs are uni-directional

Hi Usman,

Let me summarise in one post what I have been trying to say above.

  • CSPF performs a SPF check that will decide the SPF between the MPLS TE endpoints. This SPF may or may not be the SPF based on the IGP. The LSP nail up along the SPF.

  • The CSPF does make sure that the path is bidir, but that is to ensure that the SPF will support an end to end LSP. The LSP must be bidir otherwise it is broken.

  • By nature, not configuration, MPLS-TE's are bi-dir (CSPF with RSVP) but for TE FA, there needs to be 2 FA's and therefore are bi-dir by nature and configuration.

Thus, you could say that CSPF makes sure that the path selected is bidir to ensure that you don't have a broken LSP.  If the SPF is not bidir, the LSP will not work. An LSP underpins an MPLS TE Tunnel. As it's a targeted LDP session, and as such must be bi-directional.

Cheers,

Joe.

Message was edited by: jcozzupoli

Hello Joe, Usman

from the link provided by Usman

1)the feature overview clearly states:

The MPLS TE Forwarding Adjacency feature allows a network administrator to handle a traffic engineering, label-switched path (LSP) tunnel as a link in an Interior Gateway Protocol (IGP) network based on the Shortest Path First (SPF) algorithm. A forwarding adjacency can be created between routers regardless of their location in the network. The routers can be located multiple hops from each other, as shown in Figure 1.

My understanding is that MPLS TE are unidirectional in the forwarding plane, the fact that RSVP messages used to setup the tunnel need to be exchanged is part of signalling plane and of course requires bidirectional messages but it is a distinct aspect.

As it is reasonable to build an FA a pair of tunnels have to be used with the command to declare the forwarding adjacencies

from the same link:

2) Note:

You must configure a forwarding adjacency on two LSP tunnels bidirectionally, from A to B and B to A. Otherwise, the forwarding adjacency is advertised, but not used in the IGP network.

The objective is to build the equivalent of a direct link between A and B.

Hope to help

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: