Re: [j-nsp] MX960 with 3 RE's?

On 15 January 2016 at 03:13, Christopher E. Brown wrote: > When the same folks were asked about the 16XGE card and the 120G (and later > 160G) > performance it was indicated that there was an additional layer of > logic/asics used to tie > all 4 trios in the 16XGE to

Re: [j-nsp] MX960 with 3 RE's?

> From: Saku Ytti [mailto:s...@ytti.fi] > Sent: Friday, January 15, 2016 10:18 AM > On 15 January 2016 at 03:13, Christopher E. Brown > wrote: > > When the same folks were asked about the 16XGE card and the 120G (and > > later 160G) performance it was indicated that

[j-nsp] Segment Routing ( SPRING )

Hi have been reading cisco documentation on this topic. I was wondering if anyone knew the JUNOS status for this was? Cant find much on the website etc etc. many thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net

Re: [j-nsp] MX960 with 3 RE's?

So what are any bandwidth limitations of an all DPCE-R system with original SCB? Thanks, Kevin > On Jan 15, 2016, at 6:59 AM, Christopher E. Brown > wrote: > > > The MPC2-Q is an advanced per unit queueing card and has QX, it also > runs against the

Re: [j-nsp] MX960 with 3 RE's?

None. You can do 40Gbps, with multicast, on each linecard. On 15 January 2016 at 15:24, Kevin Wormington wrote: > So what are any bandwidth limitations of an all DPCE-R system with original > SCB? > > Thanks, > > Kevin > > >> On Jan 15, 2016, at 6:59 AM, Christopher E. Brown

Re: [j-nsp] MX960 with 3 RE's?

The MPC2-Q is an advanced per unit queueing card and has QX, it also runs against the lower/original fabric rate. The 16XGE rate is a port mode card with no QX, and it supports the first of the fabric speed increases. The published capacity of the MPC2-Q is 30G per MIC with a supplied by

Re: [j-nsp] RTBH

As a side note, this is how I’ve always seen it done. I believe even the RFC refers to this method. > On Jan 14, 2016, at 8:07 PM, chip wrote: > > A strategy that I've seen used is to pick some ip address and add a static > route for it pointing to discard on every

Re: [j-nsp] Segment Routing ( SPRING )

Also if folks are looking for an early intro into the config and operation within Junos there is a relatively new book “MPLS in the SDN Era” from Juniper and it has quite a bit on SPRING. The other nice thing about the book is all the use cases are mixed-vendor including both Junos and IOS-XR

Re: [j-nsp] Segment Routing ( SPRING )

Hey William, RSN. 1st half of 2016. I'm sure you can get some image to play with if you contact your account team. On 15 January 2016 at 14:33, Jackson, William wrote: > Hi > > > > have been reading cisco documentation on this topic. > > I was wondering if anyone

Re: [j-nsp] RTBH

And remember that if you plan to accept prefixes from external neighbors and send to the black hole route you need "accept-remote-nexthop". On Fri, Jan 15, 2016 at 3:20 PM, Johan Borch wrote: > Thanks > > Setting route preference helped :) > > Johan > > On Fri, Jan 15,

Re: [j-nsp] RTBH

Thanks Setting route preference helped :) Johan On Fri, Jan 15, 2016 at 12:23 AM, Charles van Niman wrote: > What route preference is your IGP route, and what IGP? I assume your > discard/static has a route preference of 5? Also, do you mind pasting > the show route

Re: [j-nsp] RTBH

Le 15/01/16 17:40, Hugo Slabbert a écrit : Sounds like the router that receives the initial RTBH /32 is re-advertising that to your other peers, i.e.: - RTBH box announces /32 with a.b.c.d/32 next-hop discard via BGP - RTBH BGP peer #1 receives and installs the route - that discard route on

Re: [j-nsp] RTBH

-- Hugo cell: 604-617-3133 h...@slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on Signal) On Thu 2016-Jan-14 22:10:46 +0100, Johan Borch wrote: Hi! I have implemented RTBH in my small network of 8

[j-nsp] Anyone tried ThreatStop on Juniper integration?

Hi all, we're taking a look at ThreatStop as a hostname and IP reputation provider, and I was wondering if anyone on this list has used them, or has any experience to share, either good or bad. We'd be using them to populate prefix lists on a pair of MX480's at our campus edge. (For the

Re: [j-nsp] Anyone tried ThreatStop on Juniper integration?

Frank Sweetser writes: >(For the curious, they integrate by installing some shell scripts on the >underlying FreeBSD level. The scripts pull down customer specific lists of IP >addresses, and dynamically create slax scripts to update a set of prefix lists >in the local config to match.) Very

Re: [j-nsp] Anyone tried ThreatStop on Juniper integration?

On 01/15/2016 03:51 PM, Phil Shafer wrote: Frank Sweetser writes: (For the curious, they integrate by installing some shell scripts on the underlying FreeBSD level. The scripts pull down customer specific lists of IP addresses, and dynamically create slax scripts to update a set of prefix

Re: [j-nsp] RTBH

On Fri 2016-Jan-15 18:58:08 +0100, Raphael Mazelier wrote: Le 15/01/16 17:40, Hugo Slabbert a écrit : Sounds like the router that receives the initial RTBH /32 is re-advertising that to your other peers, i.e.: - RTBH box announces /32 with a.b.c.d/32 next-hop discard via

Re: [j-nsp] Segment Routing ( SPRING )

Julian Lucek gave a very good talk and demo at the Nxtwork conference in San Jose a couple of months ago. He was on a vMX network with preproduction code and statically assigned label stacks in an ISIS environment. They didn't have IGP signaled labels. From the looks of things they're on it,

Re: [j-nsp] MX960 with 3 RE's?

> > I did not have gear for a 16XGE full test, but after SCBE upgrade I did > > specifically test at full duplex line rate on all 4 ports in a bank on one > > card to > > all 4 ports in a bank on a second card in the same chassis. > > > Alright, that's good news. > And there's no QX chip on these