Re: link monitoring

2021-04-30 Thread Michel Blais 
Y.1731 or TWAMP if available on those devices.

Le ven. 30 avr. 2021 17:57, Colton Conor  a écrit :

> What NMS is everyone using to graph and alert on this data?
>
> On Fri, Apr 30, 2021 at 7:49 AM Alain Hebert  wrote:
>
>> Yes the JNP DOM MIB is what you are looking for.
>>
>> It also the traps for warnings and alarms thresholds you can use
>> which is driven by the optic own parameters.
>> ( Human Interface: show interfaces diagnostics optics  ] )
>>
>> TLDR:
>>
>> Realtime: Traps;
>> Monitoring: DOM MIB;
>>
>> PS: I suggest you join [ juniper-...@puck.nether.net ] mailing list.
>>
>> -
>> Alain Hebertaheb...@pubnix.net
>> PubNIX Inc.
>> 50 boul. St-Charles
>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
>> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>>
>> On 4/29/21 5:32 PM, Eric Kuhnke wrote:
>>
>> The Junipers on both sides should have discrete SNMP OIDs that respond
>> with a FEC stress value, or FEC error value. See blue highlighted part here
>> about FEC. Depending on what version of JunOS you're running the MIB for it
>> may or may not exist.
>>
>>
>> https://kb.juniper.net/InfoCenter/index?page=content=KB36074=MX2008=LIST
>>
>> In other equipment sometimes it's found in a sub-tree of SNMP adjacent to
>> optical DOM values. Once you can acquire and poll that value, set it up as
>> a custom thing to graph and alert upon certain threshold values in your
>> choice of NMS.
>>
>> Additionally signs of a failing optic may show up in some of the optical
>> DOM MIB items you can poll:
>> https://mibs.observium.org/mib/JUNIPER-DOM-MIB/
>>
>> It helps if you have some non-misbehaving similar linecards and optics
>> which can be polled during custom graph/OID configuration, to establish a
>> baseline 'no problem' value, which if exceeded will trigger whatever
>> threshold value you set in your monitoring system.
>>
>> On Thu, Apr 29, 2021 at 1:40 PM Baldur Norddahl <
>> baldur.nordd...@gmail.com> wrote:
>>
>>> Hello
>>>
>>> We had a 100G link that started to misbehave and caused the customers to
>>> notice bad packet loss. The optical values are just fine but we had packet
>>> loss and latency. Interface shows FEC errors on one end and carrier
>>> transitions on the other end. But otherwise the link would stay up and our
>>> monitor system completely failed to warn about the failure. Had to find the
>>> bad link by traceroute (mtr) and observe where packet loss started.
>>>
>>> The link was between a Juniper MX204 and Juniper ACX5448. Link length 2
>>> meters using 2 km single mode SFP modules.
>>>
>>> What is the best practice to monitor links to avoid this scenarium? What
>>> options do we have to do link monitoring? I am investigating BFD but I am
>>> unsure if that would have helped the situation.
>>>
>>> Thanks,
>>>
>>> Baldur
>>>
>>>
>>>
>>

Re: link monitoring

2021-04-30 Thread Colton Conor 
What NMS is everyone using to graph and alert on this data?

On Fri, Apr 30, 2021 at 7:49 AM Alain Hebert  wrote:

> Yes the JNP DOM MIB is what you are looking for.
>
> It also the traps for warnings and alarms thresholds you can use which
> is driven by the optic own parameters.
> ( Human Interface: show interfaces diagnostics optics  ] )
>
> TLDR:
>
> Realtime: Traps;
> Monitoring: DOM MIB;
>
> PS: I suggest you join [ juniper-...@puck.nether.net ] mailing list.
>
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>
> On 4/29/21 5:32 PM, Eric Kuhnke wrote:
>
> The Junipers on both sides should have discrete SNMP OIDs that respond
> with a FEC stress value, or FEC error value. See blue highlighted part here
> about FEC. Depending on what version of JunOS you're running the MIB for it
> may or may not exist.
>
>
> https://kb.juniper.net/InfoCenter/index?page=content=KB36074=MX2008=LIST
>
> In other equipment sometimes it's found in a sub-tree of SNMP adjacent to
> optical DOM values. Once you can acquire and poll that value, set it up as
> a custom thing to graph and alert upon certain threshold values in your
> choice of NMS.
>
> Additionally signs of a failing optic may show up in some of the optical
> DOM MIB items you can poll:
> https://mibs.observium.org/mib/JUNIPER-DOM-MIB/
>
> It helps if you have some non-misbehaving similar linecards and optics
> which can be polled during custom graph/OID configuration, to establish a
> baseline 'no problem' value, which if exceeded will trigger whatever
> threshold value you set in your monitoring system.
>
> On Thu, Apr 29, 2021 at 1:40 PM Baldur Norddahl 
> wrote:
>
>> Hello
>>
>> We had a 100G link that started to misbehave and caused the customers to
>> notice bad packet loss. The optical values are just fine but we had packet
>> loss and latency. Interface shows FEC errors on one end and carrier
>> transitions on the other end. But otherwise the link would stay up and our
>> monitor system completely failed to warn about the failure. Had to find the
>> bad link by traceroute (mtr) and observe where packet loss started.
>>
>> The link was between a Juniper MX204 and Juniper ACX5448. Link length 2
>> meters using 2 km single mode SFP modules.
>>
>> What is the best practice to monitor links to avoid this scenarium? What
>> options do we have to do link monitoring? I am investigating BFD but I am
>> unsure if that would have helped the situation.
>>
>> Thanks,
>>
>> Baldur
>>
>>
>>
>

Weekly Routing Table Report

2021-04-30 Thread Routing Analysis Role Account 
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 01 May, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  857706
Prefixes after maximum aggregation (per Origin AS):  324495
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  407244
Total ASes present in the Internet Routing Table: 71169
Prefixes per ASN: 12.05
Origin-only ASes present in the Internet Routing Table:   61198
Origin ASes announcing only one prefix:   25266
Transit ASes present in the Internet Routing Table:9971
Transit-only ASes present in the Internet Routing Table:314
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  38
Max AS path prepend of ASN ( 37385)  33
Prefixes from unregistered ASNs in the Routing Table:  1058
Number of instances of unregistered ASNs:  1065
Number of 32-bit ASNs allocated by the RIRs:  35885
Number of 32-bit ASNs visible in the Routing Table:   29866
Prefixes from 32-bit ASNs in the Routing Table:  139106
Number of bogon 32-bit ASNs visible in the Routing Table:24
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:584
Number of addresses announced to Internet:   3031167104
Equivalent to 180 /8s, 171 /16s and 240 /24s
Percentage of available address space announced:   81.9
Percentage of allocated address space announced:   81.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  291034

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   226664
Total APNIC prefixes after maximum aggregation:   65431
APNIC Deaggregation factor:3.46
Prefixes being announced from the APNIC address blocks:  222811
Unique aggregates announced from the APNIC address blocks:89728
APNIC Region origin ASes present in the Internet Routing Table:   11550
APNIC Prefixes per ASN:   19.29
APNIC Region origin ASes announcing only one prefix:   3306
APNIC Region transit ASes present in the Internet Routing Table:   1631
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 31
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6706
Number of APNIC addresses announced to Internet:  772731136
Equivalent to 46 /8s, 14 /16s and 241 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-143673
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:246824
Total ARIN prefixes after maximum aggregation:   113053
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   247249
Unique aggregates announced from the ARIN address blocks:117945
ARIN Region origin ASes present in the Internet Routing Table:18784
ARIN Prefixes per ASN:13.16
ARIN

Re: link monitoring

2021-04-30 Thread Alain Hebert 

    Yes the JNP DOM MIB is what you are looking for.

    It also the traps for warnings and alarms thresholds you can use 
which is driven by the optic own parameters.

    ( Human Interface: show interfaces diagnostics optics  ] )

    TLDR:

        Realtime: Traps;
        Monitoring: DOM MIB;

    PS: I suggest you join [ juniper-...@puck.nether.net ] mailing list.

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 4/29/21 5:32 PM, Eric Kuhnke wrote:
The Junipers on both sides should have discrete SNMP OIDs that respond 
with a FEC stress value, or FEC error value. See blue highlighted part 
here about FEC. Depending on what version of JunOS you're running the 
MIB for it may or may not exist.


https://kb.juniper.net/InfoCenter/index?page=content=KB36074=MX2008=LIST 



In other equipment sometimes it's found in a sub-tree of SNMP adjacent 
to optical DOM values. Once you can acquire and poll that value, set 
it up as a custom thing to graph and alert upon certain threshold 
values in your choice of NMS.


Additionally signs of a failing optic may show up in some of the 
optical DOM MIB items you can poll: 
https://mibs.observium.org/mib/JUNIPER-DOM-MIB/ 



It helps if you have some non-misbehaving similar linecards and optics 
which can be polled during custom graph/OID configuration, to 
establish a baseline 'no problem' value, which if exceeded will 
trigger whatever threshold value you set in your monitoring system.


On Thu, Apr 29, 2021 at 1:40 PM Baldur Norddahl 
mailto:baldur.nordd...@gmail.com>> wrote:


Hello

We had a 100G link that started to misbehave and caused the
customers to notice bad packet loss. The optical values are just
fine but we had packet loss and latency. Interface shows FEC
errors on one end and carrier transitions on the other end. But
otherwise the link would stay up and our monitor system completely
failed to warn about the failure. Had to find the bad link by
traceroute (mtr) and observe where packet loss started.

The link was between a Juniper MX204 and Juniper ACX5448. Link
length 2 meters using 2 km single mode SFP modules.

What is the best practice to monitor links to avoid this
scenarium? What options do we have to do link monitoring? I am
investigating BFD but I am unsure if that would have helped the
situation.

Thanks,

Baldur