Re: [j-nsp] TWAMP on MX series.

Hi, TWAMP was inter-op tested at EANTC (http://www.eantc.de/fileadmin/eantc/downloads/News/2019/EANTC-MPLSSDNNFV2019-WhitePaper-v1.2.pdf ) Thanks, Krzysztof > On 2019-Jun-18, at 11:51, >

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

If you need two physical connections to between those networks, then LAG is >> a way to go. MC-LAG or virtual chassis can be configured on legacy switches >> to maintain that connection. ESI will handle that on EVPN side. > > On Thu, 18 Apr 2019, Krzysztof Szarkowicz wrote: > >> A

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

to be Juniper-flavored. If you have single switch facing EVPN PEs -> simple LAG (with members towards different EVPN PEs) on that single switch is OK. Thanks, Krzysztof > On 2019-Apr-18, at 08:35, Rob Foehl wrote: > > On Thu, 18 Apr 2019, Krzysztof Szarkowicz wrote: > >> Hi Rob, >

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

Hi Rob, RFC 7432, Section 8.5: If a bridged network is multihomed to more than one PE in an EVPN network via switches, then the support of All-Active redundancy mode requires the bridged network to be connected to two or more PEs using a LAG. So, have you MC-LAG (facing EVPN PEs)

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

Hi Aaron, LDP mapping server is not supported with OSPF yet. Thanks, Krzysztof > On 2018-Aug-21, at 20:18, Aaron Gould wrote: > > Hi all, any guidance for doing the sr-to-ldp mapping thing would be > appreciated… > > > > I tried to do the mapping server between spring (sr) and ldp but

Re: [j-nsp] Longest Match for LDP (RFC5283)

You can turn ABR to inline Route Reflector and change the next-hop to self when reflecting the routes to access PE. Thus, access PE will require loopbacks of ABRs only. Sent from handheld device. Sorry for typos. On Tue, Jul 31, 2018, 16:29 wrote: > > Of Krzysztof Szarkowicz > >

Re: [j-nsp] Longest Match for LDP (RFC5283)

> On 2018-Jul-30, at 17:13, James Bensley wrote: > > On 30 July 2018 at 15:22, Krzysztof Szarkowicz wrote: >> James, >> >> As mentioned in my earlier mail, you can use it even with DU. If ABR has >> 1 /32 LDP FECs, you can configure LDP export policy on

Re: [j-nsp] Longest Match for LDP (RFC5283)

Sorry for the delay, I read > https://tools.ietf.org/html/rfc7032, > https://tools.ietf.org/html/rfc5283 and > https://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-07 before > responding. > > On 25 July 2018 at 09:14, Krzysztof Szarkowicz > wrote: > > The purpose o

Re: [j-nsp] Longest Match for LDP (RFC5283)

Hi, The purpose of “Longest Match for LDP” is to be able to distribute /32 LDP FECs, if corresponding /32 routes are not available in IGP. So, on ABR you inject e.g. default route into access IGP domain. ABR has /32 LDP FECs, and advertises this /32 FECs in LDP (but not in IGP) downstream into

Re: [j-nsp] Egress Protection/Service Mirroring

> On 2018-Jul-19, at 10:51, James Bensley wrote: > > On 15 July 2018 at 19:20, Krzysztof Szarkowicz wrote: > ... >>>> https://pc.nanog.org/static/published/meetings/NANOG71/1451/20171004_Szarkowicz_Fast_Egress_Protection_v1.pdf >>>> https://www.y

Re: [j-nsp] Egress Protection/Service Mirroring

any tricks done by the protector. Also, another beauty of centralized protector model is, your policies manipulating next-hops are very simply, regardless how the CEs are connected to PEs. > > On 15 July 2018 at 12:55, Krzysztof Szarkowicz wrote: >> Hi,

Re: [j-nsp] Egress Protection/Service Mirroring

Hi, Egress protection was presented at NANOG71: https://pc.nanog.org/static/published/meetings/NANOG71/1451/20171004_Szarkowicz_Fast_Egress_Protection_v1.pdf

Re: [j-nsp] ISIS route leaking from Level2 to Level1

Hi Cydon, setting down bit will be supported from 16.2 with ‘then color2 1’ Best regards, Krzysztof > On 2016-Nov-18, at 14:08, Cydon Satyr wrote: > > Hi Krasimir, > > I'm aware that would work. Also, if aggregate is redistributed to level 2 > as well (not just

Re: [j-nsp] VPLS: site-range

Hi Tom, please check the concept of hub-and-spoke VPLS using site-range http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/vpns-configuring-vpls-routing-instances.html Thanks, Krzysztof On Wed, 8 Jan, 2014, at 21:54 , Tom Storey t...@snnap.net wrote: Ok, so then you

Re: [j-nsp] MX960 JunOS recommendations

November, 2009 14:34 To: Krzysztof Szarkowicz Cc: 'Tima Maryin'; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX960 JunOS recommendations On Thu, Nov 12, 2009 at 01:45:22PM +0100, Krzysztof Szarkowicz wrote: The most common cause of dropping is mismatch of MPLS MTU, or L2 device

Re: [j-nsp] MX960 JunOS recommendations

It is not a nasty bug, but problem of inappropriately configured IP and MPLS MTUs on transit nodes. //Krzysztof -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tima Maryin Sent: Wednesday, 11 November, 2009 8:28

Re: [j-nsp] MX960 JunOS recommendations

on 9.3R3.8 ? Krzysztof Szarkowicz wrote: It is not a nasty bug, but problem of inappropriately configured IP and MPLS MTUs on transit nodes. //Krzysztof -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tima