Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

[Aaron]

Thanks folks, 

Maybe you all weren't aware of what happened 

What happened was , I brought up two juniper PE's (acx5048 and mx104) into my 
bgp environment... actually 5048 and 104 were already part of the bgp 
environment , and participating nicely in vpnv4 (l3vpn).

I then enabled bgp mpls l2vpn, and BAMMO !  now listen closely... this brought 
down about 20 other bgp neighbor sessions with 20 different cisco me3600's all 
over my network .  now please, listen closely again, we aren't talking about an 
initial bgp session renegotiation, from this point forward the ME3600's were 
not able to reestablish their bgp sessions at all !

This resulted in about a 30 or 45 minute network wide outage to all of those 
me3600's.

I did "rollback 1" on the juniper 5048 and 104 and finally the me3600's were 
able to settle down and establish bgp neighboring with the dual RR core and all 
is well.

Aaron

p.s. besides, bringing up l2vpn AF on the 5048 and 104 , as I understand it, 
SHOULD NOT, cause any other PE's to renegotiate capabilities and AF's on their 
bgp neighbor sessions with the RR.


-Original Message-
From: Adam Vitkovsky [mailto:adam.vitkov...@gamma.co.uk] 
Sent: Monday, November 23, 2015 5:48 AM
To: Aaron; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

Hi Aaron,

Capabilities are advertised in the OPEN message which is sent during the 
session initialization so naturally when you enable new capability on an 
existing session the session needs to be reset for the OPEN messages to be 
exchanged again.
Unfortunately BGP does not support dynamic capability negotiation yet 
(dynamic-cap  was first proposed in 2002 and ceased in 2012).

Anyways this is why it is very important to run a separate session for each RR 
in the "cluster" (or a separate RR infrastructure per service/set of services 
vMX/XRv) So that when you need to introduce a new feature you can do that 
gradually and don't need to have a flag day on a particular PE.

Other important by-product of this design is resistance to BGP malfunction 
(especially sessions carrying internet routes are susceptible).
Though BGP enhanced error handling in modern code should "hopefully" prevent 
BGP sessions resetting network wide due to unknown BGP msg type passing by, but 
if they do for some reason at least they don't bring down other services (AFs) 
running over the common BGP session.


adam
>

Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


-Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On 
> Behalf Of Aaron
> Sent: Friday, November 20, 2015 6:08 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS 
> interoperability
>
> Can anyone share any experiences with interoperating Cisco and Juniper 
> BGP MPLS L2VPN's ?
>
>
>
> Yesterday I fired up L2VPN configs in my ACX5048 and MX104 in my lab 
> and brought up BGP L2VPN address family and got some bad results
>
>
>
> It caused all of my Cisco ME3600's in my network to send BGP 
> Notifications and drop their MP-BGP neighbor sessions to the Route 
> Reflector core and purge all their vpnv4, vpnv6 and l2vpn topology tables !
>
>
>
> Bad customer impact. lots of trouble.
>
>
>
> "Rollback 1" on ACX and MX and all is well
>
>
>
> Anyway have trouble in this area ?
>
>
>
> Aaron
>
>
>
> P.S. for a couple weeks those same ACX and MX were running just fine 
> with my route reflector core (dual asr9k's) and running fine with BGP 
> MPLS L3VPN's (layer 3) routing-instances. able to talk to the rest of 
> the routing domains, etc.  all that seemed fine.  It was just this 
> L2VPN stuff yesterday was bad.
>
>
>
> ___
> 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

Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

[Adam Vitkovsky]

Hi Aaron,

Capabilities are advertised in the OPEN message which is sent during the 
session initialization so naturally when you enable new capability on an 
existing session the session needs to be reset for the OPEN messages to be 
exchanged again.
Unfortunately BGP does not support dynamic capability negotiation yet 
(dynamic-cap  was first proposed in 2002 and ceased in 2012).

Anyways this is why it is very important to run a separate session for each RR 
in the "cluster" (or a separate RR infrastructure per service/set of services 
vMX/XRv)
So that when you need to introduce a new feature you can do that gradually and 
don't need to have a flag day on a particular PE.

Other important by-product of this design is resistance to BGP malfunction 
(especially sessions carrying internet routes are susceptible).
Though BGP enhanced error handling in modern code should "hopefully" prevent 
BGP sessions resetting network wide due to unknown BGP msg type passing by, but 
if they do for some reason at least they don't bring down other services (AFs) 
running over the common BGP session.


adam
>

Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


-Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Aaron
> Sent: Friday, November 20, 2015 6:08 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability
>
> Can anyone share any experiences with interoperating Cisco and Juniper BGP
> MPLS L2VPN's ?
>
>
>
> Yesterday I fired up L2VPN configs in my ACX5048 and MX104 in my lab and
> brought up BGP L2VPN address family and got some bad results
>
>
>
> It caused all of my Cisco ME3600's in my network to send BGP Notifications
> and drop their MP-BGP neighbor sessions to the Route Reflector core and
> purge all their vpnv4, vpnv6 and l2vpn topology tables !
>
>
>
> Bad customer impact. lots of trouble.
>
>
>
> "Rollback 1" on ACX and MX and all is well
>
>
>
> Anyway have trouble in this area ?
>
>
>
> Aaron
>
>
>
> P.S. for a couple weeks those same ACX and MX were running just fine with
> my route reflector core (dual asr9k's) and running fine with BGP MPLS
> L3VPN's (layer 3) routing-instances. able to talk to the rest of the routing
> domains, etc.  all that seemed fine.  It was just this L2VPN stuff yesterday
> was bad.
>
>
>
> ___
> 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

Re: [j-nsp] inet6 ttl filter / equivalent of hop-limit on non MX series

[Dave Bell]

Hi Scott,

I would drop that accept-traceroute-tcp term. It will allow any TCP
traffic with a TTL of 1. If you can fudge your TTL (Simple on linux,
just write the value to /proc/sys/net/ipv4/ip_default_ttl) then you
can connect to any open TCP port. Additionally I don't think I've seen
a legitimate use case for TCP traceroute.

As for how to implement this in IPv6... I'm unsure. I suspect without
the hop-limit statement being available you are going to be stuffed.
You could just make do with ICMP traceroute, and don't bother with
checking the TTL field.

Regards,
Dave

On 22 November 2015 at 04:22, Scott  wrote:
> Hi All,
>
> I am currently rewriting the inet6 firewall on a M120 and I am trying to
> figure out how I can effectively filter traceroutes, especially tcp, as
> hop-limit is supported on MX MIC/MPC only.
>
> Any pointers are highly appreciated
>
> The config is largely based on the Day One books, here is the inet version
> I am trying to convert
>
> filter accept-traceroute {
> apply-flags omit;
> term accept-traceroute-udp {
> from {
> destination-prefix-list {
> router-ips-ipv4;
> router-ips-logisys-ipv4;
> }
> protocol udp;
> ttl 1;
> destination-port 33434-33523;
> }
> then {
> policer management-1m;
> count accept-traceroute-udp;
> accept;
> }
> }
> term accept-traceroute-icmp {
> from {
> destination-prefix-list {
> router-ips-ipv4;
> router-ips-logisys-ipv4;
> }
> protocol icmp;
> ttl 1;
> icmp-type [ echo-request timestamp time-exceeded ];
> }
> then {
> policer management-1m;
> count accept-traceroute-icmp;
> accept;
> }
> }
> term accept-traceroute-tcp {
> from {
> destination-prefix-list {
> router-ips-ipv4;
> router-ips-logisys-ipv4;
> }
> protocol tcp;
> ttl 1;
> }
> then {
> policer management-1m;
> count accept-traceroute-tcp;
> accept;
> }
> }
> }
>
> Thanks,
>
> Scott
> ___
> 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

Re: [j-nsp] Mx Policy routing problem

[Dave Bell]

Hi Cahit,

> root@mx80-core# show interfaces ae0
> aggregated-ether-options {
>  minimum-links 1;
>  lacp {
>  active;
>  periodic fast;
>  }
> }
> unit 0 {
>  family inet {
>  filter {
>  input FWDirect;
>  }
>  address 10.32.35.14/30;
>  }
> }

> Request timeout for icmp_seq 14714
> 36 bytes from 10.32.35.14: Destination Net Unreachable
> Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
>  4  5  00 5400 938d   0   38  01 d3ad 192.168.2.102  185.9.159.86

This looks like you are sourcing your traffic from the address on
interface ae0? If this is the case, then it is not actually ingressing
ae0, therefore the firewall won't be hit.

Try testing from the thing connected to ae0 (if you can).

Regards,
Dave


On 23 November 2015 at 10:08, Cahit Eyigünlü  wrote:
> Hello friends  ;
>
> We have an MX80 router which has connection on ae0 to our isp
>
>
>
> root@mx80-core# show interfaces ae0
> aggregated-ether-options {
>  minimum-links 1;
>  lacp {
>  active;
>  periodic fast;
>  }
> }
> unit 0 {
>  family inet {
>  filter {
>  input FWDirect;
>  }
>  address 10.32.35.14/30;
>  }
> }
>
>
> [edit]
> root@mx80-core# show firewall
> filter FWDirect {
> term UDPFW {
> from {
> destination-address {
> 185.9.159.86/32;
> }
> protocol udp;
> }
> then {
> log;
> routing-instance UDP-Routes;
> }
> }
> term TCPFW {
> from {
> destination-address {
> 185.9.159.86/32;
> }
> }
> then {
> count TCPFWTR;
> log;
> routing-instance TCP-Routes;
> }
> }
> term Default {
> then accept;
> }
> }
>
> [edit]
> root@mx80-core# show routing-instances
> Normal-Routes {
> instance-type virtual-router;
> }
> TCP-Routes {
> instance-type forwarding;
> routing-options {
> static {
> route 0.0.0.0/0 next-hop 37.123.100.122;
> }
> }
> }
> UDP-Routes {
> instance-type forwarding;
> routing-options {
> static {
> route 0.0.0.0/0 next-hop 37.123.100.98;
> }
> }
> }
>
> [edit]
> root@mx80-core# show protocols ospf
> rib-group SPD-Route;
> area 0.0.0.0 {
> interface all;
> interface ae0.0 {
> disable;
> }
> }
>
> [edit]
>
> root@mx80-core# show routing-options rib-groups
> SPD-Route {
> import-rib [ inet.0 UDP-Routes.inet.0 TCP-Routes.inet.0 ];
> }
>
> [edit]
> root@mx80-core#
>
>
>
> The router has connection to routing instance ip addresses and logging the 
> connections :
>
>
> root@mx80-core# run ping 37.123.100.122
> PING 37.123.100.122 (37.123.100.122): 56 data bytes
> 64 bytes from 37.123.100.122: icmp_seq=0 ttl=64 time=1.194 ms
> 64 bytes from 37.123.100.122: icmp_seq=1 ttl=64 time=0.956 ms
> ^C
> --- 37.123.100.122 ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 0.956/1.075/1.194/0.119 ms
>
> [edit]
> root@mx80-core# run ping 37.123.100.98
> PING 37.123.100.98 (37.123.100.98): 56 data bytes
> 64 bytes from 37.123.100.98: icmp_seq=0 ttl=64 time=0.490 ms
> 64 bytes from 37.123.100.98: icmp_seq=1 ttl=64 time=8.739 ms
> 64 bytes from 37.123.100.98: icmp_seq=2 ttl=64 time=0.422 ms
> ^C
> --- 37.123.100.98 ping statistics ---
> 3 packets transmitted, 3 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 0.422/3.217/8.739/3.905 ms
>
> [edit]
> root@mx80-core# run show firewall log
> Log :
> Time  FilterAction Interface ProtocolSrc Addr 
> Dest Addr
> 08:44:20  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:19  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:18  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:17  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:16  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:15  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:14  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:13  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:12  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:11  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:10  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
> 08:44:09  pfe   A  ae0.0 ICMP212.174.232.182  
> 185.9.159.86
>
>
>
> but we 

[j-nsp] Mx Policy routing problem

[Cahit Eyigünlü]

Hello friends  ;

We have an MX80 router which has connection on ae0 to our isp



root@mx80-core# show interfaces ae0
aggregated-ether-options {
 minimum-links 1;
 lacp {
 active;
 periodic fast;
 }
}
unit 0 {
 family inet {
 filter {
 input FWDirect;
 }
 address 10.32.35.14/30;
 }
}


[edit]
root@mx80-core# show firewall
filter FWDirect {
term UDPFW {
from {
destination-address {
185.9.159.86/32;
}
protocol udp;
}
then {
log;
routing-instance UDP-Routes;
}
}
term TCPFW {
from {
destination-address {
185.9.159.86/32;
}
}
then {
count TCPFWTR;
log;
routing-instance TCP-Routes;
}
}
term Default {
then accept;
}
}

[edit]
root@mx80-core# show routing-instances
Normal-Routes {
instance-type virtual-router;
}
TCP-Routes {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 37.123.100.122;
}
}
}
UDP-Routes {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 37.123.100.98;
}
}
}

[edit]
root@mx80-core# show protocols ospf
rib-group SPD-Route;
area 0.0.0.0 {
interface all;
interface ae0.0 {
disable;
}
}

[edit]

root@mx80-core# show routing-options rib-groups
SPD-Route {
import-rib [ inet.0 UDP-Routes.inet.0 TCP-Routes.inet.0 ];
}

[edit]
root@mx80-core#



The router has connection to routing instance ip addresses and logging the 
connections :


root@mx80-core# run ping 37.123.100.122
PING 37.123.100.122 (37.123.100.122): 56 data bytes
64 bytes from 37.123.100.122: icmp_seq=0 ttl=64 time=1.194 ms
64 bytes from 37.123.100.122: icmp_seq=1 ttl=64 time=0.956 ms
^C
--- 37.123.100.122 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.956/1.075/1.194/0.119 ms

[edit]
root@mx80-core# run ping 37.123.100.98
PING 37.123.100.98 (37.123.100.98): 56 data bytes
64 bytes from 37.123.100.98: icmp_seq=0 ttl=64 time=0.490 ms
64 bytes from 37.123.100.98: icmp_seq=1 ttl=64 time=8.739 ms
64 bytes from 37.123.100.98: icmp_seq=2 ttl=64 time=0.422 ms
^C
--- 37.123.100.98 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.422/3.217/8.739/3.905 ms

[edit]
root@mx80-core# run show firewall log
Log :
Time  FilterAction Interface ProtocolSrc Addr   
  Dest Addr
08:44:20  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:19  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:18  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:17  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:16  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:15  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:14  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:13  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:12  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:11  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:10  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:09  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86



but we can not access from outside the network :



Request timeout for icmp_seq 14714
36 bytes from 10.32.35.14: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 938d   0   38  01 d3ad 192.168.2.102  185.9.159.86

Request timeout for icmp_seq 14715
36 bytes from 10.32.35.14: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 28e7   0   38  01 3e54 192.168.2.102  185.9.159.86

Request timeout for icmp_seq 14716
36 bytes from 10.32.35.14: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 ffb1   0   38  01 6789 192.168.2.102  185.9.159.86

Request timeout for icmp_seq 14717
36 bytes from 10.32.35.14: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 99ee   0   38  01 cd4c 192.168.2.102  185.9.159.86

Request timeout for icmp_seq 14718
36 bytes from 10.32.35.14: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 a9d1   0 

Re: [j-nsp] licence keys for MX104

[Giuliano Medalha]

You will need to install the license to use the onboard SFP+ ports (2 o 4
options)



Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811
+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br
http://www.wztech.com.br/



​
WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2015 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos
são confidenciais e para conhecimento exclusivo do destinatário. Se o
leitor  desta  mensagem  não  for o seu destinatário,
fica desde já notificado de que não poderá  divulgar,  distribuir ou, sob
qualquer forma, dar conhecimento a terceiros das informações e do conteúdo
dos documentos anexos. Neste caso, favor comunicar imediatamente
o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida
apague-o.


CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are
solely for the intended recipient and may contain confidential or
privileged information. If you are not the intended recipient, any review,
transmission,  dissemination or other use of this information is
prohibited. If you have received this communication in error, please notify
the sender immediately and delete the material from any computer, including
any copies.

On Mon, Nov 23, 2015 at 11:56 AM, Matthias Brumm  wrote:

> Hi!
>
> now, that is also a strange thing:
>
> License usage:   Licenses Licenses
> LicensesExpiry   Feature name usedinstalled  needed
> scale-subscriber  0 1000   0 permanent
>  scale-l2tp0 1000   0permanent
> scale-mobile-ip   0 1000   0 permanent
> Licenses installed: none
>
> Am 23.11.2015 um 14:54 schrieb Saku Ytti:
>
>> On 23 November 2015 at 15:51, Matthias Brumm  wrote:
>>
>>> After struggling a week with JTAC they have told me, it may be a licence
>>> issue and I have to install the key. How should I got the keyon purchase?
>>> paper, email?
>>>
>> It should be in envelope shipped with the kit. Keys are not bound to
>> chassis and same key is shipped quite long time. You can also just
>> google for the keys, even juniper.net site has examples with working
>> key.
>> But what does 'show system license' tell, it should confirm if or not
>> it's licensing issue.
>>
>>
> ___
> 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

Re: [j-nsp] licence keys for MX104

[Giuliano Medalha]

The keys came together with the box inside a letter in a box.

Did you check the manuals ?

Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811
+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br
http://www.wztech.com.br/



​
WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2015 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos
são confidenciais e para conhecimento exclusivo do destinatário. Se o
leitor  desta  mensagem  não  for o seu destinatário,
fica desde já notificado de que não poderá  divulgar,  distribuir ou, sob
qualquer forma, dar conhecimento a terceiros das informações e do conteúdo
dos documentos anexos. Neste caso, favor comunicar imediatamente
o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida
apague-o.


CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are
solely for the intended recipient and may contain confidential or
privileged information. If you are not the intended recipient, any review,
transmission,  dissemination or other use of this information is
prohibited. If you have received this communication in error, please notify
the sender immediately and delete the material from any computer, including
any copies.

On Mon, Nov 23, 2015 at 11:51 AM, Matthias Brumm  wrote:

> Hi!
>
> We have purchased a promotional bundle of the MX104 with 2x 10G built-on
> ports and after upgrading to Junos 13.3R6.5 the built-in ports seem to be
> deactivated.
>
> After struggling a week with JTAC they have told me, it may be a licence
> issue and I have to install the key. How should I got the keyon purchase?
> paper, email?
>
> Regards,
>
> Matthias
> ___
> 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

Re: [j-nsp] licence keys for MX104

[Saku Ytti]

On 23 November 2015 at 15:51, Matthias Brumm  wrote:
> After struggling a week with JTAC they have told me, it may be a licence
> issue and I have to install the key. How should I got the keyon purchase?
> paper, email?

It should be in envelope shipped with the kit. Keys are not bound to
chassis and same key is shipped quite long time. You can also just
google for the keys, even juniper.net site has examples with working
key.
But what does 'show system license' tell, it should confirm if or not
it's licensing issue.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] licence keys for MX104

[Matthias Brumm]

Hi!

now, that is also a strange thing:

License usage:   Licenses Licenses
LicensesExpiry   Feature name usedinstalled  needed 
scale-subscriber  0 1000   0 
permanent   scale-l2tp0 1000   0
permanent scale-mobile-ip   0 1000   
0 permanent Licenses installed: none


Am 23.11.2015 um 14:54 schrieb Saku Ytti:

On 23 November 2015 at 15:51, Matthias Brumm  wrote:

After struggling a week with JTAC they have told me, it may be a licence
issue and I have to install the key. How should I got the keyon purchase?
paper, email?

It should be in envelope shipped with the kit. Keys are not bound to
chassis and same key is shipped quite long time. You can also just
google for the keys, even juniper.net site has examples with working
key.
But what does 'show system license' tell, it should confirm if or not
it's licensing issue.



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] licence keys for MX104

[Saku Ytti]

Yeah you're missing the license.

On 23 November 2015 at 15:56, Matthias Brumm  wrote:
> Hi!
>
> now, that is also a strange thing:
>
> License usage:   Licenses Licenses
> LicensesExpiry   Feature name usedinstalled  needed
> scale-subscriber  0 1000   0 permanent
> scale-l2tp0 1000   0permanent
> scale-mobile-ip   0 1000   0 permanent
> Licenses installed: none
>
>
> Am 23.11.2015 um 14:54 schrieb Saku Ytti:
>>
>> On 23 November 2015 at 15:51, Matthias Brumm  wrote:
>>>
>>> After struggling a week with JTAC they have told me, it may be a licence
>>> issue and I have to install the key. How should I got the keyon purchase?
>>> paper, email?
>>
>> It should be in envelope shipped with the kit. Keys are not bound to
>> chassis and same key is shipped quite long time. You can also just
>> google for the keys, even juniper.net site has examples with working
>> key.
>> But what does 'show system license' tell, it should confirm if or not
>> it's licensing issue.
>>
>



-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

[Dale Shaw]

Hi Aaron,

On Tue, Nov 24, 2015 at 6:58 AM, Aaron  wrote:
>
[...]
> p.s. besides, bringing up l2vpn AF on the 5048 and 104 , as I understand
it, SHOULD NOT, cause any other PE's to renegotiate capabilities and AF's
on their bgp neighbor sessions with the RR.

What is your RR platform?

The outage sounded .. painful .. but the common denominator is the RR.

Cheers,
Dale
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

[Adam Vitkovsky]

Hi Aaron,


> From: Aaron [mailto:aar...@gvtc.com]
> Sent: Monday, November 23, 2015 7:58 PM
> I then enabled bgp mpls l2vpn, and BAMMO !  now listen closely... this
> brought down about 20 other bgp neighbor sessions with 20 different cisco
> me3600's all over my network .  now please, listen closely again, we aren't
> talking about an initial bgp session renegotiation, from this point forward 
> the
> ME3600's were not able to reestablish their bgp sessions at all !
>
Are the 20 different me3600's configured with l2vpn AF please?
Are the two RRs configured with l2vpn AF please?
Have you see the sessions bouncing on the me3600's
Are you running code past 15.3(1)S that should be capable of BGP Enhanced 
Attribute Error Handling but now I'm not that sure if MEs do support it,

This really looks like the second case I mentioned where RRs relied an UPDATE 
message that ME3600's perceived as malformed cause they could not parse through 
it.
And either BGP enhanced error handling wasn't enabled or a mandatory attribute 
was affected they ought to reset the session over which such a malformed UPDATE 
message is received.
Once the session is re-established they receive the update again and reset the 
session again -so the whole process loops.
And only stops after the culprit attribute is removed from the update message.

> I did "rollback 1" on the juniper 5048 and 104 and finally the me3600's were
> able to settle down and establish bgp neighboring with the dual RR core and
> all is well.
>

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] User Identity Awareness on SRX

[Syed Iftikhar Ahmed]

http://www.juniper.net/documentation/en_US/junos12.3x48/topics/example/example-userfw-ad.html


From: james list [mailto:jameslis...@gmail.com]
Sent: Monday, November 23, 2015 8:35 PM
To: Syed Iftikhar Ahmed
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] User Identity Awareness on SRX

Could you please send me a reference url ?

Cheers
Thanks

2015-11-23 17:32 GMT+01:00 Syed Iftikhar Ahmed 
>:
Yes, If you need to have user ids populated in logs.
12.1X45-D10 and other support it.

Sent from my iPhone

> On Nov 23, 2015, at 8:29 PM, james list 
> > wrote:
>
> Dear experts,
>
> is SRX supporting the User Identity Awareness feature as Checkpoint does ?
>
>
> http://www.checkpoint.com/products/identity-awareness-software-blade/
>
>
>
> Or any salsa or it ?
>
>
> Any comment  is appreciated.
>
>
> Cheers
>
> James
> ___
> 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

Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

[Aaron]

Thanks Dale, RR’s are (2) cisco asr9000’s (one is a 9006 and the other is a 
9010), configured in a RR cluster.  Both run IOS XR 4.1.2

 

Aaron

 

From: dale.s...@gmail.com [mailto:dale.s...@gmail.com] On Behalf Of Dale Shaw
Sent: Monday, November 23, 2015 4:47 PM
To: Aaron
Cc: Adam Vitkovsky; juniper-nsp@puck.nether.net; arsen...@btinternet.com
Subject: Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

 

Hi Aaron,

On Tue, Nov 24, 2015 at 6:58 AM, Aaron  wrote:
>

[...]
> p.s. besides, bringing up l2vpn AF on the 5048 and 104 , as I understand it, 
> SHOULD NOT, cause any other PE's to renegotiate capabilities and AF's on 
> their bgp neighbor sessions with the RR.

What is your RR platform?

 

The outage sounded .. painful .. but the common denominator is the RR.

 

Cheers,

Dale

 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

[Aaron]

Thanks Dave and Adam, et al, 

Interestingly I just found the following... I looked at the bgp l2vpn vpls all 
summary uptimes of my ME3600's and I saw lots of them that have been up longer 
than Nov 19th when the outage occurred.  So I went and looked at those ME3600's 
that have been up longer than that and found the following versions of IOS in 
my ME3600's and which ones were and were not affected by this outage.

ME3600 - IOS
15.2(4)S1 - NOT affected
15.2(4)S3 - affected
15.2(4)S5 - affected

ASR920 - IOS XE
03.15.00.S - NOT affected

Strange how my ME3600's running S1 were NOT affected by this, but the ME3600's 
running S3 and S5 were.

Log message seen on the 9k and ME3600 during outage...

ME3600...

Nov 19 09:19:09: %BGP-3-NOTIFICATION: sent to neighbor 10.101.0.2 3/10 (illegal 
network) 1 bytes 00
Nov 19 09:19:09: %BGP-4-MSGDUMP: unsupported or mal-formatted message received 
from 10.101.0.2:
        006A 0200  5340 0101 0040 0200 4005
0400  64C0 1010 0002   2774 800A 0502  0064 800A 0400  0180
0904   900E 0020 0019 4104 0A65 0CF8  1500 010A 650C F880  0200
0100 02C3 5001 0100 0200

ASR9k...

RP/0/RSP0/CPU0:Nov 19 09:19:09.383 : bgp[1043]: %ROUTING-BGP-5-ADJCHANGE : 
neighbor 10.101.8.28 Down - BGP Notification received, illegal network (VRF: 
default)

I'm wondering if this was an NLRI problem since we are seeing illegal network 
...  I mean I was wondering previously if it was a capabilities exchange issue, 
but now I'm wondering if it's NLRI related.

Thanks group,

Aaron


-Original Message-
From: Adam Vitkovsky [mailto:adam.vitkov...@gamma.co.uk] 
Sent: Monday, November 23, 2015 5:55 PM
To: Aaron; juniper-nsp@puck.nether.net; arsen...@btinternet.com
Subject: RE: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

Hi Aaron,


> From: Aaron [mailto:aar...@gvtc.com]
> Sent: Monday, November 23, 2015 7:58 PM I then enabled bgp mpls l2vpn, 
> and BAMMO !  now listen closely... this brought down about 20 other 
> bgp neighbor sessions with 20 different cisco me3600's all over my 
> network .  now please, listen closely again, we aren't talking about 
> an initial bgp session renegotiation, from this point forward the 
> ME3600's were not able to reestablish their bgp sessions at all !
>
Are the 20 different me3600's configured with l2vpn AF please?
Are the two RRs configured with l2vpn AF please?
Have you see the sessions bouncing on the me3600's Are you running code past 
15.3(1)S that should be capable of BGP Enhanced Attribute Error Handling but 
now I'm not that sure if MEs do support it,

This really looks like the second case I mentioned where RRs relied an UPDATE 
message that ME3600's perceived as malformed cause they could not parse through 
it.
And either BGP enhanced error handling wasn't enabled or a mandatory attribute 
was affected they ought to reset the session over which such a malformed UPDATE 
message is received.
Once the session is re-established they receive the update again and reset the 
session again -so the whole process loops.
And only stops after the culprit attribute is removed from the update message.

> I did "rollback 1" on the juniper 5048 and 104 and finally the 
> me3600's were able to settle down and establish bgp neighboring with 
> the dual RR core and all is well.
>

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

[Aaron]

Also, I'm pretty sure the way I have my ME3600's configured is, RFC4762 (bgp ad 
w/ldp sig) and my Juniper's are configured as RFC4761 (bgp ad w/bgp sig).

I pretty much understood this as I was config'ing it the other day, but I 
didn't think it would matter since all I wanted to do was get the juniper's 
signaling lsp's with each other... I wonder if that caused problems with the 
other PE's in my network.

Aaron

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Aaron
Sent: Monday, November 23, 2015 9:50 PM
To: 'Adam Vitkovsky'; juniper-nsp@puck.nether.net; arsen...@btinternet.com; 
geord...@gmail.com
Subject: Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

Thanks Dave and Adam, et al, 

Interestingly I just found the following... I looked at the bgp l2vpn vpls all 
summary uptimes of my ME3600's and I saw lots of them that have been up longer 
than Nov 19th when the outage occurred.  So I went and looked at those ME3600's 
that have been up longer than that and found the following versions of IOS in 
my ME3600's and which ones were and were not affected by this outage.

ME3600 - IOS
15.2(4)S1 - NOT affected
15.2(4)S3 - affected
15.2(4)S5 - affected

ASR920 - IOS XE
03.15.00.S - NOT affected

Strange how my ME3600's running S1 were NOT affected by this, but the ME3600's 
running S3 and S5 were.

Log message seen on the 9k and ME3600 during outage...

ME3600...

Nov 19 09:19:09: %BGP-3-NOTIFICATION: sent to neighbor 10.101.0.2 3/10 (illegal 
network) 1 bytes 00 Nov 19 09:19:09: %BGP-4-MSGDUMP: unsupported or 
mal-formatted message received from 10.101.0.2:
        006A 0200  5340 0101 0040 0200 4005
0400  64C0 1010 0002   2774 800A 0502  0064 800A 0400  0180
0904   900E 0020 0019 4104 0A65 0CF8  1500 010A 650C F880  0200
0100 02C3 5001 0100 0200

ASR9k...

RP/0/RSP0/CPU0:Nov 19 09:19:09.383 : bgp[1043]: %ROUTING-BGP-5-ADJCHANGE : 
neighbor 10.101.8.28 Down - BGP Notification received, illegal network (VRF: 
default)

I'm wondering if this was an NLRI problem since we are seeing illegal network 
...  I mean I was wondering previously if it was a capabilities exchange issue, 
but now I'm wondering if it's NLRI related.

Thanks group,

Aaron


-Original Message-
From: Adam Vitkovsky [mailto:adam.vitkov...@gamma.co.uk]
Sent: Monday, November 23, 2015 5:55 PM
To: Aaron; juniper-nsp@puck.nether.net; arsen...@btinternet.com
Subject: RE: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

Hi Aaron,


> From: Aaron [mailto:aar...@gvtc.com]
> Sent: Monday, November 23, 2015 7:58 PM I then enabled bgp mpls l2vpn, 
> and BAMMO !  now listen closely... this brought down about 20 other 
> bgp neighbor sessions with 20 different cisco me3600's all over my 
> network .  now please, listen closely again, we aren't talking about 
> an initial bgp session renegotiation, from this point forward the 
> ME3600's were not able to reestablish their bgp sessions at all !
>
Are the 20 different me3600's configured with l2vpn AF please?
Are the two RRs configured with l2vpn AF please?
Have you see the sessions bouncing on the me3600's Are you running code past 
15.3(1)S that should be capable of BGP Enhanced Attribute Error Handling but 
now I'm not that sure if MEs do support it,

This really looks like the second case I mentioned where RRs relied an UPDATE 
message that ME3600's perceived as malformed cause they could not parse through 
it.
And either BGP enhanced error handling wasn't enabled or a mandatory attribute 
was affected they ought to reset the session over which such a malformed UPDATE 
message is received.
Once the session is re-established they receive the update again and reset the 
session again -so the whole process loops.
And only stops after the culprit attribute is removed from the update message.

> I did "rollback 1" on the juniper 5048 and 104 and finally the 
> me3600's were able to settle down and establish bgp neighboring with 
> the dual RR core and all is well.
>

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal 

Re: [j-nsp] User Identity Awareness on SRX

[Syed Iftikhar Ahmed]

Yes, If you need to have user ids populated in logs.
12.1X45-D10 and other support it.

Sent from my iPhone

> On Nov 23, 2015, at 8:29 PM, james list  wrote:
> 
> Dear experts,
> 
> is SRX supporting the User Identity Awareness feature as Checkpoint does ?
> 
> 
> http://www.checkpoint.com/products/identity-awareness-software-blade/
> 
> 
> 
> Or any salsa or it ?
> 
> 
> Any comment  is appreciated.
> 
> 
> Cheers
> 
> James
> ___
> 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

Re: [j-nsp] User Identity Awareness on SRX

[james list]

Could you please send me a reference url ?

Cheers
Thanks

2015-11-23 17:32 GMT+01:00 Syed Iftikhar Ahmed :

> Yes, If you need to have user ids populated in logs.
> 12.1X45-D10 and other support it.
>
> Sent from my iPhone
>
> > On Nov 23, 2015, at 8:29 PM, james list  wrote:
> >
> > Dear experts,
> >
> > is SRX supporting the User Identity Awareness feature as Checkpoint does
> ?
> >
> >
> > http://www.checkpoint.com/products/identity-awareness-software-blade/
> >
> >
> >
> > Or any salsa or it ?
> >
> >
> > Any comment  is appreciated.
> >
> >
> > Cheers
> >
> > James
> > ___
> > 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

[j-nsp] Policy Based Routing

[Cahit Eyigünlü]

Our network Topology as this :


http://forums.juniper.net/t5/image/serverpage/image-id/12913i3A1C52D8896D0604/image-size/original?v=mpbl-1=-1​




We have an MX80 router which has connection on ae0 to our isp



root@mx80-core# show interfaces ae0
aggregated-ether-options {
 minimum-links 1;
 lacp {
 active;
 periodic fast;
 }
}
unit 0 {
 family inet {
 filter {
 input FWDirect;
 }
 address 10.32.35.14/30;
 }
}


[edit]
root@mx80-core# show firewall
filter FWDirect {
term UDPFW {
from {
destination-address {
185.9.159.86/32;
}
protocol udp;
}
then {
log;
routing-instance UDP-Routes;
}
}
term TCPFW {
from {
destination-address {
185.9.159.86/32;
}
}
then {
count TCPFWTR;
log;
routing-instance TCP-Routes;
}
}
term Default {
then accept;
}
}

[edit]
root@mx80-core# show routing-instances
Normal-Routes {
instance-type virtual-router;
}
TCP-Routes {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 37.123.100.122;
}
}
}
UDP-Routes {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 37.123.100.98;
}
}
}

[edit]
root@mx80-core# show protocols ospf
rib-group SPD-Route;
area 0.0.0.0 {
interface all;
interface ae0.0 {
disable;
}
}

[edit]

root@mx80-core# show routing-options rib-groups
SPD-Route {
import-rib [ inet.0 UDP-Routes.inet.0 TCP-Routes.inet.0 ];
}

[edit]
root@mx80-core#



The router has connection to routing instance ip addresses and logging the 
connections :


root@mx80-core# run ping 37.123.100.122
PING 37.123.100.122 (37.123.100.122): 56 data bytes
64 bytes from 37.123.100.122: icmp_seq=0 ttl=64 time=1.194 ms
64 bytes from 37.123.100.122: icmp_seq=1 ttl=64 time=0.956 ms
^C
--- 37.123.100.122 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.956/1.075/1.194/0.119 ms

[edit]
root@mx80-core# run ping 37.123.100.98
PING 37.123.100.98 (37.123.100.98): 56 data bytes
64 bytes from 37.123.100.98: icmp_seq=0 ttl=64 time=0.490 ms
64 bytes from 37.123.100.98: icmp_seq=1 ttl=64 time=8.739 ms
64 bytes from 37.123.100.98: icmp_seq=2 ttl=64 time=0.422 ms
^C
--- 37.123.100.98 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.422/3.217/8.739/3.905 ms

[edit]
root@mx80-core# run show firewall log
Log :
Time  FilterAction Interface ProtocolSrc Addr   
  Dest Addr
08:44:20  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:19  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:18  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:17  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:16  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:15  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:14  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:13  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:12  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:11  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:10  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86
08:44:09  pfe   A  ae0.0 ICMP212.174.232.182
  185.9.159.86



but we can not access from outside the network :



Request timeout for icmp_seq 14714
36 bytes from 10.32.35.14: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 938d   0   38  01 d3ad 192.168.2.102  185.9.159.86

Request timeout for icmp_seq 14715
36 bytes from 10.32.35.14: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 28e7   0   38  01 3e54 192.168.2.102  185.9.159.86

Request timeout for icmp_seq 14716
36 bytes from 10.32.35.14: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 ffb1   0   38  01 6789 192.168.2.102  185.9.159.86

Request timeout for icmp_seq 14717
36 bytes from 10.32.35.14: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
 4  5  00 5400 99ee   0   38  01 cd4c 192.168.2.102  185.9.159.86

Request timeout for icmp_seq 14718
36 bytes