IP Fast Reroute , LFA (Loop Free Alternate) , Remote LFA and in general recovery and protection discussion. In this post, I will share the discussion with one of my slack group member, Driss Jabbar. He is a CCDE and highly skilled network engineer and also author of some posts in this website. You can contact him on Linkedin.
I share this post with his permission.
I asked in the group whether anyone deployed EIGRP FRR (I don’t mean EIGRP Feasible Successor, EIGRP Fast Reroute feature). Driss replied that He deployed IP Fast Reroute for his OSPF network. We talked about his deployment, specifically from the protection,restoration point of view. Hope this real life experience help you in someway.
Hello guys, anyone deployed EIGRP FRR in production ?
I did for ospf
Not for eigrp
for production or in the lab Driss ?
still working ?
What do you mean?
any problem with it ?
I’am using it for a small mpls service provider
To cover all kind of failure
so for their topology, coverage is 100%
per link or per prefix
Per prefix as i have only loopback interfaces
In my routing table
Thanks to suppress prefix
prefix suppression you mean ?
how many prefixes approximately you suprress with it
so, routers and the links per router etc
We have 2 core routeurs (P) and about 20 PE
not much from the scalability aspect but providrd cleaner routing table
why remote lfa ? Didnt regular LFA cover all the failure scenarios ?
each PE is connected to both P,so in reality i have no need for remote lfa everywhere
But in a place where i have a circle topology
I have activate it
in a ring , LFA creates microloop
and you had to find a PQ node
now, in case of failure, link or node , did you do the test ?
yes i am here too
so i was saying that the majority of our PE were connected to both P router
so we see all other PE loopbacks from two side
where you have a ring topology then
in a place where we don’t have control on the fiber links
and the customer has bought the more economic topology (ring) from another fiber provider
and on that place i ve used remote-LFA
in the other places the frr is based only on ECMP
Between your PEs and the Ps, are you utilizing LAG or ECMPs ?
you answered already
i am typing from the phone
fast as always 🙂
but if you are doing ECMP, in case of failure, are you seeing any performance benefit with IP FRR ?
i think ECMP handle FRR well,because you have both routes in your FIB and the reroute was very fast in my test
so i decided to reduce configuration complexity when i could
yes thats what I mean. Do you need IP FRR, in your case LFA , while you already have ECMP
you dont need it
IP FRR should be used in special cases and i did in my ring topology.
what about this
i could let IP FRR in all my network but i always prefer to make it simple as much as i can
for me and for the support team
you said it is MPLS network, probably for transport LSP signalling you are using LDP, did you consider to run RSVP- TE , so you could have MPLS TE FRR , rather than IP FRR
why i have to activate an extra protocol (RSVP) if i can treat FRR with only ECMP
keep it simple is my best solution
thats okay, MPLS TE FRR would be an option in case your topology is not covered 100% for all failures and you are looking 100% coverage.
But in your case, topology is simple and is covered by IP FRR without introducing additional control plane
are you running Multicast on your core network ?
my the network we are supporting is a special service provider who deliver only L2 services for others service providers like in france like orange,SFR,COLT….etc
so we are delivering only L2 services
okay , multicast us transperent to your network
you are not providing Internet access or L3 MPLS VPNs
you are not providing residential service as well right
none of these
we are working only with service providers delivering them connexions to them customers
i would ask if you have BGP FRR , since would be an option as you have an IGP FRR
it depends right
if it’s IBGP, what’s matter is the next hop gateway,if it’s reachable from BGP point of view everything is ok
and this next hop is handled all the time by IGP protocols so i will keep using IGP FRR for IBGP
sure. the problem is not only that
if you have a multiple BGP next hop for the same prefix, hoe quickly you will start using the second next hop.i vase primary one fails
BGP PIC Edge
and if you dont wanna wait BGP Control plane to converge, you wanna change the BGP next hop for all affected prefixes as quickly as possible
it depends of your design and your architecture
IGP FRR will help for the first case which you described , it is also called as BGP PIC Core
anyine here runs BGP PIC in production ?
as long as you have more than one route in your FIB table you will be fine with FRR
sure , if uou have IBGP multipath
but you know that, multipath is not enabled by default in BGP as in the case with IGP
founding the best solution denpend to the constraint you face
sure i know
and you can use this option if you don’t have RR in the middle otherwise BGP add path will be a good choice
shadow RR i think
what about L2 service
you said you are providing L2 service to the other Providers
what type of service you provide
99% is P2P
and 1% VPLS
okay, as we discuss about protection , are you providing fast protection for them ?
by the way, how you deploy p2p service ?
with PW ?
Martini or Kompella ?
for the time being
what about protection ?
do you have AD for Martini or is it manual ?
we are protect some of them using back-tunnel
all is manual
one way or two ways PW protection ?
are you using control word
we are protecting the point of delivery
no, we don’t use control word