> > William Herrin wrote:
Until they tamper with it using localpref, BGP's default behavior with prepends
does exactly the right thing, at least in my situation.
I feel your pain Bill, but from a slightly different angle. For years the
large CDNs have been disregarding prepends. When a
Junos doesn't maintain an intermediate BGP table / RIB as you would see on
other Cisco-like platforms. Therefore you need to build comm-string actions
into your neighborship policies.
JTAC says we must disable a physical port to allocate BW for tunnel-services.
Also leaving tunnel-services bandwidth unspecified is not possible on the 204.
I haven't independently tested / validated in lab yet, but this is what they
have told me. I advised JTAC to update the MX204
-Original Message-
From: Delong.com
Sent: Monday, October 2, 2023 5:47 PM
To: behrnsj...@yahoo.com
Cc: nanog@nanog.org
Subject: Re: MX204 tunnel services BW
> “Tunnel gets whatever bandwidth is left after physical port packets are
> processed” and likely some additional overhead for
Encountered an issue with an MX204 using all 4x100G ports and a logical
tunnel to hairpin a VRF. The tunnel started dropping packets around 8Gbps.
I bumped up tunnel-services BW from 10G to 100G which made the problem
worse; the tunnel was now limited to around 1.3Gbps. To my knowledge with
Trio
Lumen / Level3 filtergen is trimming these routes now. Don't bother trying
to query filtergen.level3.net currently; server is full. Small AS cone does
not equal small societal footprint & impact. While I appreciate the
intention upthread of proxy registering at ATLDB, it really just distracted
6 matches
Mail list logo
