Great thread. I want to emphasize (and perhaps ask Saku for clarification), the following statement.
>>All these protocols have hello timers, LDP, ISIS, RSVP, BGP. And each >>of them you'd like to configure to trigger from events without delay >>when possible, instead of relying on timers. Indeed you can have BGP >>next-hop invalidated the moment IGP informs it, allowing rapid >>convergence. When I was a bit greener with our MPLS network I would experience the same concern as Alexandre when a dual connected customer lost a PE, in that I would experience loss of service waiting for BGP to timeout. I briefly went down the wrong path (IMHO) of BFD everywhere, including on directly connected links (yes, I know BFD can help for control plane issues, but 99%+ of the time for us it is 'switch-in-the-middle' problem). I even put multihop BFD on my iBGP sessions, which I later removed. The correct configuration (at least in my experience) was to invalidate BGP next hops, as Saku points out, and keep the BGP session up (assuming outage is less than 60s - 90s and normal timers), so I had no delay in re-estalbishing BGP and repopulating RIB in the flap was brief. In our network, this means the following set routing-options resolution rib inet.0 import limit-inet0-resolution set policy-options policy-statement limit-inet0-resolution term reject-routes from prefix-list-filter limit-inet0-resolution exact set policy-options policy-statement limit-inet0-resolution term reject-routes then reject set policy-options policy-statement limit-inet0-resolution then accept set policy-options prefix-list sync_lists-limit-inet0-resolution 0.0.0.0/0 set policy-options prefix-list sync_lists-limit-inet0-resolution $any_less_specific_routes_for_your_loopbacks Are others doing this? FWIW, we're doing pseudowire, redundant pseudowire, L3VPN and multipoint E-VPN (in that order of preference). Regarding services, like others, I avoid mac learning if at all possible, and have strict mac limits on our E-VPN routing instances. -Michael >>-----Original Message----- >>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf >>Of Saku Ytti >>Sent: Saturday, July 07, 2018 4:24 PM >>To: alexandre.guimar...@ascenty.com >>Cc: Juniper List <juniper-nsp@puck.nether.net> >>Subject: Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc- >>lag) >> >>Hey Alexandre, >> >> >>> When we use l2circuits, you remove some layer of routing protocol >>troubleshooting. In just few command you know what’s going on. >>> In a flap, BGP session will be dropped after timers reached. >>> >>> RSVP/ISIS/LDP will be affect immediately. Also ISIS is the fundamental key >>of everything over here.... >>> With BGP, you have to check everything twice, including filters everywhere >>if someone change this or change that. >> >>All these protocols have hello timers, LDP, ISIS, RSVP, BGP. And each >>of them you'd like to configure to trigger from events without delay >>when possible, instead of relying on timers. Indeed you can have BGP >>next-hop invalidated the moment IGP informs it, allowing rapid >>convergence. >> >>-- >> ++ytti >>_______________________________________________ >>juniper-nsp mailing list juniper-nsp@puck.nether.net >>https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
