Re: [j-nsp] Advertisement of VRRP IP in an EVPN with IRB setup
Am 25.05.2020 16:22, schrieb Roger Wiklund: Hi Why are you using VRRP instead of Virtual Gateway Address? https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/virtual-gateway-address-edit-interfaces.html Hi Roger, i didn't know this feature before. That's what i was looking for. I already got an reply offlist that mentioned virtual-gateway-address Regards, Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP very slow on MX10003
You hit sometimes high response time ( > 14 secs) to collect stats of AE's
units. Could you correlate this timestamp with significant changes on the
router of routing events ?
-Message d'origine-
De : Leon Kramer [mailto:leonkra...@gmail.com]
Envoyé : lundi 25 mai 2020 18:42
À : ROY David DTSI/DERS; juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] SNMP very slow on MX10003
> show snmp stats-response-statistics
Average response time statistics:
StatsStatsAverage
Type ResponsesResponse
Time (ms)
ifd(non ae) 15311162 5.60
ifd(ae) 482105 34.68
ifl(non ae) 5930128 5.96
ifl(ae) 74751690 8.80
firewall 66199433 10.87
Bucket statistics:
Bucket Stats
Type(ms) Responses
0 - 10 117512092
11 - 50 36891316
51 - 100 3645978
101 - 2001647536
201 - 5001330240
501 - 1000 889495
1001 - 2000 707479
2001 - 5000 40989
More than 5001 9393
Bad responses:
ResponseRequestStats Key
Time Type
(ms)(UTC)
14048.002020-04-30 02:26:36ifl(ae)713
13649.322020-05-06 16:50:12ifl(ae)1319
13649.032020-05-06 16:50:12ifl(ae)1320
13648.822020-05-06 16:50:12ifl(ae)1321
13648.592020-05-06 16:50:12ifl(ae)1322
13648.382020-05-06 16:50:12ifl(ae)1323
13647.942020-05-06 16:50:12ifl(ae)1324
13647.722020-05-06 16:50:12ifl(ae)1325
12174.382020-05-19 07:08:22ifl(ae)1517
12145.672020-05-06 16:53:38ifl(ae)3743
12145.422020-05-06 16:53:38ifl(ae)3744
12145.082020-05-06 16:53:38ifl(ae)3745
12144.832020-05-06 16:53:38ifl(ae)3786
12144.522020-05-06 16:53:38ifl(ae)3787
12144.272020-05-06 16:53:38ifl(ae)3788
12144.052020-05-06 16:53:38ifl(ae)3789
12143.772020-05-06 16:53:38ifl(ae)3790
12143.492020-05-06 16:53:38ifl(ae)3791
12143.222020-05-06 16:53:38ifl(ae)3792
12143.002020-05-06 16:53:38ifl(ae)3793
Am Mo., 25. Mai 2020 um 18:32 Uhr schrieb :
>
> Hello
>
> Could you issue this command & share the output : show snmp
> stats-response-statistics
>
> Otherwise, we use telemetry to collect, among other things, interface stats.
>
> David
>
>
> -Message d'origine-
> De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de
> Leon Kramer
> Envoyé : lundi 25 mai 2020 18:26
> À : juniper-nsp@puck.nether.net
> Objet : [j-nsp] SNMP very slow on MX10003
>
> Hello,
>
> we meter approximately 500 logical subinterface counters (e.g. ae0.95,
> ae0.96, etc) of our Juniper MX10003. While this works it is also too
> slow as we fetch the data every 60 seconds.
>
> snmpbulkwalks of IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets take
> anything from 1 to 180 seconds.
>
> The time it takes increases noticeably as more subinterfaces are configured.
>
> I know Juniper is not known for fast SNMP queries, but is there
> anything you can do to increase performance? 500 interfaces should
> really not be too much for a fairly new router imho.
> We already have some interface filters in place, but apparently they
> are not sufficient.
>
> If you think that SNMP is too slow, what alternative can you recommend
> for fetching interface counters?
>
> Thank you for your help.
>
>
> Kind Regards
> Leon Kramer
>
>
> > show version
> Model: mx10003
> Junos: 18.4R2-S3
>
>
> > show configuration snmp
> interface [ fxp0.0 ];
> filter-interfaces {
> interfaces {
> "fe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> "xe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> "ge-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> "et-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> }
> all-internal-interfaces;
> }
> filter-duplicates;
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> routing-instance-access;
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
>
Re: [j-nsp] SNMP very slow on MX10003
> show snmp stats-response-statistics
Average response time statistics:
StatsStatsAverage
Type ResponsesResponse
Time (ms)
ifd(non ae) 15311162 5.60
ifd(ae) 482105 34.68
ifl(non ae) 5930128 5.96
ifl(ae) 74751690 8.80
firewall 66199433 10.87
Bucket statistics:
Bucket Stats
Type(ms) Responses
0 - 10 117512092
11 - 50 36891316
51 - 100 3645978
101 - 2001647536
201 - 5001330240
501 - 1000 889495
1001 - 2000 707479
2001 - 5000 40989
More than 5001 9393
Bad responses:
ResponseRequestStats Key
Time Type
(ms)(UTC)
14048.002020-04-30 02:26:36ifl(ae)713
13649.322020-05-06 16:50:12ifl(ae)1319
13649.032020-05-06 16:50:12ifl(ae)1320
13648.822020-05-06 16:50:12ifl(ae)1321
13648.592020-05-06 16:50:12ifl(ae)1322
13648.382020-05-06 16:50:12ifl(ae)1323
13647.942020-05-06 16:50:12ifl(ae)1324
13647.722020-05-06 16:50:12ifl(ae)1325
12174.382020-05-19 07:08:22ifl(ae)1517
12145.672020-05-06 16:53:38ifl(ae)3743
12145.422020-05-06 16:53:38ifl(ae)3744
12145.082020-05-06 16:53:38ifl(ae)3745
12144.832020-05-06 16:53:38ifl(ae)3786
12144.522020-05-06 16:53:38ifl(ae)3787
12144.272020-05-06 16:53:38ifl(ae)3788
12144.052020-05-06 16:53:38ifl(ae)3789
12143.772020-05-06 16:53:38ifl(ae)3790
12143.492020-05-06 16:53:38ifl(ae)3791
12143.222020-05-06 16:53:38ifl(ae)3792
12143.002020-05-06 16:53:38ifl(ae)3793
Am Mo., 25. Mai 2020 um 18:32 Uhr schrieb :
>
> Hello
>
> Could you issue this command & share the output : show snmp
> stats-response-statistics
>
> Otherwise, we use telemetry to collect, among other things, interface stats.
>
> David
>
>
> -Message d'origine-
> De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de
> Leon Kramer
> Envoyé : lundi 25 mai 2020 18:26
> À : juniper-nsp@puck.nether.net
> Objet : [j-nsp] SNMP very slow on MX10003
>
> Hello,
>
> we meter approximately 500 logical subinterface counters (e.g. ae0.95,
> ae0.96, etc) of our Juniper MX10003. While this works it is also too
> slow as we fetch the data every 60 seconds.
>
> snmpbulkwalks of IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets take
> anything from 1 to 180 seconds.
>
> The time it takes increases noticeably as more subinterfaces are configured.
>
> I know Juniper is not known for fast SNMP queries, but is there
> anything you can do to increase performance? 500 interfaces should
> really not be too much for a fairly new router imho.
> We already have some interface filters in place, but apparently they
> are not sufficient.
>
> If you think that SNMP is too slow, what alternative can you recommend
> for fetching interface counters?
>
> Thank you for your help.
>
>
> Kind Regards
> Leon Kramer
>
>
> > show version
> Model: mx10003
> Junos: 18.4R2-S3
>
>
> > show configuration snmp
> interface [ fxp0.0 ];
> filter-interfaces {
> interfaces {
> "fe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> "xe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> "ge-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> "et-[0-9]/[0-9]/[0-9]+\.[0-9]+";
> }
> all-internal-interfaces;
> }
> filter-duplicates;
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> community xxx {
> authorization read-only;
> routing-instance mgmt_junos;
> }
> routing-instance-access;
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie.
Re: [j-nsp] SNMP very slow on MX10003
Hi, On 25.05.2020 18:25, Leon Kramer wrote: If you think that SNMP is too slow, what alternative can you recommend for fetching interface counters? Probably the canonical answer these days is streaming telemetry which can be done directly from the PFE for a lot of counters. In a former life when SNMP got too slow we sometimes switches to screenscraping "show interfaces | display XML" via SSH/netconf. But this would only help if the data itself is presented fast enough. We had boxes where presenting thh data itself towards the cli/SNMP agent was the bottleneck so the method of pulling it made no difference. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP very slow on MX10003
Hello
Could you issue this command & share the output : show snmp
stats-response-statistics
Otherwise, we use telemetry to collect, among other things, interface stats.
David
-Message d'origine-
De : juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] De la part de
Leon Kramer
Envoyé : lundi 25 mai 2020 18:26
À : juniper-nsp@puck.nether.net
Objet : [j-nsp] SNMP very slow on MX10003
Hello,
we meter approximately 500 logical subinterface counters (e.g. ae0.95,
ae0.96, etc) of our Juniper MX10003. While this works it is also too
slow as we fetch the data every 60 seconds.
snmpbulkwalks of IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets take
anything from 1 to 180 seconds.
The time it takes increases noticeably as more subinterfaces are configured.
I know Juniper is not known for fast SNMP queries, but is there
anything you can do to increase performance? 500 interfaces should
really not be too much for a fairly new router imho.
We already have some interface filters in place, but apparently they
are not sufficient.
If you think that SNMP is too slow, what alternative can you recommend
for fetching interface counters?
Thank you for your help.
Kind Regards
Leon Kramer
> show version
Model: mx10003
Junos: 18.4R2-S3
> show configuration snmp
interface [ fxp0.0 ];
filter-interfaces {
interfaces {
"fe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
"xe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
"ge-[0-9]/[0-9]/[0-9]+\.[0-9]+";
"et-[0-9]/[0-9]/[0-9]+\.[0-9]+";
}
all-internal-interfaces;
}
filter-duplicates;
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
routing-instance-access;
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SNMP very slow on MX10003
Hello,
we meter approximately 500 logical subinterface counters (e.g. ae0.95,
ae0.96, etc) of our Juniper MX10003. While this works it is also too
slow as we fetch the data every 60 seconds.
snmpbulkwalks of IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets take
anything from 1 to 180 seconds.
The time it takes increases noticeably as more subinterfaces are configured.
I know Juniper is not known for fast SNMP queries, but is there
anything you can do to increase performance? 500 interfaces should
really not be too much for a fairly new router imho.
We already have some interface filters in place, but apparently they
are not sufficient.
If you think that SNMP is too slow, what alternative can you recommend
for fetching interface counters?
Thank you for your help.
Kind Regards
Leon Kramer
> show version
Model: mx10003
Junos: 18.4R2-S3
> show configuration snmp
interface [ fxp0.0 ];
filter-interfaces {
interfaces {
"fe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
"xe-[0-9]/[0-9]/[0-9]+\.[0-9]+";
"ge-[0-9]/[0-9]/[0-9]+\.[0-9]+";
"et-[0-9]/[0-9]/[0-9]+\.[0-9]+";
}
all-internal-interfaces;
}
filter-duplicates;
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
community xxx {
authorization read-only;
routing-instance mgmt_junos;
}
routing-instance-access;
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] flow-active-timeout apparently ignored on MX204
Hello,
I see a problem with IPFIX Flow Export on an Juniper MX204 device.
We have approximately 80 Gbps Egress and 40 Ingress Traffic going
through this router with input sampling enabled on every interface and
output sampling disabled. The sampling rate is set to 2500 and works
basically but the flows seem flawed.
This has been noticed when we received a notification of supposedly
250 Gbps egress DDOS attack. Analysis showed that there was only a
single flow sent by the MX204 router for this particular flow. The
flow was probably a backup job through an IPSEC-Tunnel with constantly
100 Mbps for around 12 hours resulting in the very big flow export of
250 Gbps. So it seems that the MX204 is accumulating active flows for
even a very long period ignoring the flow-active-timeout setting. This
of course is creating trouble for flow based services.
Looking at flow exports / second statistics for MX204 we also see a
very flat line once there are around 3200 flows/second. In comparison:
Our MX10003 running with the same version and configuration has a nice
curve for flow exports / second.
We have had MX480 running with IPFIX and same sampling rate without
any issues. I wonder if The MX204 really cannot handle more than 3200
flows.
This situation with active flow accumulation could only be improved by
lowering the sample rate to even lower values. After doing this the
active-flow-timeout apparently also worked again. As MX480 worked
perfectly fine I hope the MX204 can do so either.
If anyone can help with this issue to improve the situation I am
thankful for your help.
Kind Regards
Leon Kramer
> show version
Model: mx204
Junos: 18.4R2-S3
> show services accounting flow inline-jflow fpc-slot 0
Flow information
FPC Slot: 0
Flow Packets: 13228303295, Flow Bytes: 6472971946326
Active Flows: 41659, Total Flows: 16231808905
Flows Exported: 17168991038, Flow Packets Exported: 4317826420
Flows Inactive Timed Out: 7017316323, Flows Active Timed Out: 8789666564
Total Flow Insert Count: 7442142341
IPv4 Flows:
IPv4 Flow Packets: 13195410076, IPv4 Flow Bytes: 6446418303883
IPv4 Active Flows: 41547, IPv4 Total Flows: 16203134906
IPv4 Flows Exported: 17139188812, IPv4 Flow Packets exported: 4290996954
IPv4 Flows Inactive Timed Out: 7003594699, IPv4 Flows Active Timed
Out: 8774863492
IPv4 Flow Insert Count: 7428271414
IPv6 Flows:
IPv6 Flow Packets: 32893219, IPv6 Flow Bytes: 26553642443
IPv6 Active Flows: 112, IPv6 Total Flows: 28673999
IPv6 Flows Exported: 29802226, IPv6 Flow Packets Exported: 26829466
IPv6 Flows Inactive Timed Out: 13721624, IPv6 Flows Active Timed
Out: 14803072
IPv6 Flow Insert Count: 13870927
> show services accounting errors inline-jflow fpc-slot 0
Error information
FPC Slot: 0
Flow Creation Failures: 15998072
Route Record Lookup Failures: 9623950, AS Lookup Failures: 9623950
Export Packet Failures: 174967
Memory Overload: No, Memory Alloc Fail Count: 0
IPv4:
IPv4 Flow Creation Failures: 15998069
IPv4 Route Record Lookup Failures: 9283780, IPv4 AS Lookup Failures: 9283780
IPv4 Export Packet Failures: 174836
IPv6:
IPv6 Flow Creation Failures: 3
IPv6 Route Record Lookup Failures: 340170, IPv6 AS Lookup Failures: 340170
IPv6 Export Packet Failures: 131
> show services accounting status inline-jflow fpc-slot 0
Status information
FPC Slot: 0
IPV4 export format: Version-IPFIX, IPV6 export format: Version-IPFIX
BRIDGE export format: Not set, MPLS export format: Not set
IPv4 Route Record Count: 1612737, IPv6 Route Record Count: 175463,
MPLS Route Record Count: 0
Route Record Count: 1788200, AS Record Count: 835618
Route-Records Set: Yes, Config Set: Yes
Service Status: PFE-0: Steady
Using Extended Flow Memory?: PFE-0: No
Flex Flow Sizing ENABLED?: PFE-0: No
IPv4 MAX FLOW Count: 4891446, IPv6 MAX FLOW Count: 349389
BRIDGE MAX FLOW Count: 1024, MPLS MAX FLOW Count: 1024
> show configuration forwarding-options
sampling {
instance {
export_flows {
input {
rate 2500;
run-length 0;
max-packets-per-second 65535;
}
family inet {
output {
flow-server x.x.x.x {
port 4739;
source-address x.x.x.x;
version-ipfix {
template {
IPv4;
}
}
}
flow-server x.x.x.x {
port 4739;
source-address x.x.x.x;
version-ipfix {
template {
IPv4;
}
}
}
inline-jflow {
Re: [j-nsp] Advertisement of VRRP IP in an EVPN with IRB setup
Hi
Why are you using VRRP instead of Virtual Gateway Address?
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/virtual-gateway-address-edit-interfaces.html
/Roger
On Wed, May 20, 2020 at 2:51 PM Alex D. wrote:
> Hello,
>
> i'm trying to setup a multihomed EVPN with IRB and VRRP (see
> configuration below). I know, that i could omit VRRP configuration and
> use the same IP on irb interfaces of the participating PE routers for
> next-hop redundancy. But from an operational perspective, i find it
> useful to have a possibility to ping the local IPs with knowing who
> reponds to my ICMP requests. The local IP/MAC addresses are advertised
> with the default gateway extended community as expected and are
> pingable, but unfortunatly the VRRP IP isn't. Is there a knob to
> activate this ?
>
> EVPN_DHCP {
> instance-type virtual-switch;
> route-distinguisher :1001;
> vrf-target target:1001:1001;
> protocols {
> evpn {
> extended-vlan-list [ 122 132 ];
> }
> }
> bridge-domains {
> VLAN-122 {
> vlan-id 122;
> no-arp-suppression;
> interface ae10.122;
> routing-interface irb.122;
> }
> VLAN-132 {
> vlan-id 132;
> no-arp-suppression;
> interface ae10.132;
> routing-interface irb.132;
> }
> }
> }
>
> irb {
> unit 122 {
> description dhcp-2-fttx-lan2;
> family inet {
> address 192.168.202.53/29 {
> vrrp-group 122 {
> virtual-address 192.168.202.54;
> priority 200;
> fast-interval 200;
> accept-data;
> authentication-type md5;
> authentication-key "$9$L2N7w2oJDH.5BI"; ## SECRET-DATA
> }
> }
> }
> }
> unit 132 {
> description dhcp-3-fttx-lan2;
> family inet {
> address 192.168.202.61/29 {
> vrrp-group 132 {
> virtual-address 192.168.202.62;
> priority 200;
> fast-interval 200;
> accept-data;
> authentication-type md5;
> authentication-key "$9$L2N7w2oJDH.5BI"; ## SECRET-DATA
> }
> }
> }
> }
> }
>
> Regards,
> Alex
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
