Re: [j-nsp] VMX integrated FPC

> James Bensley > Sent: Monday, December 21, 2020 3:01 PM > > On Mon, 21 Dec 2020 at 09:56, Mark Tees wrote: > > > > Hello > > > > I remember when I originally got my mittens on VMX there was a boot > > flag to tell it to use an integrated FPC or integrated RIOT without a > > separate VM running

Re: [j-nsp] BGP output queue priorities between RIBs/NLRIs

> Rob Foehl > Sent: Tuesday, November 10, 2020 6:26 PM > > On Tue, 10 Nov 2020, Jeffrey Haas wrote: > > > The thing to remember is that even though you're not getting a given afi/safi > as front-loaded as you want (absolute front of queue), as soon as we have > routes for that priority they're

Re: [j-nsp] Big flows up to 320 Gbs

Yes I was recommending to have the QFX switch ports as L3 ports with p2p L3 links to servers -where each server would be engaging in routing with the QFX-es (understanding it can load-share across its two links to get to the other 15 servers). (this could be accomplished by static routing on

Re: [j-nsp] Big flows up to 320 Gbs

> james list > Sent: Saturday, September 26, 2020 11:57 AM > > Dear experts > I have a project to connect at layer2 level 16 servers (two interfaces > each) with a total of 32 x 10Gbs server interfaces in order to setup a big data > solution. > > These interfaces must have in normal conditions

Re: [j-nsp] How to pick JUNOS Version

> Saku Ytti > Sent: Wednesday, September 2, 2020 8:37 AM > > On Wed, 2 Sep 2020 at 10:23, Andrew Alston > wrote: > > > 2. Start looking at the new features - decide what may be useful - > > if anything - and start testing to that to death - again preferably > > before release so that the

Re: [j-nsp] vrf auto-export rib-group

> Mihai > Sent: Tuesday, June 23, 2020 12:39 PM > > Hi, > > Is the rib-group configured under VRF auto-export supposed to be a 'per- > table' (instead of per-protocol) rib-group which can also export routes from > VRFs to non-VRF instances, default included? > The example on the link below shows

Re: [j-nsp] Netflow config for MX204

> From: Saku Ytti > Sent: Friday, April 17, 2020 11:53 AM > > On Fri, 17 Apr 2020 at 13:23, wrote: > > > Yup this bit was clear, actually on this one, when I was searching I > > stumbled > upon a XR-9k cmd to enable connecting management port to fabric ... "rp > mgmtethernet forwarding" > >

Re: [j-nsp] Netflow config for MX204

> From: Saku Ytti > Sent: Friday, April 17, 2020 8:49 AM > > On Fri, 17 Apr 2020 at 10:39, wrote: > > > Can you expand on the above please? > > Say comparing RE/RSP management port on ASR9k and MX, > > No management port is revenue port, and will kill your flow export, if flow > export is

Re: [j-nsp] Prioritize route advertisement

> From: Jeffrey Haas > Sent: Monday, April 6, 2020 6:06 PM > > > On Apr 6, 2020, at 12:59 PM, > wrote: > > > >> Gustavo Santos > >> Sent: Monday, April 6, 2020 4:06 PM > >> > >> Is there a way to prioritize advertisement on some BGP sessions above > >> others? I tried the > >>

Re: [j-nsp] Netflow config for MX204

> Saku Ytti > Sent: Sunday, April 12, 2020 9:44 AM > > On Sun, 12 Apr 2020 at 03:53, Mark Tinka wrote: > > > On 11/Apr/20 08:04, Nick Schmalenberger via juniper-nsp wrote: > > > I had the same issue with first trying to export over fxp0, then > > > > We just export flows in-band. Just seems

Re: [j-nsp] [c-nsp] how many IGP routes is too many?

> Mark Tinka > Sent: Wednesday, April 8, 2020 12:55 PM > > On 5/Apr/20 12:25, adamv0...@netconsultings.com wrote: > > > Nowadays however, in times of FRR (-well that one has u-loops), but > > for instance ti-LFA or classical RSVP-TE Bypass... and BGP PIC "Core", > > I'd say the SPF calculation

Re: [j-nsp] Prioritize route advertisement

> Gustavo Santos > Sent: Monday, April 6, 2020 4:06 PM > > Hi, > > We have a MX10003 as peering router with over 400 BGP sessions. Last week > we had to change MTU from one Interface and after change, the router took > about 20 minutes to advertise routes some of our transit providers. > > Is

Re: [j-nsp] [c-nsp] how many IGP routes is too many?

> Pierfrancesco Caci > Sent: Thursday, April 2, 2020 8:46 AM > > Hello, > > is there any recent study about how many IGP (isis or ospf, I don't really care > right now) routes are "too many" with current generations of route > processors? Think RSP880, NCS55xx and so on on the cisco side and

Re: [j-nsp] Decoding DDOS messages

> Saku Ytti > Sent: Wednesday, March 18, 2020 4:37 PM > > On Wed, 18 Mar 2020 at 18:30, John Kristoff wrote: > > > Yep, I get all that. I can tighten that up. Care to show us how you > > do loopback filters? > > Really Juniper would be in the best position to automatically generate > lo0

Re: [j-nsp] Next-table, route leaking, etc.

> -Original Message- > From: juniper-nsp On Behalf Of > Saku Ytti > Sent: Saturday, February 22, 2020 9:52 AM > To: Jeff Haas > Cc: Juniper NSP > Subject: Re: [j-nsp] Next-table, route leaking, etc. > > On Sat, 22 Feb 2020 at 00:26, Jeff Haas wrote: > > > The problem and example

Re: [j-nsp] Automation - The Skinny (Was: Re: ACX5448 & ACX710)

> From: Robert Raszuk > Sent: Sunday, January 26, 2020 10:18 PM > > Hi Adam, > > I would almost agree entirely with you except that there are two completely > different reasons for automation. > > One as you described is related to service provisioning - here we have full > agreement. > > The

Re: [j-nsp] Automation - The Skinny (Was: Re: ACX5448 & ACX710)

> Mark Tinka > Sent: Friday, January 24, 2020 2:32 PM > > On 24/Jan/20 12:10, Saku Ytti wrote: > > > In my opinion we do roughly the same thing, the same way in networks, > > with the same protocols since my start of career in 90s, very little > > has changed and you could drop competent neteng

Re: [j-nsp] ACX5448 & ACX710

> From: Mark Tinka > Sent: Thursday, January 23, 2020 9:21 AM > > On 23/Jan/20 10:55, adamv0...@netconsultings.com wrote: > > > But it's gonna be your only choice if you want to do any sensible > > automation (or Junos). > > Over the past 10 years of hearing about all the buzz words, it's very

Re: [j-nsp] ACX5448 & ACX710

> Mark Tinka > Sent: Wednesday, January 22, 2020 6:46 PM > > On 22/Jan/20 20:39, Tim Durack wrote: > > > If you can stomach the BU wars, UADP is a nice ASIC - I think the > > Cat9k has legs, but the Enterprise BU is definitely in a parallel > > universe. I asked about porting XR to run on UADP.

Re: [j-nsp] ACX5448 & ACX710

> Mark Tinka > Sent: Thursday, January 23, 2020 7:01 AM > > This is one of the reasons operators with enough in-house coding skill are > seriously looking to build (or already building) their own routers with DPDK > on white boxes + friends, even if those solutions may be proprietary and > used

Re: [j-nsp] ACX5448 & ACX710

> Giuliano C. Medalha > Sent: Tuesday, January 21, 2020 8:24 PM > > Hello > > We did some initial lab teste using 5448 for a client and we have checked with > JUNIPER. > > The major problems we found for our client environment: > > - No support for FAT (no roadmap); > - No support for Entropy

Re: [j-nsp] MX204 vs. MX240??

> From: Saku Ytti > Sent: Thursday, November 14, 2019 1:31 PM > > On Thu, 14 Nov 2019 at 15:18, wrote: > > > > But still I don't see how the LU microcode has the ability to actually > > generate packets, let alone to host a complete daemon. > > It does, there is dispatch block in LU, in this

Re: [j-nsp] MX204 vs. MX240??

> Saku Ytti > Sent: Tuesday, November 12, 2019 11:28 AM > > On Tue, 12 Nov 2019 at 12:34, Mark Tinka wrote: > > > On our MX480's, we've known for a very long time that IPv4 BFD is > > supported in the PFE. However, IPv6 BFD runs on the RE. > > PFE is an ambiguous term, it variably means NPU or

Re: [j-nsp] EVPN all-active vs. layer 3

> Rob Foehl > Sent: Tuesday, November 12, 2019 3:19 AM > > Given a pair of EX uplinked to a pair of MX, with various downstream CE that > may be single devices or their own layer 2 topologies, as in this terrible > diagram: > >MX1 - MX2 >| / \ | >EX1 EX2 > \ / > CEs >

Re: [j-nsp] MX204 vs. MX240??

> Giuliano C. Medalha > Sent: Friday, November 8, 2019 4:48 PM > > Yes > > MX204 is a super router !!! > > Very impressive about its performance > > > *Forwarding plane and control plane performance > We didn't have it on our testbench yet but we did have MPC7 on there and were not

Re: [j-nsp] MX204 vs. MX240??

> Clarke Morledge > Sent: Friday, November 8, 2019 4:39 PM > > I wanted to resurrect an old thread about the MX204, from a year and a half > ago: > > https://lists.gt.net/nsp/juniper/64290 > > My understanding is that the MX204 is a 1 RU MPC7, but with a few > modifications. Yup, so be aware

Re: [j-nsp] BPDUs over EVPN?

> Rob Foehl > Sent: Monday, October 21, 2019 9:44 PM > > On Fri, 18 Oct 2019, Rob Foehl wrote: > > > Juniper is now telling me that this is occuring by design, but can't > > point to any documentation or standards which support that, nor > > explain why it suddenly changed post-upgrade.

Re: [j-nsp] BPDUs over EVPN?

> Gert Doering > Sent: Friday, October 18, 2019 10:45 AM > > Hi, > > On Fri, Oct 18, 2019 at 11:40:53AM +0200, Mark Tinka wrote: > > On 18/Oct/19 09:15, Gert Doering wrote: > > > > > I could see very special cases where it would be necessary, but that > > > would need to be a non-default-enabled

Re: [j-nsp] JunOS on EX4550?

Would anyone know how or if at all usable is netconf/yang on 15 code on these EX4550 switches? adam > -Original Message- > From: juniper-nsp On Behalf Of > Aaron Gould > Sent: Thursday, October 17, 2019 3:14 PM > To: 'Richard McGovern' ; 'Josh Baird' > > Cc: 'Juniper List' > Subject:

Re: [j-nsp] Suggestions for Edge/Peering Router..

> From: Saku Ytti > Sent: Thursday, September 19, 2019 2:42 PM > > On Thu, 19 Sep 2019 at 16:29, wrote: > > > The dynamic in Cisco implementation means that peers are automatically > placed to update groups based on commonalities in export policies, > regardless of the configuration. > > In

Re: [j-nsp] Suggestions for Edge/Peering Router..

> From: Saku Ytti > Sent: Thursday, September 19, 2019 1:32 PM > > On Thu, 19 Sep 2019 at 15:11, wrote: > > > Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in > Junos. > > They are dynamic, but once you make export change which affects subset of > members in

Re: [j-nsp] Suggestions for Edge/Peering Router..

> From: Saku Ytti > Sent: Thursday, September 19, 2019 12:33 PM > > On Thu, 19 Sep 2019 at 14:22, wrote: > > > Just a few examples when you change export policy it resets the peer > > or the cockup with RR clearing all sessions or the fact BGP is part of > > very complex RDP monolith -to me

Re: [j-nsp] Suggestions for Edge/Peering Router..

> Phil Reilly > Sent: Thursday, September 19, 2019 6:05 AM > > the BGP functionality and extensions are well > developed in JUNOS. Ha... :) Just a few examples when you change export policy it resets the peer or the cockup with RR clearing all sessions or the fact BGP is part of very complex

Re: [j-nsp] MPLS Auto-BW experiences

> Jared Mauch > Sent: Friday, September 6, 2019 10:42 PM > > What have you found are the most important parts of your settings, be it the > underflow/overflow settings or otherwise. I’ve had a few people come to > me recently asking for settings information, but I’m curious what the > collective

Re: [j-nsp] MX10 Pseduwire

> Mohammad Khalil > Sent: Thursday, August 29, 2019 7:55 PM > > Greetings all. > > Am trying to find how many pseduwires are supported on MX10 with no luck. > Any ideas? > Any vendor scaling numbers are the result of unidimensional testing if not stated otherwise -so X number of PWs but there's

Re: [j-nsp] LAG/ECMP hash performance

> James Bensley > Sent: Thursday, August 29, 2019 9:52 AM > > In the worst case scenario (1), with 4 bytes of CRC output to represent an > entire frame there is a large amount of hash collisions; Min size frame; 6 byte > SRC, 6 byte DST, 2 byte EType, 46 byte payload == 2^480 possible Ethernet >

Re: [j-nsp] vMX and SR-IOV, VFP xml dump

> From: Chris > Sent: Thursday, August 22, 2019 6:44 AM > > Hi > > On 21/08/2019 3:32 pm, adamv0...@netconsultings.com wrote: > > Thank you, much appreciated. > > Out of curiosity what latency you get when pinging through the vMX > please? > > It's less than 1/10th of a millisecond (while

Re: [j-nsp] vMX and SR-IOV, VFP xml dump

> Chris > Sent: Tuesday, August 20, 2019 3:05 AM > > Hi, > > On 19/08/2019 6:59 pm, adamv0...@netconsultings.com wrote: > > Wondering if anyone would share their xml dump from VFP -the interface > > config for a working SR-IOV setup please. (not sure if vCPU related > > info is needed as well,

Re: [j-nsp] PFE forwarding bug - PR1380183

> Aaron Gould > Sent: Monday, August 19, 2019 4:36 PM > > I hit PR1380183 last week on an MX960. > > > > https://prsearch.juniper.net/InfoCenter/index?page=prcontent > 0183> > =PR1380183 > > I currently run 17.4R2-S1.2

[j-nsp] vMX and SR-IOV, VFP xml dump

Hi folks, Wondering if anyone would share their xml dump from VFP -the interface config for a working SR-IOV setup please. (not sure if vCPU related info is needed as well, probably if cpu pinning is used) The juniper script is useless in my opinion as I'd like to understand the xml settings.

Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?

> From: Nathan Ward > Sent: Friday, August 16, 2019 11:20 AM > > Weird that the refresh timer <1200 triggers it. Do you mean the refresh timer > in the time values object is 1200 - i.e. 1.2s? JunOS default is 30,000 (30s), > 1200 > seems very short, or very long? Certainly it sounds like a bug,

Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?

> From: Nathan Ward > Sent: Friday, August 16, 2019 8:39 AM > > > On 1/07/2019, at 9:59 PM, adamv0...@netconsultings.com wrote: > > > >> From: Michael Hare > >> Sent: Friday, June 28, 2019 7:02 PM > >> > >> Adam- > >> > >> Have you accounted for this behavioral change? > >> > >> >

Re: [j-nsp] 40Gig Ether for MX480

> Saku Ytti > Sent: Friday, July 19, 2019 7:46 AM > > On Fri, 19 Jul 2019 at 04:27, Jared Mauch wrote: > > > Is there a reason to not do 4x10G or 1x100G? It’s cheap enough these > days. > > If they’re in-datacenter I can maybe understand 40G but outside the DC it’s > unclear to me why someone

[j-nsp] Junos to ODL (OpenDaylight)

Hi folks, Could anyone please share working setting to get Junos talk NETCONF-YANG to ODL please? Well they talk it's just ODL doesn't seem to like what Junos has to say with the OPEN msg for some reason. Same on ODL ver 4 or 3 and Junos 17 or 15 We followed the below guide to no avail:

Re: [j-nsp] EVPN - BGP attribute propagation on MXes

> Guillermo Fernando Cotone > Sent: Monday, July 1, 2019 3:39 PM > > Hi folks, > > Does anyone have implemented BGP attribute propagation using EVPN > route type-5? > We're trying to get BGP community propagation over an EVPN L3VNI, but so > far we had no luck. I've no idea if there's any knob

Re: [j-nsp] RSVP-TE broken between pre and post 16.1 code?

> From: Michael Hare > Sent: Friday, June 28, 2019 7:02 PM > > Adam- > > Have you accounted for this behavioral change? > > https://kb.juniper.net/InfoCenter/index?page=content=KB32883= > print=LIST==currentpaging > Thank you, yes please we're aware of that, but even with this the issue is

[j-nsp] RSVP-TE broken between pre and post 16.1 code?

Hi gents, Just wondering if anyone experienced RSVP-TE incompatibility issues when moving from pre 16.1 code to post 16.1 code. Didn't get much out of Juniper folks thus far so I figured I'll ask here as well. The problem we're facing is that in case 17 code is LSP head-end and 15 code is

[j-nsp] TWAMP on MX series.

Hi folks, Anyone using TWAMP on MX series? - both ends (client/sender & server/reflector) Any bugs or horror stories to be aware of please? I'd appreciate any pointers, Thanks. adam netconsultings.com ::carrier-class solutions for the telecommunications industry::

Re: [j-nsp] BGP Peering Policies - Best Practices

> From: Niall Donaghy > Sent: Wednesday, May 22, 2019 12:31 PM > > OP>> Are there non-technical reasons for leaving the Internet on the default > RIB? > Adam> Are there technical reasons please? > > How about: > > uRPF causing discarded packets in a multi-VRF environment, eg: > -

Re: [j-nsp] BGP Peering Policies - Best Practices

> Louis Kowolowski > Sent: Monday, May 20, 2019 5:58 PM > > On May 20, 2019, at 11:50 AM, Mark Tinka wrote: > > > > On 20/May/19 18:40, Richard Hicks wrote: > > > >> - Do you use policies to put prefixes into specific RIB groups? For > >> what > > > > I know many people put the Internet in a

Re: [j-nsp] BGP Peering Policies - Best Practices

> Richard Hicks > Sent: Monday, May 20, 2019 5:41 PM > > We are currently a mix of Juniper and Cisco. With the Cisco routers eBGP > peering with providers, exchanges, and customers. > > We will be reintroducing Juniper as peering routers. While I have some old > Juniper BGP peering policies I

Re: [j-nsp] LACP is not running between two VMX

> omar sahnoun > Sent: Wednesday, April 24, 2019 8:55 AM > > Hello all, > > I tried to mount a MC-LAG between two VMXs (using EVE-NG). I note that > the lacp protocol is not operational. > I did some research (including on this forum). The explanations I find are a > little complicated. That's

Re: [j-nsp] rib-groups && VPN reflection

> Adam Chappell > Sent: Thursday, April 18, 2019 9:13 AM > > Hello all. > > I figure this topic is a fundamental and probably frequently asked/answered > although it's new problem space for me. I thought I'd consult the font of > knowledge here to seek any advice. > > Environment: MX, JUNOS

Re: [j-nsp] EVPN all-active toward large layer 2?

> Tarko Tikan > Sent: Thursday, April 18, 2019 10:14 AM > > hey, > > > You have effectively created L2 loop over EVPN, so to cut it you need > > a link between bridged network and EVPN to be a single link. There is > > no STP in EVPN. > > To be fair it's not a full loop but only BUM traffic

Re: [j-nsp] EVPN all-active toward large layer 2?

> Wojciech Janiszewski > Sent: Thursday, April 18, 2019 7:48 AM > > Hi Rob, > > You have effectively created L2 loop over EVPN, so to cut it you need a link > between bridged network and EVPN to be a single link. There is no STP in > EVPN. > So the bridge-domains on PEs consume BPDUs and do not

Re: [j-nsp] EVPN all-active toward large layer 2?

> Rob Foehl > Sent: Thursday, April 18, 2019 6:43 AM > > First and foremost, is a topology like this even a valid use case? > > EVPN PE <-> switch <-> switch <-> EVPN PE > > ...where both switches are STP root bridges and have a pile of VLANs and > other switches behind them. All of the

Re: [j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?

> Raphael Mazelier > Sent: Tuesday, April 16, 2019 3:51 PM > > On 16/04/2019 15:52, Saku Ytti wrote: > > On Tue, 16 Apr 2019 at 16:35, Vincent Bernat wrote: > > > >> Can you confirm that rpd is answering ICMP echo requests? I find this > >> surprising as I would have expected the FreeBSD kernel

Re: [j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?

> Martin T > Sent: Monday, April 15, 2019 11:47 AM > > Hi Saku, > > thanks for reply! > > > > This is well know behavior and documented in several KB articles. > > > However, what exactly causes this? > > > > I think just CPU doing something else before given time to do the ICMP > > packets.

Re: [j-nsp] Fusion using vMX and vQFX

> Aaron Gould > Sent: Friday, April 12, 2019 4:54 PM > > Ok thanks > > ...was purely a training/familiarization question as an attempt to spin-up > some fusion in my eve-ng lab > > I'll resort to my hardware, which is limited, but good gear... mx960, mx204, > qfx5120 of which I only have

Re: [j-nsp] 400G is coming?

> Thomas Bellman > Sent: Monday, March 18, 2019 11:26 PM > > On 2019-03-18 23:24 +0200, Saku Ytti wrote: > > > Cheaper is subjective. To a small and dynamic shop CAPEX may represent > > majority of cost. To an incumbent CAPEX may be entirely irrelevant, > > money is cheap, but approving hardware

Re: [j-nsp] Old JunOS upgrade path

> Saku Ytti > Sent: Sunday, March 10, 2019 2:49 PM > > On Sun, Mar 10, 2019 at 4:30 PM Tom Beecher > wrote: > > > was when it was shut down. ( Hopefully. :) ) When you upgrade it, the > > process only modifies certain components. Any OS upgrade process like > > that > > This is not true, the

Re: [j-nsp] Hyper Mode on MX

> Franz Georg Köhler > Sent: Thursday, March 7, 2019 11:46 AM > > On Thu, Mar 07, 2019 at 12:31:48PM +0100, Olivier Benghozi > wrote: > > By the way HyperMode is only useful if you expect some very high > > throughput with very small packets (none of the MPCs are linerate > > using very small

Re: [j-nsp] Nested subroutine behaviour

Try adding: policy-options { policy-statement P-TEST1 { term ALLOW_REST { then accept; } } adam > -Original Message- > From: juniper-nsp On Behalf Of > Jason Lixfeld > Sent: Tuesday, February 26, 2019 10:02 PM > To: juniper-nsp > Subject: [j-nsp]

Re: [j-nsp] Finding drops

Hi Jason, Sorry missed the previous email, Hmm interesting, so it's capped at the WA block then not on the ASIC, good to know. On MPC7s we did not run into this issue but rather to the chip overload problem From my notes: MPC7 24x10GE per PFE that is 2x212.773Mpps (425.546Mpps two directions) ->

Re: [j-nsp] Avoid transit LSPs

> From: Luis Balbinot > Sent: Monday, January 28, 2019 1:39 PM > > I have many LSPs from P1 to P4 and all have FRR protection (Juniper FRR, 1:1). > Even with two distinct paths from P1 to P4 (both with much lower IGP > metrics) I get some detour LSPs setup on PE1. PE1 is a low-end ACX5k with >

Re: [j-nsp] Avoid transit LSPs

> Luis Balbinot > Sent: Friday, January 25, 2019 4:50 PM > > And link coloring does not help, at least in my case. > Not sure which method are you using for the FRR LSPs but you should be able to specify colouring constrains for the bypass LSPs to exclude specific colours (even though they are

Re: [j-nsp] Avoid transit LSPs

> Luis Balbinot > Sent: Thursday, January 24, 2019 4:45 PM > > Hi. > > How could I prevent a device from getting transit RSVP LSPs being > established through it? I only want it to accept ingress LSPs destined to that > box. > If this is a permanent thing, You could create a colouring scheme

Re: [j-nsp] Finding drops

Hey Jason, > Jason Lixfeld > Sent: Wednesday, January 23, 2019 3:02 PM > > This is somewhat embarrassing. I was looking at the wrong side of the test > when I initially observed the issue and I didn’t clue into that till now, so > some > of the previous claims are false. > > Just for

Re: [j-nsp] Finding drops

> Jason Lixfeld > Sent: Monday, January 21, 2019 8:09 PM > > Hi all, > > I’m doing some RFC2544 tests through an MX204. The tester is connected to > et-0/0/2, and the test destination is somewhere out there via et-0/0/0. 64 > byte packets seem to be getting dropped, and I’m trying to find

Re: [j-nsp] OSPF reference-bandwidth 1T

> Thomas Bellman > Sent: Thursday, January 17, 2019 3:48 PM > > On 2019-01-16 16:41 MET, Saku Ytti wrote: > > > No one should be using bandwidth based metrics, it's quite > > non-sensical. I would recommend that if you have only few egress > > points for given prefix, adopt role based metric

Re: [j-nsp] RE filter BCP

> Saku Ytti > Sent: Thursday, January 3, 2019 8:53 PM > > On Thu, 3 Jan 2019 at 22:50, Anderson, Charles R wrote: > > > Thanks. I assume the same problem exists if you have VRF loopback > > interfaces inside the VPN as well (e.g. OSPF router-id loopbacks for > > the customer's VPN). So the

Re: [j-nsp] IPAM like tool/DB for managing communities

Yes that's what I was thinking too, use RD as merely an arbitrary VPN ID. And then I realized that even though I could use these tools for documenting the VRF config after the fact But I can't use these with automated service provisioning. I need my automated service provisioning tool to query

Re: [j-nsp] IPAM like tool/DB for managing communities

Yes I tried NINAP, but as others IPAM tools out there it has this 1:1 relationship between VRF and RT I could hack around this and use the main RT thing as sort of an arbitrary ID (or main VRF RT) and add the actual/additional RTs as TAGs. Tried the same thing in netbox. But these are hacks

[j-nsp] IPAM like tool/DB for managing communities

Hi folks, I'm just wondering if anyone happens to know about a tool that can be used to manage BGP communities (standard/extended/large communities). I'd appreciate any pointers Thanks adam netconsultings.com ::carrier-class solutions for the telecommunications industry::

Re: [j-nsp] Interconnecting spines in spine & leaf networks [ was Re: Opinions on fusion provider edge ]

> Of Aaron1 > Sent: Thursday, November 15, 2018 4:23 PM > > Well, I’m a data center rookie, so I appreciate your patience > > I do understand that layer 2 emulation is needed between data centers, if I > do it with traditional mechanisms like VPLS or l2circuit martini, I’m just > afraid > if I

Re: [j-nsp] Interconnecting spines in spine & leaf networks [ was Re: Opinions on fusion provider edge ]

> Of Pavel Lunin > Sent: Friday, November 16, 2018 12:10 AM > > Gert Doering wrote: > > > > > EVPN is, basically, just putting a proper control-plane on top of MPLS > > or VXLAN for "L2 routing" - put your MAC addresses into BGP, and it > > will scale like hell. > > > > "Like hell" is the right

Re: [j-nsp] [c-nsp] show ospf lsdb - topology drawing

> Robert Raszuk > Sent: Thursday, October 25, 2018 2:42 PM > > Hi, > > Would anyone be able to recommend some open or closed src tool which > can draw nice topology of the OSPFv2 single area0 based on the show ospf > lsdb output capture ? > > I saw https://blog.webernetz.net/ospf-visualizer/

Re: [j-nsp] Juniper MPC2E-3D-NG-R-B vs MPC2E-3D-R-B

> Kevin Wormington > Sent: Friday, October 19, 2018 6:29 PM > > Hi list, > > Can anyone tell me the differences in scaling or features of the MPC2E-3D- > NG-R-B vs MPC2E-3D-R-B. I know the NG requires an SBCE2. > > Thanks, > Without going into too much detail (again), If all your traffic

Re: [j-nsp] Use cases for IntServ in MPLS backbones

> From: James Bensley [mailto:jwbens...@gmail.com] > Sent: Wednesday, October 03, 2018 9:19 AM > > On Tue, 2 Oct 2018 at 15:11, Mark Tinka wrote: > > Of course, in the real world, > > it was soon obvious that your Windows laptop or your iPhone XS sending > > RSVP messages to the network will

Re: [j-nsp] BFD Distributed Mode for IPv6

> From: James Bensley [mailto:jwbens...@gmail.com] > Sent: Wednesday, October 03, 2018 10:51 AM > > On Wed, 3 Oct 2018 at 10:13, Mark Tinka wrote: > > On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote: > > > > If you'd have separate ISIS process for v6 would it be possible to > > spin up a

Re: [j-nsp] BFD Distributed Mode for IPv6

> From: Mark Tinka [mailto:mark.ti...@seacom.mu] > Sent: Wednesday, October 03, 2018 10:13 AM > > > On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote: > If you'd have separate ISIS process for v6 would it be possible to spin up a > separate/dedicated BFD process for that ISIS? > > Probably

Re: [j-nsp] BFD Distributed Mode for IPv6

> Of Mark Tinka > Sent: Tuesday, October 02, 2018 9:47 PM > > > > On 2/Oct/18 21:13, James Bensley wrote: > > > I presume that if one were to run MT-ISIS there would be no impact to > IPv4? > > We already run MT for IS-IS. I consider this as basic a requirement as "Wide > Metrics". > >

Re: [j-nsp] Use cases for IntServ in MPLS backbones

Hi folks, I'm glad the thread spun up an interesting discussion but my original question was more around why would anyone prefer IntServ to DiffServ in an RSVP-TE environment. Personally I prefer RSVP-TE solely for TE purposes and QoS for QoS purposes, but there are always compromises if you

Re: [j-nsp] Use cases for IntServ in MPLS backbones

> Of Mark Tinka > Sent: Tuesday, October 02, 2018 11:56 AM > > > > On 2/Oct/18 12:48, Saku Ytti wrote: > > > You tell to them DSCP values do not affect forwarding or queueing > > behaviour in your network. > > If only the whole Internet was ran by just one AS. > Mark, it's a simple premise

[j-nsp] Use cases for IntServ in MPLS backbones

Hi folks, Another pooling question from me, This time I'm interested on what are your thoughts on DiffServ vs IntServ in MPLS backbones and what use cases for IntServ can you think of please. So what I have in mind specifically is RSVP-TE in combination with DiffServ (standard QoS) vs IntServ

Re: [j-nsp] Use IGP metrics for BGP routes

> Of "Rolf Hanßen" > Sent: Monday, September 24, 2018 6:23 PM > > Hello, > > we run ibgp over ISIS/MPLS (exchanging loopback IPs only) and run BGP > loopback to loopback (next-hop self). > Can somebody tell me if there is a possibility to use the igp metric for the bgp > routes. > The feature

Re: [j-nsp] auto b/w mpls best practice -- cpu spikes

> Of tim tiriche > Sent: Wednesday, September 12, 2018 6:04 AM > > Hi, > > Attached is my MPLS Auto B/w Configuration and i see frequent path > changes and cpu spikes. I have a small network and wanted to know if there > is any optimization/best practices i could follow to reduce the churn. >

Re: [j-nsp] vRR/L3VPN/Unusable

Yes I thought the FIB filter is a given on a RR, But didn’t know about the “no-install” knob so using: “set routing-options forwarding-table export ” –where the policy is just ”from protocol bgp; then reject” -so I guess then it’s the FIB filter –that does the trick and allows us to use

Re: [j-nsp] vRR/L3VPN/Unusable

> From: Ivan Ivanov [mailto:ivanov.i...@gmail.com] > Sent: Thursday, September 13, 2018 10:58 AM > > Hi, > > There are a few different ways to resolve the MP-BGP routes on out of band > Juniper RR. Depends on how flexible you want to be, one can use static route > in inet.3, change of the

Re: [j-nsp] vRR/L3VPN/Unusable

Hmm, these things are nasty you set them once and forget how they work :) Why to define the inet.3 table at all? I mean if you can have bgp.l3vpn.0 resolve directly from inet.0 (which I seem to remember it would do without any help anyways): set routing-options resolution rib bgp.l3vpn.0

Re: [j-nsp] "set routing-options protect core" breaks local-preference

> From: "Rolf Hanßen" [mailto:n...@rhanssen.de] > Sent: Tuesday, September 11, 2018 6:14 PM > > Hi Adam, > > I do not agree with your praise for the vm lab. > When I think of the last (real) issues in our network or things that fucked up > with Software-Upgrades, in most of the cases testing it

Re: [j-nsp] "set routing-options protect core" breaks local-preference

> -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf > Of Karl Gerhard > > Hello > > I am experimenting with BGP PIC before deploying it to production and I > have found an oddity: > With "set routing-options protect core" local-preference stops

Re: [j-nsp] LSP's with IPV6 on Juniper

Hi Rob, Some interesting points you raised indeed, > Of Rob Foehl > Sent: Wednesday, August 29, 2018 6:14 AM > > On Tue, 28 Aug 2018, adamv0...@netconsultings.com wrote: > > > Just out of curiosity is there a business problem/requirement/limitation > you're trying to solve by not changing the

Re: [j-nsp] LSP's with IPV6 on Juniper

> Of craig washington > Sent: Monday, August 27, 2018 5:40 PM > > Hello all. > > Wondering if anyone is using MPLS with IPV6? > > I have read on 6PE and the vpn counterpart but these all seem to take into > account that the CORE isn't running IPV6? > > My question is how can we get the ACTUAL

Re: [j-nsp] Network automation vs. manual config

> Of Antti Ristimäki > Sent: Sunday, August 19, 2018 4:17 PM > To: juniper-nsp > Subject: Re: [j-nsp] Network automation vs. manual config > > Hi, > > Thank you all for your comments both on and off the list. A lot of food for > thoughts. I can see that many of you have been evidently thinking

Re: [j-nsp] [c-nsp] L3VPN/RR/PE on Same router

> From: Saku Ytti [mailto:s...@ytti.fi] > Sent: Saturday, August 18, 2018 12:15 PM > > On Sat, 18 Aug 2018 at 14:02, wrote: > > > Really? Interesting, didn't know that, are these features documented > anywhere? I could not find anything looking for multi instance RPD. > > Are the RPD instances

Re: [j-nsp] [c-nsp] L3VPN/RR/PE on Same router

> From: Saku Ytti [mailto:s...@ytti.fi] > Sent: Saturday, August 18, 2018 11:44 AM > > On Fri, 17 Aug 2018 at 16:40, wrote: > > > Another alternative would be to spin up a separate BGP process, which I > think is supported only in XR, but once again that somewhat places one on > the outskirts

Re: [j-nsp] L3VPN/RR/PE on Same router

> From: Youssef Bengelloun-Zahr [mailto:benge...@gmail.com] > Sent: Friday, August 17, 2018 3:43 PM > To: Robert Raszuk > Cc: adamv0...@netconsultings.com; Saku Ytti; Juniper List > Subject: Re: [j-nsp] L3VPN/RR/PE on Same router > > Hi, > > > > Le 17 août 2018 à 16:28, Robert Raszuk a écrit

Re: [j-nsp] L3VPN/RR/PE on Same router

> From: Saku Ytti [mailto:s...@ytti.fi] > Sent: Friday, August 17, 2018 2:38 PM > To: Mark Tinka > Cc: adamv0...@netconsultings.com; tim tiriche; Juniper List > Subject: Re: [j-nsp] L3VPN/RR/PE on Same router > > Hey Mark, > > > > Yes a good practice is to separate internet routes from > > >

Re: [j-nsp] L3VPN/RR/PE on Same router

> From: Robert Raszuk [mailto:rob...@raszuk.net] > Sent: Friday, August 17, 2018 9:57 AM > To: Mark Tinka > Cc: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net; cisco- > n...@puck.nether.net > Subject: Re: [j-nsp] L3VPN/RR/PE on Same router > > Hey Mark, > > It has been a while >

  1   2   3   >