Re: [j-nsp] AE vs PT , and OSPF neigh not forming

Hi Ben, Yes, it's allowed in the security zone. Regards, 2014/1/23 Ben Dale > Make sure you have: > > host-inbound-traffic protocols ospf > > configured under the security zone for your reth interface > > On 23 Jan 2014, at 3:58 pm, Samol wrote: > > > Hi List, > > > > I've got not another pr

Re: [j-nsp] AE vs PT , and OSPF neigh not forming

Make sure you have: host-inbound-traffic protocols ospf configured under the security zone for your reth interface On 23 Jan 2014, at 3:58 pm, Samol wrote: > Hi List, > > I've got not another problem with ospf neigh. As the topo below, SRX and MX > can reach each other by ping, but ospf neig

[j-nsp] AE vs PT , and OSPF neigh not forming

Hi List, I've got not another problem with ospf neigh. As the topo below, SRX and MX can reach each other by ping, but ospf neig can't form. MX (ae0.88)--(pt-1/0/0.0) SRX I did the investigation on SRX and I found that SRX is sending/receiving ospf hello message. Time Filte

Re: [j-nsp] Loopback VPN termination High End SRX

I interpret that as them saying I can do it in RG1, but not RG0. "lo0 pseudointerface can be configured in such a setup for RG1" Can anyone else confirm? Thanks! Morgan On Wed, Jan 22, 2014 at 2:19 PM, Bao Nguyen wrote: > This have been posted before but on the "high-end" SRX such as 3600 yo

Re: [j-nsp] Loopback VPN termination High End SRX

This have been posted before but on the "high-end" SRX such as 3600 you can not terminate IKE on lo0 [1] "On branch SRX Series devices, the lo0 pseudointerface can be configured in any redundancy group; for example, RG0, RG1, RG2, and so on. However, on high-end SRX Series devices, the lo0 pseudoi

[j-nsp] Loopback VPN termination High End SRX

Hi all, Quick question regarding terminating IKE on a lo0 interface on a 3600 cluster. http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/concept/security-loopback-interface-ha-for-vpn.html According to this, it mentions putting lo0 into an RG thats not 0, which is the one tied to RE and

Re: [j-nsp] CoS and ingress traffic with DSCP markings

Hi John, As far as I'm aware, when traffic hits the box, it has to be put into a forwarding class. If you have not defined any, it will drop into the default forwarding class. There are commands you can run that will show you what forwarding classes are attached to your interfaces - I can't rememb

Re: [j-nsp] MX ping - ToS overrided

If you're capturing your outbound ping packet, why does the capture show "echo reply"? Shouldn't you be capturing the echo request? Serge From: Arash Alizadeh To: "juniper-nsp@puck.nether.net" Sent: Wednesday, January 22, 2014 10:21:44 AM Subject: [j-nsp]

[j-nsp] CoS and ingress traffic with DSCP markings

I ran into an issue yesterday that confused me, which seems to be a weekly occurrence lately regarding Juniper CoS.. We had an interface that was receiving traffic marked as EF. The interface only had the default CoS configuration. For some reason, the traffic was arriving at the destination marked

Re: [j-nsp] MX ping - ToS overrided

You are monitoring ToS in ICMP ECHO REPLY, not request. And that can be set/overridden anywhere by QoS policies, i.e. - on Google DNS server 8.8.8.8 itself - on any transit network HTH Thanks Alex On 22/01/2014 14:21, Arash Alizadeh wrote: Hi, I'm experiencing issues when initating ToS ping f

Re: [j-nsp] Advanced Address book statements

For the archives... address-book { VPN-Management { address Management { wildcard-address 10.0.255.0/255.0.255.255; } } } On Wed, Jan 22, 2014 at 2:55 PM, Mattias Gyllenvarg wrote: > Dear All > > I am looking at keeping a neat config in a VPN-hub device that

Re: [j-nsp] MX ping - ToS overrided

Hi David, Thank's for this input. Appears that host-outbound-traffic is active in the boxes which causes the rewrite. One could argue if this is reasonable to use, but it is infact the case at the moment. Thanks again. Regards, Arash > From: david@orange.com > To: david@orange.com

Re: [j-nsp] MX ping - ToS overrided

I meant host-outbound-traffic ;)   David Roy IP/MPLS NOC engineer - Orange France Ph. : +33 2 99 87 64 72 Mob. : +33 6 85 52 22 13 SkypeID : davidroy.35 david@orange.com   JNCIE x3 (SP #703 ; ENT #305 ; SEC #143) -Message d'origine- De : juniper-nsp [mailto:juniper-nsp-boun...@puc

Re: [j-nsp] MX ping - ToS overrided

Not the case with 12.3R4 for me : ping 8.8.8.8 tos 96 15:37:03.950763 Out IP (tos 0x60, ttl 64, id 64980, offset 0, flags [none], proto: ICMP (1), length: 84) X.X.X.X > 8.8.8.8: ICMP echo request, id 34658, seq 3, length 64 Do you have host-inbound-traffic knob or Output FWF on lo0 that rewr

[j-nsp] MX ping - ToS overrided

Hi, I'm experiencing issues when initating ToS ping from MX devices. The specified ToS argument just seems to be overrided to dec 192 when leaving the interface. I verified this with the traffic monitor on the egress interface: user@node> ping 8.8.8.8 tos 96 64 bytes from 8.8.8.8: icmp_seq=

[j-nsp] Advanced Address book statements

Dear All I am looking at keeping a neat config in a VPN-hub device that will have a large set of rules and address books. Some of these address books could be expressed with a one-liner assuming that I could use regular expressions or any kind of * statement. I have not found any such documentat

[j-nsp] MX-480 BGP Open message error with unknown subcode.

Hello, I have strange problem on my MX-480. From some time router suddenly drops BGP peering with two customers and session doesn't come up from that time. One peer is IPv4, another one IPv6. Not configuration change done. There are lot of other BGP peers working OK on that router. Here is e

Re: [j-nsp] MX960 - Release 12.3R4

Hi, If you consider rsvp and link-protection, it's better to use 12.3R5 Regards, Wojciech 22 sty 2014 04:02, "Giuliano Medalha" napisał(a): > People, > > Does anyone used JUNOS 12.3R4 on MX960 gear ? > > Is this a stable release ? > > Could you please send some feedback about it ? > > We have a