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

> > Can you do the EVPN routes on a separate session (different loopback on > both ends, dedicated to EVPN-afi-only BGP)? Separate sessions would help if TCP socket would be the real issue, but here clear it is not. > Or separate RRs? > Sure that may help. In fact even separate RPD demon on

Re: [j-nsp] Slow RE path 20 x faster then PFE path

Yes NAT is configured there as I indicated via presence of si- phantom load ... Having NAT there is not my idea though :). But sorry can not share the config. If you could shed some more light on your comment how to properly configure it and what to avoid I think it may be very useful for many

Re: [j-nsp] Slow RE path 20 x faster then PFE path

PM Timur Maryin wrote: > > > On 23-Mar-20 14:03, Robert Raszuk wrote: > > Hi, > > > > Would anyone have any idea why IP packets with options are forwarded via > > MX104 20x faster then regular IP packets ? > > > > "fast" PFE path - 24-35 ms &

Re: [j-nsp] Slow RE path 20 x faster then PFE path

PFE bugs ... but I will happily let vendor handle it these days :) On Mon, Mar 23, 2020 at 6:30 PM Mark Tinka wrote: > > > On 23/Mar/20 19:25, Robert Raszuk wrote: > > > Hi Mark, > > > > Oh yes ... exact same config and same setup and even same hw (mx104) > >

Re: [j-nsp] Slow RE path 20 x faster then PFE path

Hi Mark, Oh yes ... exact same config and same setup and even same hw (mx104) works fine in other location giving consistent 1 ms without IP options and mostly 1-3 ms with IP options - but that is all fine. Going to RE is always non deterministic :) Another interesting observation is that show

Re: [j-nsp] Slow RE path 20 x faster then PFE path

That is actual topology and during testing no other return path existed. It seems that there are PFE loops which would explain why punted to RE packets are forwarded so fast JTAC is debugging :) Thx, R. On Mon, Mar 23, 2020 at 4:17 PM Saku Ytti wrote: > Hey, > > > This is very simple

Re: [j-nsp] Slow RE path 20 x faster then PFE path

st you think > (tshark might add information). > > a) is 1.4ms possible in terms of speed-of-light? > b) where are 24ms packets sitting, do you also have longer path > available or are you heavily congested causing massive queueing delay? > > > > On Mon, 23 Mar 2020 at

[j-nsp] Slow RE path 20 x faster then PFE path

Hi, Would anyone have any idea why IP packets with options are forwarded via MX104 20x faster then regular IP packets ? "fast" PFE path - 24-35 ms "slow" RE path - 1-4 ms Example (I used record route to force IP Options punt to slow path): rraszuk@cto-lon2:~$ ping 62.189.71.209 -R -v PING

Re: [j-nsp] Internet monitoring in case of general issues

d some would like network to be a little bit more smart :) Best, R. On Sun, Mar 15, 2020 at 12:31 PM Mark Tinka wrote: > > > On 15/Mar/20 12:56, Robert Raszuk wrote: > > All, > > > > It seems that most answers and in fact the question itself assumes that > all >

Re: [j-nsp] Internet monitoring in case of general issues

All, It seems that most answers and in fact the question itself assumes that all we can do here is to be reactive. In my books that is an indication that we have already failed. I do think that any one who has more then one internet upstream ISPs (full table or even defaults out) can do

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

> And I think almost no one is collecting data in such a manner > that it's actually capitalisable, because we can keep running the > network with how how we did in 90s, IF-MIB and netflow, in separate > systems, with no encrichement at all. Spot on ! Btw Saku - you keep suggesting measuring

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

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 other one is actually of keeping your network running. Imagine router maintaining

Re: [j-nsp] ACX5448 & ACX710

CPE with its datasheet not even mentioning IPSec/DTLS hardware support ... LOL what year do we have ? On Wed, Jan 22, 2020 at 3:01 PM wrote: > > 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

Re: [j-nsp] FlowSpec and RTBH

I see there are two questions here Marcin is asking: > I was wondering is there a way to export family flow routes (from > inetflow.0) to non flowspec BGP speaker? Q1 - Can I advertise Flowspec NLRIs to non Flowspec speakers ? The answer is clearly "No" > For example tag Flowspec route with

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

> > > 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 peer-group, that member gets reset while placed to new > update-group. And that is how dynamic update groups works

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

Hi Eldon, You are very correct. I was very highly surprised to read Saku mentioning use of CRC for hashing but then quick google revealed this link: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/hash-parameters-edit-forwarding-options.html Looks

Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?

wrote: > > On Thu, 31 Jan 2019 at 10:34, Robert Raszuk wrote: > > > > > As mentioned on the other thread decent routers should resolve peer's > IP to mac when creating FIB adj and building rewrite entries. > > > There is no "first packet" notion nor any

Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?

of transit. Thx On Thu, Jan 31, 2019, 09:51 Saku Ytti On Thu, 31 Jan 2019 at 10:34, Robert Raszuk wrote: > > > As mentioned on the other thread decent routers should resolve peer's IP > to mac when creating FIB adj and building rewrite entries. > > There is no "first packet

Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?

As mentioned on the other thread decent routers should resolve peer's IP to mac when creating FIB adj and building rewrite entries. There is no "first packet" notion nor any ARPing driven by packet reception. This should apply to p2p adj as well as p2mp - classic LANs. Are you guys saying that

Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows

Hi Alex, > as opposed to normal ARP behaviour where ARP is only > resolved where there is a packet going to 203.0.113.1. In correctly constructed ISP grade routers FIB data plane is build regardless of packets going through the router or not. So it is actually control plane driven to build MAC

[j-nsp] show ospf lsdb - topology drawing

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/ but looking for more tools like this proven in battle field especially those

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

> > It's about increasing the odds of it to fall on the right side, > Exactly ! > But comparing say XR and Junos, judging from the rest of the inner workings I could experience empirically, I'd say they are sufficiently different > implementations. > True. In fact even XE & XR BGP code core

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

If I have Cisco PEs and Juniper RRs by your description it may crash ... hence better to avoid it - right ?. Good thing this is thread about iBGP not eBGP :):) Thx R. On Fri, Aug 17, 2018 at 4:43 PM, Youssef Bengelloun-Zahr wrote: > Hi, > > > > Le 17 août 2018 à 16:28, R

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

> and that thing would then crash BGP on RRs, can't afford that happening. Then best thing is to run two or three RRs in parallel each using different BGP code base - even for the same AFI/SAFI pair I am seeing number of networks running single vendor RRs and when things melt they run around and

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

Just to clarify ... I was not really worried about how to follow various lists - mail client does a good job to combine them into one folder, filter duplicates etc ... But when writing general reply/question to Mark today about BGP sessions I noticed it only had j-nsp - but oh the question is

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

Hey Mark, It has been a while > We've been running all address families on the same RR's (different > sessions, obviously, but same hardware) Out of pure curiosity how are you setting up different BGP sessions to the same RR ? I think what Adam is proposing is real TCP session isolation,

Re: [j-nsp] Summarize Global Table

Chris, Have you read draft-ietf-grow-simple-va-04 ? There is nothing in the draft nor in the implementation reg route to the left. It is all about take the same door as your big boss when you exit and when you get new smaller boss in the middle who exist differently via different doors your

Re: [j-nsp] Summarize Global Table

Hi Pavel, Robert, is there any non-production implementation of simple-va, which we could play with? The only implementation I am aware of is cisco ios component code. Yes there are non-production EFT images you could perhaps get from cisco to play around with it. Since I have switched

Re: [j-nsp] Summarize Global Table

Hi Shane, First I would like to actually thank all who provided some points reg simple-va during the discussion since yesterday. By all means I agree in some concerns expressed if additional CPU or RIB/FIB installation times for possibly batches of more specifics in relatively short time

Re: [j-nsp] Force IP traffic not to use the LSP path when enabling ISIS Traffic Engineering with Shortcuts

Peter, One way to accomplish what I think you are asking for is to use different BGP next hops for destinations you want to have native IP switched traffic and those which you want to transport over MPLS LSP (TE or LDP). Then you are only constructing MPLS LSPs to those next hops you would

Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...

Hi Derick, I previously blogged that a (totally hypothetical) multi-tenant network built entirely with PBR or FBF would not pass audit because of a lack of separate RIB and separate FIB structures for each tenant in the network. Why wouldn't this pass audit? OpenFlow is similar. Well I

Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...

Hi Keegan, over another. However, if the vrf's all have separate tables in the real world then that should require the table lookup to come before the prefix lookup. If not there would be no way to figure out which fib to search. For packets coming from customer (CE) there is no need for

Re: [j-nsp] full table?

Hi Keegan, Is it always necessary to take in a full table? Why or why not? In light of the Saudi Telekom fiasco I'm curious what others thing. This question is understandably subjective. We have datacenters with no more than three upstreams. We would obviously have to have a few copies of

Re: [j-nsp] 32-Bit JunOS on the 64-Bit Routing Engines

Hi Keegan, They are saying that the new 16G RE's can handle 250M routes. How is this possible if none of the daemons are 64bit? The only real practical scaling use case I am aware of in the range of 5M routes today is for vpnv4 route reflectors. Another possible scaling point would be

Re: [j-nsp] 32-Bit JunOS on the 64-Bit Routing Engines

Hi Thomas, I agree with your reasoning - it is very practical :) However I am not sure what you exactly call by software. AFAIK the BSD kernel has been 64 bit enabled and capable years ago so from that point of view this is mature. For a change various processes for example RPD last time I

Re: [j-nsp] load balancing in Route reflector scenario

Hi Harry, default, differences in route preference cause a JUNI to prefer an IGP route while ios prefer the bgp routs over IGP. Let's make a clear distinction between preferring eBGP route versus iBGP route. Talking CSCO here eBGP admin distance is as you say 20 while iBGP as even the URL

Re: [j-nsp] load balancing in Route reflector scenario

Hi Keegan, Nope ... there can be other producers of the same route (OSPF, ISIS, STATIC) which will be in the RIB. If not there is always next step - less specific route to be used. I suppose there's a use for this or the feature wouldn't exist, but why would you have a route in the

Re: [j-nsp] load balancing in Route reflector scenario

Hi Keegan, I thought advertise inactive just configured the routers to advertise the entire BGP RIB instead of only advertising the routes in the routing-table. Nope. BGP advertises by default single best path. Any subsequent advertisement will be an implicit withdraw. Hi Humair, Per RR

Re: [j-nsp] load balancing in Route reflector scenario

Hi Keegan, I think the advertise inactive knob turns that off, but I don't know for sure because I've never tried it. I know it's not supported on cisco routers. The reason for it is the size of the BGP table. So if the table is 400k routes and you have 5 different ISP's and you advertise

Re: [j-nsp] load balancing in Route reflector scenario

Hi Keegan, By default Junos and IOS-XR advertise only those best path in BGP which actually are installed into forwarding. Advertising inactive knob will overwrite it. Wouldn't this lead to traffic being blackholed? If all the routes for a given destination are inactive would this

Re: [j-nsp] DOS attack?

Hi Matthias, I wonder now, which is the event, that triggered this behavious? The numer of ssh-logins at that time or this zbexpected EOF? I would with good deal of assurance conclude that the cause were ssh-login attack which apparently starved the poor box to it's memory limits. When

Re: [j-nsp] MPLS Route Distinguisher Question

Hi William, The Route distinguisher is the VPN instance identifier correct? Incorrect. The only function of RD is to make the routes unique. It has no meaning beyond it. The reason is that between VPNs you may have overlapping address space and if so vpnv4 would get mixed up in the

Re: [j-nsp] EX4200 9.4R2.9 process crash on previously valid config

Hi Richard, Honestly, I think you should just give up now and accept the fact that Juniper is the new Cisco. Excuse me ? Cisco in vast majority of new products is way much better now. Yes historically there was an issue with IOS, but AFAIK that has been also fixed now. * Look at highly