I'm looking for an equivalent of 'then metric igp' that would actually
work in a BGP import policy, specifically such that the resulting MEDs
would be redistributed to iBGP neighbors. 'path-selection med-plus-igp'
seems to be purely local, and 'then metric igp' is explicitly documented
as
According to the release notes for 11.4R8, the KRT queue stall issue
(PR836197) has been marked as resolved. Has anyone had a chance to
confirm this on a suitably session-heavy MX?
-Rob
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
Hey folks,
Another OSPF issue for the day: I have a somewhat specific need to match a
route from a particular OSPF speaker in an aggregate policy, and I'm not
having much luck coming up with a straightforward way to do so.
The route in question is injected via a type 5 LSA from a (dumb)
On Thu, 26 Sep 2013, Phil Fagan wrote:
Is your aggregate policy already on the MX and is its purpose to export into
BGP from OSPF?
That's the idea... There are disparate contributing routes, and they tend
to come and go on a fairly regular basis. Generating like aggregates
elsewhere and
On Fri, 27 Sep 2013, Phil Fagan wrote:
could you use BGP multi-hop and simply peer directly to the MX bypassing the
need to redist routes in though your OSPF core?
That's basically what I'm considering from the perspective of
readvertising into BGP on the ABR... The source is going to be
A quick question: how are folks handling RSVP path messages in loopback
firewall filters, particularly on MX? prefix-lists covering all RSVP
speakers? Explicit IP options match? Ignoring them entirely and hoping
the policer on a default accept term won't step on them too hard? ;)
Thanks,
On Thu, 15 Jan 2015, Mark Tees wrote:
For me on an MX80 running 11.4R13 with samlping that 10 minute equates to:
- around 3mins of rpd + sampling taking turns to smash the routing
engine CPU whilst seeming allowing other things to still be scheduled
in (phew).
- another 7mins of sampling
Does anyone have any clever methods for probing Enhanced Layer 2 Software
support from a commit script on QFX/EX in order to generate changes
appropriate to the platform? Specifically looking for something beyond
checking hardware and version numbers, or for pieces of config hierarchy
that
On Tue, 13 Sep 2016, Chuck Anderson wrote:
Could you just use a strict MPLS path with an ERO?
Hmm, doesn't look like it... I just tried configuring an explicit path
LSP to nowhere on a lab box, and it didn't install anything into the
routing table without the LSP up. Either way, a strict
On Tue, 13 Sep 2016, Chuck Anderson wrote:
I guess I don't understand what you are trying to accomplish then.
Ttaffic engineering specific routes is exactly what RSVP is used for.
The MPLS path should be torn down if there is no available
RSVP-capable route. Did you try just not configuring
Assuming a typical IBGP session built between loopbacks, is there any
relatively clean way to tie that session state to RSVP-signaled LSPs
between the same pair of routers?
I'm trying to work around a case where the IGP knows about another path
between the two that doesn't carry any MPLS
On Wed, 8 Jun 2016, Phil Mayers wrote:
On 07/06/16 21:51, Rob Foehl wrote:
Does anyone have any clever methods for probing Enhanced Layer 2
Software support from a commit script on QFX/EX in order to generate
changes appropriate to the platform? Specifically looking for something
beyond
For the Juniper engineering folks on the list:
PR1097749 was opened in June 2015 concerning a default-address-selection
regression in 12.1 and later releases, which was eventually fixed on SRX,
but we're still running into it on EX in certain circumstances.
The PR remains non-public, and
On Mon, 21 May 2018, Chris Kawchuk wrote:
Your dates are all over the place
May 19, then Jun 14, then back to May 19th...
That's what happens when a card boots, before it figures out the current
time... Why the RE accepts logs like this at face value is another
question, but this
On Fri, 29 Jun 2018, Mark Tinka wrote:
I prefer not to find out whether walking on hot coal will kill all
feeling in my feet, or just numb them for 2hrs :-).
So... Is that a vote for or against, and which one? ;)
On Fri, 29 Jun 2018, Job Snijders wrote:
For the purpose of inter-domain
On Wed, 27 Jun 2018, Mark Tinka wrote:
At this stage, I'd say the cheapest MX router you should go for that is
decent is the MX204.
Any thoughts on MX204s replacing ancient MX240s, assuming one can make the
interface mix work?
I'm looking at the replacement option vs. in-place upgrades of
On Fri, 29 Jun 2018, Rob Foehl wrote:
I may have been insufficiently specific... I'm referring to:
group example {
neighbor 192.0.2.0;
neighbor 2001:db8::;
}
vs.
group example-ipv4 {
neighbor 192.0.2.0;
}
group example-ipv6 {
neighbor 2001:db8::;
}
Hey folks
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 next hop to v6 mapped v4 address and using
native v6 NHs instead please?
I'd asked a similar question as the OP two
On Wed, 4 Apr 2018, Aaron Gould wrote:
Any idea why this happened and how do I tshoot cause ?
login: root
Password:SysRq : Trigger a crash
Looks like you're running a RE-S-X6-64G, and somehow sent it SysRq c --
which is a break followed by c within 5 seconds on a serial console -- and
Wondering aloud a bit... I've seen plenty of cases where wedging parallel
v4/v6 sessions into the same BGP group and letting the router sort out
which AFI it's supposed to be using on each session works fine, and nearly
as many where configuring anything family-specific starts to get ugly
On Wed, 27 Jun 2018, Mark Tinka wrote:
But to your question, there is nothing ancient about the MX240. It's just
small. Look at your future needs and consider whether having those 2 line
card slots running the latest-generation Trio chip will scale better than
migrating to the MX204, and that
On Thu, 27 Sep 2018, Karl Gerhard wrote:
thanks for sharing, seems like all Junos versions above 17.3R3 are affected.
I'd been hoping this was specific to 18.x, but no such luck. We'd just
settled on 17.4 in large part due to the number of times we've heard that
it's received "extra QA",
On Mon, 10 Sep 2018, Ivan Malyarchuk wrote:
Hi. We also find something wrong with "protect core".
Seems like Junos 18.1 and 18.2 (running on MX204 in our case) makes one
#Multipath equal-cost group with ALL paths except one worst AND one with worst
path - as backup.
I think it must create
On Fri, 22 Mar 2019, Vincent Bernat wrote:
❦ 22 mars 2019 13:39 -04, Rob Foehl :
I've got a few really large layer 2 domains that I'm looking to start
breaking up and stitching back together with EVPN+VXLAN in the middle,
on the order of a few thousand VLANs apiece. Trying to plan around
any
On Fri, 22 Mar 2019, Sebastian Wiesinger wrote:
What did bother us was that you are limited (at least on QFX5100) in
the amount of "VLANs" (VNIs). We were testing with 30 client
full-trunk ports per leaf and with that amount you can only provision
around 500 VLANs before you get errors and
I've been experimenting with EVPN all-active multihoming toward some large
legacy layer 2 domains, and running into some fairly bizarre behavior...
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
On Thu, 18 Apr 2019, Krzysztof Szarkowicz wrote:
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
On Thu, 18 Apr 2019, Wojciech Janiszewski wrote:
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.
If you need two physical connections to between those networks, then LAG is
a way to go.
On Tue, 7 May 2019, Nathan Ward wrote:
Is it actually coming back? Hard to believe the “technical issue” given how
long it’s been, seems like a pretty big systemic issue rather than a technical
one. “Actively worked on” seems pretty inactive, to me.
Maybe it runs on Space, and they're just
I'll preface this by saying that the MX204 is a great box, and fits many a
niche quite well... However:
On Fri, 8 Nov 2019, Clarke Morledge wrote:
My understanding is that the MX204 is a 1 RU MPC7, but with a few
modifications.
More or less -- it's an RE glued to the non-fabric-facing
On Fri, 18 Oct 2019, Gert Doering wrote:
On Thu, Oct 17, 2019 at 05:37:16PM -0400, Rob Foehl wrote:
Is EVPN expected to be forwarding BPDUs at all, intact or otherwise?
The way understand "how things are meant to be plugged together", you
should not see forwarded BPDUs - "co
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. I'm... not convinced.
Plot twist: the BPDUs in question turned out
On Fri, 18 Oct 2019, Gert Doering wrote:
On Fri, Oct 18, 2019 at 01:37:21PM +0200, Daniel Verlouw wrote:
On Fri, Oct 18, 2019 at 11:45 AM Gert Doering wrote:
If yes, is this something people do over EVPN?
as an extension to 'plain' EVPN, yes. It's called EVPN-VPWS, RFC 8214.
Basically EVPN
Seeing something "interesting" after an 18.1R3 to 18.4R1 upgrade on some
EVPN PEs: the 18.4 boxes are now emitting BPDUs toward the CE interfaces
containing pre-translation VLAN IDs from the CEs attached to remote PEs,
which as far as I can tell are originating from the remote CE.
Is EVPN
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
...and a need to deliver various EVPN services to access ports on the EX,
On Sun, 10 Nov 2019, Saku Ytti wrote:
More or less -- it's an RE glued to the non-fabric-facing parts of the
MPC7, which tends to tickle some "interesting" corner cases in code that
assumes there's a fabric chip present.
I don't think RE connects atypically in MX204. RE is ETH+PCI
connected,
On Wed, 22 Jan 2020, Giuliano C. Medalha wrote:
TE / TE++ and auto-bandwidth
Still broken? Been hearing excuses about why these don't work on merchant
silicon boxes since the EX3200...
-Rob
___
juniper-nsp mailing list
On Wed, 22 Jan 2020, Saku Ytti wrote:
On Wed, 22 Jan 2020 at 11:48, Rob Foehl wrote:
TE / TE++ and auto-bandwidth
Still broken? Been hearing excuses about why these don't work on merchant
silicon boxes since the EX3200...
Excuses seems strong word, it implies you know what merchant
I'll preface this by saying I don't have anything constructive to add...
On Fri, 28 Aug 2020, Nathan Ward wrote:
I’ve tried JTAC on this, twice. First on 16.1, and again now on 19.4. Both
times JTAC have either not understood and stalled for months and refused to
escalate to someone who does
On Tue, 28 Jul 2020, Jeffrey Haas wrote:
- "show bgp output-scheduler" is empty without top-level "protocols bgp
output-queue-priority" config, regardless of anything else
- Top-level "protocols bgp family evpn signaling" priority config -- and
nothing else within that stanza -- broke every
Anyone know the secret to getting BGP output queue priorities working
across multiple NLRIs?
Had trouble with EVPN routes getting stuck behind full refreshes of the v4
RIB, often for minutes at a time, which causes havoc with the default DF
election hold timer of 3 seconds. Bumping those
On Mon, 9 Nov 2020, Jeffrey Haas wrote:
As the source of this particular bit of difficulty, a bit of explanation for
why it simply wasn't done when the initial feature was authored.
Much appreciated -- the explanation, anyway ;)
An immense amount of work in the BGP code is built around the
On Tue, 10 Nov 2020, Gert Doering wrote:
Can you do the EVPN routes on a separate session (different loopback on
both ends, dedicated to EVPN-afi-only BGP)? Or separate RRs?
Yes, this is not what you're asking, just a wild idea to make life
better :-)
Not that wild -- I've already been
On Tue, 10 Nov 2020, Robert Raszuk wrote:
But what seems wired is last statement:
"This has problems with blackholing traffic for long periods in several
cases,..."
We as the industry have solved this problem many years ago, by clearly
decoupling connectivity restoration term from protocol
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 dispatched accordingly.
Right, that turns out to be the essential
On Mon, 27 Jul 2020, Rob Foehl wrote:
Anyone know the secret to getting BGP output queue priorities working across
multiple NLRIs?
[...]
I've tried about a dozen combinations of options, and cannot get any other
result with inet/evpn routes in the same session -- inet.0 routes always
arrive
On Sat, 6 Feb 2021, Robert Huey wrote:
Have you looked into IGP Overload? I think it will do the trick without ever
getting into TE constraints.
In this case, it's OSPF, so overload is just max metric. The path metric
already exceeds any other through the network under ordinary
Possibly-missing-something-obvious question: are there any less-involved
alternatives to link coloring to preclude RSVP from signaling LSPs through
specific nodes?
I've got some traffic occasionally wandering off where it shouldn't be --
mostly due to bypass LSPs landing on some "temporary"
On Tue, 2024-01-09 at 10:55 +0200, Saku Ytti via juniper-nsp wrote:
> What do we think of HPE acquiring JNPR?
I'm just hoping the port checker gets updated to show which slots will
accept a fresh magenta cartridge in order to bring BGP back up...
(Just kidding -- but only because it's the wrong
49 matches
Mail list logo
