Hi Steve, This might not be helpful but I'll throw it out there. On customers that are delivered over an NNI to ourselves we monitor for a "significant traffic drop" in observium which looks for the following:-
ANY / OR ifInOctets_rate le 2 ifOutOctets_rate le 2 ifInUcastPkts_rate equals 0 Delay 3 This works for us but ymmv. This will alert us to issues including single direction which are normally the case. Best Regards, James Greig -----Original Message----- From: Steven Maddox <[email protected]> Sent: 28 March 2023 08:31 To: [email protected] Subject: Monitoring if leased lines are down via an NNI Lo, We use Juniper MX series routers, and take various NNI services from operators like TalkTalk, BT Wholesale, etc... Essentially each VLAN they present on the same particular Juniper interface is a different leased line. But if a leased line goes down, that subinterface (a Juniper 'unit' with a vlan-id on it) doesn't go down. So a) we don't get any alerts, and b) if the customer has a backup leased line, our systems don't know to automatically swap to that. After checking with people like BT Wholesale, it would seem they do get OAM-CFM from Openreach, but then neglect to actually pass that upstream to us. How common is this likely to be with other suppliers? does anyone know if there is something stopping BT Wholesale (or others?) from passing back this information? We know we could supply our own hardware to the customer. But that would mean the customer would have the Openreach ADVA NTU, plus their own router (of their choosing), *and* a third box from us (sitting in between the other two) acting as another NTU... just for this one purpose of generating our own OAM-CFM. Although we deal with Openreach directly for exchanges we've opened up locally (so locally we don't have this issue)... if we're providing leased lines further afield (e.g. sold via BT Wholesale, TalkTalk, etc...) then we can't guarantee a timely replacement of such an extra NTU (that we've supplied) should it fail, as we don't have engineers that far out. One thought was to monitor a thing that the customer was likely to have. This might be to poll for ICMP or listen for BFD polls from their router, and then if it stops... to have the Juniper disconnect what that unit is connected to (e.g. a psuedowire across our MPLS core to where IP or VPLS services are delivered) but continue to listen on the unit to see if it comes back. But there doesn't seem to be any elegant configuration to do this, that we're aware of. Just wondering if anyone had encountered this scenario before and what might be best practice? Thanks -- 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.
