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 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 FilterAction Interface ProtocolSrc Addr > > Dest Addr > > 18:37:46 pfe A pt-1/0/0.0OSPF172.16.161.1 > > 224.0.0.5 > > 18:37:44 OSPF-DEBUG A local OSPF172.16.161.2 > > 224.0.0.5 > > 18:37:38 pfe A pt-1/0/0.0OSPF172.16.161.1 > > 224.0.0.5 > > 18:37:35 OSPF-DEBUG A local OSPF172.16.161.2 > > 224.0.0.5 > > 18:37:29 pfe A pt-1/0/0.0OSPF172.16.161.1 > > 224.0.0.5 > > 18:37:26 OSPF-DEBUG A local OSPF172.16.161.2 > > 224.0.0.5 > > > > However, on MX side, It's sending the hello message, but it's not > receiving > > hello message that SRX ACKs. that leads to OSPF state in INIT state on > SRX > > side, and no neigh status on MX side. Looking in to ae interface > statistics > > , get the result as below : > > > >Link: > > ge-1/0/0.88 > >Input : 0 0 00 > >Output: 62551 0 68045620 > > ge-1/0/1.88 > >Input : 882 02879320 > >Output: 0 0 00 > > > > it's using one link to send and another to receive. Surely, OSPF message > > that sending from SRX is being dropped somewhere in the middle, however > why > > is it not dropping ICMP message ? Any idea is really appreciated. > > > > Regards, > > > > > > > > -- > > Samol Khoeurn > > (855) 077 55 64 02 / (855) 067 41 88 66 > > Network Engineer > > Cisco: CCNA/CCNP SP/CCIP/ > > Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT > > www.linkedin.com/in/samolkhoeurn > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- Samol Khoeurn (855) 077 55 64 02 / (855) 067 41 88 66 Network Engineer Cisco: CCNA/CCNP SP/CCIP/ Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT www.linkedin.com/in/samolkhoeurn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 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 FilterAction Interface ProtocolSrc Addr > Dest Addr > 18:37:46 pfe A pt-1/0/0.0OSPF172.16.161.1 > 224.0.0.5 > 18:37:44 OSPF-DEBUG A local OSPF172.16.161.2 > 224.0.0.5 > 18:37:38 pfe A pt-1/0/0.0OSPF172.16.161.1 > 224.0.0.5 > 18:37:35 OSPF-DEBUG A local OSPF172.16.161.2 > 224.0.0.5 > 18:37:29 pfe A pt-1/0/0.0OSPF172.16.161.1 > 224.0.0.5 > 18:37:26 OSPF-DEBUG A local OSPF172.16.161.2 > 224.0.0.5 > > However, on MX side, It's sending the hello message, but it's not receiving > hello message that SRX ACKs. that leads to OSPF state in INIT state on SRX > side, and no neigh status on MX side. Looking in to ae interface statistics > , get the result as below : > >Link: > ge-1/0/0.88 >Input : 0 0 00 >Output: 62551 0 68045620 > ge-1/0/1.88 >Input : 882 02879320 >Output: 0 0 00 > > it's using one link to send and another to receive. Surely, OSPF message > that sending from SRX is being dropped somewhere in the middle, however why > is it not dropping ICMP message ? Any idea is really appreciated. > > Regards, > > > > -- > Samol Khoeurn > (855) 077 55 64 02 / (855) 067 41 88 66 > Network Engineer > Cisco: CCNA/CCNP SP/CCIP/ > Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT > www.linkedin.com/in/samolkhoeurn > ___ > 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] 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 FilterAction Interface ProtocolSrc Addr Dest Addr 18:37:46 pfe A pt-1/0/0.0OSPF172.16.161.1 224.0.0.5 18:37:44 OSPF-DEBUG A local OSPF172.16.161.2 224.0.0.5 18:37:38 pfe A pt-1/0/0.0OSPF172.16.161.1 224.0.0.5 18:37:35 OSPF-DEBUG A local OSPF172.16.161.2 224.0.0.5 18:37:29 pfe A pt-1/0/0.0OSPF172.16.161.1 224.0.0.5 18:37:26 OSPF-DEBUG A local OSPF172.16.161.2 224.0.0.5 However, on MX side, It's sending the hello message, but it's not receiving hello message that SRX ACKs. that leads to OSPF state in INIT state on SRX side, and no neigh status on MX side. Looking in to ae interface statistics , get the result as below : Link: ge-1/0/0.88 Input : 0 0 00 Output: 62551 0 68045620 ge-1/0/1.88 Input : 882 02879320 Output: 0 0 00 it's using one link to send and another to receive. Surely, OSPF message that sending from SRX is being dropped somewhere in the middle, however why is it not dropping ICMP message ? Any idea is really appreciated. Regards, -- Samol Khoeurn (855) 077 55 64 02 / (855) 067 41 88 66 Network Engineer Cisco: CCNA/CCNP SP/CCIP/ Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT www.linkedin.com/in/samolkhoeurn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 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 pseudointerface cannot be configured > in RG0 when it is used as an IKE gateway external interface. Because a VPN > is only supported in an active-passive HA environment on high-end SRX > Series devices, the lo0 pseudointerface can be configured in such a setup > for RG1. In a HA setup, the node on which the external interface is active > selects an SPU to anchor the VPN tunnel. IKE and IPsec packets are > processed on that SPU. Thus an active external interface decides the anchor > SPU." > > [1] > http://www.juniper.net/techpubs/en_US/junos12.1x45/topics/concept/security-loopback-interface-ha-for-vpn.html > > -bn > 0216331C > > > On Wed, Jan 22, 2014 at 2:08 PM, Morgan McLean wrote: > >> 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 master node etc. Does anybody do this? Do you just >> assign lo0 to redundancy group say 2, and then it just works? Anything >> else >> we need to do? The VPN packets could come in over node 0 or node 1...so >> I'm >> not sure exactly how this helps. >> >> -- >> Thanks, >> Morgan >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 pseudointerface cannot be configured in RG0 when it is used as an IKE gateway external interface. Because a VPN is only supported in an active-passive HA environment on high-end SRX Series devices, the lo0 pseudointerface can be configured in such a setup for RG1. In a HA setup, the node on which the external interface is active selects an SPU to anchor the VPN tunnel. IKE and IPsec packets are processed on that SPU. Thus an active external interface decides the anchor SPU." [1] http://www.juniper.net/techpubs/en_US/junos12.1x45/topics/concept/security-loopback-interface-ha-for-vpn.html -bn 0216331C On Wed, Jan 22, 2014 at 2:08 PM, Morgan McLean wrote: > 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 master node etc. Does anybody do this? Do you just > assign lo0 to redundancy group say 2, and then it just works? Anything else > we need to do? The VPN packets could come in over node 0 or node 1...so I'm > not sure exactly how this helps. > > -- > Thanks, > Morgan > ___ > 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] 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 master node etc. Does anybody do this? Do you just assign lo0 to redundancy group say 2, and then it just works? Anything else we need to do? The VPN packets could come in over node 0 or node 1...so I'm not sure exactly how this helps. -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 remember them off the top of my head though! If you do have rewrite rules on egress, then you will likely mark it to DF as you were seeing. It sounds like you have hit the nail on the head. Dave On 22 January 2014 16:20, John Neiberger wrote: > 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 as CS0. After I applied the CoS group to the > interface, which included classifiers, the packets started arriving at > the destination as EF like they were supposed to be. > > I don't understand why a lack of CoS config would reset DSCP markings > for traffic that is already marked when it hits the router. Could it > be that since there were no ingress classifiers, the traffic was not > put into a forwarding class, so the rewrite rules on egress re-marked > it? That just occurred to me. I'm going to go check the rewrites rules > we have applied on egress to see if that is what was happening. I was > under the bad assumption that traffic already marked would traverse > the router unchanged. > > Thanks, > John > ___ > 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 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] 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=0 ttl=246 time=15.675 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms user@node> monitor traffic interface xe-0/0/0.0 extensive matching icmp PFE proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], proto: ICMP (1), length: 84) x.x.x.x > 8.8.8.8: ICMP echo reply, id 47826, seq 0, length 64 14:06:58.721197 Out I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the same result. Did anyone else ran into this issue? Any input is appriciated. Regards, Arash ___ 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] 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 as CS0. After I applied the CoS group to the interface, which included classifiers, the packets started arriving at the destination as EF like they were supposed to be. I don't understand why a lack of CoS config would reset DSCP markings for traffic that is already marked when it hits the router. Could it be that since there were no ingress classifiers, the traffic was not put into a forwarding class, so the rewrite rules on egress re-marked it? That just occurred to me. I'm going to go check the rewrites rules we have applied on egress to see if that is what was happening. I was under the bad assumption that traffic already marked would traverse the router unchanged. Thanks, John ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 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=0 ttl=246 time=15.675 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms user@node> monitor traffic interface xe-0/0/0.0 extensive matching icmp PFE proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], proto: ICMP (1), length: 84) x.x.x.x > 8.8.8.8: ICMP echo reply, id 47826, seq 0, length 64 14:06:58.721197 Out I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the same result. Did anyone else ran into this issue? Any input is appriciated. Regards, Arash ___ 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] 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 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 documentation for address books.
>
> Hints?
>
> --
> *Med Vänliga Hälsningar*
> *Mattias Gyllenvarg*
>
--
*Med Vänliga Hälsningar*
*Mattias Gyllenvarg*
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
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; aras...@hotmail.se; juniper-nsp@puck.nether.net > Date: Wed, 22 Jan 2014 15:40:50 +0100 > Subject: 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...@puck.nether.net] De la part de > david@orange.com > Envoyé : mercredi 22 janvier 2014 15:39 > À : 'Arash Alizadeh'; juniper-nsp@puck.nether.net > Objet : 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 rewrites > control plane ? > > > > 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...@puck.nether.net] De la part de > Arash Alizadeh Envoyé : mercredi 22 janvier 2014 15:22 À : > juniper-nsp@puck.nether.net Objet : [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=0 ttl=246 time=15.675 ms > 64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms > > user@node> monitor traffic interface xe-0/0/0.0 extensive matching icmp PFE > proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], proto: > ICMP (1), length: 84) x.x.x.x > 8.8.8.8: ICMP echo reply, id 47826, seq 0, > length 64 > 14:06:58.721197 Out > > I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the > same result. > > Did anyone else ran into this issue? > Any input is appriciated. > > Regards, > Arash > > ___ > 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 > > _ > > 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
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...@puck.nether.net] De la part de david@orange.com Envoyé : mercredi 22 janvier 2014 15:39 À : 'Arash Alizadeh'; juniper-nsp@puck.nether.net Objet : 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 rewrites control plane ? 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...@puck.nether.net] De la part de Arash Alizadeh Envoyé : mercredi 22 janvier 2014 15:22 À : juniper-nsp@puck.nether.net Objet : [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=0 ttl=246 time=15.675 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms user@node> monitor traffic interface xe-0/0/0.0 extensive matching icmp PFE proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], proto: ICMP (1), length: 84) x.x.x.x > 8.8.8.8: ICMP echo reply, id 47826, seq 0, length 64 14:06:58.721197 Out I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the same result. Did anyone else ran into this issue? Any input is appriciated. Regards, Arash ___ 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 _ 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
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 rewrites control plane ? 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...@puck.nether.net] De la part de Arash Alizadeh Envoyé : mercredi 22 janvier 2014 15:22 À : juniper-nsp@puck.nether.net Objet : [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=0 ttl=246 time=15.675 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms user@node> monitor traffic interface xe-0/0/0.0 extensive matching icmp PFE proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], proto: ICMP (1), length: 84) x.x.x.x > 8.8.8.8: ICMP echo reply, id 47826, seq 0, length 64 14:06:58.721197 Out I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the same result. Did anyone else ran into this issue? Any input is appriciated. Regards, Arash ___ 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] 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=0 ttl=246 time=15.675 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms user@node> monitor traffic interface xe-0/0/0.0 extensive matching icmp PFE proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], proto: ICMP (1), length: 84) x.x.x.x > 8.8.8.8: ICMP echo reply, id 47826, seq 0, length 64 14:06:58.721197 Out I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the same result. Did anyone else ran into this issue? Any input is appriciated. Regards, Arash ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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 documentation for address books. Hints? -- *Med Vänliga Hälsningar* *Mattias Gyllenvarg* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[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 excerpt from log of one BGP session: Jan 22 12:46:34.412693 bgp_event: peer 2a02:2a50:0:11::2 (External AS 47623) old state Idle event Start new state Active Jan 22 12:46:34.412703 task_timer_ucreate: created timer BGP_47623_49800.2a02:2a50:0:11::2_Connect flags <> Jan 22 12:46:34.412713 task_timer_uset: timer BGP_47623_49800.2a02:2a50:0:11::2_Connect set to offset 2:28 at 12:49:02 Jan 22 12:47:37.567137 Jan 22 12:47:37.567137 BGP RECV 2a02:2a50:0:11::2+59259 -> 2a02:2a50:0:11::1+179 Jan 22 12:47:37.567190 BGP RECV message type 1 (Open) length 45 Jan 22 12:47:37.567198 BGP RECV version 4 as 47623 holdtime 180 id 93.187.163.1 parmlen 16 Jan 22 12:47:37.567204 BGP RECV Refresh capability, code=2 Jan 22 12:47:37.567210 BGP RECV 4 Byte AS-Path capability (65), as_num 47623 Jan 22 12:47:37.567215 BGP RECV MP capability AFI=2, SAFI=1 Jan 22 12:47:37.567252 task_timer_delete: BGP_47623_49800.2a02:2a50:0:11::2_Connect Jan 22 12:47:37.567267 task_set_socket: task BGP_47623_49800.2a02:2a50:0:11::2 socket 112 Jan 22 12:47:37.567278 task_set_option_internal: task BGP_47623_49800.2a02:2a50:0:11::2 socket 112 option RecvBuffer(0) value 16384 Jan 22 12:47:37.567287 task_set_option_internal: task BGP_47623_49800.2a02:2a50:0:11::2 socket 112 option SendBuffer(1) value 16384 Jan 22 12:47:37.567309 task_set_option_internal: task BGP_47623_49800.2a02:2a50:0:11::2+59259 socket 112 option PathMTUDiscovery(26) value 0 Jan 22 12:47:37.567333 task_set_option_internal: task BGP_47623_49800.2a02:2a50:0:11::2+59259 socket 112 option DontRoute(5) value 1 Jan 22 12:47:37.567342 task_set_option_internal: task BGP_47623_49800.2a02:2a50:0:11::2+59259 socket 112 option IifRestrict(36) value 1 Jan 22 12:47:37.567351 task_set_option_internal: task BGP_47623_49800.2a02:2a50:0:11::2+59259 socket 112 option TTL(15) value 1 Jan 22 12:47:37.567362 task_timer_ucreate: created timer BGP_47623_49800.2a02:2a50:0:11::2+59259_Hold flags <> Jan 22 12:47:37.567373 task_timer_uset: timer BGP_47623_49800.2a02:2a50:0:11::2+59259_Hold set to offset 1:30 at 12:49:07 Jan 22 12:47:37.567382 bgp_event: peer 2a02:2a50:0:11::2 (External AS 47623) old state Active event Open new state OpenSent Jan 22 12:47:37.567391 advertising graceful restart receiving-speaker-only capability to neighbor 2a02:2a50:0:11::2 (External AS 47623) Jan 22 12:47:37.567401 bgp_4byte_aspath_add_cap():153 AS4-Peer 2a02:2a50:0:11::2 (External AS 47623)(SEND): 4 byte AS capability added, AS 49800 Jan 22 12:47:37.567408 bgp_send: sending 59 bytes to 2a02:2a50:0:11::2 (External AS 47623) Jan 22 12:47:37.567414 Jan 22 12:47:37.567414 BGP SEND 2a02:2a50:0:11::1+179 -> 2a02:2a50:0:11::2+59259 Jan 22 12:47:37.567421 BGP SEND message type 1 (Open) length 59 Jan 22 12:47:37.567427 BGP SEND version 4 as 49800 holdtime 90 id 46.19.96.5 parmlen 30 Jan 22 12:47:37.567432 BGP SEND MP capability AFI=2, SAFI=1 Jan 22 12:47:37.567436 BGP SEND Refresh capability, code=128 Jan 22 12:47:37.567440 BGP SEND Refresh capability, code=2 Jan 22 12:47:37.567445 BGP SEND Restart capability, code=64, time=120, flags= Jan 22 12:47:37.567450 BGP SEND 4 Byte AS-Path capability (65), as_num 49800 Jan 22 12:47:37.567490 bgp_process_4byte_aspath_cap():286 AS4-Peer 2a02:2a50:0:11::2 (External AS 47623)(RECV): 4 byte AS Cap value stored 47623 Jan 22 12:47:37.567499 bgp_event: peer 2a02:2a50:0:11::2 (External AS 47623) old state OpenSent event RecvOpen new state OpenConfirm Jan 22 12:47:37.567504 bgp_send: sending 19 bytes to 2a02:2a50:0:11::2 (External AS 47623) Jan 22 12:47:37.567517 Jan 22 12:47:37.567517 BGP SEND 2a02:2a50:0:11::1+179 -> 2a02:2a50:0:11::2+59259 Jan 22 12:47:37.567524 BGP SEND message type 4 (KeepAlive) length 19 Jan 22 12:47:37.567533 bgp_recv_change: peer 2a02:2a50:0:11::2 (External AS 47623) receiver changed to bgp_recv_open Jan 22 12:47:37.567540 task_set_socket: task BGP_47623_49800.2a02:2a50:0:11::2+59259 socket 112 Jan 22 12:47:37.568371 task_process_events: recv ready for BGP_47623_49800.2a02:2a50:0:11::2+59259 Jan 22 12:47:37.568378 bgp_recv_open: called for peer 2a02:2a50:0:11::2 (External AS 47623) Jan 22 12:47:37.568387 Jan 22 12:47:37.568387 BGP RECV 2a02:2a50:0:11::2+59259 -> 2a02:2a50:0:11::1+179 Jan 22 12:47:37.568395 BGP RECV message type 4 (KeepAlive) length 19 Jan 22 12:47:37.568426 bgp_peer_established:6685: NOTIFICATION sent to 2a02:2a50:0:11::2 (External AS 47623): code 2 (Open Message Error), Reason: pending close Jan 22 12:47:37.568433 bgp_send: sending 21 bytes to 2a02:2a50:0:11::2 (External AS 47623) Jan 22 12:47:37.568439 Jan 22 12:47:37.568439 BGP SEND 2a02:2a50:0:11::1+179 -> 2a02:2a50:0:11::2+59259 Jan 22 12:47:37.568446
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 recommendation of using it but we need to know if is stable or > not in production environment ... considering BGP and MPLS. > > Thanks a lot, > > Giuliano > ___ > 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
