Re: [j-nsp] AFEB vs TFEB

[Tim Jackson]

Isn't the T for Taz, the old MX80 code name?

On Thu, Nov 26, 2020, 11:18 AM Caio Fratelli  wrote:

> Greetings,
>
> Does anyone know why Juniper uses the name AFEB on MX104 referring to
> its Forward Engine Base instead of TFEB?
> I know that TFEB means Trio Forward Engine Base, so what's the meaning
> for the "A" on AFEB?
>
> Thank you.
> ___
> 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] Appending customer ASN to BGP

[Tim Jackson]

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/as-path-edit-routing-options.html

On Sun, Nov 8, 2020, 2:09 PM Dario Amaya  wrote:

> Hello,
>
> Our customer has own ASN from ARIN and want us to take care of all
> routing. We already originate the customer prefix from our ASN. What
> is easiest / recommended way to append customer's ASN to the prefixes
> to make it appear as though it's originated from their ASN without any
> routing equipment / BGP from them? This is on Juniper MX, is L3VPN the
> answer?
> ___
> 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] QFX10008 and sFlow

[Tim Jackson]

Iirc enabling it on 1 unit will actually turn it on on all units on sFlow.

Re: IPFIX, it's probably broken, too. At least on the fixed config boxes it
is:

https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1365864

On Mon, Oct 14, 2019, 5:18 PM Olivier Benghozi 
wrote:

> Hi,
> you probably don't really want to configure the older sFlow monitoring
> those days (with its various limitations), what you probably really need is
> to configure inline IPFIX flow monitoring, as it is supported by QFX10k
> devices.
>
> > Le 14 oct. 2019 à 19:49, Tim Vollebregt  a écrit :
> >
> > I’m toying around with some QFX10008’s in a customer PoC.
> > Having some issues with sFlow and can’t find proper documentation in
> regards to this.
>
> ___
> 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] 100G DAC issue between MX204 and QFX5110

[Tim Jackson]

Don't think it's just you. We've had tons of issues with QSFP28 optics
across all sorts of hardware.

--
Tim

On Thu, Jun 20, 2019 at 8:38 AM Saku Ytti  wrote:

> Is it just me or does 100GE have lot more interop issues than we had
> with 1GE and 10GE?
>
> Vendor rep explained it as MSA being too ambiguous so both can do
> everything right and still not interop, unsure if defensive or
> factual.
>
>
> On Thu, 20 Jun 2019 at 16:34, Tim Jackson  wrote:
> >
> > We've actually had the reverse issue where 17.4 is the only release that
> > some DACs will function. Any 18.x release seems to break them. These
> aren't
> > Juniper coded DACs, but just generic coded:
> >
> >
> https://paste.somuch.fail/?248d62d55916f17b#+flZp6LEb0ZY48AI/3rc4YidWw6LENIQTPxpc4O6j7g=
> >
> > --
> > Tim
> >
> > On Thu, Jun 20, 2019 at 8:24 AM Chris Wopat  wrote:
> >
> > > We have tested flexoptix 3rd party DAC between MX204 and
> QFX5120/QFX10002
> > > with mixed results. Per release notes/ HCL, DAC isn't supported on
> MX204
> > > until 18.2
> > >
> > > https://apps.juniper.net/hct/product/#prd=MX204
> > >
> > > We couldn't link anything with mx204 dac on anything below 18.2. There
> are
> > > also a few DAC related PRs in the 18.2r1 release notes.
> > >
> > >
> > >
> https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/18.2/junos-release-notes-18.2.pdf
> > > ___
> > > 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
>
>
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 100G DAC issue between MX204 and QFX5110

[Tim Jackson]

We've actually had the reverse issue where 17.4 is the only release that
some DACs will function. Any 18.x release seems to break them. These aren't
Juniper coded DACs, but just generic coded:

https://paste.somuch.fail/?248d62d55916f17b#+flZp6LEb0ZY48AI/3rc4YidWw6LENIQTPxpc4O6j7g=

--
Tim

On Thu, Jun 20, 2019 at 8:24 AM Chris Wopat  wrote:

> We have tested flexoptix 3rd party DAC between MX204 and QFX5120/QFX10002
> with mixed results. Per release notes/ HCL, DAC isn't supported on MX204
> until 18.2
>
> https://apps.juniper.net/hct/product/#prd=MX204
>
> We couldn't link anything with mx204 dac on anything below 18.2. There are
> also a few DAC related PRs in the 18.2r1 release notes.
>
>
> https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/18.2/junos-release-notes-18.2.pdf
> ___
> 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] Silly question for a Friday

[Tim Jackson]

Sorry, I'm thinking of ping/traceroutes..

On Fri, Jun 7, 2019, 4:49 PM Tim Jackson  wrote:

> show route family inet/inet6 
>
> On Fri, Jun 7, 2019, 4:43 PM Chris Adams  wrote:
>
>> I can "show route " and JUNOS will do a DNS lookup and show
>> the route for the resolved IP.  Is there any way to control that for
>> hosts with multiple IPs, especially IPv6?
>> --
>> Chris Adams 
>> ___
>> 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] Silly question for a Friday

[Tim Jackson]

show route family inet/inet6 

On Fri, Jun 7, 2019, 4:43 PM Chris Adams  wrote:

> I can "show route " and JUNOS will do a DNS lookup and show
> the route for the resolved IP.  Is there any way to control that for
> hosts with multiple IPs, especially IPv6?
> --
> Chris Adams 
> ___
> 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] EVPN/VXLAN over IPsec over Internet

[Tim Jackson]

I've done some hacks with an MX to do inline GRE frag+reassembly over the
internet with a looped macsec GigE port to get encrypted traffic with full
MTU. You could add VXLAN to that and get what you want kinda. MX GRE inline
frag/reassembly works well.



On Sat, Jun 1, 2019, 7:44 AM Chen Jiang  wrote:

> Hi! Experts
>
> Sorry for disturbing, we know that EVPN/VXLAN cannot fragment packets, but
> we want to use IPsec/Internet as backup EVPN/VXLAN path, is there any
> workaround to forwarding such packets in EVPN/VXLAN over IPsec over
> Internet?
>
> Thanks in advance.
>
> --
> BR!
>
>
>
>James Chen
> ___
> 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] QSFP28 oddities between Arista and QFX after upgrade

[Tim Jackson]

Check FEC settings. Try turning FEC on or off on both sides.

Arista: (config-if)#error-correction encoding reed-solomon

Juniper: set interfaces et-0/0/1 gigether-options fec fec91

On Sat, May 11, 2019, 6:32 AM Jason Lixfeld  wrote:

> I had no idea auto-negotiation was still a thing with 100G, but in any
> event, toggling auto negotiation didn’t work.
>
> > On May 11, 2019, at 2:21 AM, Eric Krichbaum  wrote:
> >
> > I had a similar issue with 18.x and MX204. Did you try turning off
> auto-negotiation?
> >
> > set interfaces et-4/0/52 ether-options no-auto-negotiation
> >
> > I had a similar issue with QFX5100/EX4300 and 40G and this fixed the
> issue oddly enough.
> >
> > Eric
> >
> > -Original Message-
> > From: juniper-nsp  On Behalf Of
> Jason Lixfeld
> > Sent: Friday, May 10, 2019 6:13 PM
> > To: juniper-nsp 
> > Subject: [j-nsp] QSFP28 oddities between Arista and QFX after upgrade
> >
> > Hey,
> >
> > I have a QFX5110 in the lab which I upgraded from 17.something to 18.4
> to resolve some ISIS weirdness.  ISIS weirdness resolved, but now the
> previously working link between this QFX and an Arista 7280SR no longer
> comes up, despite light levels on both sides being within norms.  I went
> from 18.4 to 19.1 just for the hell of it, and still no bueno.
> >
> > The QSFP28 in the QFX comes up if it’s looped to itself, as does the
> QSFP28 in the Arista.  The Arista QSFP28 links to another Arista, or an
> MX204.  The QFX QSFP28 links to the same MX204 as well (no other QSFP28
> gear to test with otherwise) so it seems to be a weird compatibility issue
> between the Arista and the QFX?
> >
> > Does this sort of thing smell familiar to anyone?  I’ve had pretty good
> luck with 100G compatibility in general so far, so I’m not overly familiar
> with any knobs to work around any compatibility issues that may creep up
> here or there, so happily accept some pointers if anyone has some clue.
> >
> > Thanks!
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
>
> ___
> 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] MX204 in 2-post rack?

[Tim Jackson]

You can probably use some 4-post conversion kits to mount it in 2-post..
The mounts/rails on the MX204 are very similar to the other 1RU QFX mounts.
Either flush or center-mount:

https://www.racksolutions.com/2-post-conversion-brackets.html
https://www.racksolutions.com/4u-flushmount-conversion-kit.html

On Fri, Mar 15, 2019 at 2:51 PM Richard Hicks 
wrote:

> Is anyone running the MX204 in a 2-post rack?
> How is it holding up?
>
> Spec sheet says it requires 4-post, which is a non-start in many of our
> locations.
>
> Thanks,
> Rick
> ___
> 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] MX204 Tunnel Services

[Tim Jackson]

I've done LT interfaces on MX204 with multiple LSYS' to build some lab
topologies without issue. This was back in beta and worked fine, haven't
run it on newer code, but I do run GRE tunnels in 18.1R3 without issue.

--
Tim



On Wed, Dec 26, 2018, 5:43 PM Fraser McGlinn  Hey Everyone,
>
> Yet another post re MX204 ;)
>
> Trying to get lt-x/x/x interfaces working on MX204 (18.3R1.9), thus far no
> luck. Interfaces are created and bandwidth set after enabling tunnel
> services on the PIC, however only output packets on the source interface
> increment. Input packets do not increment on the receiving unit, so seems
> to get lost in the nether.
>
> Has anyone got LT interfaces working on MX204 and an example config?
>
> Cheers,
> Fraser
> ___
> 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] MX80 Input Scheduling/Shaping

[Tim Jackson]

The QX/Dense Queuing Block exists for the MIC slots on the MX80.

Looks like you get 12 queues per MX80/104 for ingress shaping. Doesn't seem
to be tied to QX at all. Egress you get per unit on the MIC slots though.


https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/cos-configuring-ingress-hierarchical-cos-on-trio-mpc-mic.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/cos-hierarchical-scheduling-understanding-fine-grained-queuing-for.html


On Fri, Oct 5, 2018, 8:45 PM Alexander Arseniev via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hello,
> Egress scheduling/shaping on MIC ports - correct, that's why I said
> "roughly" equal.
> Ingress scheduling/shaping  requires Q or EQ MPC which is not supported
> on MX80.
> Thanks
> Alex
>
> -- Original Message --
> From: sth...@nethelp.no
> To: arsen...@btinternet.com; juniper-nsp@puck.nether.net
> Sent: 05/10/2018 20:20:06
> Subject: Re: [j-nsp] MX80 Input Scheduling/Shaping
>
> >>Ingress scheduling is supported only on Q and EQ MPCs - Juniper MX
> >>series book, 2nd ed, page 598.
> >>
> >>MX80 COS capabilities are roughly equal to MPC1, without Q.
> >
> >Disagree. MX80 does per-VLAN queuing/scheduling/shaping just fine for
> >ports on MICs. *Not* for the builtin 10G ports.
> >
> >Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
> ___
> 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] Mounting a QFX5100 or ACX5048 on 2 Post Rack

[Tim Jackson]

https://www.racksolutions.com/2-post-rack-rails.html

--
Tim

On Wed, Aug 1, 2018 at 5:39 PM, Colton Conor  wrote:

> We are constantly having to mount these larger switches to two post racks.
> To my knowledge Juniper does not make 2 post mounting brackets for these
> switches. Does anyone have any recommendations on a shelf or something to
> hold these up? We are dealing with 19 and 23 inch racks.
> ___
> 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] Router for full routes

[Tim Jackson]

I think the PFE ukern runs as a process in the hypervisor that uses another
core and a few G of ram:

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 4479 root  20   0 16.7g  16g  26m S  500 53.0 114757:25 qemu-system-x86
21332 root  20   0 3008m 263m 215m R  135  0.8  30488:26 J-UKERN

--
Tim


On Wed, Jun 27, 2018 at 9:02 AM, Jason Lixfeld 
wrote:

> So the rest is for guest VMs then?
>
> > On Jun 27, 2018, at 9:57 AM, Tim Jackson  wrote:
> >
> > Yeah 16G for the RE + I think you actually get 5 cores in the Junos VM:
> >
> > % sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
> > hw.machine: amd64
> > hw.model: QEMU Virtual CPU version 1.7.2
> > hw.ncpu: 5
> > hw.machine_arch: amd64
> >
> > It's really fast though. Great little box so far.
> >
> > --
> > Tim
> >
> >
> > On Wed, Jun 27, 2018 at 8:51 AM, Chris Adams  wrote:
> >
> >> Once upon a time, Tim Jackson  said:
> >>> Yes. Calling it decent is an understatement. It's really quick. It's a
> >> Xeon
> >>> E5-2608Lv4.
> >>
> >> Yep.  The RE VM "only" gets half the resources (so 4 cores and 16G RAM),
> >> but that is plenty good!  It also has dual NVMe SSDs for storage.  When
> >> I upgraded JUNOS from 17.4 to 18.1, I think it only took about 3 minutes
> >> from "request system reboot" until I could SSH back in to the RE
> >> management ethernet.
> >>
> >> --
> >> Chris Adams 
> >> ___
> >> 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] Router for full routes

[Tim Jackson]

Yeah 16G for the RE + I think you actually get 5 cores in the Junos VM:

% sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: amd64
hw.model: QEMU Virtual CPU version 1.7.2
hw.ncpu: 5
hw.machine_arch: amd64

It's really fast though. Great little box so far.

--
Tim


On Wed, Jun 27, 2018 at 8:51 AM, Chris Adams  wrote:

> Once upon a time, Tim Jackson  said:
> > Yes. Calling it decent is an understatement. It's really quick. It's a
> Xeon
> > E5-2608Lv4.
>
> Yep.  The RE VM "only" gets half the resources (so 4 cores and 16G RAM),
> but that is plenty good!  It also has dual NVMe SSDs for storage.  When
> I upgraded JUNOS from 17.4 to 18.1, I think it only took about 3 minutes
> from "request system reboot" until I could SSH back in to the RE
> management ethernet.
>
> --
> Chris Adams 
> ___
> 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] Router for full routes

[Tim Jackson]

Yes. Calling it decent is an understatement. It's really quick. It's a Xeon
E5-2608Lv4.


On Wed, Jun 27, 2018 at 8:31 AM, Jason Lixfeld 
wrote:

>
>
> > On Jun 27, 2018, at 9:18 AM, Mark Tinka  wrote:
> >
> > At this stage, I'd say the cheapest MX router you should go for that is
> > decent is the MX204.
>
> Isn’t the MX204 RE more than decent?  8 core 1.6Ghz, 32GB DDR4 RE sounds
> like decent is an understatement, no?
> ___
> 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] MX204

[Tim Jackson]

I think you're in the ~200gbps range for them if VXLAN is considered tunnel
services. If not it should be line rate.

ARP scale on 204 is rather large, even when terminating over a VTEP.

That's my exact use case for the MX 204 tbh.

On Tue, May 15, 2018, 11:49 AM Luca Salvatore via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> How is the MX204 for VXLAN routing (routing between VXLANs)
> Can i expect close to line rate performance for that?
> Curious how it would stack up against triednt2+ based switches fo VXLAN
> routing.
>
> On Mon, May 14, 2018 at 8:44 PM Mark Tinka  wrote:
>
> >
> >
> > On 15/May/18 02:24, Aaron Gould wrote:
> > > Does it have lots of MPLS service capability?
> >
> > It's the same Trio chip you find in modern MPC's. So I expect so.
> >
> > Testing some shortly.
> >
> > Mark.
> > ___
> > 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] MX204

[Tim Jackson]

It's a great box. Basically an MPC7e in 1RU with a fast intel-based RE
(Xeon E5-2608Lv4)

Only kinda weird drawback is you can't use all 4x100G and the 8xSFP+
onboard. (https://apps.juniper.net/home/port-checker/)

17.4R1+ only.

The routing-engine VM gets 16G of ram. 32G total in the box.

No MIC slots, so 0 services you can add to it (no MS-MIC, etc).. 8x SFP+,
4x QSFP-28..

What else do you wanna know?


On Mon, May 14, 2018 at 12:41 PM, Bill Blackford 
wrote:

> Anyone using MX204?
>
> Thoughts?
>
> Benefits / Drawbacks?
>
> Thank you in advance.
>
> B
>
> ___
> 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] MACsec over a service provider

[Tim Jackson]

I've done 1g MACSEC over l2circuit or ccc just fine.. You can even do stuff
like get an MX104 with a 20G MIC that supports MACSEC, loop a 1g port back
into itself, carry that EoMPLS over a GRE tunnel w/ inline frag/re-assembly
and do "encrypted" VPN using a pair of MX104s..

--
Tim

On Tue, Oct 31, 2017 at 3:49 PM, Chuck Anderson  wrote:

> My testing has revealed that it works, as long as the service provider
> (MX) is doing something like e-line/l2circuit/CCC rather than bridging.  I
> even got it to work with ethernet-ccc on the MX port facing the EX4300 and
> vlan-ccc on the MX port facing the core/WAN.
>
> However I've now run into an issue where I can only get a single MACsec
> connection working on the EX4300's.  As soon as I add a 2nd one, it fails
> to come up.  If I then reboot, neither one comes up.  If I deactivate the
> 2nd one, the 1st one comes up.
>
> On Tue, Oct 31, 2017 at 07:30:35PM +, Nick Cutting wrote:
> > I am also interested in this - my carriers keep saying "try it"
> >
> > I have the config now - still have not tested - but I'm moving many of
> my customer P2P links (hosted by carriers) to nexus switches that don't
> support macsec.
> >
> > Is anyone in the enterprise doing this over e-line services?
> >
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> Behalf Of Chuck Anderson
> > Sent: Friday, October 27, 2017 9:39 PM
> > To: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] MACsec over a service provider
> >
> > This Message originated outside your organization.
> >
> > Destination MAC 01:80:c2:00:00:03, EtherType 0x888e (ieee8021x) is eaten
> by the PE router (MX480).  I'm not sure about the ASR9k at the other end of
> the production scenario--it may have the same trouble.
> >
> > My lab is like this, with the EX2200 substituting for the ASR9k.  The
> idea is to have MACsec between the EX4300s, with the middle being
> transparent to it.
> >
> > I got this working:
> >
> > EX4300---EX2200---EX4300
> >
> > For the EX2200, I had to configure layer2-protocol-tunneling to allow
> the EAPOL 802.1x through:
> >
> > vlans {
> > MACSEC-TRANSPORT {
> > vlan-id 10;
> > ##
> > ## Warning: requires 'dot1q-tunneling' license
> > ##
> > dot1q-tunneling {
> > layer2-protocol-tunneling {
> > all;
> > }
> > }
> > }
> > }
> >
> > MACsec comes up fine on both EX4300s and I can ping between them.
> >
> >
> > But this fails:
> >
> > EX4300---EX2200---MX480---EX4300
> >
> > I'm doing simple bridging through the MX, but the MX doesn't support the
> mac-rewrite needed (ieee8021x).  Anyone have any clever ideas to work
> around that limitation?
> >
> > On Fri, Oct 27, 2017 at 05:40:57PM +0300, Elijah Zhuravlev wrote:
> > > Hello
> > >
> > > Ethertypes 0x888e and 0x88e5 should be supported by the switching hw,
> > > no any other special requirements.
> > > Btw keep in the mind macsec overhead, +32.
> > >
> > > regards, Eli
> > >
> > > On Fri, 27 Oct 2017 10:23:01 -0400
> > > Chuck Anderson  wrote:
> > >
> > > > Has anyone been able to run MACsec over a service provider's
> > > > Ethernet Private Line (or even just a 802.1q vlan)?  I'm looking at
> > > > using 10gig ports on the EX4300 or the EX4600/QFX5100-24Q with the
> > > > MACsec uplink module.
> ___
> 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] Using a QFX5100 without QFabric?

[Tim Jackson]

MPLS is now supported on IRB on QFX5100:

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-limitations-qfx-series.html#jd0e57



On Fri, Oct 27, 2017 at 3:50 PM, Andrey Kostin  wrote:

> Chris Wopat писал 25.10.2017 13:00:
>
>> On 10/24/2017 05:30 PM, Vincent Bernat wrote:
>>
>>>   ❦ 24 octobre 2017 14:29 -0400, Andrey Kostin  :
>>>
>>>
> Straight up saying "don't put public IPs on them" doesn't seem like
>> the best advice to me. You can certainly do this, we do and it's fine.
>> When you craft your RE protection filter you just have to squeeze a
>> bit more space here or there compared to say, an MX filter. You should
>> have this enabled weather you're using public IPs or not.
>>
>> Regarding TCAM programming, it's loud and clear when this happens via
>> a console message and a sev0 syslog message.
>>
>
> Yes, that's true, and we spend a decent amount of time packing lo0 filters
> in a tiny TCAM after discovered that filter input-list silently allows
> everything except the first filter and doesn't generate any complaint.
> So, no objection for public IPs but only careful filter planning required.
>
> --
> Kind regards,
> Andrey
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper PTX1000

[Tim Jackson]

But I want it all and I don't want to pay for it :(

--
Tim

On Sat, Dec 17, 2016 at 3:51 PM, Hannes Viertel 
wrote:

> of course you are correct and the HM cubes are off-chip and not on-chip as
> my auto correct stated before.
>
>
> the only point i wanted to make and here i want to close the loop to
> colton’s posting.
>
> In my eyes, there is a significant difference between an barista 7280R and
> a PTX1k, both from the software features and scaling in terms of software
> and hardware.   Jericho+ and derivates (like barefoot’s tofino) will change
> this in the future on the HW side. On the SW side things look different..
> EOS itself has a modern architecture, but the quality of routing code when
> it comes to scaling and features is a different beast.  Even if a lot of
> features became commodity in the past the ability to hold 30m routes in the
> RIB is still a complicated thing to do…
>
> in the end it’s like always in life,
>
> you get what you pay for….
>
>
> /hannes
>
>
>
>
> > On 17 Dec 2016, at 21:42, Saku Ytti  wrote:
> >
> > On 17 December 2016 at 21:26, Hannes Viertel 
> wrote:
> >
> > Hey,
> >
> >> PTX1k is based on the paradise chipset and uses only LPM. The lookup
> memory is HMC based and is entirely on-chip. ( that’s at least the
> fpc3/ptx5k behavior, i’m relatively sure  it’s the same for ptx1k without
> having checked it explicitly)
> >
> > The 3*2GB HMC are off-chip memory. Two of them are for packet memory,
> > 3rd one is for lookup tables. Bloom is on-chip. FPC3 is same, except
> > only 2*2GB HMC, halving packet memory.
> >
> >> The issue i have is not the black art part…the thing with the current
> implementation in EOS is that it’s highly dependent on the prefix
> distribution and  you have to monitor in order to not shoot you in your
> feet… And given the current capacity limits of Jericho you probably will
> see issues more in the 700-800k prefix range than in the claimed 1,2m FIB
> entries.  Assuming the current FIB size in the DFZ, * I  * would want to
> know the exact limits and have some reasonable margins. Will that change?
> sure… but today it is like it is and *I* would not bet my job on it…
> >
> > The actual FIB count you get out of PTX1k will depend also, the HMC
> > itself is not the bottle neck, you'll run into other problems before
> > filling 2GB of HMC (Trio LU is 256MB RLDRAM).
> > So like always, you gotta test on actual demands and either that works
> > or does not work.
> >
> > Sure PTX1k scales further because of the off-chip memory, but if
> > you're near the edge of the scaling limits you gotta test. But in case
> > of PTX!k or -SE, you can throw money at the problem and avoid testing,
> > if your requirement is exactly DFZ, then you can safely know there
> > will be no risk for the foreseeable future.
> >
> >> but again, your milage may vary...
> >
> >
> >
> >
> > --
> >  ++ytti
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper PTX1000

[Tim Jackson]

https://www.juniper.net/documentation/en_US/junos16.1/topics/concept/mpls-features-qfx-series-overview.html#mpls-features-by-release

On Fri, Dec 16, 2016 at 2:50 PM, Aaron  wrote:

> Thanks Tim(s), I understand the QFX1 isn’t mpls capable.
>
>
>
> Also, I’m thinking the cisco ncs5501 might work for me at (6) 100’s.
> also, wow, ncs5502 has (48) 100 gig.
>
>
>
> -Aaron
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper PTX1000

[Tim Jackson]

Arista does not have RSVP-TE, nor fully featured BGP-LU..

FlexRoute for full fib usage seems a little like black magic & hand waving
though:
https://www.arista.com/assets/data/pdf/Whitepapers/FlexRoute-WP.pdf


The other cheaper option to the PTX1000 is QFX1 when you don't need a
full FIB.

--
Tim



On Fri, Dec 16, 2016 at 2:30 PM, Jesper Skriver  wrote:

> On Fri, Dec 16, 2016 at 02:21:22PM -0600, Aaron wrote:
> > I was thinking about the ptx1000 as a supercore fast mpls swapping
> p-box.  I understand it can have (24) 100 gig !
> >
> > I've seen the PTX1000 referred to as a supercore router , and I
> understand it has MPLS LSR functions (someone told me that it does not do
> mpls edge (pe) functions)
> >
> > ...i see/hear no mention of mpls for this 7280...
> > https://www.arista.com/en/products/7280r-series
> > http://www.gossamer-threads.com/lists/nanog/users/188708
>
> https://www.arista.com/en/support/product-documentation/supported-features
>
> click MPLS tab
>
> > ...i have heard of the NCS5500 but I think it only has (4) 100 gig and
> we are wanting 6 or more.  Does cisco have a small form factor mpls router
> with lots of 100 gig ?
> >
> > - Aaron
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper PTX1000

[Tim Jackson]

It costs wy too much is what I think about it..

--
Tim



On Fri, Dec 16, 2016 at 12:12 PM, Aaron  wrote:

> Anyone using the PTX1000 ?  If so, let me know what you think about it.
>
>
>
> - 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

Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic

[Tim Jackson]

monitor traffic interface ge-0/0/0 size  no-resolve layer2-headers
extensive

--
Tim

On Mon, Nov 28, 2016 at 12:43 PM, Alex K.  wrote:

> Hello everyone,
>
> By any chance - is there an equivalent for Ciscos' "debug ip packet"
> command in Juniper?
>
> I'm fully aware that there is a complete distinction between forwarding
> layer and control layer, in those devices - But,  I'm taking specifically
> about traffic TARGETING the box itself.
>
> I'm troubleshooting a strange behavior by Juniper EX line. It's a compex
> topology but the issue is very simple: under certain circumstances, an EX
> stop responding even to pings to its own addresses, even from directly
> connected interfaces.
>
> I'm fully aware that I can mirror a port on those machines (and such), but
> mirroring alone, will not answer the million dollar question - why?
>
> Since there is no doubt that packets are reaching the box (packets don't
> leak from a directly connected cable, with PC on its other end) - I was
> hoping, Juniper might have provided us with a trace option, for following
> the packet inside the box?
>
> Anyone know such trace option?
>
>
> Any suggestions will be welcomed.
> ___
> 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] Infranet controller solution

[Tim Jackson]

The Pulse Secure you're talking about is the Dynamic VPN client, not as an
Infranet enforcer..

--
Tim

On Fri, Oct 28, 2016 at 11:45 AM, Bill Blackford 
wrote:

> I believe it's a licensing issue and I don't know the details of their
> agreement with Pulse Secure after they spun them off, so it may be all of
> the platforms. I ran into it with the branch models.
>
> On Fri, Oct 28, 2016 at 7:54 AM, james list  wrote:
>
> > Interesting, which models are you referring to ? Also high end (ie 5600
> or
> > 5800) ?
> >
> > Cheers
> >
> > 2016-10-28 16:49 GMT+02:00 Bill Blackford :
> >
> >> I was told by our SE that the newer models of SRX will no longer support
> >> Pulse Secure. I've also had to downgrade code to get older models to
> >> support it as well.
> >>
> >> Sent from my iPhone
> >>
> >> > On Oct 28, 2016, at 00:59, Michael Gehrmann 
> >> wrote:
> >> >
> >> > Hi James,
> >> >
> >> > I'm only aware of Palo Alto and Juniper supporting this function. The
> >> next
> >> > generation SRX (300 and 1500) have some pretty good pricing from what
> I
> >> > have experienced.
> >> >
> >> > https://www.pulsesecure.net/download/document/988/PulseSecur
> >> e_Solution_Brief_PAN_PPS_d1v5.fin.pdf
> >> >
> >> > I have experienced the Juniper integration with NAC and it works very
> >> well.
> >> >
> >> > Cheers
> >> > Mike
> >> >
> >> >> On 28 October 2016 at 18:52, james list 
> wrote:
> >> >>
> >> >> Hi Mike
> >> >> here the functionality I'm looking for in the firewall device:
> >> >>
> >> >> - integration with MAG Pulse Secure
> >> >> - policy enforcement using at least destination ip address, port and
> >> >> protocol
> >> >> - policy enforcement with action at least like allow, deny, reject
> >> >> - policy enforcement based on user role
> >> >>
> >> >> Cheers
> >> >> James
> >> >>
> >> >>
> >> >> -
> >> >>
> >> >> 2016-10-28 7:21 GMT+02:00 Michael Gehrmann  >:
> >> >>
> >> >>> Hi James,
> >> >>>
> >> >>> Might be useful if you describe what functionality you are trying to
> >> >>> achieve. i.e. SRX as an enforcer
> >> >>>
> >> >>> Also you may not find many 'cheaper' alternatives in the TNC space:
> >> >>> https://en.wikipedia.org/wiki/Trusted_Network_Connect
> >> >>>
> >> >>> Cheers
> >> >>> Mike
> >> >>>
> >>  On 28 October 2016 at 01:36, james list 
> >> wrote:
> >> 
> >>  Hi experts,
> >> 
> >>  has anybody ever configured an infranet controller solution using
> MAG
> >>  (today Pulse Secure) other than using SRX firewall ?
> >> 
> >> 
> >>  I looking to find an alternative solution to SRX and as far as I’ve
> >>  searched till now, seems that only Palo Alto could do something.
> I’m
> >>  wondering if there are (cheaper) alternative…
> >> 
> >> 
> >>  Thanks in advance
> >> 
> >> 
> >>  Cheers
> >> 
> >>  James
> >>  ___
> >>  juniper-nsp mailing list juniper-nsp@puck.nether.net
> >>  https://puck.nether.net/mailman/listinfo/juniper-nsp
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Michael Gehrmann
> >> >>> Senior Network Engineer - Atlassian
> >> >>> m: +61 407 570 658
> >> >
> >> >
> >> > --
> >> > Michael Gehrmann
> >> > Senior Network Engineer - Atlassian
> >> > m: +61 407 570 658
> >> > ___
> >> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> >> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >
> >
>
>
> --
> Bill Blackford
>
> Logged into reality and abusing my sudo privileges.
> ___
> 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] NETCONF vs.

[Tim Jackson]

Have you just tried to just compare source=>running to source=>candidate
from get_config?

--
Tim

On Wed, Sep 21, 2016 at 2:26 PM, Chuck Anderson  wrote:

> Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the
> candidate configuration to see what changed before issuing a commit
> request so I can avoid "empty" commits after doing a "replace"
> operation on a subtree.  I see that NETCONF defines a standard
>  call, and I believe  is a
> legacy/proprietary Junos call.  There is a  example in the
> documentation, but there doesn't appear to be a way to see what was
> changed in the candidate config vs. the committed config:
>
> https://www.juniper.net/techpubs/en_US/junos16.1/
> topics/task/program/netconf-perl-client-application-
> submitting-requests.html
>
> The API call I want to make is documented here:
>
> https://www.juniper.net/documentation/en_US/junos14.1/
> topics/reference/tag-summary/netconf-junos-xml-protocol-
> get-configuration.html
>
> But I can't for the life of me figure out how to pass the various
> attributes inside the  tag with Perl.  How does one
> map the attributes INSIDE a tag to the Perl API call as below?
>
>  database="candidate">
>
> This doesn't work:
>
> $res = $jnx->get_configuration(changed => 'changed', compare =>
> 'rollback', database => 'candidate');
>
> because that generates this:
>
> 
>   
> candidate
> rollback
> changed
>   
> 
>
> when I need it to be this:
>
> 
>changed="changed">
>   
> 
>
> 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] EVPN/VXLAN on QFX5100

[Tim Jackson]

You can run VXLAN over an MPLS LSP on QFX5100 just fine.. As long as the L3
lookup for the remote VTEP goes across an LSP the VXLAN traffic will too..

But it's not l2ompls.. it's l2ovxlanoipompls.

--
Tim

On Aug 3, 2016 6:52 PM, "Chris Kawchuk"  wrote:

> You cannot use MPLS as the "underlay" Transport on QFX51xx. I tried the
> same -- you need to use VxLAN as the "transport LSP" so to speak. (Think of
> VXLAN remote VTEP IP address as being the outer label, and the VNI is the
> inner label.)
>
> There's a config guide floating around out there on the JNPR Website fort
> the QFX manual showing how to setup the VTEPs so that the switches setup an
> "inet.3" table between each other for remote-next-hop resolution (from
> iBGP/MP-BGP sessions), pointing to a remote VTEP IP.
>
> Good luck! Would be nice if they could do MPLS as the underlay, but
> <-insert Trident2+ Pipeline issues-> here.
>
> - CK.
>
>
> On 4 Aug 2016, at 7:19 am, Joe Freeman  wrote:
>
> > The QFX's are connected via an MPLS/IP connection with LDP/RSVP/ISIS, and
> > MP-IBGP.
> >
> > A show evpn instance extensive command shows that the two switches see
> each
> > other, but I am unable to learn mac addresses between them.
>
> ___
> 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] MX104 capabilities question

[Tim Jackson]

It can't hold a full table in it's FIB for sure, but in the RIB it's fine:

inet.0: 588286 destinations, 1091804 routes (588284 active, 0 holddown, 2
hidden)

--
Tim

On Thu, Jun 9, 2016 at 9:40 AM, Aaron  wrote:

> Thanks, Let me test this claim that an acx5048 cannot hold a full bgp
> table…… anyone know a way to get a test bgp session for a full feed ?
>
>
>
> -Aaron
>
>
>
>
>
> “I think the big thing the ACX5048 is lacking is the ability to hold a
> full routing table compared to the MX104 and ASR9001. Remember the ACX5048
> has a Broadcom Trident II chipset.”
>
>
>
>
>
> ___
> 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] srrd process

[Tim Jackson]

451m here on an MX104 running 14.2:

 2269 root 1  400   451M   445M select  36:07  0.00% srrd

Looks to be the sampling daemon:

http://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-collections/release-notes/15.1F5/topic-104232.html

With Junos OS Release 15.1F2 and later, when inline sampling is enabled on
MX Series-based FPC, the srrd (Sampling Route-Record Daemon) process would
be created to maintain, collect and export JFLOW records. On a regular time
intervals, the srrd scans through the sampling database for any
update/change in the record. In a scaled environment with more route churn,
for example 1.14M routes, the scan process might hog CPU for more than
2.5sec which leads to FPC crash. In some situations, the scan process can
run for longer time without causing FPC crash, but it can cause BFD
sessions to flap. PR1158154

--
Tim


On Thu, May 19, 2016 at 12:03 PM, Han Hwei Woo 
wrote:

> We had an MX80 become unresponsive the other night while trying to turn
> down our peers at an exchange during a maintenance, which was due to
> running out of RAM and a bunch of processes swapping out. We had recently
> upgraded to 14.2R6.5, and have now noticed there is a new process that
> wasn't present in 12.3 and 13.3.
>
>   PID USERNAME   THR PRI NICE   SIZERES STATETIME   WCPU
> COMMAND
>  1733 root 1   40   778M   705M kqread  43:13  0.73% rpd
>  1745 root 1  400   585M   578M select   0:20  0.00% srrd
>
> I can't seem to find anything about what srrd is. Anyone have any ideas,
> and what function it serves? Almost 600MB out of a total 2GB on an MX80 is
> quite a good portion.
>
> --
> Han Hwei Woo
> h...@astutehosting.com
>
> Astute Hosting Incorporated
> T: 1.888.685.1661 (604.637.7939)
> M: 604.417.2092
> F: 604.738.0518
> www.astutehosting.com
> 100% Uptime Dedicated Hosting in Vancouver, Seattle,
> Los Angeles, Toronto, New York, and Miami
>
> ___
> 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] EX4600 Vs QFX 5100 VS ACX 5048

[Tim Jackson]

I've never used their software in production, but I have been looking
at it for some 100G ToR switches.. The featureset is awesome, but I
can't really speak to how well the software works as I haven't
received any demo gear actually running it yet..

I will say that a 32x100G Tomahawk + their SW is less (by a little)
than I was paying for Trident II boxes (QFX5100/EX4600) from Juniper..
I don't know what ACX5k costs, though.

--
Tim

On Tue, May 10, 2016 at 12:16 PM, Colton Conor  wrote:
> Tim,
>
> Do you use IP Infusion software today? I have never heard of them, but I
> like the software feature set I see on their website with MPLS and MEF
> features. However, I doubt the white box plus their software will be any
> less than the Juniper solution, but I could be surprised.
>
> On Tue, May 10, 2016 at 8:46 AM, Tim Jackson  wrote:
>>
>> You might be able to buy some off the shelf (E.g. Acton or quanta etc)
>> white box Trident 2 box and look IP Infusion for an OS on it. It may be cost
>> competitive and have almost all of the features..
>>
>> On May 10, 2016 8:31 AM, "Colton Conor"  wrote:
>>>
>>> Aaron,
>>>
>>> Just wondering if you company compared any other products from other
>>> vendors against the ACX5048? Is there anything else on the market with
>>> this
>>> high of port count, for this low of a price, with this amount of
>>> features?
>>>
>>> On Mon, May 9, 2016 at 11:52 AM, Aaron  wrote:
>>>
>>> > Thanks Raphael,
>>> >
>>> > My core links are untagged typically... in rare case I'll tag, and it
>>> > doesn't seem to be a problem, I haven't done that on acx5048 yet
>>> >
>>> > Ok I did MEF EPL (eline port based carrying any and all vlans, tagged
>>> > and
>>> > untagged...) works. I shut and deactivate core bgp for this test to
>>> > prove
>>> > that it's purely igp, mpls, ldp to make it work.  Ce-ce pings and
>>> > l2protocols seem to be fine ( I tested cdp and stp for CE to CE and
>>> > it's
>>> > fine )...of course the config's below are the MPLS PE's... the ce's I
>>> > mention are not shown anywhere here.
>>> >
>>> >
>>> > ---3600
>>> >
>>> > interface GigabitEthernet0/15
>>> >
>>> >  switchport trunk allowed vlan none
>>> >
>>> >  switchport mode trunk
>>> >
>>> >  load-interval 30
>>> >
>>> >  service instance 1 ethernet
>>> >
>>> >   encapsulation default
>>> >
>>> >   l2protocol forward
>>> >
>>> >   xconnect 10.101.12.245 999 encapsulation mpls
>>> >
>>> > --- ACX5048
>>> >
>>> > set protocols l2circuit neighbor 10.101.12.251 interface ge-0/0/38.0
>>> > virtual-circuit-id 999
>>> >
>>> > set interfaces ge-0/0/38 encapsulation ethernet-ccc
>>> >
>>> > set interfaces ge-0/0/38 unit 0 family ccc
>>> >
>>> > - 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
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Tim Jackson]

You might be able to buy some off the shelf (E.g. Acton or quanta etc)
white box Trident 2 box and look IP Infusion for an OS on it. It may be
cost competitive and have almost all of the features..
On May 10, 2016 8:31 AM, "Colton Conor"  wrote:

> Aaron,
>
> Just wondering if you company compared any other products from other
> vendors against the ACX5048? Is there anything else on the market with this
> high of port count, for this low of a price, with this amount of features?
>
> On Mon, May 9, 2016 at 11:52 AM, Aaron  wrote:
>
> > Thanks Raphael,
> >
> > My core links are untagged typically... in rare case I'll tag, and it
> > doesn't seem to be a problem, I haven't done that on acx5048 yet
> >
> > Ok I did MEF EPL (eline port based carrying any and all vlans, tagged and
> > untagged...) works. I shut and deactivate core bgp for this test to prove
> > that it's purely igp, mpls, ldp to make it work.  Ce-ce pings and
> > l2protocols seem to be fine ( I tested cdp and stp for CE to CE and it's
> > fine )...of course the config's below are the MPLS PE's... the ce's I
> > mention are not shown anywhere here.
> >
> >
> > ---3600
> >
> > interface GigabitEthernet0/15
> >
> >  switchport trunk allowed vlan none
> >
> >  switchport mode trunk
> >
> >  load-interval 30
> >
> >  service instance 1 ethernet
> >
> >   encapsulation default
> >
> >   l2protocol forward
> >
> >   xconnect 10.101.12.245 999 encapsulation mpls
> >
> > --- ACX5048
> >
> > set protocols l2circuit neighbor 10.101.12.251 interface ge-0/0/38.0
> > virtual-circuit-id 999
> >
> > set interfaces ge-0/0/38 encapsulation ethernet-ccc
> >
> > set interfaces ge-0/0/38 unit 0 family ccc
> >
> > - 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] cgnat on service module - interesting bgp advertisements

[Tim Jackson]

Mind pasting your show route for those routes and your export policy?
On Apr 19, 2016 6:48 PM, "Aaron"  wrote:

> Very interesting. anyone know why this is happening ?  Is this documented ?
> I put a /25 as the public nat pool, but look what this mx104 is advertising
> via bgp.. It appears to chop up that /25 into a bunch of smaller subnets
> and
> advertise those out
>
>
>
>
>
> agould@eng-lab-mx104-cgn> show configuration | grep 1.2.3. | display set
>
> set services nat pool nat1 address 1.2.3.128/25
>
>
>
>
>
> agould@eng-lab-mx104-cgn> show route advertising-protocol bgp 10.101.0.2
> table one.inet.0
>
>
>
> one.inet.0: 782 destinations, 970 routes (782 active, 0 holddown, 0 hidden)
>
>   Prefix  Nexthop  MED LclprefAS path
>
> * 10.144.2.4/30   Self 100I
>
> * 1.2.3.129/32 Self 100I
>
> * 1.2.3.130/31 Self 100I
>
> * 1.2.3.132/30 Self 100I
>
> * 1.2.3.136/29 Self 100I
>
> * 1.2.3.144/28 Self 100I
>
> * 1.2.3.160/27 Self 100I
>
> * 1.2.3.192/27 Self 100I
>
> * 1.2.3.224/28 Self 100I
>
> * 1.2.3.240/29 Self 100I
>
> * 1.2.3.248/30 Self 100I
>
> * 1.2.3.252/31 Self 100I
>
> * 1.2.3.254/32 Self 100I
>
>
>
>
>
> 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

Re: [j-nsp] protect ssh and telnet

[Tim Jackson]

Sadly, you guys messed up ACX5k lo0 filtering.. Even though it's a
QFX5100/EX4600 inside..

--
Tim

On Mon, Apr 4, 2016 at 9:23 PM, Phil Shafer  wrote:
> Aaron writes:
>>I'm new to Juniper. and I'm looking to protect ssh/telnet on all interfaces
>>on my juniper ACX5048's.
>
> First comment is: if you want security, don't allow telnet.
> Force the use of ssh.
>
> Me, I don't even like allowing passwords.  JUNOS now supports the
> "system services ssh no-passwords" knob to force the use of ssh
> keys over text passwords.  And your radius server will happily serve
> ssh keys.  Force the move away from passwords.
>
> The "lo0" filter covers traffic to the routing engine.  Any filter
> applied to lo0 will block/allow only that traffic.
>
> More generally, take a look at the "secure junos template" from
> Team Cymru:
>
> http://www.team-cymru.org/templates.html
>
> Thanks,
>  Phil
> ___
> 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] Acx5048 ecmp feature and usage

[Tim Jackson]

For L3 and L3VPN ECMP should work fine. For any L2oMPLS you're gonna be SOL.
On Mar 28, 2016 9:08 PM, "Alexandre Guimaraes" <
alexandre.guimar...@ascenty.com> wrote:

> Gents,
>
> I had a demand where the equipment that best fits is an ACX5048 for N
> reasons
>
> I use some vpls and l2circuits, but there is a feature that i need to use,
> ecmp.
>
> Someone had knownledge about the ecmp feature using ACX5048?
>
> Att.
> AŁexandre
>
> > Em 28 de mar de 2016, às 22:34, Mark Tees  escreveu:
> >
> >> On 27 March 2016 at 22:02, Saku Ytti  wrote:
> >> On 27 March 2016 at 13:37, Mark Tinka  wrote:
> >>
> >> Hey,
> >>
> >>> As costs and management got out of control, they run l3vpn's and
> >>> Internet in the same chassis, but on different line cards.
> >>>
> >>> Eventually, everything converged.
> >>
> >> I tend to agree. If there is significant CAPEX delta buying L3 MPLS
> >> VPN + HQoS capable boxes and Internet transit capable boxes, then it
> >> might make sense to buy two networks, as likely L3 MPLS VPN traffic
> >> rates are very minor but service requires much higher touch hardware.
> >> But I don't suspect the delta is high these days and more importantly
> >> I don't think the IP device CAPEX is very large part of TCO.
> >>
> >> Another justification might be, if the software stack is very
> >> different, but for L3 MPLS VPN will need all services IP Transit uses,
> >> so having IP Transit on same devices does not require turning on
> >> additional services, so it is not really creating additional risk on
> >> the premium services.
> >> If your bread and butter would be L2 VPN, then separating IP transit
> >> on another edge device might be very prudent, as you could do away
> >> with BGP and IP lookups completely on the edge.
> >>
> >> I am fan of Internet-in-VRF, mainly because global-table is special
> >> case and it's hard to import/export route between global and VRF, and
> >> this complexity has forced me to do some really bad/ugly solutions,
> >> which would have been clean and simple if Internet was in VRF. It does
> >> not have to mean ugly traceroutes, you can configure device on TTL
> >> exceeded to pop labels and do IP lookup in transit for returning TTL
> >> exceeded messages. This does not even exclude BGP free core, as your
> >> core can have static route pointing to anycast IGP loopback added to
> >> all edge devices with full BGP, so TTL exceeded message goes to
> >> closest edge device for lookup, probably creating less than
> >> millisecond additional delay on traceroute.
> >
> > Yes, ICMP tunnelling possibly seems to be what I need for that.
> >
> >>
> >> OP states that mistakes in IGP do not affect each other, but mistakes
> >> in the 'core' network IGP where the L2 circuits run, still break
> >> everything.
> >
> > True, there is shared risk here but not in all cases for us.
> >
> >>
> >> I'd say you need solid arguments to separate  the networks, state
> >> exact specific problems and how it solves them, default to converged
> >> network in absence of such arguments. For background it might be
> >> interesting to hear what problems you've had, what is prompting this
> >> separate edge.
> >
> > Agree. Rather than being paranoid about it I need a strict list.
> >
> >
> >>
> >>
> >> --
> >>  ++ytti
> >
> >
> >
> > --
> > Regards,
> >
> > Mark L. Tees
> > ___
> > 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] Encrypted MPLS between MXes

[Tim Jackson]

That's good news to hear.. Today EX4600 was my solution, and it actually
works quite well.

On Sun, Mar 27, 2016, 1:27 PM Saku Ytti  wrote:

> On 27 March 2016 at 21:12, Tim Jackson  wrote:
> > Run EX4600s as your P routers, and encrypt w/ MACSec on them.
>
> IIRC next-gen Trio does MacSec, so all ports will support it.
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Encrypted MPLS between MXes

[Tim Jackson]

Run EX4600s as your P routers, and encrypt w/ MACSec on them.
On Mar 27, 2016 1:11 PM, "Alex K."  wrote:

> Hello everyone,
>
> I was just wondering if there's a new way to encrypt MPLS traffic between
> MX boxes without the good old encrypted GRE?
>
> MPLS over encrypted MACSec links, encrypted internal tunnels between
> logical systems, everything goes. If that was your network, what's the
> craziest idea you'd go with?
>
> Is at 2016, we're still stuck with MPLS over GRE over IPSec, to encrypt
> MPLS traffic?
>
> Feel free to share your thoughts.
>
> Thank you.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper 10G Switch Options

[Tim Jackson]

It should support EVPN shortly.

On Thu, Jun 4, 2015, 6:38 AM Joe Freeman  wrote:

> Keep in mind the QFX5100 doesn't support evpn or vpls. To do vpls right
> now, we're having to l2vpn back to an MX tunnel interface and stitch into a
> bridge domain. It's not pretty but so far it has worked. We've got our
> fingers crossed that evpn is coming soon.
>
> Also, the 5100's apparently aren't using ASICs, or at least aren't using
> an ASIC on the interfaces that will support flexible-ethernet-services.
> What this means is that I can't L2 switch a customer on the same QFX
> interface that I'm either A) Terminating another customer at L3 (l3 vpn for
> example), or B) Doing a vlan-ccc/l2circuit/l2vpn connection on. This means
> there are some use cases (p2p ethernet circuits between olt's in the same
> CO for instance) that may require more than 1 port between the QFX and the
> olt.
>
> Joe
>
> On Thu, Jun 4, 2015 at 8:26 AM, Tim Jackson  wrote:
>
>> I'd recommend QFX5100 or EX4600. Same hardware inside for both.
>>
>> Beware that there are a few issues with DHCP and DHCPv6 pass through on
>> them, but that seems to be resolved now.
>> On Jun 4, 2015 6:22 AM, "Colton Conor"  wrote:
>>
>> > We need a Juniper switch with at least 24 built in SFP+ ports. Looks
>> like
>> > Juniper has a ton of options including the EX4500, EX4550, EX4600, and
>> the
>> > QFX line which I don't know much about. This switch will be for
>> aggregation
>> > purposes for an access network that has GPON OLT's with 10G uplinks on
>> > them. What do you recommend? Which has the latest hardware? Which is the
>> > most cost effective? Any limitations to be aware of?
>> > ___
>> > 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] Juniper 10G Switch Options

[Tim Jackson]

I'd recommend QFX5100 or EX4600. Same hardware inside for both.

Beware that there are a few issues with DHCP and DHCPv6 pass through on
them, but that seems to be resolved now.
On Jun 4, 2015 6:22 AM, "Colton Conor"  wrote:

> We need a Juniper switch with at least 24 built in SFP+ ports. Looks like
> Juniper has a ton of options including the EX4500, EX4550, EX4600, and the
> QFX line which I don't know much about. This switch will be for aggregation
> purposes for an access network that has GPON OLT's with 10G uplinks on
> them. What do you recommend? Which has the latest hardware? Which is the
> most cost effective? Any limitations to be aware of?
> ___
> 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] Arguments for commit scripts

[Tim Jackson]

Use an apply-macro..

--
Tim

On Wed, Mar 18, 2015 at 3:27 PM, Ross Vandegrift  wrote:
> Hi all,
>
> Working on a commit script with a regex that might need occasional updates.
> Ideally, this could be stored in the config, and loaded at run-time.
> Possible?
>
> If not: any catches with abusing annotate to provide this?
>
> Thanks,
> Ross
>
> ___
> 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] Request for help: Firewall config to match fragmented ipv6 packet

[Tim Jackson]

... V6 fragments don't exist.
On Mar 14, 2015 7:36 PM, "Vijesh Chandran"  wrote:

> Hello,
>   Is it possible to match a fragmented ipv6 traffic using juniper fw term?
> Please help if someone knows this.
>
>
> -Thanks,
>  Vijesh
>
> ___
> 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] Experience with QFX5100 13.2 & 14.1

[Tim Jackson]

For DHCPv4 that was the case, but it still persisted after disabling
dhcp-relay. For DHCPv6, ipv6 isn't even configured on the box.

--
Tim


On Fri, Jan 16, 2015 at 11:15 AM, Michael Loftis  wrote:

> On Thu, Jan 15, 2015 at 6:43 AM, Tim Jackson 
> wrote:
> > L3/MPLS LSR - Great experience, one issue currently in 14.1X53-D15 is any
> > traffic that would have been sent an ICMP redirect (even with that turned
> > off) will be duplicated.. One copy forwarded through the RE, one copy
> > through T2 caused by PR1022354 (there are other scenarios that can cause
> > this, too.. and this is still unfixed).. I think in 13.x there is an LDP
> > bug (PR889585), but it's easy to work around.
> >
> > L2 - Several issues with it.. DHCPv4 Traffic in I think up to 13.2X53-D25
> > in L2 will be silently discarded (punted to the RE as you can see this
> > traffic by doing monitor traffic).. 14.1X53-D10+ fixes this (maybe
> > 13.2X53-D25). DHCPv6 traffic is still broken in even 14.1X53-D15, no PR
> for
> > that one yet.
>
> Do you have DHCPv4 enabled in any other way?   Ex dhcp-relay?  I ask,
> b/c, on an unrelated platform (nd entirely different JunOS
> versions- MX960s and EX9214s) we ran into - turning on dhcp-relay will
> cause them to punt all UDP port 67 traffic.  Even if it's on an
> interface that isn't mentioned in the config.  I haven't had a chance
> yet to see if that happens to all logical instances or just the LI
> that the dhcp-relay or dhcp features are enabled on.  Like I said,
> unrelated platform, but, effectively the same thing.
>
> >
> > I've also had several QFX5100-96S boxes reboot without reason (on
> software
> > all the way up to 14.1X53-D10), 0 logs, like they were powered off..
> Still
> > haven't found the root cause of this one yet, we're suspecting a bad
> batch
> > of hardware possibly.
> >
> > I have several that are about to enter a mixed L2+L3/MPLS P/PE role
> soon..
> > MC-LAG+L2+L3/MPLS+L3VPN all on a pair.. So far with testing that there
> > haven't been any issues outside of the previously mentioned L2 gotchas.
> >
> >
> > In general the experience has been pretty positive with them outside of a
> > few L2 snafus.. I'm also not using the boxes in a traditional DC role,
> > these are all SP roles..
> >
> >
> > On Thu, Jan 15, 2015 at 1:30 AM, Richard Hartmann <
> > richih.mailingl...@gmail.com> wrote:
> >
> >> Dear all,
> >>
> >> I was wondering what experience, if any, you have had with QFX5100.
> >>
> >> Of special interest would be what JunOS version you are running, what
> >> features you have enabled, and if you consider them production-ready.
> >>
> >>
> >> This question is open-ended on purpose.
> >>
> >>
> >> Thanks,
> >> Richard
> >> ___
> >> 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
>
>
>
> --
>
> "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] Experience with QFX5100 13.2 & 14.1

[Tim Jackson]

On Thu, Jan 15, 2015 at 6:55 AM, Chuck Anderson  wrote:

>
> We are using 48S in production with 13.2X51-D20 & D26, standalone and
> VC (not VCF), L2 features only (MSTP, RSTP).  TISSU worked great up to
> D20 (completely hitless), but I was told I couldn't use it for getting
> to D26 (it would fail or cause issues), so I didn't try.
>
>
I forgot to mention that we tried TISSU a couple of times with no success..
Evidently it had to do with CoS configuration according to JTAC, but it
wasn't something I bothered spending much time on.

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

Re: [j-nsp] Experience with QFX5100 13.2 & 14.1

[Tim Jackson]

L3/MPLS LSR - Great experience, one issue currently in 14.1X53-D15 is any
traffic that would have been sent an ICMP redirect (even with that turned
off) will be duplicated.. One copy forwarded through the RE, one copy
through T2 caused by PR1022354 (there are other scenarios that can cause
this, too.. and this is still unfixed).. I think in 13.x there is an LDP
bug (PR889585), but it's easy to work around.

L2 - Several issues with it.. DHCPv4 Traffic in I think up to 13.2X53-D25
in L2 will be silently discarded (punted to the RE as you can see this
traffic by doing monitor traffic).. 14.1X53-D10+ fixes this (maybe
13.2X53-D25). DHCPv6 traffic is still broken in even 14.1X53-D15, no PR for
that one yet.

I've also had several QFX5100-96S boxes reboot without reason (on software
all the way up to 14.1X53-D10), 0 logs, like they were powered off.. Still
haven't found the root cause of this one yet, we're suspecting a bad batch
of hardware possibly.

I have several that are about to enter a mixed L2+L3/MPLS P/PE role soon..
MC-LAG+L2+L3/MPLS+L3VPN all on a pair.. So far with testing that there
haven't been any issues outside of the previously mentioned L2 gotchas.


In general the experience has been pretty positive with them outside of a
few L2 snafus.. I'm also not using the boxes in a traditional DC role,
these are all SP roles..


On Thu, Jan 15, 2015 at 1:30 AM, Richard Hartmann <
richih.mailingl...@gmail.com> wrote:

> Dear all,
>
> I was wondering what experience, if any, you have had with QFX5100.
>
> Of special interest would be what JunOS version you are running, what
> features you have enabled, and if you consider them production-ready.
>
>
> This question is open-ended on purpose.
>
>
> Thanks,
> Richard
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] juniper qfx5100 vs ex9200

[Tim Jackson]

QFX5100 has L2VPN (LDP based) now, and will get EVPN support..
On Dec 24, 2014 7:07 AM, "Chuck Anderson"  wrote:

> EX9200 has more potential to support more MPLS features as a PE, like
> EVPN.  QFX5100 is a nice box, but won't do much MPLS (L3VPN, but no
> L2VPN, VPLS or EVPN).  See the Feature Explorer:
>
> http://pathfinder.juniper.net/feature-explorer/search-features.html
>
> Interestingly, EX9200 isn't shown as having L3VPN support.  You need
> to take the Feature Explorer with a grain of salt.  If you look up
> "BGP for L2VPNs and L3VPNs" for example, it only shows PTX support for
> that feature, but of course MX supports that too.
>
> On Wed, Dec 24, 2014 at 03:55:30AM +, Randy Manning wrote:
> > People,
> >
> > Any advice on a distribution layer switch for campus networks?  juniper
> > qfx5100 vs ex9200?  I am not sure what the requirements need to be a
> > priority.  The core is MX 960 and currently routing.  I am thinking about
> > campus distro¹s becoming PE with TE and allowing the core¹s to label
> > switch only?  Given the current network and possible change, which
> > platform is the best?  Qfx or ex?
> >
> > Data centers are working well with q-fabric, but I understand that has
> > been abandoned by juniperŠ. Which is sadŠ I liked the eVPN BGP NLRI
> design.
> >
> >
> > Thanks,
> > -
> > Randy
> ___
> 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] QFX5100 question

[Tim Jackson]

To be honest, I'd run them as a P instead and use the MX as your PE.
For large L2 flows over MPLS there's no support or plans (or maybe
even the ability afaik) to support any sorts of FAT-PW or entropy
label for the box. As an LSR they work great.

There are some issues in the current 14.1 code with any traffic that
*might* get an ICMP redirect (even if no-redirects is turned on) that
causes some awesome behavior (such as duplicate packets where one gets
forwarded by the RE, and another by the BCM asic).. Outside of that
and a couple of other issues 14.x has been fine so far on it.

--
Tim

On Thu, Dec 18, 2014 at 4:07 PM, Joe Freeman  wrote:
> Before we go out and spend a large amount of money to replace some gear
> we're not happy with in our network, I thought I'd check to see what
> opinions I could get on the QFX5100.
>
> We are looking at using them in an MPLS PE role, with the new code release
> that has added support for L2VPN's (according to our SE). Each of these
> 5100's would be connected to at least one MX router (preferably two for
> redundancy) via one or more 10Ge LAG groups. Our CO's are too far apart for
> 40Gbe at the moment.
>
> Any thoughts or opinions would be helpful.
>
> Thanks-
> Joe
> ___
> 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] EX2200 rate limiting/shaping question

[Tim Jackson]

filter-specific means that if you apply multiple terms in the firewall
filter with an action of policer that it aggregates across all of
those in that filter.

term-specific means each term gets its own rate in that filter.

To do what you're after you just do a interface-specific firewall
filter which should cause it to use different counters/policers per
interface that it is applied to.

--
Tim



On Tue, Nov 25, 2014 at 11:10 AM, joe mcguckin  wrote:
> Can someone explain the difference between filter-specific and term-specific? 
> I want to create a filter for rate limiting and apply it to multiple  
> physical ports and have each interface
> rate limited independently, not as an aggregate.
>
> Thanks,
>
> Joe
>
>
>
> ___
> 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] ACX is just not there (was Re: EX4550 L2Circuit/VPN to MX80/lt Interface)

[Tim Jackson]

Speaking of RRs, has anyone actually looked at:

http://www.metaswitch.com/products/networking/virtual-route-reflector

?


On Thu, Nov 13, 2014 at 10:02 AM, Daniel Verlouw  wrote:
> Hej Mark,
>
> On Thu, Nov 13, 2014 at 5:10 PM, Mark Tinka  wrote:
>> I'd deploy vMX as a route reflector. I was actually
>> evaluating vRR a few months ago, but it still had a long way
>> to go, so went with Cisco's CSR1000v (which is, basically,
>> IOS XE) instead.
>
> would you be able to elaborate on your experience with vRR ? We’re
> about to re-evaluate our RR deployment and going ‘virtual / PC-based’
> is certainly high on our list. Too bad there's hardly any info on vRR
> around, or I'm looking in the wrong place (which is not terribly hard
> after yet another poor redesign of jnpr.net)
>
> Other than being used as RR, I (so far) fail to see how vMX would be
> deployed in carrier networks such as ours. Virtualized DCs, yes,
> maybe, but that’s whole different ball game.
>
> BR, Daniel.
>
> ___
> 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] EX3300/4300 Switch MPLS CCC Support

[Tim Jackson]

Is MPLS CCC really a basic feature?

What other enterprise switch can do L2 over MPLS?

I'd imagine that EX4300 is capable of it (and more) that it can do it,
but why waste the effort making l2circuit work on Broadcom DC/EX
chips? It wasn't promised in the switches datasheets, was it?

Push for cash?

Basic features?

You got shit for free now you expect it. I agree that shit should just
appear from my vendors magically for free at prices cheaper than their
competitors, but I also live in the real world where reality and my
dreams aren't the same thing..

Then again, I'm also just an angry man waiting on his plane in an airport...

--
Tim

On Fri, Nov 7, 2014 at 10:22 PM, Skeeve Stevens
 wrote:
> I agree... it is quite rude and seems to be just a push for cash
> considering what basic features these are.
>
>
> ...Skeeve
>
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/eintellegonetworks ;  
> linkedin.com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com
>
>
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
>
> On 8 November 2014 12:26, Robin Williams  wrote:
>
>> Hi all,
>>
>> We currently make some use of the MPLS CCC functionality of EX3200 and
>> EX4200 switches with the AFL, but note that their replacements EX3300 and
>> EX4300 don't have any MPLS support.  Does anyone know if this is a
>> temporary lack of support while the box is being developed further, or is
>> there no plans no bring this support back in the new products?  I don't
>> like the way the EX3300 is being touted as the replacement for the EX3200
>> but the feature set has entirely changed.
>>
>> I also think it's a bit rich that you now need an EFL license for things
>> like OSPF support, where you didn't previously, and for the AFL features
>> such as BGP, you now need both an EFL *AND* and AFL where you previously
>> only needed an AFL.
>>
>> Would be interested to hear other opinions on this, to me it all seems
>> like a bit of a silly move on the part of Juniper and a gift to Cisco.
>>
>> Regards,
>> Robin.
>> ___
>> 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] EX3300/4300 Switch MPLS CCC Support

[Tim Jackson]

Licenses for stupid SW features are total BS, here's to hoping that Juniper
figures this out. Probably not though.

If I missed that, sorry..

>From what I know, MPLS on new EX is unlikely to happen (even though I
really really really want it). ACX is where MPLS on Broadcom based products
is going to happen (outside of the generous MPLS featureset available on
QFX today).

--
Tim

On Fri, Nov 7, 2014 at 10:44 PM, Skeeve Stevens <
skeeve+juniper...@eintellegonetworks.com> wrote:

> I was referring to OSPF, IPv6, etc.. basic features
>
> and the fact you need an EFL and AFL now is just rude.
>
>
> ...Skeeve
>
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/eintellegonetworks ;  <http://twitter.com/networkceoau>
> linkedin.com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com
>
>
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
>
> On 8 November 2014 15:35, Tim Jackson  wrote:
>
>> Is MPLS CCC really a basic feature?
>>
>> What other enterprise switch can do L2 over MPLS?
>>
>> I'd imagine that EX4300 is capable of it (and more) that it can do it,
>> but why waste the effort making l2circuit work on Broadcom DC/EX
>> chips? It wasn't promised in the switches datasheets, was it?
>>
>> Push for cash?
>>
>> Basic features?
>>
>> You got shit for free now you expect it. I agree that shit should just
>> appear from my vendors magically for free at prices cheaper than their
>> competitors, but I also live in the real world where reality and my
>> dreams aren't the same thing..
>>
>> Then again, I'm also just an angry man waiting on his plane in an
>> airport...
>>
>> --
>> Tim
>>
>> On Fri, Nov 7, 2014 at 10:22 PM, Skeeve Stevens
>>  wrote:
>> > I agree... it is quite rude and seems to be just a push for cash
>> > considering what basic features these are.
>> >
>> >
>> > ...Skeeve
>> >
>> > *Skeeve Stevens - *eintellego Networks Pty Ltd
>> > ske...@eintellegonetworks.com ; www.eintellegonetworks.com
>> >
>> > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>> >
>> > facebook.com/eintellegonetworks ;  <http://twitter.com/networkceoau>
>> > linkedin.com/in/skeeve
>> >
>> > twitter.com/theispguy ; blog: www.theispguy.com
>> >
>> >
>> > The Experts Who The Experts Call
>> > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
>> >
>> > On 8 November 2014 12:26, Robin Williams 
>> wrote:
>> >
>> >> Hi all,
>> >>
>> >> We currently make some use of the MPLS CCC functionality of EX3200 and
>> >> EX4200 switches with the AFL, but note that their replacements EX3300
>> and
>> >> EX4300 don't have any MPLS support.  Does anyone know if this is a
>> >> temporary lack of support while the box is being developed further, or
>> is
>> >> there no plans no bring this support back in the new products?  I don't
>> >> like the way the EX3300 is being touted as the replacement for the
>> EX3200
>> >> but the feature set has entirely changed.
>> >>
>> >> I also think it's a bit rich that you now need an EFL license for
>> things
>> >> like OSPF support, where you didn't previously, and for the AFL
>> features
>> >> such as BGP, you now need both an EFL *AND* and AFL where you
>> previously
>> >> only needed an AFL.
>> >>
>> >> Would be interested to hear other opinions on this, to me it all seems
>> >> like a bit of a silly move on the part of Juniper and a gift to Cisco.
>> >>
>> >> Regards,
>> >> Robin.
>> >> ___
>> >> 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] QFX5100 3rd party optic/DAC

[Tim Jackson]

Some good debugging:

start shell
vty fpc0
show qsfp list
show qsfp 




On Mon, Sep 29, 2014 at 10:16 AM, Darren O'Connor  wrote:
> I've got the very latest code on as it's in a lab D25
>
> I've got two 3rd party DACs and it's going from QFX5100 to QFX5100. Both have 
> the same issue. Same two cables in QSFP ports on the back of the 4300s works 
> perfectly fine.
>
> Date: Mon, 29 Sep 2014 08:25:38 -0600
> Subject: Re: [j-nsp] QFX5100 3rd party optic/DAC
> From: aaron.dew...@gmail.com
> To: darre...@outlook.com
> CC: juniper-nsp@puck.nether.net
>
> What version of code? D10 (frs) had some issues with some cables which is 
> resolved in more current versions.
> Also if this is 5100 to 4300 make sure you have auto negotiation turned off 
> on the 4300 (but that would probably fail with a juniper branded dac as well 
> so unlikely to be the issue).
> On Sep 29, 2014 6:43 AM, "Darren O'Connor"  wrote:
> Anyone having any luck with this? I've got a few QSFP DACs that work 
> perfectly fine on a 4300 stack, but the QFX5100 refuses to work with them. 
> Work fine with a Juniper branded DAC.
>
>
>
>
>
>
>
> ___
>
> 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] EX9200 DHCP Relay

[Tim Jackson]

http://www.utdallas.edu/~ravip/cs6390/fall01/dhcp.figure.pdf

On Thu, Sep 18, 2014 at 7:01 AM, Chris Jones  wrote:
> My DHCP clients are all stuck in SELECTING state. Has anyone ever seen that, 
> or maybe know what causes it?
>
> root@DVT-EX9200> show dhcp relay binding
>
> IP addressSession Id  Hardware address   Expires State  
> Interface
> 0.0.0.0   18  00:25:90:3d:76:34  0   SELECTING  irb.30
> 0.0.0.0   19  00:25:90:3d:e5:13  0   SELECTING  irb.30
> 0.0.0.0   17  00:25:90:6d:f0:c3  0   SELECTING  irb.30
> 0.0.0.0   23  d4:be:d9:95:b6:4f  0   SELECTING  irb.16
>
>
>
>
>> On Sep 16, 2014, at 3:13 PM, William McLendon  wrote:
>>
>> this is a working DHCP config on EX9200s — make sure you include the 
>> forward-snooped-clients all-interfaces statement, or any transit DHCP packet 
>> that traverses an interface without DHCP relay configured will be eaten by 
>> the EX9200 — its the most asinine thing in the world to have (a carryover 
>> from MX some sort of DHCP security i’m sure), but its completely 
>> undocumented it does this from what i’ve seen.
>>
>>dhcp-relay {
>>forward-snooped-clients all-interfaces;
>>server-group {
>>CAMPUS {
>>192.168.168.168;
>>}
>>}
>>active-server-group CAMPUS;
>>route-suppression {
>>destination;
>>}
>>group LOCAL-NETS {
>>interface ge-5/0/0.304;
>>interface irb.9;
>>}
>>}
>> }
>>
>>
>> the route-suppression destination statement also prevents it from installing 
>> access-internal host routes and permanent ARP entries for every DHCP lease.
>>
>>
>> will
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> Chris Jones, JNCIE-ENT #272 / JNCIP-SP
> SDN Engineer
> www.sdnessentials.com
> Cell: 858-888-0373
> E-Mail: ch...@sdnessentials.com
>
>
> ___
> 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] EX9200 DHCP Relay

[Tim Jackson]

Basically everything is moving to jdhcpd.. It's only really licensed
on MX iirc (shouldn't be on 9200?)

set forwarding-options dhcp-relay overrides allow-snooped-clients
set forwarding-options dhcp-relay overrides always-write-giaddr
set forwarding-options dhcp-relay overrides trust-option-82
set forwarding-options dhcp-relay overrides send-release-on-delete
set forwarding-options dhcp-relay server-group DHCP-1 1.2.3.4
set forwarding-options dhcp-relay group DYNAMIC active-server-group DHCP-1
set forwarding-options dhcp-relay group DYNAMIC interface ae1.101

For most networks, you probably don't need those overrides, but if you
have something else downstream doing DHCP snooping and option 82
insertion, you have to tell it to trust it..


On Tue, Sep 16, 2014 at 7:02 AM,   wrote:
> Juniper Geniuses,
>
> I'm trying to set up some basic DHCP relay on an EX9200. The CLI rejects the 
> "forwarding-options bootp" syntax, saying "unsupported platform".
>
> Googling for some documentation, I came across "DHCP Relay Minimum 
> Configuration":
>
> http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/dhcp-subscriber-access-dhcp-relay-minimum-configuration.html
>
> Now, while I've come to understand that this DHCP Relay configuration was 
> specifically meant to be for MX subscriber management, this particular page 
> happens to be under the EX9200 documentation (I also realize the EX9200 is 
> basically an MX). I've also read that it's kind of buggy (or was in 2012...). 
> I also tried labbing this using some Fireflies and a VMX in Junosphere but 
> couldn't get it working.
>
> Anybody out there know if this is the correct way to do DHCP relaying on an 
> EX9200? If not, could somebody please provide a config example of how to do 
> this?
>
> Regards,
>
> Chris
>
>
> Chris Jones, JNCIE-ENT #272 / JNCIP-SP
> SDN Engineer
> www.sdnessentials.com
> Cell: 858-888-0373
> E-Mail: ch...@sdnessentials.com
> ___
> 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] ACX Series Technical Information

[Tim Jackson]

ACX is Broadcom Enduro inside. Basically a Cisco ASR901 (or Ciena 39xx).

Route scaling for all ACX is somewhere around 12k routes (give or take, its
11p on Bourbon Street)..

Licensing is only for ptp as far as I know. I had talks about reducing
price on units and per-port licensing was talked abou.t but no general
licensing is in place.

Runs 12.3X code.. Limited DHCP, most shit works.. I've deployed many 10s of
units so far as edge PEs with good success.
On May 13, 2014 10:02 PM, "Skeeve Stevens" <
skeeve+juniper...@eintellegonetworks.com> wrote:

> Hi all,
>
> The Juniper website is very light on technical information and capabilities
> of the ACX platform.
>
> Things such as throughput comparisons between models, routing protocols,
> number of routes per routing protocols supported, etc.
>
> There also is no mention of licensing on the base datasheet, so I am
> assuming everything it mentions, it is licensed for.
>
> Does anyone know of more detailed information?
>
> ...Skeeve
>
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/eintellegonetworks ;  
> linkedin.com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com
>
>
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper finally launches a route reflector platform

[Tim Jackson]

After reading more about this, this seems to *just* be for the PTX... :(

On Mon, Feb 24, 2014 at 3:13 PM, Julien Goodwin
 wrote:
> And in a sensible form factor too.
>
> http://www.juniper.net/us/en/products-services/routing/cse2000/
>
> Can think of plenty of other use cases for the box as well.
>
>
> ___
> 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] Can I do "dumb" Q-in-Q switching on Juniper MX?

[Tim Jackson]

interface-switch..

set protocols connections interface-switch BLAH interface ge-4/2/0.144
set protocols connections interface-switch BLAH interface ge-5/4/2.42

Setup each of the 2 interfaces with the right encapsulation
(CCC/VLAN-CCC) and the right push/pop operations..

On Mon, Jul 1, 2013 at 3:11 AM, Sebastian Wiesinger
 wrote:
> Hello,
>
> I need to do a sort of "dumb" Q-in-Q on a MX box. What I want from
> the MX is:
>
> Take alle VLAN tagged frames on an Port (CE-facing) and switch
> them to another interface (Core-Facing). On the core-facing interface
> push VLAN 42 on the frames (Q-in-Q).
>
> When frames arrive on the core-facing IF, remove vlan tag 42 and
> switch them to the CE.
>
> I don't need mac-learning for this as this is just p2p switching.
>
> (How) is that achievable?
>
> Regards
>
> Sebastian
>
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE 
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> ___
> 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] MX80 port numbering

[Tim Jackson]

Nab the Visio stencil for it. It scales up fine for printing on an entire
sheet of paper and has everything labeled. Throw the right MICs into it as
well.


On Fri, Mar 15, 2013 at 5:41 AM, Sebastian Wiesinger <
juniper-...@ml.karotte.org> wrote:

> Has anyone here an easily understandable graphic for port numbering on
> MX80 mic slot(s)? I can't get it right half of the time and support
> staff on-site never knows which port is which. Even the labels on the
> box are not really helpful.
>
> Regards
>
> Sebastian
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper equivalent to Cisco 3800X

[Tim Jackson]

Any of the EX3200/3300/4200 meet those requirements, but do not have the
full MPLS suite that the 3800X will have, nor do they have the buffers that
the 3800X does.

If that's all you want from a switch, the 3800X is overkill, maybe look at
ME3400E vs EX4200/3300..

--
Tim


On Wed, Jan 2, 2013 at 7:48 AM, Riccardo S  wrote:

>
>
>
>
>
> Which is,
> from your point of view, the equivalent model of Cisco 3800X metro
> ethernet ?
>
>
> I’m
> focusing on the following feature needed:
>
> -
> At
> least 24 gigaethernet ports
>
> -
> Full
> BGP support
>
> -
> Full
> multicast support
>
> -
> Ethernet-aggregation
> (LAG)
>
> -
> Full
> layer2 capabilities
>
>
> For the
> decision takes sense also a cost analysis, as far as I can understand Cisco
> 3800X is more than 20k $ price list…
>
>
> Tks
>
>
> ___
> 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] LDP on ex4200/3200 series….and 1RU LSR?

[Tim Jackson]

It can't even pass packets with > 1 label.

--
Tim


On Wed, Dec 19, 2012 at 7:44 PM, Mark Tees  wrote:

> Would it be feasible still for only outer label operations?
>
> To use as P router would you only ever need to work with outer label?
>
> Sent from some sort of iDevice.
>
> On 20/12/2012, at 9:52 AM, Craig Askings 
> wrote:
>
> > On 19 December 2012 20:18, Mark Tees  wrote:
> >
> >> Hi list.
> >>
> >> Has anyone heard about if there is ever going to be support for LDP on
> the
> >> ex4200/3200 series?
> >
> > From what I understand the chipset on ex4200/3200 does not support more
> > than one mpls label, so LDP etc is not possible on that hardware.
> >
> > --
> >
> > Regards,
> >
> > Craig Askings
> >
> > io Networks Pty Ltd.
> >
> >
> >
> > mobile: 0404 019365
> >
> > phone: 1300 1 2 4 8 16
> > ___
> > 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] CCC on EX, link state propagation

[Tim Jackson]

gigether-options asynchronous-notification is the command for MX

--
Tim

On Wed, Oct 10, 2012 at 11:16 AM, Tim Jackson  wrote:

> MX has a gig ether option for doing this. I'd check and see if EX4550
> does. EX 4200 does not AFAIK.
> On Oct 10, 2012 10:38 AM, "Benny Amorsen"  wrote:
>
>> I am considering building a very simple setup with a number of ethernet
>> interfaces on one switch each CCC-tunnelled through a common fiber to
>> another switch. I.e. simply emulating a typical ethernet CWDM using
>> EoMPLS.
>>
>> One feature which would be very handy is link state propagation across
>> those EOMPLS links. Ideally, if the fiber breaks, the ports at each end
>> go down so the equipment at each end quickly become aware of the break.
>> Even better if loss of link on a port at one end also shuts down the
>> link at the other end.
>>
>> Can the EX series do that? I'm thinking of the EX4550 in particular, but
>> information about other EX-switches is welcome as well.
>>
>>
>> /Benny
>>
>>
>> ___
>> 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] CCC on EX, link state propagation

[Tim Jackson]

MX has a gig ether option for doing this. I'd check and see if EX4550 does.
EX 4200 does not AFAIK.
On Oct 10, 2012 10:38 AM, "Benny Amorsen"  wrote:

> I am considering building a very simple setup with a number of ethernet
> interfaces on one switch each CCC-tunnelled through a common fiber to
> another switch. I.e. simply emulating a typical ethernet CWDM using
> EoMPLS.
>
> One feature which would be very handy is link state propagation across
> those EOMPLS links. Ideally, if the fiber breaks, the ports at each end
> go down so the equipment at each end quickly become aware of the break.
> Even better if loss of link on a port at one end also shuts down the
> link at the other end.
>
> Can the EX series do that? I'm thinking of the EX4550 in particular, but
> information about other EX-switches is welcome as well.
>
>
> /Benny
>
>
> ___
> 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] Config help for basic MPLS setup

[Tim Jackson]

I'm pretty sure this is the case. EX4200 will not forward anything with > 1
label.
On Sep 24, 2012 8:40 PM, "Jeff Wheeler"  wrote:

> On Mon, Sep 24, 2012 at 6:55 PM, Caillin Bathern 
> wrote:
> > On point 2 there, the ex can only process one label at a time but there
> could be a larger label stack than that so it can be a P router.
>
> I've been told the EX4200 will actually drop frames with more than one
> MPLS label.  If you are able to get your proposed configuration
> working, please post a follow-up.  I would like to know if it will
> indeed function as a P box.
>
> --
> Jeff S Wheeler 
> Sr Network Operator  /  Innovative Network Concepts
> ___
> 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] GPL licensed software in juniper products

[Tim Jackson]

That's actuall pre-Trapeze...

On Thu, Jun 7, 2012 at 5:51 PM, Rubens Kuhl  wrote:
>>> Their AX411 access point line, for one:
>
> Humm, got in there when they acquired Trapeze.
>
> Rubens
> ___
> 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] Unit-ID's revisited / accessing committed configuration

[Tim Jackson]

show configuration | display commit-scripts

On Thu, Apr 26, 2012 at 7:53 AM, Benny Amorsen  wrote:
> Is it possible to somehow get the committed configuration as it looked
> after commit-scripts were applied? I do not want the commit-scripts
> re-run, I simply want to fetch the configuration as it was after all
> scripts were run and the commit succeeded.
>
> To explain why I need to do this, it is necessary to go back to the unit
> ID problem I posted about earlier.
>
> To reiterate, the challenge is to generate unit ID's for a bunch of
> q-in-q interfaces like this:
>
>   unit 5239 {
>        encapsulation vlan-ccc;
>        vlan-tags outer 1559 inner 3;
>        input-vlan-map pop-pop;
>        output-vlan-map push-push;
>    }
>
> I solved it, or so I thought, by keeping all configuration in
> apply-macros, like this:
>
> apply-macro eompls-1001089 {
>    inner 3;
>    interface ge-1/0/4;
>    outer 1559;
> }
>
> which then generates the above q-in-q interface as a transient-change.
> The unit ID is simply the position of the apply-macro in the
> configuration file + 5000, so this particular apply-macro happens to be
> the 239th apply-macro.
>
> It all works really well, in general. Except I had not considered what
> happens if you remove an apply-macro. All is well if you remove the last
> apply-macro, but if you happen to remove one of the first ones, every
> interface below changes unit ID. The MX80 was less than happy about
> hundreds of interfaces being torn down and rebuilt...
>
> At this point it is tempting to give up on that design and "simply" add a
> unit ID to the provisioning database and to the apply-macro. Keeping
> them consistent is no fun at all.
>
> However, I would like to give the dynamic ID's one more chance. If it is
> possible to find out which unit ID the previous commit used for a
> particular apply-macro, I can then reuse that unit ID. Since all the
> changes my commit script does are transient, this seems to be a
> challenging task.
>
> Any help is really appreciated!
>
>
> /Benny
>
> ___
> 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] MX80 Power

[Tim Jackson]

Probably a bad idea.. You shouldn't really even be mixing AC and DC
power in the same racks if you can avoid it..


On Thu, Mar 29, 2012 at 12:05 PM, Kevin Wormington  wrote:
> Curious if anyone has used one AC and one DC power supply in an MX80?  Yes, I 
> know the docs say it's not supported but we all know how that goes.
>
> Thanks,
>
> Kevin
> ___
> 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] adding a ex4200px to a ex4200 chassis

[Tim Jackson]

http://kb.juniper.net/InfoCenter/index?page=content&id=KB22001&cat=JUNOS&actp=LIST

You'll have to run 11.2R1 or later..

--
Tim

On Tue, Mar 13, 2012 at 2:05 PM, Pappas, AJ  wrote:
> Anyone have any issues or comments or concerns about adding a new
> ex4200px to an existing chassis of ex4200's?  I know that to add a new
> switch to an existing chassis, you must be on the same code level.
> Should I downgrade the new ex4200px and put it to the same level as what
> I have now?
>
>
>
> AJ Pappas
>
> Network Administrator
>
> *  apap...@ottawaregional.org 
> " http://www.ottawaregional.org 
>
> ( 815-431-5180
>
> Ottawa Regional Hospital & Healthcare Center
> , 1100 E. Norris Dr., Ottawa, IL 61350
>
>
>
> P Please consider the environment before printing this e-mail and any
> attachments.
>
> Confidentiality Notice:  This e-mail may contain confidential
> information.  The information is intended only for the use of the
> intended recipient named above.  If you are not the intended recipient,
> you are hereby notified that any disclosure, copying, distribution, or
> the taking of any action in reliance on the contents of this telecopied
> information, except its direct delivery to the intended recipient named
> above, is strictly prohibited.  If you have received this e-mail in
> error, please notify the sender and delete the e-mail.
>
>
>
> ___
> 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] Sources for SFP+ optics

[Tim Jackson]

Personally I've never had a single issue with Finisar, Fujitsu, or Opnext.

SFP, SFP+, or XFP.

On Thu, Feb 23, 2012 at 7:46 AM, Robert Juric  wrote:
> Thanks for the insights. Which 3rd party transceivers have you had the best
> luck with then?
>
> Robert
>
> On Thu, Feb 23, 2012 at 4:31 AM, Daniel Roesen  wrote:
>
>> On Wed, Feb 22, 2012 at 02:27:40PM -0600, Robert Juric wrote:
>> > Juniper also has only tested and verified their equipment with their
>> > optics. If you want to know without doubt that it will work, go
>> > straight to the source.
>>
>> "Without doubt" will give you surprises. See PR/486951 for extended
>> fun with certain revision of Juniper-premium-price-sold Picolight/JDSU
>> XFPs with links not coming up anymore. Or the desaster with early
>> revision of Methode Elec. SFP-T which had a bad physical design of
>> the locking/ejection mechanics so you were almost unable to remove
>> them from without damaging the DPC.
>>
>> Bottom line: we had far less trouble with 3rd party transceivers than
>> with Juniper premium priced transceivers for a fraction of cost.
>>
>>
>> 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
>>
> ___
> 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] WAN-PHY support for EX-series 10g interfaces

[Tim Jackson]

LAN-PHY only on EX4200/4500 as far as i know.

--
Tim

On Tue, Feb 14, 2012 at 11:53 PM, Dale Shaw  wrote:
> Hi,
>
> Potentially odd question here but does anyone know, from 1st hand
> experience, whether WAN-PHY mode is supported on 10g interfaces in
> EX-series devices? Specifically EX4200 and/or EX4500?
>
> I ask because we have a new carrier circuit being delivered in the
> not-too-distant future and we need to plug something into it to test
> it. Eventually we'll jam a SRX5800 with a 4x10GE DPC onto the end of
> it but in the meantime it would be handy to terminate and test with
> something .. smaller.
>
> The existing interfaces we have (provisioned before my time)
> apparently needed to be configured with the "framing wan-phy" and
> "optics-options wavelength 1550.12" configuration options. The framing
> command auto-completes on an EX-series box but the optics-options
> command is hidden.
>
> Couldn't find any definitive references in the product docs.
>
> cheers,
> Dale
> ___
> 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 Error Entry

[Tim Jackson]

On Wed, Feb 1, 2012 at 10:53 AM, Paul Stewart  wrote:
> Has anyone seen these errors before and can shed some light on whether they
> are serious or not?


http://stagect.juniper.net/techpubs/en_US/junos11.1/information-products/topic-collections/release-notes/11.1/index.html?topic-53314.html

The following system log message might be reported on MX routers with MPC:

fpc8 MQ(2): %PFE-3: pio_handle(0x414e0908); pio_read_u64() failed:
1(generic failure)! addr=02244298
fpc8 trinity_pio: %PFE-3: 1 PIO errors occurred
fpc8 trinity_pio: %PFE-3: Last error: 11MQ-2 Trinity PCI
0xfe6dfbfe Read  PCIe

[PR/613139: This issue has been resolved.]
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Frame loss during Ethernet test

[Tim Jackson]

This isn't running on an MPC carded MX running 10.2 code is it?

There was a bug that bit us that had some random small bits of frame
loss on CCC circuits on MX80 on 10.2.. I can't recall the bug ID, but
it was fixed in 10.4R6.. If I remember right, check your logs and
you'll see some parity errors scrolling through when there is frame
loss.

--
Tim

On Tue, Jan 24, 2012 at 4:03 AM, Gökhan Gümüş  wrote:
> Dear all,
>
> One of our customer complaining a small amount of frame loss on their
> service.
> I see that lost packets when i compare input and output statistics on the
> interface.
> We are terminating service with ccc configuration.
> At remote end, we have a hardware loop and customer connects its tester to
> A-end sends traffic.
> When we run the test for 2-3 mins, we have no frame loss but at longer test
> we start to see 10-20 frame loss.
> Frames are lost when our PE puts sent test traffic into corrresponding LSP
> but there is no issue in our LSP.
>
> I do not know the exact principle of these testers but i checked all the
> possible reasons which may cause frame loss
> Delay, errors on the line, oversubscription, etc...None of them is an issue
> during test.
>
> Is there anybody who has such an experience with Ethernet testers?
>
> Thanks and regards,
> Gokhan
> ___
> 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] QFX3500 optics lock?

[Tim Jackson]

+1

Nobody wants "support" just don't cripple the platform. "Reasons to use
Juniper over Cisco" - 1 if this stays this way, or becomes the norm.
On Jan 7, 2012 9:28 PM, "Julien Goodwin"  wrote:

> On 07/01/12 15:50, Salman Zahid wrote:
> > 2.  In terms of 3rd party optics support , we are evaluating the
> support for 3rd party optics . Please continue to check the Juniper
> documentation and talk to your account team for roadmap information .
>
> My ire has cooled considerably since reading this statement yesterday,
> so here's an attempt at a sane response.
>
> Nobody is asking Juniper to *support* third party optics, they never
> have before. All we want is, that like all other Juniper products to
> date (that I'm aware of) that third party optics work, and have feature
> parity.
>
> If you're so worried about latency within a Qfabic making Juniper
> branded (because I'll bet they're not even a special run, let alone
> special model) optics required on the internal side of a fabric is
> annoying, but not all that objectionable. There's also nothing wrong
> with WONTFIXing latency tickets if the path is not 100% Juniper optics,
> much as other issues with third party optics are handled today.
>
> To lock third party optics out you had to *add* code to JunOS, remember
> that.
>
> Even ignoring common optic types (SR, LR, etc) there's still plenty of
> reasons to want third party optics, passive C/DWDM is just the start,
> RAD's [TE][13] SFP modules are another type that Juniper just don't offer.
>
>
> ___
> 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] Booting Cisco AP's - JUNOS DHCP

[Tim Jackson]

set system services dhcp pool 192.168.240.0/24 option 43 string
"192.168.1.1,192.168.2.1"

or the hex stuff, you'll need to set it as a byte-stream:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB19509&actp=search&viewlocale=en_US&searchid=1304332102670

I don't think theres a way to use Option 60 inbound to change the
outgoing options on the local DHCP server.. I could be wrong, but you
can (if you're using another server or server(s)) use option 60 to
change DHCP Relay:

http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/example-using-option60-strings-to-drop-dhcp-client-traffic.html#example-using-option-60-drop

http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/using-matching-option60-strings-to-process-dhcp-client-traffic.html

etc..

On Thu, Jan 5, 2012 at 10:09 AM, Paulhamus, Jon  wrote:
> Hello group-
>
> Can anyone guide me with configuring DHCP option 43 and option 60 using JUNOS 
> DHCP to properly configure Cisco AP's?    I'm not able to make this work 
> correctly.
>
> Thank you all,
> Jon
>
> ___
> 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] SRX2xx Question.

[Tim Jackson]

Anybody tested the throughput on these in packet mode only?
On Jul 26, 2011 8:26 PM, "Bill Blackford"  wrote:
> Used 210's and 220 that were running BGP, OSPF and NAT (both static
> and pools) all simultaneously. They do well.
>
> -b
>
>
>
> On Tue, Jul 26, 2011 at 4:26 PM, Keith  wrote:
>> We need to get something in our work lab for testing the odd thing out
>> and just to bang on.
>>
>> Is the SRX line, say the 240 or or 210 enough to run a very simple
>> BGP config (like say sending a few /22's and receiving a default route)
>> and RIP/OSPF?
>>
>> Seems we can pick up an SRX for 600-2000 depending on what SRX
>> it is. At least this is what I see on Ebay.
>>
>> Thanks.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
>
> --
> Bill Blackford
> Network Engineer
>
> Logged into reality and abusing my sudo privileges.
> ___
> 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] MX80 Opinions

[Tim Jackson]

>
>
> Juniper would really do well to introduce a 1U small/simple external RE
> which can be connected over Ethernet, to "redundantize" a box like the
> MX80, and to be a reasonably sized BGP route reflector.
>
>
If there was a like button on j-nsp, I'd click it about this..

Outside of a few bugs we've been really happy with the MX80.. We have 6 or 7
in production now..

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

Re: [j-nsp] RSVP LSP metric

[Tim Jackson]

That's correct.
On Apr 19, 2011 10:45 PM, "Thedin Guruge"  wrote:
> Hi Experts,
>
> This is really to confirm my understanding is correct wrt to how RSVP
> inherits its metric,
>
> when RSVP and OSPF is configured in-conjunction, RSVP will inherit OSPFs
> cost to get to that network? presume it's a flat area 0 OSPF network.
> Configuring a manual metric within RSVP LSP will override this behavior
for
> that specific LSP.
>
> Regards,
>
> Thedin
> ___
> 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] XFP-10G-L-OC192-SR1

[Tim Jackson]

They're fine to run back to back..

Average launch power  -8.2 through *0.5 dBm*

Average receive power -14.4 through *0.5
 dBm*

*Receiver saturation 0.5 dBm*

You'll never launch hotter than the max RX..


They usually launch @ -2 -> -3dbm..

--
Tim

On Thu, Mar 24, 2011 at 7:07 AM, Paul Stewart  wrote:

> Hi folks.
>
>
>
> These are "10KM" optics - how short of a run can you use them for?  We have
> several of these spared at the moment and I'd like to use them for
> connections between MX480's in the same rack. will they run too hot?
>
>
>
> The specs on the Juniper site show:
>
>
>
> Transceiver model number XFP-10G-L-OC192-SR1
>
> Optical interface   Single-mode
>
> Transceiver type  XFP
>
> Standard  IEEE
> 802.3ae-2002
>
> Maximum distance 9/125 SMF cable:
> 6.2 miles/10  km
>
> Transmitter wavelength   1260 through 1355 nm
>
> Average launch power  -8.2 through 0.5 dBm
>
> Average receive power -14.4 through 0.5
>  dBm
>
> Receiver saturation 0.5 dBm
>
> Receiver sensitivity -14.4 dBm
>
>
>
>
>
> 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

Re: [j-nsp] EX4200 JunOS Recommendation

[Tim Jackson]

I've been told 10.0R4 is the release to run, but I have no real evidence of
why it's the right release. I've got several boxes being used for end user
aggregation on 10.0R3 w/o issues..

We're about to roll out 15 or 20 in a metro ring setup.. I'm going to try
out 10.0R4 and see what happens..
On Nov 8, 2010 1:40 PM, "Keegan Holley"  wrote:
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multicast / IGMP

[Tim Jackson]

Remove the "DATABASES" from the vlan members list..

The native VLAN will take care of it... Right now incoming untagged goes to
Databases and outgoing it gets tagged.

Outside of that, multicast should work. If you don't have an igmp router
somewhere you may need to enable igmp querrier support (I do believe that's
what it is called)..

On Aug 8, 2010 2:52 PM, "Bill Blackford" 
wrote:

The basic question here is, does Juniper handle multicast on a single vlan
differently than Cisco?

I have two Linux mysql hosts configured in a cluster connected to the same
switch on the same vlan. They communicate on multicast when that switch is a
Cisco 3560 and not at all when that switch is a EX3200. The EX's have
igmp-snooping enabled by default, as I believe the Cisco does.

Both interfaces are pretty straight forward. MGT vlan-id is "1", DATABASES
vlan-id is "5". Both hosts need to send un-tagged traffic on 802.1q tag 5.


ge-0/0/2 {
   description data-01.mysql;
   unit 0 {
   family ethernet-switching {
   port-mode trunk;
   vlan {
   members [ MGT DATABASES ];
   }
   native-vlan-id 5;
   }
   }
}
ge-0/0/3 {
   description data-02.mysql;
   unit 0 {
   family ethernet-switching {
   port-mode trunk;
   vlan {
   members [ MGT DATABASES ];
   }
   native-vlan-id 5;
   }
   }
}


Thank you in advance for any insight,

-b

--
Bill Blackford
Senior Network Engineer
Technology Systems Group
Northwest Regional ESD

Logged into reality and abusing my sudo priviledges



___
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] MX80 = vaporware?

[Tim Jackson]

And power needs... MX240 is a power hog compared to an MX80..

--
Tim

On Mon, Jun 21, 2010 at 8:28 AM, matthew zeier  wrote:

>
> On Jun 21, 2010, at 4:58 AM, Scott T. Cameron wrote:
>
> > Why don't you just get an MX240?  They are available and on the market.
>
> Significantly different price structure!
> ___
> 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] (no subject)

[Tim Jackson]

+1

Droid is great for SSH... Connectbot is by far the best mobile SSH client
ever... Better than blackberry's offerings and WinMo...

--
Tim

2010/6/5 Frank Sweetser 

> On 6/5/2010 3:36 PM, Tomasz Mikołajek wrote:
>
>> Ok, so if we are talking about mobile phones/smartphones, which one in the
>> best for network engineer? I am befor changing my phone to new one. I need
>> SSH and VPN.
>>
>
> I'm quite happy so far with my Droid.  It has an excellent ssh client,
> ConnectBot, that lets you open up multiple simultaneous ssh sessions.  I
> haven't played around with it's VPN capabilities, but it claims support for
> PPTP, L2TP, and IPSec connections, and if you're willing to root the phone,
> openvpn as well.
>
> --
> Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution
> that
> WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL
> Mencken
>GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC
>
> ___
> 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] WebVPN Problem / SRX

[Tim Jackson]

Do you have a policy in place like:

security {
 policies {
  from-zone untrust to-zone trust {
   policy leo-vpn {
 match {
   source-address any;
   destination-address any;
   application any;
  }
  then {
permit {
  tunnel {
ipsec-vpn leo;
  }
 }
}
   }
}
}




On Tue, May 25, 2010 at 12:14 PM, Paul Stewart  wrote:

> Anyone on here setup WebVPN on Juniper SRX?  I've had a JTAC ticket running
> for quite a while and they haven't been able to figure out why we can't
> connect.  according to the logs the username is getting authenticated and
> then the session drops for some reason.. I'm about 6-7 hours on the phone
> with JTAC so far - hoping someone has some ideas ;)
>
>
>
> Thanks ;)
>
>
>
>
>
> SRX210 running 10.0R3.10
>
>
>
> access {
>
>profile user-auth-profile {
>
>client leo {
>
>firewall-user {
>
>password ""; ## SECRET-DATA
>
>}
>
>}
>
>}
>
>firewall-authentication {
>
>web-authentication {
>
>default-profile user-auth-profile;
>
>}
>
>}
>
> }
>
>
>
>
>
> security {
>
>ike {
>
>traceoptions {
>
>flag all;
>
>}
>
>proposal phase1-prop {
>
>authentication-method pre-shared-keys;
>
>dh-group group5;
>
>authentication-algorithm sha-256;
>
>encryption-algorithm aes-256-cbc;
>
>}
>
>policy ike-pol {
>
>mode aggressive;
>
>proposals phase1-prop;
>
>pre-shared-key ascii-text "xxx"; ##
> SECRET-DATA
>
>}
>
>gateway leo {
>
>ike-policy ike-pol;
>
>dynamic hostname leo;
>
>external-interface ge-0/0/0.0;
>
>xauth access-profile user-auth-profile;
>
>}
>
>}
>
>ipsec {
>
>proposal phase2-prop {
>
>protocol esp;
>
>authentication-algorithm hmac-sha1-96;
>
>encryption-algorithm aes-256-cbc;
>
>}
>
>policy ipsec-pol {
>
>perfect-forward-secrecy {
>
>keys group2;
>
>}
>
>proposals phase2-prop;
>
>}
>
>vpn leo {
>
>ike {
>
>gateway leo;
>
>ipsec-policy ipsec-pol;
>
>}
>
>}
>
>}
>
>
>
>   zones {
>
>security-zone untrust {
>
>screen untrust-screen;
>
>interfaces {
>
>ge-0/0/0.0 {
>
>host-inbound-traffic {
>
>system-services {
>
>dhcp;
>
>tftp;
>
>https;
>
>ssh;
>
>ping;
>
>snmp;
>
>ike;
>
>}
>
>}
>
>}
>
>}
>
>}
>
>}
>
>
>
>
>
>dynamic-vpn {
>
>access-profile user-auth-profile;
>
>clients {
>
>leo {
>
>remote-protected-resources {
>
>10.1.1.0/24;
>
>}
>
>remote-exceptions {
>
>0.0.0.0/0;
>
>}
>
>ipsec-vpn leo;
>
>user {
>
>leo;
>
>}
>
>}
>
>}
>
>}
>
> }
>
> ___
> 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] SRX as Little Juniper BGP Box

[Tim Jackson]

I second that. Buggy still but getting better...

On Mar 22, 2010 6:24 PM, "Stefan Fouant" 
wrote:

> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
> boun...
IMO, with the release of the SRX platforms I really can't see why anyone
would still be looking at the J-Series.  I expect Juniper is going to slow
down the development of these platforms in favor of the SRX.

Although there are still a fair number of bugs on the SRX, for what you want
to do I think you'd be perfectly safe running an SRX platform.  I have
worked with several customers who are using this as their
edge-router/firewall platform with a good degree of success.

Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D


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