Maybe I'm missing the details .. BFD if up will install a static route, but if BFD is down it'll withdraw the route. This should solve the issue of is the VLAN up or down since the state will be based on BFD not the link state.. no?
On Thu, 6 Apr 2023 at 11:34, Steven Maddox via uknof < [email protected]> wrote: > No because we're not wanting BFD to control whether there is, or is not, a > static route (which is what that page is talking about). It would seem BFD > can only be linked to things under 'set routing-options' such as static > routes, OSPF, BGP, etc... > > We'd want to use BFD to control whether a pseudowire can or can't form to > to the particular unit it was monitoring... and can't see a way to do that. > > 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. > > On 05/04/2023 15:41, Stephen Wilcox wrote: > > This email originated from OUTSIDE the Internet Central Corporate Network. > Please treat HYPERLINKS and ATTACHMENTS with caution. > You also just run it over a point-to-point eg > https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic-map/bfd-configuring.html > > Doesn't this work for your setup? > > On Wed, 5 Apr 2023 at 14:17, Steven Maddox via uknof < > [email protected]> wrote: > >> 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. >> >> > > > *CONFIDENTIALITY AND DISCLAIMER NOTICE: * > This email is intended only for the person to whom it is addressed and/or > otherwise authorized personnel. The information contained herein and > attached is confidential. If you are not the intended recipient, please be > advised that viewing this message and any attachments, as well as copying, > forwarding, printing, and disseminating any information related to this > email is prohibited, and that you should not take any action based on the > content of this email and/or its attachments. If you received this message > in error, please contact the sender and destroy all copies of this email > and any attachment. Please note that the views and opinions expressed > herein are solely those of the author and do not necessarily reflect those > of the company. While antivirus protection tools have been employed, you > should check this email and attachments for the presence of viruses. No > warranties or assurances are made in relation to the safety and content of > this email and attachments. The Company accepts no liability for any damage > caused by any virus transmitted by or contained in this email and > attachments. No liability is accepted for any consequences arising from > this email. > > *AVIS DE CONFIDENTIALITÉ ET DE NON RESPONSABILITE* : > Ce courriel, ainsi que toute pièce jointe, est confidentiel et peut être > protégé par le secret professionnel. Si vous n’en êtes pas le destinataire > visé, veuillez en aviser l’expéditeur immédiatement et le supprimer. Vous > ne devez pas le copier, ni l’utiliser à quelque fin que ce soit, ni > divulguer son contenu à qui que ce soit. BSO se réserve le droit de > contrôler toute transmission qui passe par son réseau. Veuillez noter que > les opinions exprimées dans cet e-mail sont uniquement celles de l'auteur > et ne reflètent pas nécessairement celles de la société. Bien que des > outils de protection antivirus aient été utilisés, vous devez vérifier cet > e-mail et les pièces jointes pour toute présence de virus. Aucune garantie > ou assurance n'est donnée concernant la sécurité et le contenu de cet > e-mail et de ses pièces jointes. La Société décline toute responsabilité > pour tout dommage causé par tout virus transmis par ou contenu dans cet > e-mail et ses pièces jointes. Aucune responsabilité n'est acceptée pour les > conséquences découlant de cet e-mail. > > -- Stephen Wilcox BSO | IX Reach E: [email protected] M: +44 7966 048633 <+44%207966%20048633> M: +1 305 613 9492 <(305)%20613-9492> -- *CONFIDENTIALITY AND DISCLAIMER NOTICE: * This email is intended only for the person to whom it is addressed and/or otherwise authorized personnel. The information contained herein and attached is confidential. If you are not the intended recipient, please be advised that viewing this message and any attachments, as well as copying, forwarding, printing, and disseminating any information related to this email is prohibited, and that you should not take any action based on the content of this email and/or its attachments. If you received this message in error, please contact the sender and destroy all copies of this email and any attachment. Please note that the views and opinions expressed herein are solely those of the author and do not necessarily reflect those of the company. While antivirus protection tools have been employed, you should check this email and attachments for the presence of viruses. No warranties or assurances are made in relation to the safety and content of this email and attachments. The Company accepts no liability for any damage caused by any virus transmitted by or contained in this email and attachments. No liability is accepted for any consequences arising from this email. *AVIS DE CONFIDENTIALITÉ ET DE NON RESPONSABILITE* : Ce courriel, ainsi que toute pièce jointe, est confidentiel et peut être protégé par le secret professionnel. Si vous n’en êtes pas le destinataire visé, veuillez en aviser l’expéditeur immédiatement et le supprimer. Vous ne devez pas le copier, ni l’utiliser à quelque fin que ce soit, ni divulguer son contenu à qui que ce soit. BSO se réserve le droit de contrôler toute transmission qui passe par son réseau. Veuillez noter que les opinions exprimées dans cet e-mail sont uniquement celles de l'auteur et ne reflètent pas nécessairement celles de la société. Bien que des outils de protection antivirus aient été utilisés, vous devez vérifier cet e-mail et les pièces jointes pour toute présence de virus. Aucune garantie ou assurance n'est donnée concernant la sécurité et le contenu de cet e-mail et de ses pièces jointes. La Société décline toute responsabilité pour tout dommage causé par tout virus transmis par ou contenu dans cet e-mail et ses pièces jointes. Aucune responsabilité n'est acceptée pour les conséquences découlant de cet e-mail.
