[j-nsp] MX80 is getting Rebooted Frequently....
Dear All We have just purchased a new Juniper MX80 that came with a external USB. The USB contains the Junos 11.1R17. I don't know whether MX80 boot with only USB.. can't we install the Junos in inbuilt storage? Can anyone confirm me the same? One more thing is that the Router is getting rebooted frequentlyPlz help to sort out the issue Thanks & Regards, Abdullah Mullick Indian Cable Net Company Limited J-1/12, Block - EP, 4th Floor, Sector - V, Kol-91 (91) 33 4002 5108 | Cell (91) 90511 33372 This communication contains confidential or legally privileged information. The material, data, information, theme, ideas, stories, concepts, abstracts, notes, etc. (Proprietary Information) contained in this communication is the sole and exclusive property of Siticable Network Limited and form part of this communication solely for the discussion with the addressee. The Proprietary information contained in this communication may be used only in the manner and for the purposes as may be expressly permitted by Siticable Network Limited. If you are not the intended recipient and have received this Proprietary Information in error, please notify us immediately by responding to this by post/email and delete it from your records. Any use, utilization dissemination, distribution or copying of this Proprietary Information without proper authorization by us is strictly prohibited. Damages merely shall not be a sufficient remedy for violation of the aforesaid and we are entitled to th! e remedies by way of injunction, specific performance and other equitable relief for any breach of the above in addition to any other remedies available to us at law or in equity(c) 2008. Siticable employs every reasonable precaution to minimize risk arising from virus and malware, and ensure virus-free communication. However we cannot accept liability for any damage which may arise as a result of software viruses. Recipients are strongly advised to employ powerful and updated virus checks at their end. All rights reserved with Siticable Network Limited. www.siticable.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 version
I believe 12.3R2 still has the bug where the syslog fills up with erroneous messages about one or both of the power supplies being removed (12.3R1 complains about the fan tray AND the power supplies). This is finally put to bed in 12.3R3 Cheers, Ben On 24/07/2013, at 7:56 PM, Pierre-Yves Maunier wrote: > I'll be deploying a couple of EX4550 doing mainly L3/MPLS stuff (ospf, > bgp, l3vpn, l2circuit) and I'm going to roll out 12.3R3.4. > > Generally I prefer using at least an R3 release and as Juniper > promised me that 12.3 would be 'the next 11.4' then I'm going for this > one. > > 2013/7/24 Luca Salvatore : >> Hi All, >> >> Just got a couple of new EX4550 switches... current recommended version is >> 12.2r2.5 >> But I just saw tha the 12.2 train is up release 5.3. >> >> Just wondering what the rest of you guys are running and if you have any >> horror stories. >> I'm not doing VC with these guys, they are going to be a pretty simple layer >> 2 aggregation type switch. >> >> Thanks. >> >> ___ >> 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] flow sampling: what packets are chosen?
> > Run-length appears to be unsupported on newer (e.g. MX3D MPC) hardware.
>
> ISTR reading that's because they're 1:1 hardware sampling inside Trio
> instead of just punts to the LC CPU or RE CPU, at least for IPFIX on
> Trio. Probably from the O'Reilly Juniper MX ... yup found it. (any
> typos are mine as I'm retyping this)
>
> "When using inline IPFIX the only valid rate is 1. The option
> run-length isn't configurable, because there's no need to sample data
> from the perspective of the microcode in the Trio Lookup Block. Every
> packet will be inspected and is subject to flow export."
We're doing inline IPFIX with 1:100 sampling rate, and getting sensible
data. This is on an MPC-3D-16XGE-SFPP line card. Config snippet:
sampling {
instance {
inline-netflow {
input {
rate 100;
run-length 0;
}
...
Steinar Haug, AS 2116
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] flow sampling: what packets are chosen?
On Wed, Jul 24, 2013 at 10:10 AM, Phil Sykes wrote: > Run-length appears to be unsupported on newer (e.g. MX3D MPC) hardware. > > Regards, > > Phil > ISTR reading that's because they're 1:1 hardware sampling inside Trio instead of just punts to the LC CPU or RE CPU, at least for IPFIX on Trio. Probably from the O'Reilly Juniper MX ... yup found it. (any typos are mine as I'm retyping this) "When using inline IPFIX the only valid rate is 1. The option run-length isn't configurable, because there's no need to sample data from the perspective of the microcode in the Trio Lookup Block. Every packet will be inspected and is subject to flow export." Which seems like a dumb/dense view of things since even Trio has limits on the flow rates/etc and - while I haven't done the math at all - I'd bet it's entirely possible to exceed those limits. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Static NAT and VPN tunnels
What device are you using? Sometimes it is possible to use a route-based VPN even if the other side only can use policy-based VPN (SRX with Cisco ASA is a typical example), that could perhaps solve your problem? /Per 24 jul 2013 kl. 19:50 skrev Aaron Dewell : > > Hey all, > > Got a conflict here and hoping someone has some ideas on this. We have 1:1 > static nat for a server, but that server also needs to communicate over a > policy-based VPN. If this VPN were route-based, there'd be no problem. > > The VPN works for this server if I remove the static NAT so everything there > is good. > > The option I've considered is to create a static route to the remote subnet > which goes into a different zone (even a fake zone) and adjust the policies > to go into that zone instead of the Internet zone. However, the traffic from > the far side would still be coming from the Internet zone, so I'm betting the > flows wouldn't match. It also seems like an extreme hack. > > Removing the static NAT would be awesome, but there are unknown things using > it, so it's not so easy as that. > > Anyone have other suggestions? > > Thanks! > > Aaron > > > ___ > 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] Static NAT and VPN tunnels
Hey all, Got a conflict here and hoping someone has some ideas on this. We have 1:1 static nat for a server, but that server also needs to communicate over a policy-based VPN. If this VPN were route-based, there'd be no problem. The VPN works for this server if I remove the static NAT so everything there is good. The option I've considered is to create a static route to the remote subnet which goes into a different zone (even a fake zone) and adjust the policies to go into that zone instead of the Internet zone. However, the traffic from the far side would still be coming from the Internet zone, so I'm betting the flows wouldn't match. It also seems like an extreme hack. Removing the static NAT would be awesome, but there are unknown things using it, so it's not so easy as that. Anyone have other suggestions? Thanks! Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] flow sampling: what packets are chosen?
The sampling is more random - the probability of an individual packet being sampled is 1/1000, but it's not exactly every 1000th packet, and every linecard has an independent sampling engine. A caveat on sample rate - some Juniper hardware (e.g. T-Series FPC3, MX960 DPC) will silently round that up to nearest 65535 / int(x), so pick sampling rates like 8191, 4095 rather than 4000, 1. You can miss flows of any size - as the size of the flow increases, the probability you will sample at least one packet from it increases, but there are no guarantees. Run-length appears to be unsupported on newer (e.g. MX3D MPC) hardware. Regards, Phil On Tue, Jul 23, 2013 at 7:16 PM, chris r. wrote: > Hi guys, > > I'm using Juniper hardware to sample traffic and dump it to NetFlow > data. In my config, the sampling rate is 1000, run-length is 0. > > According to the docs [1], this means that 1 out of 1000 packets per > flow is sampled. Does this mean that *always* the first (1001st, 2001st, > 3001st, ...) packet of a flow is included (as the figure in the docs > suggests) or is the sampling more random? > > And if sampling is done more random: Can I miss flows due to packet > sampling, e.g., if flows have fewer than 1000 packets? > > Thanks a lot for your help, > Chris > > [1]: > > http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/configuring-traffic-sampling.html#id-11354799 > ___ > 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] Correct config for SRX port channel -> Cisco
On 24/07/13 17:01, Olivier Benghozi wrote: Hi Phil, what is the Cisco model & IOS? It's actually an Nexus 7009 running NX-OS. Did you create the vlan in the vlan database in your Cisco switch? :) Yep Maybe try switchport nonegotiate... No such command on NX-OS, there's no DTP. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Correct config for SRX port channel -> Cisco
Hi Phil, what is the Cisco model & IOS? Did you create the vlan in the vlan database in your Cisco switch? :) Maybe try switchport nonegotiate... Le 24 juil. 2013 à 17:39, Phil Mayers a écrit : > On 24/07/13 16:07, Phil Mayers wrote: >> On 24/07/13 15:48, Stacy W. Smith wrote: >>> In general, I see no problems with your AE configuration. >>> >>> Could you define "never comes up"? Is it the ae0 interface, or the >>> ae0.999 unit that is in a down state? >> >> >> Both (see below) > > Interestingly, this comes up if you use "sub-ints" on the Cisco side: > > interface port-channel20 > > interface port-channel20.999 > encapsulation dot1q 999 > ip address 192.168.1.1/31 > no shutdown > > ...as opposed to > > interface port-channel20 > switchport > switchport mode trunk > switchport trunk allowed vlan 999 > > int Vlan999 > ip address 192.168.1.1/31 > no shutdown > > Clearly there's some sort of LACP-layer parameter that corresponds to "trunk" > versus "not" - can this be influenced by the specific "style" of ae0 config > on the SRX side? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Correct config for SRX port channel -> Cisco
On 24/07/13 16:07, Phil Mayers wrote: On 24/07/13 15:48, Stacy W. Smith wrote: In general, I see no problems with your AE configuration. Could you define "never comes up"? Is it the ae0 interface, or the ae0.999 unit that is in a down state? Both (see below) Interestingly, this comes up if you use "sub-ints" on the Cisco side: interface port-channel20 interface port-channel20.999 encapsulation dot1q 999 ip address 192.168.1.1/31 no shutdown ...as opposed to interface port-channel20 switchport switchport mode trunk switchport trunk allowed vlan 999 int Vlan999 ip address 192.168.1.1/31 no shutdown Clearly there's some sort of LACP-layer parameter that corresponds to "trunk" versus "not" - can this be influenced by the specific "style" of ae0 config on the SRX side? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Correct config for SRX port channel -> Cisco
In general, I see no problems with your AE configuration.
Could you define "never comes up"? Is it the ae0 interface, or the ae0.999 unit
that is in a down state?
The output of "show interfaces terse" (at least for the member and ae
interfaces)
and the output of "show lacp interfaces" might be helpful.
FWIW, the two ends of your link are in different subnets. 192.168.1.1/31 and
192.168.1.2/31 are not in the same subnet.
--Stacy
On Jul 24, 2013, at 7:27 AM, Phil Mayers wrote:
> If I have a single SRX3600 device (NOT a cluster), what config (if any...)
> can I use to match a config on the Cisco side:
>
> int
> lacp rate fast
> channel-group 20 mode active
> int Po20
> switchport
> switchport mode trunk
> switchport trunk allowed vlan 999
> int Vlan999
> ip address 192.168.1.1 255.255.255.254
>
> I would have thought it would be something like:
>
> chassis {
>aggregated-devices {
>ethernet {
>device-count 2;
>}
>}
> }
> interfaces {
>xe-1/0/0 {
>gigether-options {
>802.3ad ae0;
>}
>}
>xe-1/0/1 {
>disable;
>}
>xe-4/0/0 {
>gigether-options {
>802.3ad ae0;
>}
>}
>xe-4/0/1 {
>disable;
>}
>ae0 {
>vlan-tagging;
>aggregated-ether-options {
>lacp {
>active;
>periodic fast;
>}
>}
>unit 999 {
>vlan-id 999;
>family inet {
>address 192.168.1.2/31;
>}
>}
>}
> }
>
> ...but this never comes up. I've seen this before, and I think it's because
> there's something in the LACP PDUs which disagrees about trunk/access mode.
> The config works if I set the Cisco side to "access", but obviously that's
> not what I want.
>
> Can you even do this on SRX? I see lots of documents talking about reth
> interfaces, but AFAICT those are all for chassis clustering, which we don't
> want to use.
> ___
> 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] Problem to insert rule into IDP
Dear friend: Wishes all are fine.I am facing some problem on my IDP to insert rule, here the details information : Platform: NS-IDP-200 Managed OS version: IDP4.0 Running OS Version: IDP4.0.93787 NSM Version: 2012.1R2 Problem description: After fresh installing NSM I can push configuration to IDP without any problem but next time when I edit or insert any new rule and try to push configuration in to IDP it shows Error Code: Error Text: Exception caught during update device: null Error Details: java.lang.NullPointerException it would be nice any one give me suggestion to resolve this issue ? Thanks jahangir ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Correct config for SRX port channel -> Cisco
On 24/07/13 15:48, Stacy W. Smith wrote: In general, I see no problems with your AE configuration. Could you define "never comes up"? Is it the ae0 interface, or the ae0.999 unit that is in a down state? Both (see below) The output of "show interfaces terse" (at least for the member and ae interfaces) admin@srx-3600-1> show interfaces terse Interface Admin Link ProtoLocal Remote xe-1/0/0upup xe-1/0/0.999upup aenet--> ae0.999 xe-1/0/0.32767 upup aenet--> ae0.32767 ae0 updown ae0.999 updown inet 192.168.1.2/31 multiservice ae0.32767 updown multiservice and the output of "show lacp interfaces" might be helpful. admin@srx-3600-1> show lacp interfaces Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-1/0/0 ActorNo YesNo No No Yes Fast Active xe-1/0/0 PartnerNo YesNo No No Yes Fast Passive LACP protocol:Receive State Transmit State Mux State xe-1/0/0Defaulted Fast periodic Detached FWIW, the two ends of your link are in different subnets. 192.168.1.1/31 and 192.168.1.2/31 are not in the same subnet. That's a typo on my part. I've seem something similar to this before, where a port-channel wouldn't come up between a Cisco IOS and IOS-XR box if one end was "switchport trunk" and the other "switchport access". This confused me slightly - I didn't know LACP was aware of the trunk/access nature of the "upper" interface. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 version
I'd like to know more about LAG+ECMP as well. You can't really use LAG+ECMP on EX3300 for instance. If you have 2x10G LAG uplink on which you're doing ECMP. Traffic will eventually be load balanced over the 2 LAGs thanks to ECMP but traffic will not be load balanced within the LAG members. 2013/7/24 Phil Bedard : > This is unrelated somewhat, but what are the current LAG member limits > as well as ECMP limits? Any restrictions on LAG+ECMP? > > phil From: Sam > Sent: 7/24/2013 8:46 > To: Bouzemarene, Farid (ATS) > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] EX4550 version > Hi Farid, > > From an old case I had open with Juniper: > >>The EX4550 has an ARP table of maximum 8k entries. >> These entries are tracked in the kernel through something called tokens. >> Each ARP entry is a token. >> >> Because we have only 8k tokens available, from here we have the maximum >> number of ARP entries. >> >> However, because of how the chipset of EX4550 is designed, the MPLS LSPs are >> also making use of the same tokens. >> But each MPLS LSP is using 8 tokens. Therefore, 1000 LSPs would use all >> tokens and no ARP can be learned. >> >> The token usage is scaled up by the number of ECMP next-hops. So 1 LSP with >> 4 ECMP next-hops will take 1*8*4=32 tokens. > > -- > sam > > > On 24 Jul 2013, at 11:28, "Bouzemarene, Farid (ATS)" > wrote: > >> Hello, >> >> Can you clarify the MPLS limits ? >> >> Thx >> >> - Message d'origine - >> De : Sam [mailto:sam...@arahant.net] >> Envoyé : Wednesday, July 24, 2013 10:39 AM >> À : Luca Salvatore >> Cc : juniper-nsp@puck.nether.net >> Objet : Re: [j-nsp] EX4550 version >> >> I used the 12.3R2.5 for quite some time now without any issue. The platform >> has its limitations (especially related to how MPLS is handled), but if >> you're just using it for L2 or basic L3 it works just fine. >> >> -- >> sam >> >> On 24 Jul 2013, at 03:27, Luca Salvatore wrote: >> >>> Hi All, >>> >>> Just got a couple of new EX4550 switches... current recommended version is >>> 12.2r2.5 >>> But I just saw tha the 12.2 train is up release 5.3. >>> >>> Just wondering what the rest of you guys are running and if you have any >>> horror stories. >>> I'm not doing VC with these guys, they are going to be a pretty simple >>> layer 2 aggregation type switch. >>> >>> Thanks. >>> >>> ___ >>> 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 > > ___ > 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 version
I assume that aggregating multiple interfaces would downscale the tokens usage, as a 4x10GE bundle would use just 8 tokens rather than 32 of 4 equal cost paths. Limits are in the data-sheet: - Number of LAGs supported: 64 - Maximum number of ports per LAG: 8 I'd expect this value to be the same for the number of ECMP paths. -- sam On 24 Jul 2013, at 15:07, Phil Bedard wrote: > This is unrelated somewhat, but what are the current LAG member limits > as well as ECMP limits? Any restrictions on LAG+ECMP? > > phil From: Sam > Sent: 7/24/2013 8:46 > To: Bouzemarene, Farid (ATS) > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] EX4550 version > Hi Farid, > > From an old case I had open with Juniper: > >> The EX4550 has an ARP table of maximum 8k entries. >> These entries are tracked in the kernel through something called tokens. >> Each ARP entry is a token. >> >> Because we have only 8k tokens available, from here we have the maximum >> number of ARP entries. >> >> However, because of how the chipset of EX4550 is designed, the MPLS LSPs are >> also making use of the same tokens. >> But each MPLS LSP is using 8 tokens. Therefore, 1000 LSPs would use all >> tokens and no ARP can be learned. >> >> The token usage is scaled up by the number of ECMP next-hops. So 1 LSP with >> 4 ECMP next-hops will take 1*8*4=32 tokens. > > -- > sam > > > On 24 Jul 2013, at 11:28, "Bouzemarene, Farid (ATS)" > wrote: > >> Hello, >> >> Can you clarify the MPLS limits ? >> >> Thx >> >> - Message d'origine - >> De : Sam [mailto:sam...@arahant.net] >> Envoyé : Wednesday, July 24, 2013 10:39 AM >> À : Luca Salvatore >> Cc : juniper-nsp@puck.nether.net >> Objet : Re: [j-nsp] EX4550 version >> >> I used the 12.3R2.5 for quite some time now without any issue. The platform >> has its limitations (especially related to how MPLS is handled), but if >> you're just using it for L2 or basic L3 it works just fine. >> >> -- >> sam >> >> On 24 Jul 2013, at 03:27, Luca Salvatore wrote: >> >>> Hi All, >>> >>> Just got a couple of new EX4550 switches... current recommended version is >>> 12.2r2.5 >>> But I just saw tha the 12.2 train is up release 5.3. >>> >>> Just wondering what the rest of you guys are running and if you have any >>> horror stories. >>> I'm not doing VC with these guys, they are going to be a pretty simple >>> layer 2 aggregation type switch. >>> >>> Thanks. >>> >>> ___ >>> 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] Windows NTP server for JUNOS client
Yes the windows server wasn't in synch with it's parent After fixing that, issued a set date and it is fixed. Thank you all for your help Sent from Samsung Mobile Original message From: Jared Gull Date: 24/07/2013 4:43 PM (GMT+03:00) To: Abdullah Baheer ,juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Windows NTP server for JUNOS client Hi Abdullah, I have seen others experience issues when using a Windows server as their NTP server when that server does not have an external time source. Does your Windows NTP server have an upstream time source? If not, you could try to link it with one to see if that fixes the issue. If not, you may need to do some local modifications on the server. As I understand it the issue stems from a high root dispersion value on the WIndows server. You can confirm the root dispersion value by capturing an inbound NTP packet on your Junos device: 12:40:22.325750 In Juniper PCAP Flags [Ext, no-L2, In], PCAP Extension(s) total length 22 Device Media Type Extension TLV #3, length 1, value: Ethernet (1) Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14) Device Interface Index Extension TLV #1, length 2, value: 132 Logical Interface Index Extension TLV #4, length 4, value: 365 Logical Unit Number Extension TLV #5, length 4, value: 511 -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 126, id 28940, offset 0, flags [none], proto: UDP (17), length: 76) 10.11.14.1.123 > 10.13.11.248.123: [udp sum ok] NTPv3, length 48 Server, Leap indicator: (0), Stratum 3, poll 9s, precision -6 Root Delay: 0.00, Root dispersion: 10.062759, Reference-ID: 202.175.115.244 Reference Timestamp: 3572566348.62949 Originator Timestamp: 3572570422.323693987 Receive Timestamp: 3572570422.31649 Transmit Timestamp: 3572570422.31649 Originator - Receive Timestamp: -0.007193988 Originator - Transmit Timestamp: -0.007193988 If you see the high root dispersion and you are using Windows 2003/2008 server, you can change the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config\LocalClockDispersion from value 10 to value 0 and then restart the time services in the command prompt by “w32tm /config /update”. After that you can then capture the NTP packet again the see that the value has changed and verify the client no synchronizes with the server. Hope this helps, Jared From: Abdullah Baheer To: "juniper-nsp@puck.nether.net" Sent: Wednesday, July 24, 2013 6:13 AM Subject: [j-nsp] Windows NTP server for JUNOS client Hi Has anyone tried to synchronize NTP from Junos device towards Windows NTP server (NTP running as a service from Windows)? I am trying and getting the following output: show ntp associations remote refid st t when poll reach delay offset jitter == 192.168.x.x .LOCL. 1 - 1 64 1 3.438 -13033. 73.051 There is no "*" in the beginning, in stead there is a space, which I checked and it means: * space—Discarded because of a high stratum value or failed sanity checks. My Netscreen devices are able to sync with this NTP server. Thanks Abdullah Baheer ___ 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] Windows NTP server for JUNOS client
Hi Abdullah, I have seen others experience issues when using a Windows server as their NTP server when that server does not have an external time source. Does your Windows NTP server have an upstream time source? If not, you could try to link it with one to see if that fixes the issue. If not, you may need to do some local modifications on the server. As I understand it the issue stems from a high root dispersion value on the WIndows server. You can confirm the root dispersion value by capturing an inbound NTP packet on your Junos device: 12:40:22.325750 In Juniper PCAP Flags [Ext, no-L2, In], PCAP Extension(s) total length 22 Device Media Type Extension TLV #3, length 1, value: Ethernet (1) Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14) Device Interface Index Extension TLV #1, length 2, value: 132 Logical Interface Index Extension TLV #4, length 4, value: 365 Logical Unit Number Extension TLV #5, length 4, value: 511 -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 126, id 28940, offset 0, flags [none], proto: UDP (17), length: 76) 10.11.14.1.123 > 10.13.11.248.123: [udp sum ok] NTPv3, length 48 Server, Leap indicator: (0), Stratum 3, poll 9s, precision -6 Root Delay: 0.00, Root dispersion: 10.062759, Reference-ID: 202.175.115.244 Reference Timestamp: 3572566348.62949 Originator Timestamp: 3572570422.323693987 Receive Timestamp: 3572570422.31649 Transmit Timestamp: 3572570422.31649 Originator - Receive Timestamp: -0.007193988 Originator - Transmit Timestamp: -0.007193988 If you see the high root dispersion and you are using Windows 2003/2008 server, you can change the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config\LocalClockDispersion from value 10 to value 0 and then restart the time services in the command prompt by “w32tm /config /update”. After that you can then capture the NTP packet again the see that the value has changed and verify the client no synchronizes with the server. Hope this helps, Jared From: Abdullah Baheer To: "juniper-nsp@puck.nether.net" Sent: Wednesday, July 24, 2013 6:13 AM Subject: [j-nsp] Windows NTP server for JUNOS client Hi Has anyone tried to synchronize NTP from Junos device towards Windows NTP server (NTP running as a service from Windows)? I am trying and getting the following output: show ntp associations remote refid st t when poll reach delay offset jitter == 192.168.x.x .LOCL. 1 - 1 64 1 3.438 -13033. 73.051 There is no "*" in the beginning, in stead there is a space, which I checked and it means: * space—Discarded because of a high stratum value or failed sanity checks. My Netscreen devices are able to sync with this NTP server. Thanks Abdullah Baheer ___ 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] Correct config for SRX port channel -> Cisco
If I have a single SRX3600 device (NOT a cluster), what config (if
any...) can I use to match a config on the Cisco side:
int
lacp rate fast
channel-group 20 mode active
int Po20
switchport
switchport mode trunk
switchport trunk allowed vlan 999
int Vlan999
ip address 192.168.1.1 255.255.255.254
I would have thought it would be something like:
chassis {
aggregated-devices {
ethernet {
device-count 2;
}
}
}
interfaces {
xe-1/0/0 {
gigether-options {
802.3ad ae0;
}
}
xe-1/0/1 {
disable;
}
xe-4/0/0 {
gigether-options {
802.3ad ae0;
}
}
xe-4/0/1 {
disable;
}
ae0 {
vlan-tagging;
aggregated-ether-options {
lacp {
active;
periodic fast;
}
}
unit 999 {
vlan-id 999;
family inet {
address 192.168.1.2/31;
}
}
}
}
...but this never comes up. I've seen this before, and I think it's
because there's something in the LACP PDUs which disagrees about
trunk/access mode. The config works if I set the Cisco side to "access",
but obviously that's not what I want.
Can you even do this on SRX? I see lots of documents talking about reth
interfaces, but AFAICT those are all for chassis clustering, which we
don't want to use.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 version
This is unrelated somewhat, but what are the current LAG member limits as well as ECMP limits? Any restrictions on LAG+ECMP? phil From: Sam Sent: 7/24/2013 8:46 To: Bouzemarene, Farid (ATS) Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX4550 version Hi Farid, >From an old case I had open with Juniper: >The EX4550 has an ARP table of maximum 8k entries. > These entries are tracked in the kernel through something called tokens. > Each ARP entry is a token. > > Because we have only 8k tokens available, from here we have the maximum > number of ARP entries. > > However, because of how the chipset of EX4550 is designed, the MPLS LSPs are > also making use of the same tokens. > But each MPLS LSP is using 8 tokens. Therefore, 1000 LSPs would use all > tokens and no ARP can be learned. > > The token usage is scaled up by the number of ECMP next-hops. So 1 LSP with 4 > ECMP next-hops will take 1*8*4=32 tokens. -- sam On 24 Jul 2013, at 11:28, "Bouzemarene, Farid (ATS)" wrote: > Hello, > > Can you clarify the MPLS limits ? > > Thx > > - Message d'origine - > De : Sam [mailto:sam...@arahant.net] > Envoyé : Wednesday, July 24, 2013 10:39 AM > À : Luca Salvatore > Cc : juniper-nsp@puck.nether.net > Objet : Re: [j-nsp] EX4550 version > > I used the 12.3R2.5 for quite some time now without any issue. The platform > has its limitations (especially related to how MPLS is handled), but if > you're just using it for L2 or basic L3 it works just fine. > > -- > sam > > On 24 Jul 2013, at 03:27, Luca Salvatore wrote: > >> Hi All, >> >> Just got a couple of new EX4550 switches... current recommended version is >> 12.2r2.5 >> But I just saw tha the 12.2 train is up release 5.3. >> >> Just wondering what the rest of you guys are running and if you have any >> horror stories. >> I'm not doing VC with these guys, they are going to be a pretty simple layer >> 2 aggregation type switch. >> >> Thanks. >> >> ___ >> 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 ___ 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] EX4550 version
Hi Farid, >From an old case I had open with Juniper: >The EX4550 has an ARP table of maximum 8k entries. > These entries are tracked in the kernel through something called tokens. > Each ARP entry is a token. > > Because we have only 8k tokens available, from here we have the maximum > number of ARP entries. > > However, because of how the chipset of EX4550 is designed, the MPLS LSPs are > also making use of the same tokens. > But each MPLS LSP is using 8 tokens. Therefore, 1000 LSPs would use all > tokens and no ARP can be learned. > > The token usage is scaled up by the number of ECMP next-hops. So 1 LSP with 4 > ECMP next-hops will take 1*8*4=32 tokens. -- sam On 24 Jul 2013, at 11:28, "Bouzemarene, Farid (ATS)" wrote: > Hello, > > Can you clarify the MPLS limits ? > > Thx > > - Message d'origine - > De : Sam [mailto:sam...@arahant.net] > Envoyé : Wednesday, July 24, 2013 10:39 AM > À : Luca Salvatore > Cc : juniper-nsp@puck.nether.net > Objet : Re: [j-nsp] EX4550 version > > I used the 12.3R2.5 for quite some time now without any issue. The platform > has its limitations (especially related to how MPLS is handled), but if > you're just using it for L2 or basic L3 it works just fine. > > -- > sam > > On 24 Jul 2013, at 03:27, Luca Salvatore wrote: > >> Hi All, >> >> Just got a couple of new EX4550 switches... current recommended version is >> 12.2r2.5 >> But I just saw tha the 12.2 train is up release 5.3. >> >> Just wondering what the rest of you guys are running and if you have any >> horror stories. >> I'm not doing VC with these guys, they are going to be a pretty simple layer >> 2 aggregation type switch. >> >> Thanks. >> >> ___ >> 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Windows NTP server for JUNOS client
Hi Has anyone tried to synchronize NTP from Junos device towards Windows NTP server (NTP running as a service from Windows)? I am trying and getting the following output: show ntp associations remote refid st t when poll reach delay offset jitter == 192.168.x.x .LOCL. 1 - 1 64 1 3.438 -13033. 73.051 There is no "*" in the beginning, in stead there is a space, which I checked and it means: * space—Discarded because of a high stratum value or failed sanity checks. My Netscreen devices are able to sync with this NTP server. Thanks Abdullah Baheer ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX devices upgraded to 2GB ram
> This transition isn't that big a deal - it's happened plenty of times in the > past. J-Series with 256MB RAM and flash anyone? At least with the J-2300 (and probably others) you could easily upgrade both ram & flash. For many of the branch srx devices this isn't possible. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX devices upgraded to 2GB ram
Not even remotely true - I have a 240H and a 240H2 clustered together on my desk right beside me - no issues.. Wow, thanks. Though I wonder if you can cluster SRX***B with and H2 one. They are not shipping to Russia yet, so I can't check myself. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX devices upgraded to 2GB ram
Not even remotely true - I have a 240H and a 240H2 clustered together on my desk right beside me - no issues.. Wow, thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 version
There was a bug in 12.2R3 which cause VC cable not to forward traffic should be fixed in R4 (look in the list archive for the PSN ) Now I am working with 12.2R3 and R4 without VC Nitzan On Wed, Jul 24, 2013 at 10:38 AM, Nick Kritsky wrote: > I have several running 12.2R1.8, some of them as pure L2 aggregation > switches, some of them doing basic L3 including OSPF, VRRP. No VC. > No issues found so far. > > nick > > > On Wed, Jul 24, 2013 at 5:27 AM, Luca Salvatore wrote: > > > Hi All, > > > > Just got a couple of new EX4550 switches... current recommended version > is > > 12.2r2.5 > > But I just saw tha the 12.2 train is up release 5.3. > > > > Just wondering what the rest of you guys are running and if you have any > > horror stories. > > I'm not doing VC with these guys, they are going to be a pretty simple > > layer 2 aggregation type switch. > > > > Thanks. > > > > ___ > > 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 version
I'll be deploying a couple of EX4550 doing mainly L3/MPLS stuff (ospf, bgp, l3vpn, l2circuit) and I'm going to roll out 12.3R3.4. Generally I prefer using at least an R3 release and as Juniper promised me that 12.3 would be 'the next 11.4' then I'm going for this one. 2013/7/24 Luca Salvatore : > Hi All, > > Just got a couple of new EX4550 switches... current recommended version is > 12.2r2.5 > But I just saw tha the 12.2 train is up release 5.3. > > Just wondering what the rest of you guys are running and if you have any > horror stories. > I'm not doing VC with these guys, they are going to be a pretty simple layer > 2 aggregation type switch. > > Thanks. > > ___ > 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] IDP series SSL decryption
Hello, i wonder if the IDP series (75, 250 etc) are able to decrypt SSL sessions using keys transparently to check for IPS. According to http://www.juniper.net/techpubs/en_US/idp5.0/topics/task/configuration/intrusion-detection-prevention-ssl-decryption-enabling.html this should be possible. I wonder if this is really transparent in terms of certificate errors showing up on the clients browser visiting a site behind the IDP. (Internet -> IDP -> SSL Server) Does the IDP in this mode mangle with the SSL packets in any way? If anyone has a setup like the above and can confirm that it works i'd like to hear about it. -Jonas signature.asc Description: This is a digitally signed message part ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 version
I used the 12.3R2.5 for quite some time now without any issue. The platform has its limitations (especially related to how MPLS is handled), but if you're just using it for L2 or basic L3 it works just fine. -- sam On 24 Jul 2013, at 03:27, Luca Salvatore wrote: > Hi All, > > Just got a couple of new EX4550 switches... current recommended version is > 12.2r2.5 > But I just saw tha the 12.2 train is up release 5.3. > > Just wondering what the rest of you guys are running and if you have any > horror stories. > I'm not doing VC with these guys, they are going to be a pretty simple layer > 2 aggregation type switch. > > Thanks. > > ___ > 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] EX4550 version
I have several running 12.2R1.8, some of them as pure L2 aggregation switches, some of them doing basic L3 including OSPF, VRRP. No VC. No issues found so far. nick On Wed, Jul 24, 2013 at 5:27 AM, Luca Salvatore wrote: > Hi All, > > Just got a couple of new EX4550 switches... current recommended version is > 12.2r2.5 > But I just saw tha the 12.2 train is up release 5.3. > > Just wondering what the rest of you guys are running and if you have any > horror stories. > I'm not doing VC with these guys, they are going to be a pretty simple > layer 2 aggregation type switch. > > Thanks. > > ___ > 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
