--- Begin Message ---
On 29/03/2023 12:41, Richard Halfpenny wrote:   
BGP to the customer's own router/firewall?      
        
Sure BGP, BFD, OSPF, ICMP, lots of stuff the customers router could do, which we can check for (ICMP being the most ubiquitous and simplest to just check for a non-reply). However the problem with this approach is finding an elegant way for the Juniper to automatically take that non-reply as a reason to drop the related pseudowire path... whilst at the same time knowing when its back to then allow that path to reform! The hope is to still try and find a way of doing this using the features of a Juniper only.
        
But here is a possible inelegant way!.. 
        
Imagine for a moment you've got two suppliers NNIs on a QFX5100... one as ge-1/0/1 (e.g. BT Wholesale) and one as ge-1/0/2 (e.g. TalkTalk).
        
A customer has two leased lines coming in on that same QFX5100, one is their primary line as unit ge-1/0/1.100 and one is their backup line as unit ge-1/0/2.200. Coincidentally unit 100 uses VLAN 100 and unit 200 uses VLAN 200 :)
        
However the customers public /30 (for Internet access) lives on an MX480 on unit lt-4/0/0.999. You want lt-4/0/0.999 to form a pseudowire to ge-1/0/1.100 (primary path), unless that destination unit is "down", in which case form it to ge-1/0/1.200 (secondary path). But still keep checking to see if the primary path becomes possible again and swap back to it when it can automatically.
        
But ge-1/0/1.100 and ge-1/0/1.200 won't ever go "down" (as they're VLANs on an NNI).
        
We *could* put two extra units on the QFX of ge-1/0/1.10100 (also listening to vlan 100) and ge-1/0/1.10200 (vlan 200) that just have private subnets on them (that customers router would also need). Then some script (running on the QFX) could do ping tests to see which is working, and the one that isn't working gets its pseudowire config purefully hobbled (forcing the MX480 to use the other path) and then when it returns working... unhobble it :P
        
        
On 29/03/2023 05:48, scott via uknof wrote:     
BFD is made for this (Both up and down) if the provider will do that with you
Well that's my thoughts exactly, which is why I mentioned BFD in the original e-mail.
        
But with Junipers it seems that BFD must be tied to something else (e.g. a static route, BGP, OSPF, etc...) and it can't be tied to whether a unit should be considered a valid endpoint for a pseudowire or not :S
        
At least, not anything we've found!     
        
        
On 28/03/2023 13:13, James Greig wrote: 
we monitor for a "significant traffic drop"   
        
Yeah we use Observium too, although lately we've begun to regret it as some of their users seem, err fanatical? The other month I accidentally pasted my clipboard into their Discord (about a dozen words, nothing long), unfortunately one of their users fancies themselves as a codebreaker... and thought they'd "deciphered" the word 'LibreNMS' in the contents (and we don't even use LibreNMS, we pay for Observium). Apparently any mention of that project (even if you just plainly didn't mention it!?) gets you an instant and permanent ban... it's completely nutty there!
        
As for your approach though... ultimately I'd be worried that it'd mean pseudowires would flip between circuits in the middle of night when usage goes low.
        

Steven Maddox
Business Systems Engineer
Internet Central Limited

Registered in England & Wales number 03079542 at Ivy House Foundry, Stoke-on-Trent, ST1 3NR. VAT registration number GB278923705. Read our disclaimer at http://ic.uk/legal before acting on this e-mail.


--- End Message ---

Reply via email to