Re: [j-nsp] Recommended firmware for QFX5100-48T
You can set "ether-options autonegotiate" on XE interfaces, and it will do
just as you'd expect.
Firmware on QFX-5100-48T is bad in a lot of ways, but we've gotten them to
work mostly as youd want.
We are on 14.1X53-D35.3
xe-0/0/0 {
ether-options {
auto-negotiation;
}
unit 0 {
family ethernet-switching;
}
}
On Mon, Oct 10, 2016 at 1:34 PM, Dale Shaw <dale.shaw+j-...@gmail.com>
wrote:
> Hi all,
>
> On 11 Oct 2016 6:23 AM, "Graham Brown" <juniper-...@grahambrown.info>
> wrote:
> >
> > Hi Paul,
> >
> > Correct, just use 'replace pattern xe-0/0/0 with ge-0/0/0' etc and you
> > should be fine.
>
> I don't think that's how it works on qfx5100-48**T**
>
> It's more like copper based EX, where the interfaces are configured as
> ge-x/x/x even if they're plugged into something capable of only 10 or
> 100BASE-T operation.
>
> I seem to recall that there is a trick to making it work that involves
> autoneg but I'm currently using a tiny screen and an imaginary keyboard so
> digging up the details isn't possible right now.
>
> I'm certain that JTAC could help but I'll try to find something when I'm
> properly online.
>
> Cheers,
> Dale
>
> > On 11 October 2016 at 07:05, Paul S. <cont...@winterei.se> wrote:
> >
> > > Hi Joel,
> > >
> > > Thanks for replying.
> > >
> > > What are the steps to configure the ports as "ge." Do I just get rid of
> xe
> > > from the config and replace it with ge for that port, that's all?
> > >
> > >
> > > On 10/11/2016 12:21 AM, joel jaeggli wrote:
> > >
> > >> On 10/10/16 7:34 AM, Paul S. wrote:
> > >>
> > >>> Hi folks,
> > >>>
> > >>> Are everyone running the JTAC recommended 14.1X53-D35.3 or have you
> > >>> found better stability at some newer revision?
> > >>>
> > >>> My problem is that the "tri state" 10g ports (copper) don't seem to
> > >>> want to run at anything less than 10g. It links up when connected to
> a
> > >>> 1g device, but still claims that the port is operating in 10g mode.
> > >>>
> > >>> The biggest issue I have is that if I assign a /30 to the p2p
> > >>> interfaces (between the qfx and any copper 1g device), my p2p latency
> > >>> is somewhere from 10 to 40ms.
> > >>>
> > >>> I asked around to see if there's any way to force the ports into 1g
> > >>> mode, but the "speed" knob is missing. I deliberately turned on
> > >>> auto-negotiation, does not seem to help.
> > >>>
> > >>> 802.3ad LAGs created using any of these links also claim to have
> > >>> speeds of 20g/40g when there's in reality only 4g of capacity.
> > >>>
> > >>> Can someone hit me with a clue stick? Thanks!
> > >>>
> > >> I presume that you're specifing the port config as ge-0/0/foo rather
> > >> than xe-0/0/foo
> > >>
> > >> joel@ show interfaces ge-0/0/46
> > >> Physical interface: ge-0/0/46, Enabled, Physical link is Up
> > >>Interface index: 701, SNMP ifIndex: 616
> > >>Description:
> > >>Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error:
> > >> None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering:
> > >> Disabled, Flow control: Disabled, Auto-negotiation: Enabled,
> > >>Remote fault: Online, Media type: Copper
> > >>Device flags : Present Running
> > >>Interface flags: SNMP-Traps Internal: 0x4000
> > >>Link flags : None
> > >>CoS queues : 12 supported, 12 maximum usable queues
> > >>Current address:
> > >>Last flapped : 2016-08-26 03:31:56 UTC (6w3d 19:46 ago)
> > >>Input rate : 0 bps (0 pps)
> > >>Output rate: 0 bps (0 pps)
> > >>Active alarms : None
> > >>Active defects : None
> > >>Interface transmit statistics: Disabled
> > >>
> > >>Logical interface ge-0/0/46.0 (Index 563) (SNMP ifIndex 617)
> > >> Flags: SNMP-Traps 0x4004000 Encapsulation: ENET2
> > >> Input packets : 146287
> > >> Output packets: 292513
> > >> Protocol inet, MTU: 1500
> > >> Flags: Sendbcast-pkt-to-re
> > >>Addresses, Flags: Is-Preferred Is-Prim
Re: [j-nsp] SRX 1500
The 1400's are basically a fixed form factor too - never saw much in the way of an upgrade path (unless you just jump to 3400's). 1500 seems like a fair compromise On Thu, May 19, 2016 at 2:06 PM, Hugo Slabbert <h...@slabnet.com> wrote: > > On Thu 2016-May-19 14:03:31 -0700, Brent Jones <br...@brentrjones.com> > wrote: > > I use SRX1400's, so if the 1500 is just a "newer, better. faster", I'm >> interested. >> > > More juice; more of a fixed form factor. Also running 1400s and have not > yet toyed with the 1500s. > -- > Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com > pgp key: B178313E | also on Signal > > > >> On Thu, May 19, 2016 at 12:57 PM, Maxwell Cole < >> mcole.mailingli...@gmail.com >> >>> wrote: >>> >> >> Heya. >>> >>> Has anyone used box yet? >>> >>> >>> http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/ >>> < >>> >>> http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/ >>> > >>> >>> It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib >>> and 86x running Junos 15 at 11k msrp. Looks like it might be pretty >>> interesting for a small deploy depending on the speeds it can get in >>> packet >>> mode. Pick up a table or two on the sfp+ and an IX on the 1g sip. >>> Anyone comment on convergence time, feature set, commit time etc? I see >>> 16G of ram which should be nice for its RIB but no info on the CPU >>> itself. >>> Is it a xeon? >>> >>> Looks like a very interesting box but I have yet to hear anything about >>> it. >>> >>> Cheers, >>> Max >>> _______ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >>> >> >> >> -- >> Brent Jones >> br...@brentrjones.com >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 1500
I use SRX1400's, so if the 1500 is just a "newer, better. faster", I'm interested. On Thu, May 19, 2016 at 12:57 PM, Maxwell Cole <mcole.mailingli...@gmail.com > wrote: > Heya. > > Has anyone used box yet? > > http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/ > < > http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/ > > > > It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib > and 86x running Junos 15 at 11k msrp. Looks like it might be pretty > interesting for a small deploy depending on the speeds it can get in packet > mode. Pick up a table or two on the sfp+ and an IX on the 1g sip. > Anyone comment on convergence time, feature set, commit time etc? I see > 16G of ram which should be nice for its RIB but no info on the CPU itself. > Is it a xeon? > > Looks like a very interesting box but I have yet to hear anything about it. > > Cheers, > Max > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Monitoring a gre tunnel on an EX4200
Oh, nice trick. Didn't know about that! On Tue, May 17, 2016 at 10:26 PM, Victor Sudakov <v...@mpeks.tomsk.su> wrote: > Victor Sudakov wrote: > > > > > > > Could you perhaps suggest an SNMP OID to monitor the OSPF adjacency > in > > > > a non-default routing-instance? > > > > > > Likely. I'll SNMPWalk my EX2220c here and see if I can spot > > > anything. I recall seeing something in an OSPF MIB last time when I > > > did this; but never implemented it myself. > > > > I don't seem to be able to get access to the states of OSPF neighbors > > in a *non-default* *routing-instance*. > > Indeed it's documented. One should add the routing-instance name to > the community string, like "LTM@public" instead of just "public." > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > sip:suda...@sibptus.tomsk.ru > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Reliability
On Wed, Jun 12, 2013 at 5:41 AM, Andrew Gabriel mailandr...@gmail.comwrote: On Wed, Jun 12, 2013 at 3:58 PM, Phil Mayers p.may...@imperial.ac.uk wrote: We recently evaluated an SRX 3600, and modulo some minor cosmetic bugs and one major one (PSN-2012-10-754, fixed in later software) they seemed solid to me. We tested IPv4 IPv6 layer4 firewalling, AppFW, dynamic routing with BGP and multicast. It all seemed to work ok, and we have gone ahead and purchased. It might help if you could specify what sort of things you want to do on them e.g. IPsec, IDP, inline AV/web filtering (which the 3000s can't do) and so forth. Hi Phil, Thanks, we are mainly looking at basic FW, VPN, and routing capability, which we need to be rock solid. We do not intend to use the IPS and UTM type features at the moment. Thanks, -Andrew. We have several sets of SRX1400s in chassis cluster, plus dozens of SRXs from SRX100's up to SRX240's throughout various offices. We've had minor bugs here and there, but they get resolved through code or workarounds, no more bugs than other vendors really. Early on, yes, pre-10, tons of bugs, but 10.4 and greater are solid. We do various NAT, FW, VPNs, routing instances, etc, no issues to report. -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] experience using 10G DAC (twinax) cables between EX and multi-vendor
Care to share any details? Such as what problems you had with twinax, and how you overcame the cost disparity? On Wed, May 15, 2013 at 12:57 PM, Morgan McLean wrx...@gmail.com wrote: Go with optics, the twinax cables are garbage in my experience. In the process of removing all the twinax from my network in favor of optics. Morgan On Wed, May 15, 2013 at 11:16 AM, Andy Litzinger andy.litzin...@theplatform.com wrote: Has anyone used a 10G DAC/Twinax cable between an EX4550 and other vendor gear? Did you use Juniper DAC cables or the other vendor cables? In particular I'm planning on linking a Cisco UCS Fabric Interconnect and also an F5 BigIP 4200v to a VC of EX4550s. would you recommend it or should I fork over the money to use optics? thanks! -andy ___ 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 -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] high 10GE port density in EX switch?
There is always the EX4550, 32 10Gb ports in 1U, with a module to add 8 more I believe On Sat, Feb 2, 2013 at 1:43 PM, Eugeniu Patrascu eu...@imacandi.net wrote: On Sun, Dec 16, 2012 at 4:13 AM, Michel de Nostredame d.nos...@gmail.com wrote: Hi There~ One of my customers has some Cisco Nexus 7K but budget wise prevents him from buying N7K in new locations. His environment is pretty simple and straight forward. Lots of 10GE ports (around 2200 ports) divide into around 30+ VLANs. Then uplink to two MX routers (the border) and go to Internet. Previous setups were using N5K as L2 access switch and aggregate to N7K as core L3 switch, then multiple 10GE L3 uplinks to MX480. The N7K is doing VLAN routing and lots (total 3+ thousand lines) of ACL. The QFX total solution looks pretty interesting, but does not have too significant price difference compares to Nexus solution. Will Juniper ship new switch fabric on EX 8000 series to support line-rate high port density 10GE? (for example, 40 port line rate 10GE per slot.) If you do not really need line rate 40 x 10Gbps ports you can go with EX8200-40XS and fill a 8216 with them. It's oversubscribed 5:1 in 5x8 port groups. Another option for a lot of 10G ports would be a stack of EX4500 switches, but you would still be limited by the Virtual Chassis available bandwidth (128Gbps Half-Duplex) - but if you can get some flexibility as you can try to mix and match servers that talk to each other on the same switch in order to have line rate 10G traffic and avoid VC traffic. You can use the up-link modules to populate them with 10G ports and do a MC-LAG to the MXs. Even with the QFabric, you would still need to run a lot of 40G interconnect ports in order to have a high throughput fabric backplane. Other vendor that might do (you should check with them) full line rate 40+ 10GbE ports is Brocade with the new VDX 8770-8 switch (they claim 4Tbps/slot and 384 ports per 15U chassis). HTH. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How are max routes calculated on an SRX
You're better off putting a router in front of your SRX to handle taking full feeds. You -can- do it on the SRX, but as mentioned, it isn't a fast platform for converging. If you're looking for on the cheap, MX5s can be had for a song. On Wed, Oct 17, 2012 at 5:12 PM, Morgan McLean wrx...@gmail.com wrote: 700,000 routes in the control plane, as far as I know. Let me share my experience. SRX650 cluster, max routes somewhere along that 700k number you gave. I was taking four feeds, giving me somewhere around 1.6M routes. It technically took all of them, but it took 20 minutes to failover all of those routes to another interface. The box was way overloaded and caused major headaches. It would do things like say next hop unavailable etc, this was because the forwarding plane still was pointing the route to the downed interface, while the control plane was already looking to the backup. Morgan On Wed, Oct 17, 2012 at 5:04 PM, Skeeve Stevens skeeve+juniper...@eintellego.net wrote: Hey all, I am considering using an SRX550 as a border router - its cheap, fast, and flexible, with a great selection of interfaces. Question is the specs say it can support a maximum of 700k routes. Now, if what I suspect is right, that is great, but I am getting conflicting information. A full feed at the moment is about 430k routes. So I am hoping that the SRX550 could take multiple full feeds... lets say - 3-4, and it just installs a single unique copy of the full feed which is way under the 700k threshold. But someone was trying to tell me that it couldn't take two world feeds as together they are 860k routes.. but my gut feeling is that this is wrong as I am not sure what purpose the SRX550 having 700k route capacity would be if it operated that way. Any pointers to documentation that supported how Juniper SRX counted their routes would be great. ...Skeeve * * *Skeeve Stevens, CEO - *eintellego Pty Ltd ske...@eintellego.net ; www.eintellego.net Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net The Experts Who The Experts Call Juniper - Cisco – IBM - Cloud ___ 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 -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Static NAT - Not working in both directions
Try to apply the static NAT policy to zone 'user' and see how that goes.
On Fri, Sep 7, 2012 at 12:22 PM, Oliver Garraux oli...@g.garraux.net wrote:
Hey,
I recently bought an SRX and have been trying the different NAT
configuration options to become more familar with JunOS.
Static NAT isn't operating quite as I'd expect from the documentation.
My understanding is that static NAT should be bidirectional, in that
it should translate connections going in both directions.
I'm using 192.168.32.0/24 on the interface connected to the rest of my
network (ge-0/0/0.100), and 192.168.35.0/24 on vlan.200 on my SRX.
ge-0/0/0.100 is in the trust zone, and vlan.200 is in the user
zone.
static {
rule-set user_to_trust {
from zone trust;
rule desktop1 {
match {
destination-address 192.168.32.5/32;
}
then {
static-nat prefix 192.168.35.200/32;
}
}
}
}
proxy-arp {
interface ge-0/0/0.100 {
address {
192.168.32.5/32;
}
}
}
I'm only seeing it translate connections coming in to the destination
address (192.168.32.5). The source address on connections initiated
by the static-nat address (192.168.35.200 - the address on the
desktop sitting behind my SRX) are not being translated to
192.168.32.5. Am I misunderstanding how static NAT works?
I've tried using an IP that is routed to the SRX (where no proxy-arp
should have been required in that situation). I also don't see the
address being translated when I look at these flows in show security
flow session, so I don't think this is an issue with proxy-arp. I'm
permitting all traffic between the user and trust zones (in both
directions) in my security policies.
Here's one of the flow entries when I try to ping from 192.168.35.200
to 192.168.17.16
Session ID: 21626, Policy name: permit-all/5, Timeout: 16, Valid
In: 192.168.35.200/25622 -- 192.168.17.16/1280;icmp, If: vlan.200,
Pkts: 1, Bytes: 60
Out: 192.168.17.16/1280 -- 192.168.35.200/25622;icmp, If:
ge-0/0/0.100, Pkts: 0, Bytes: 0
Any ideas?
Thanks,
Oliver
-
Oliver Garraux
Check out my blog: www.GetSimpliciti.com/blog
Follow me on Twitter: twitter.com/olivergarraux
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Brent Jones
br...@brentrjones.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 LLDP service crash
On Fri, Aug 17, 2012 at 5:56 PM, Sergey T pu...@puhis.net wrote: Hi! (platform:QFX3500, junos:12.2X50-D10.3) Have a problem with LLDP service on QFX3500 Service never starts on boot without any log-lines. When i try to restart it manually have that crash-report: serj@qfx3500-p2a restart lldpd-service error: Link Layer Discovery Protocol is not running Link Layer Discovery Protocol started, pid 90798 serj@qfx3500-p2a show log messages Aug 18 03:50:04 qfx3500-p2a mgd[41086]: UI_RESTART_EVENT: User 'serj' restarting daemon 'Link Layer Discovery Protocol' Aug 18 03:50:04 qfx3500-p2a init: lldpd-service (PID 90798) started Aug 18 03:50:04 qfx3500-p2a /kernel: cpuid = 0 Aug 18 03:50:04 qfx3500-p2a /kernel: BAD_PAGE_FAULT: pid 90798 (lldpd), uid 0: pc 0x57bca4 got a read fault at 0x4 Aug 18 03:50:04 qfx3500-p2a /kernel: Trapframe Register Dump: Aug 18 03:50:04 qfx3500-p2a /kernel: zero: at: 0001 v0: 0004v1: 0189 Aug 18 03:50:04 qfx3500-p2a /kernel: a0: 0004a1: 0005 a2: 00a22190a3: 0001 Aug 18 03:50:04 qfx3500-p2a /kernel: t0: 002bt1: 77feb62d t2: 77feb62dt3: Aug 18 03:50:04 qfx3500-p2a /kernel: t4: ff00t5: t6: t7: 001c Aug 18 03:50:04 qfx3500-p2a /kernel: t8: 00fft9: 0057bc50 s0: 0004s1: 0001 Aug 18 03:50:04 qfx3500-p2a /kernel: s2: 0001s3: s4: 00a09c00s5: Aug 18 03:50:04 qfx3500-p2a /kernel: s6: 00a0c000s7: 0001 k0: k1: Aug 18 03:50:04 qfx3500-p2a /kernel: gp: 00979120sp: 77feaf00 s8: 77feaf00ra: 0057bc34 Aug 18 03:50:04 qfx3500-p2a /kernel: sr: 50809813badvaddr: 0004 Aug 18 03:50:04 qfx3500-p2a /kernel: mullo: 000c mulhi: Aug 18 03:50:04 qfx3500-p2a /kernel: cause: 0008 pc: 0057bca4 Aug 18 03:50:04 qfx3500-p2a /kernel: Page table info for pc address 0x57bca4: pde = 0x87d6b000, pte = 0x4109271a Aug 18 03:50:04 qfx3500-p2a /kernel: Dumping 4 words starting at pc address 0x57bca4: Aug 18 03:50:04 qfx3500-p2a /kernel: 8c42 afc20020 8fc20020 1444 Aug 18 03:50:05 qfx3500-p2a init: lldpd-service (PID 90798) terminated by signal number 11. Core dumped! Aug 18 03:50:22 qfx3500-p2a init: lldpd-service is thrashing, not restarted Somebody have any ideas? -- Sergey Tkachenko +38-050-3266737 __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp I would stick with recommended releases (11.3R5.5 afaik). I run 11.3R5.3 right now without any problems (besides some 3rd party optics still locked out by Juniper). If you follow every release, you will be hurting. -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Firewall best practices
On Mon, Jun 11, 2012 at 8:14 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Wayne, Thanks for this - that's actually a really good solution I hadn't even considered - I can take it a step further and use wildcards on the zone to solve my multiple address-book on a single zone request: set groups HQ-UNTRUST-HOSTS security zones security-zone * address-book address U-HOST1 200.1.1.1/32 set groups HQ-UNTRUST-HOSTS security zones security-zone * address-book address U-HOST2 200.1.1.2/32 set groups HQ-UNTRUST-HOSTS security zones security-zone * address-book address U-HOST3 200.1.1.3/32 set groups HQ-DMZ-HOSTS security zones security-zone * address-book address D-HOST1 100.1.1.1/32 set groups HQ-DMZ-HOSTS security zones security-zone * address-book address D-HOST2 100.1.1.2/32 set groups HQ-DMZ-HOSTS security zones security-zone * address-book address D-HOST3 100.1.1.3/32 set security zones security-zone WAN apply-groups [HQ-UNTRUST-HOSTS HQ-DMZ-HOSTS] Neat! On 12/06/2012, at 12:49 PM, Wayne Tucker wrote: On Mon, Jun 11, 2012 at 5:04 PM, Ben Dale bd...@comlinx.com.au wrote: What would really help though is if Junos allowed multiple address-books to be bound to a single zone - that way, SRXs buried deeper in your network would have access to all address-book entries on a single upstream zone with very little configuration management. I'm sure this concept would make tools like Space and NSM easier to use as well - Juniper SRX PLMs are you listening out there? SAVE US! It takes some getting used to, but this can be accomplished through configuration groups: Here's a vanilla address book on a Junos 10.4 box: # show security zones security-zone trust address-book address ironman 192.168.0.16/32; address knife 192.168.0.8/32; Create a couple of groups and apply them: # set groups group1 security zones security-zone trust address-book address address1 192.168.0.1/32 # set groups group2 security zones security-zone trust address-book address address2 192.168.0.1/32 # set apply-groups [ group1 group2 ] And now the address book contains the additional entries: # show security zones security-zone trust address-book | display inheritance address ironman 192.168.0.16/32; address knife 192.168.0.8/32; address inet6:sandman 2001:470:ea7c:0:221:6aff:fe66:bdcc/128; ## ## 'address1' was inherited from group 'group1' ## '192.168.0.1/32' was inherited from group 'group1' ## address address1 192.168.0.1/32; ## ## 'address2' was inherited from group 'group2' ## '192.168.0.1/32' was inherited from group 'group2' ## address address2 192.168.0.1/32; An added bonus of having the address book (or almost other configuration) in a group is that you can use load replace (or the equivalent in the XML API) to keep it consistent when you distribute it around. Add a few more layers and you could have a fully fledged system for managing any configuration bits on a device. :w Yup, this is a good way to go. I manage a dozen or so SRXs with apply groups configured this way (apply group for address groups, security zones inherit those groups). Makes configs pretty easy to read, and as noted above, load replace is a great tool via Rancid jlogin or via XML. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX recommended software
On Mon, Apr 2, 2012 at 2:24 PM, Jeff Rooney jtroo...@nexdlevel.com wrote: I have a few SRX650's that are running 10.4R9.2 per the Juniper recommended release page http://kb.juniper.net/InfoCenter/index?page=contentid=KB21476 However, I just have a few more which came with 11.2R4.3 on them. Just curious as to what everyone is running on these, should I downgrade the new guys? or upgrade old? The workload on these boxes is nothing crazy, some IPSEC vpn, OSPF with about 200 routes, firewalling, no cluster...etc. Thanks for any input. Jeff ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp I still run 11.1R3.5 on several sets of SRX1400s. Then on branch units, I chose to stick with 10.4R6.5 I have to say, no major issues uncovered so far, same stuff as you, IPSec, VPNs, OSPF... -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] console switch to access juniper devices
On Fri, Mar 30, 2012 at 11:50 AM, Matt Hite li...@beatmixed.com wrote: Recently (within past 2 years) did a eval of console servers. I was pretty impressed with OpenGear. I will note I wasn't trying them with Juniper devices, but I'm sure it will work fine. In the end, we went with Avocent mainly because they could control pin-out via software and other vendors required special cabling for each device type. Avocent devices themselves are slow as snot. But the pin-out control was the deciding factor in the end. -M On Fri, Mar 30, 2012 at 4:40 AM, Sachin Rai sachinrai1...@hotmail.com wrote: Hi Team, I want to buy a console server and wanted to know, what are the available console servers compatible with Juniper devices. thanks Sachin ___ 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 We went with OpenGear, it is inexpensive and has all the features we need. Pretty solid boxes -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX8200 power supplies taking down an entire 208v circuit
On Tue, Mar 13, 2012 at 11:39 PM, Morgan McLean wrx...@gmail.com wrote: Hi everyone... I have a troubling problem. We run a couple EX8208's, and have a mix of 1200, 2000 and 3000w PSU's in use. So far within the past ~60 days, we have had 2 out of a total of 12 PSU's running have a failure. Unfortunately, thats not the problem. The problem is, when these PSUs die, they're taking out our entire circuit. A 20A 208v circuit, completely popped. Is this normal behavior when a PSU dies? We've had plenty of other units' PSUs go bad, and never experienced something like this. Its been different circuits in our two network cabs, and both weren't very loaded up last we checked before they popped. Usually just a couple amps worth. Any ideas? Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Certainly strange, I'd probably look at the breakers or fuses on the cabinet distribution first. I've seen different types of breakers have different reaction time to sudden loads. Could also be an upstream problem causing the EX's power supplies to fail. -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX240 - ready for prime time?
On Mon, Mar 5, 2012 at 3:28 PM, TCIS List Acct lista...@tulsaconnect.comwrote: Over the past few years the general feeling I've gotten reading j-nsp and elsewhere was to stay away from the SRX line until the code matured. We've got an upcoming project that I'm considering using a SRX 240 for. Has the code matured to the point that it can be considered a stable platform for security (just basic firewall, 1:1 NATs, maybe a few VPNs), high availability, and some very basic layer 3 routing services? TIA. --Mike __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp I have many SRXs, from 100's, to 1400's, and things in between. There are still some gotchas, but I would say they are very mature. On my branch units, I run 10.4R6.5, and on the highend units I run 11.1R3.5 Have not have any stability issues, they are quick, a pleasure to configure, and reliable. I wouldn't go back to ASAs ever at this point either -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX gui
On Mon, Mar 5, 2012 at 4:58 PM, David Klein davidkl...@dhk.com wrote: Just curious about your experiences with the SRX J-Web GUI. We have been testing the SRX-210 for a couple of years and have noticed that the GUI is very slow to load and configure compared to an SSG5. We're running the SRX at OS 11.4R1.6; the SSG5 at 6.2.0r5. Is it just the GUI on the SRX 210 that is slow? Does it run faster on the bigger hardware? We've tried it with IE8, IE9, and Firefox. Is there a specific browser or applet we need in order for it to run fast? If there is something that we need to do in order to make it run faster, please let me know. Thanks! -David Klein ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp The GUI across all Juniper products are generally pretty slow, I don't think it is a primary function that they spend a lot of resources to make it even usable half the time. Luckily, the CLI is fully functional :) -- Brent Jones br...@brentrjones.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX - DHCP client is not working right
On Wed, Oct 12, 2011 at 2:07 AM, martin papik pa...@utia.cas.cz wrote:
Hi,
a have detected very strange behaviour when SRX interface is configured as
DHCP client interface and this interface (untrust zone) is connected to
cable ISP modem (Motorola SurfBoard SB 5101). The ISP is UPC company
(Europe). The IP assigned address from ISP is related to MAC address of SRX
interface. But assigned IP is not right. With different device (like linksys
WRT with clone MAC) the assigned IP is OK.
I found same problem in juniper forum discussion here:
http://www.juniperforum.com/index.php?topic=8129.0
My conf is:
version 11.1R3.5;
interfaces {
fe-0/0/0 {
unit 0 {
family inet {
dhcp;
}
}
}
..
security-zone untrust {
screen untrust-screen;
interfaces {
fe-0/0/0.0 {
host-inbound-traffic {
system-services {
dhcp;
ping;
}
}
}
}
}
Have anybody some idea why assigned IP from ISP is not right (MAC is
registred by ISP and with another devices DHCP client working with good IP)?
I was thinking about TTL parameter, but I dont know how I can change
it..
Thanks
Martin
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
The DHCP client code doesn't work well (or at all) on 11.1 right now.
Roll back to 10.4, and you'll be good to go
--
Brent Jones
br...@servuhome.net
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Interesting EX4200 gotcha and resolution
On Sun, Sep 25, 2011 at 12:36 PM, Jeff Wheeler j...@inconcepts.biz wrote: A colleague pointed out recently that some of the gotchas and fixes we run into are interesting to others, so in that spirit, I have another one to share with you today. In this case, a malfunctioning EX4200 (10.4R4.5) appears to have valid ARP entries for a few boxes, but when you try to ping them, etc. the boxes do not get any traffic. In fact, they receive nothing from the switch except ARP who-has. They respond, and upon clearing the ARP entries from the EX4200, that process repeats. Upon investigating the PFE data, I found that the halp-nh arp-table was missing these ARP entries, even though they were present in the Junos CLI and indeed the correct MAC address is referenced in the PFE route table. See below: PFEM0(vty)# show route ip prefix 192.0.2.39 detail IPv4 Route Table 0, default.0, 0x0: Destination NH IP Addr Type NH ID Interface --- - - 192.0.2.39 192.0.2.39 Unicast 2933 RT-ifl 197 vlan.1122 ifl 197 RT flags: 0x, Ignore: 0x, COS index: 0 DCU id: 0, SCU id: 0, RPF ifl list id: 0 PFEM0(vty)# show nh id 2933 detail ID Type Interface Next Hop Addr Protocol Encap MTU Flags PFE internal Flags - - --- -- -- 2933 Unicast vlan.1122 192.0.2.39 IPv4 Ethernet 0 0x 0x Flags: 2 nh_idx: 3 CMD: Route Arp Idx: 1341 MTU Idx: 2 Num Tags: 0 Upd Cnt: 1 Tun Strt: False Chain_nh 3484: Hw install: 1 Mac: 00 0e 0c a2 2d dc PFEM0(vty)# show halp-nh arp-table Device: 0 ...hundreds and hundreds of lines... ArpEntry Idx 1340 : 00:15:17:6b:a9:7c ArpEntry Idx 1342 : 00:25:90:2c:41:e5 ...hundreds more, but where is Idx 1341?! Our fix is to remove 192.0.2.1/27 from the vlan.1122 configuration, commit, and then rollback. This is obviously not good. I would like to have tried installing a different ARP entry (by configuring this IP address on another machine) but I have not had an opportunity to test this yet. The reason this is happening is the ASIC vendor format ARP table in the PFE memory is abstracted from the Juniper ARP table, as I understand. It appears that simply refreshing the Juniper ARP table with an identical entry does not cause a missing entry to be put into the forwarding table. I would love to be able to reproduce this, but with hundreds to a few thousand machines each on many EX4200 stacks, it happens very rarely. I only mention it because clear arp from the CLI does not work, so this problem gets escalated until it reaches someone brave enough to temporarily break some unaffected boxes to fix a broken one. It would be nice, though, if clear arp actually worked right. If you encounter this problem and do something different, I would be very interested to hear from you! -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Did you observe any strange entries in /var/log/shadow when these events occur? I've had similar issues, where some EX4200's in a VC lose the ARP table, and traffic cannot transit the switch to another switch (if the traffic must go through that VCP). JTAC was unable to find any root cause, but there were number errors in /var/log/shadow about the ASIC forwarding table didn't match what was in software/memory -- Brent Jones br...@servuhome.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Experiences - Was: JUNOS 10.4S6 for EX8200 - PR/676826
On Thu, Sep 1, 2011 at 11:00 AM, Paul Stewart p...@paulstewart.org wrote: We have yet to see that even with PIM modules installed - do you remember what version of JunOS you were running by chance? Paul From: Nathan Sipes [mailto:nathan.si...@gmail.com] Sent: September-01-11 12:05 PM To: Paul Stewart Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826 I have had similar experiences to Richard's with the Free SRX210H I even managed to get a DSL PIM in there as well. Had it up and working for about 2 months when the pim quit forwarding traffic randomly. Rebooting the SRX seems to fix it well enough though... I will say that the free hardware has cost a lot of my time and some annoyed phone calls from my wife when netflix doesn't work. On Thu, Sep 1, 2011 at 9:48 AM, Paul Stewart p...@paulstewart.org wrote: Actually I'm curious as well - RAS is not typically wrong though about this kind of stuff ;) We have numerous SRX deployed for firewall and router functionality - some are running Dynamic VPN (which yes, we've had issues with - definitely it's not perfect). We've been bitten by some surprises as well ... so I'm not disagreeing, just saying that we're pretty used to these issues we've encountered and don't deploy if we know they will come up. Typically, we use them as site to site VPN boxes along with firewalling. I have an SRX210 at my home as well - run the full UTM suite on it and had no real issues (granted it's a home environment to be fair). RAS, can you share a few highlights of broken? Appreciate it, Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: September-01-11 11:35 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826 On 01/09/11 10:09, Richard A Steenbergen wrote: I have an SRX210 in my basement doing my home routing, and it is the only free device I've ever been given that I would seriously consider returning and asking for my money back. Broken doesn't even begin to describe it, my condolences to anyone who actually needs to run these things in production. Is this for routing functionality, or firewall functionality? We're using one as an MPLS PE, and it seems to be working ok, but given what you've said... gulp! Is there a good summary of the problems anywhere, or do I need to trawl the archives? ___ 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 I run multiple SRXs at several sites doing firewalling, routing, VPNs. Have everything from SRX100s, to SRX 1400s, branch units run 10.4R6 I believe, and SRX1400s running 11.1R3 (will double check later). Have had minor issues, mainly with VPNs to other vendor devices like Cisco ASAs. You have to be mindful if you need policy based VPN or route based VPNs to work with other vendors. I'd be curious to hear what problems other people have, for something to look out for, but otherwise the SRXs have worked as well as most anything else on the market. I would know, I've gone through the whole lifecycle of Cisco PIX, into ASAs, Sonicwall, Fortigate, etc, and I would say SRXs have worked better than most, especially considering they are a young product line. -- Brent Jones br...@servuhome.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN between Cisco and Juniper
On Sun, Jul 31, 2011 at 4:26 PM, David water dwater2...@gmail.com wrote: All, What are the factor to consider for implementing L3VPN between Cisco and Juniper? Any documentation that someone can share with me? -- David W. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Question is a bit vague, what considerations for your VPN tunnel are you looking for? Do you need route based VPN, or policy based VPN? Do you need routing protocols to traverse the VPN? Will traffic IPs be private or public? NAT? I've always found Cisco VPN (and NAT, and security policies, and practically everything actually) concepts to be a bit ... backwards, so some terminology doesn't match on both sides. If both sides have the correct settings, I have not had any major problems establishing VPNs between equipment vendors though. Also, cross posting may not be the best approach, especially with such a vague question. -- Brent Jones br...@servuhome.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Dell - Juniper
On Sun, Jul 17, 2011 at 4:37 PM, Ryan Finnesey ryan.finne...@harrierinvestments.com wrote: Does anyone have any comments on the switches Dell OEMs from Juniper? Are they truly the same? We meet with them last week regarding server and storage for a new DaaS build out. They told us they can offer us Dell networking hardware that they OEM from Juniper at a much lower cost than Juniper direct. Cheers Ryan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp The hardware is truly the same, minus a Dell logo, and Powered by JunOS sticker. Support wise, you are supposed to call Dell first for tier1/2 issues, and Dell can escalate to JTAC when necessary. We actually got better pricing when we worked with a Juniper direct account manager, funneling the purchasing through Dell. Juniper was able to approve larger discounts on Juniper branded equipment, than Dell could do on the Dell re-brand stuff. YMMV. Either way, you're getting real Juniper equipment, so you can't really lose. -- Brent Jones br...@servuhome.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MLAG on EX4500
On Sun, May 15, 2011 at 3:21 PM, Matt Hite li...@beatmixed.com wrote: Well, more or less, except as Doug points out the stacking/virtual-chassis is how one pulls it off. The idea is that a single host has two uplinks -- plugged into two separate EX4500's -- aggregated into single logical LACP-enabled port-channel/LAG. -M On Sun, May 15, 2011 at 10:59 AM, James Jones ja...@freedomnet.co.nz wrote: Are talking about multi-chassis lag? Sent from my iPhone On May 15, 2011, at 12:59 PM, Matt Hite li...@beatmixed.com wrote: Hello, Anyone have battle time using the virtual-chassis MLAG functionality on the EX4500 series? Has it given you any headache? Any potential pitfalls/bugs/versions I should look out for? We are exploring a high-availability LAG connection from hosts to pairs of redundant EX4500 joined into a virtual chassis. I would love to know if I am in for a world of hurt or not. Thanks, -M ___ 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 It isn't MLAG in the sense of Arista's technology, but you can have two 4500's in a VC and span a LAG across members just fine. Without VC (or the equivalent from any other switch vendor) this is not possible. -- Brent Jones br...@servuhome.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MLAG on EX4500
On Sun, May 15, 2011 at 9:59 AM, Matt Hite li...@beatmixed.com wrote: Hello, Anyone have battle time using the virtual-chassis MLAG functionality on the EX4500 series? Has it given you any headache? Any potential pitfalls/bugs/versions I should look out for? We are exploring a high-availability LAG connection from hosts to pairs of redundant EX4500 joined into a virtual chassis. I would love to know if I am in for a world of hurt or not. Thanks, -M ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Works fine for me -- Brent Jones br...@servuhome.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX-series Redundant RE - Unable to mask fxp0 down alarm
On Sun, May 1, 2011 at 6:00 PM, Chris Kawchuk juniperd...@gmail.com wrote:
Heh. Good question! I just had to double check:
show config system
commit synchronize;
Thats in there.. OK let's try it manually.
ckawchuk@jmx480# commit synchronize and-quit
re0:
configuration check succeeds
re1:
commit complete
re0:
commit complete
Exiting configuration mode
{master}
ckawchuk@jmx480 show chassis alarms
1 alarms currently active
Alarm time Class Description
2011-04-07 11:19:35 EST Major Host 1 fxp0 : Ethernet Link Down
Yeah... alarm still there. No worries - it's just an annoyance more than
anything.
- Chris.
On 2011-05-02, at 10:52 AM, OBrien, Will wrote:
Silly question... You did use commit sync, correct?
Will O'Brien
On May 1, 2011, at 7:51 PM, Chris Kawchuk juniperd...@gmail.com wrote:
Hi Paul..!
Yeah - I tried that as well initially with no luck (and just tried
again just now...)
me@wowter show configuration chassis
alarm {
management-ethernet {
link-down ignore;
}
}
user@wowter show chassis alarms
1 alarms currently active
Alarm time Class Description
2011-04-07 11:19:35 EST Major Host 1 fxp0 : Ethernet Link Down
... Which now definitely leads me to suspect it's a bug in this release; as
you don't seem have this issue in 10.0 =)
Thanks! I'll ignore it for now, and see what happens when we do our 10.4
upgrade soon.
- Chris.
On 2011-05-02, at 10:42 AM, Paul Stewart wrote:
Hey Chris...
On MX480's running 10.0R3.10 we just have it setup as:
paul@core2.toronto1 show chassis alarms
No alarms currently active
paul@core2.toronto1 show configuration chassis alarm
management-ethernet {
link-down ignore;
}
Thanks,
Paul
___
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
On EX switches, I've had the alarm get stuck. I had to restart
chassis-control and it went away
--
Brent Jones
br...@servuhome.net
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] about 10.4R3 on EX
On Wed, Mar 23, 2011 at 11:14 AM, Daniel Roesen d...@cluenet.de wrote: On Tue, Mar 22, 2011 at 01:48:04PM -0700, Kaj Niemi wrote: It took 838 seconds on a 2 member EX4200 VC bundle. Yes, I did time it. ;-) Around 13 minutes downtime for a EX3200... Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Took about 20 minutes on a VC with 4 members. Didn't sit and watch though. -- Brent Jones br...@servuhome.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
