Admittedly this late to arrive follow up may not be J specific. Our transit extensions aren't really traditional metro ethernet circuits, topology looks more like following
<us>a-----vlanX----b<shared l2>c-----vlanX---d<transit> The "shared l2" device connects several .edu institutions into major aggregation facilities. link 'a---b' is optically protected. . 'b' to 'c' is actually a vlan-ccc so 'b' and 'c' are already tied but the point is moot. We run BFD with 'd'. If I understand correctly a theoretical eOAM session between 'a' and 'd' could cause both 'a' and 'd' IFLs to drop on end to end connectivity fault but eOAM assumes you manage both eOAM endpoints and is not meant for a cross domain situation. Is it the correct conclusion that eOAM between 'a' and 'd' is unlikely to be supported by any reasonable upstream? In this case 'd' is a tier1. using this URL as a starting point for exploring eOAM https://www.juniper.net/documentation/en_US/junos12.3/topics/example/layer-2-802-1ag-ethernet-oam-cfm-example-over-bridge-connections-mx-solutions.html -Michael From: Alexander Arseniev [mailto:arsen...@btinternet.com] Sent: Wednesday, April 19, 2017 11:19 AM To: Michael Hare <michael.h...@wisc.edu>; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC) Hi Michael, With multiple full tables from two or more eBGP providers + iBGP peers, Your ASBR has to go via BGP best path reselection first before it can start programming FIB. And most specific route always wins, even if it otherwise inferior so BGP has to go over 100,000s of prefixes to find the bests among specific prefixes. JUNOS INH helps at FIB programming stage, not at BGP best path reselection stage. Additionally in recent JUNOS versions, there are improvements made regarding FIB programming speed, please ask Your Juniper account team for details. If You would not have full tables over iBGP peering, then the picture would be simplified in a sense that in case of full-table eBGP peer down its invalidated prefixes need to be only removed, and eBGP 0/0 becomes best path. But I guess You won't like to run the network that way? You can sense L2 failures by using either LACP with single member link (assuming Your Metro Ethernet provider passes LACP PDU), or Ethernet OAM (assuming Your Metro Ethernet provider passes EOAM PDU) or BFD. I would personally rate BFD as tool of last resort as (a) BFD being an UDP/IP protocol means there are many other failures that affect BFD like access-lists (b) even when BFD is down, the BGP session may be still up whereas You want the BFD to follow BGP and (c) BFD failure does not bring the interface down, it just tears down the BGP session whereas LACP failure/EOAM failure brings the logical interface down. Presumably, someone will point out to uBFD over LAG but it still requires LACP so LACP+uBFD is overkill for a simple network UNLESS You are really into microseconds convergence. When I said "JUNOS is different from IOS - BGP session will stay up until holdtime fires ..." - this is default behavior, You don't need to configure anything for it. HTH Thx _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
