Errata
>So your BGP route will not be inactive because of the unreachable
next-hop.
So your BGP route *will be* inactive because of the unreachable next-hop.
On Sun, Jul 22, 2018 at 11:52 PM, Pavel Lunin wrote:
>
>
> On Sun, Jul 22, 2018 at 9:45 PM, Andrey Kostin wrote:
&
> Looks like it's all documented except next-hop conversion...
>
It's RFC4798 which prescribes to do so. Juniper/Cisco docs mention this
behavior briefly (google://bgp ipv4 ipv6 mapped ) but they consider it
part of BGP itself, not specific to implementation / configuration, so not
their job t
> > in a virtual chassis you could add:
> >
> > set virtual-chassis no-split-detection
> >
> > This will ensure that if both VC ports go down, the master routing
> engine carries on working.
>
> Are you referring to "Scenario B" in
> https://kb.juniper.net/InfoCenter/index?page=content&id=KB13879 ?
--> so then in a 2node VC one node is Master one node is backup
> If they split the master will go down but the backup should survive as it
> is
> still half of the original cluster
>
> So this means you should make the part you want to survive to be the
> backup-RE and not the master-RE
>
> --- or
To troubleshoot this kind of condition, you need to understand 1) the
complete structure of the headers (is there any tunneling, MPLS,
pseudowires etc) 2) what kind of forwarding decision your MX performs for
those packets: IP LPM only, Ethernet switching, IP + Ethernet (irb-based
L3), MPLS, MPLS+I
>
>
> But if I'm honest, I don't put a lot of stock in this. If you remember,
> this was Juniper's line back in the day, "One Junos to rule them all".
> Well, things obviously took another turn when they introduced the MX and
> EX platforms around 2007/2008.
>
Moreover, as we've discussed a few we
>
>
>
> > Not sure, but from the first glance it doesn't look like they've
> > gained
> > more than they've lost with the JunosE to JUNOS BNG migration.
>
> I didn't miss JunosE any single day after we finished migration to MX.
> MX platform is not ideal and has it's own quirks but I doubt that ide
Antti Ristimäki wrote:
So, now that more and more of us are automating their network, there will
> be the question about how to manage the configurations, if they are
> partially automated and partially manually maintained.
>
...
One option is to generate the whole config [...]
>
...
Another o
In stateless mode — as much as the cpus and ram can accommodate.
Performance and scaling should be somewhat near the IP packet-mode numbers,
and most major features are there.
In stateful mode — zero, if I didn't miss something.
пт, 24 авг. 2018 г., 16:31 Alain Hebert :
> Curious to know.
>
y wondering if I could use a Juniper SRX firewall in its purest
> firewall form, I think known as stateful mode, with MPLS encapsulation and
> services terminating directly inside of the SRX
>
> Let me know , thanks
>
> Aaron
>
> > On Aug 24, 2018, at 10:12 AM, Pavel L
Hey,
The Q-in-Q encapsulation comes from the EX2300 switches to the QFX switches
> (the S-VLAN Q-in-Q tag is also 1001), but on the other end of the tunnel we
> don't have the Q-in-Q frames coming.
>
I am curious if the packets don't leave the ingress VTEP at all or the
tail-end VTEP can't treat
Hi,
If memory serves, MPC2-NG is much like MPC3-NG: one MPC5-like PFE inside. A
good question is what is the difference between the MPC2-NG and MPC3-NG...
I'll let the astute readers figure it out on their own.
Old MPC2 non-NG is the "first generation Trio"-based card: two PFE, one per
MIC. There
Andrey Kostin wrote:
>
> HQoS is needed for subscriber aggregation, exactly for the case that is
> discussed in another thread "Juniper buffer float".
This is how Juniper and other vendors present it. But it's very
questionable if you really need a dedicated set of queues per subscriber
interfa
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 name for it.
Not that I don't like EVPN but... a) EVPN is not necessarily L2 b)
Hi all,
> Would you advise avoiding bandwidth-based metrics in e.g. datacenter
> or campus networks as well?
>
> (I am myself running a mostly DC network, with a little bit of campus
> network on the side, and we use bandwidth-based metrics in our OSPF.
> But we have standardized on using 3 Tb
Hi list,
It's been long time I didn't write here :)
Does anyone know in details how sampling-rate works (if it does) for inline
IPFIX on MX/Trio?
AFAIR sampling rate config hadn't had any meaning for inline IPFIX until
some version of JUNOS. It used to be always 1, no matter what you have in
the
2017-07-25 21:41 GMT+02:00 Scott Granados :
> I can confirm the rate=1 regardless of behavior up through 13.2 up through
> the PFE programming blocked by flow PR when that bug was addressed.
>
To be honest I didn't understand. You mean, the famous "rate is always 1
regardless of confing" is in fa
Aaron, just open "MPLS Enabled Applications" or/and "MPLS in the SDN era".
Both are fantastic books. It's all there :)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
+1 to Saku.
This means your egress PFE, identified by FPC and ICHIP(),
receives corrupted cells from the fabric. It might be caused by ingress PFE
or fabric chips or even backplane lines.
In this case you see it on different fabric streams, so it means that this
is not caused by a single faulty
> I raised the same point to Joerg in another forum and suggested JTAC,
> if I had to venture a guess, perhaps PFE_ID 128 is actually RE
> injected packet?
>
>
I though of this, but it shouldn't come through the fabric.
JTAC is always an option but, as it is I-chip, it might be not supported.
And…
BTW, I personally think that even aggregate routes bring more headache than
benefits, let alone generate.
Classic case is using aggregate to generate your own public prefixes and at
the same time having a loopback address out of this range. Or a static
route. Or a connected subnet. Theoretically y
Not sure this is specifically related to the OP but there is a known
hardware limitation/feature of some Broadcom chips used in many EX switches
of the previous generations (including EX4500). They use a hash table to
reduce MAC lookup length, which was too small in some older JUNOS versions,
leadi
Not sure this is specifically related to the OP but there is a known
> hardware limitation/feature of some Broadcom chips used in many EX switches
> of the previous generations (including EX4500).
>
As some you have already pointed out off-list, it's Marvell, of course, not
Broadcom )
Try to add no-control-world under your l2circuit/neighbor/interface config
on both sides (as well the VLAN push/pop on the ACX side).
2017-08-23 15:16 GMT+02:00 Jay Hanke :
> No luck. Here is the config I tried
>
> unit 517 {
> encapsulation vlan-ccc;
> vlan-id 517;
> input-vlan-map p
ntrol world.
23 авг. 2017 г. 11:16 PM пользователь "Jay Hanke"
написал:
> Setting the control word worked right away. Is the issue lack of
> support of the control word on one of the sides?
>
> On Wed, Aug 23, 2017 at 8:49 AM, Pavel Lunin wrote:
> >
> >
> &g
VRs on a basic enterprise access switch? You guys are really crazy.
"Gustav Ulander" :
Yea lets make the customers job harder partly by not supporting old
features in the next incarnation of the platform (think VRF support) . Also
lets not make them work the same so that the customer must relearn
“lets remove a feature and
> not replace it with something similar” that gets me. It shows a lack of
> commitment to ones customers.
>
> To be honest perhaps Juniper shouldn’t have added VRF support on the 2200s
> at all and just point to 3300s or SRX line.
>
>
>
> /
Hi Aaron,
Yes, I had a customer with 2× MS-MICs in an MX104 in production. No major
issues with this so far.
They use nor ams neither rsp, just old-good per source IP FBF with bit
masks like this:
from source address 10.0.0.0/255.0.0.1 then routing-instance CGN-1 /*
10.x.x.a, a is even */
from s
I really doubt that it's supported on QFX5100. Not 100% sure though.
But what's your problem? It does not work in this combination or does not
work at all?
IIRC, ex4600/qfx5100 do not support control word on pseudowires as well
(like ex4500/4550). So if you have something like an MX on the other
Strongly agree with Ytti. Most LSYS deployments I've seen were really
"deploy an LSYS to deploy an LSYS" kind of of thing.
Some more or less viable use-case I know is BGP scaling: dedicated rpd in
an LSYS for an off-path RR. It creates a dedicated 32-bit rpd, which can
consume another 4GB of RAM.
The command you are looking for is called "show interfaces diagnostics
optics".
2017-10-04 21:20 GMT+02:00 Aaron Gould :
> I put this into my ACX5048 in the lab today. actually 2 of them.
> QSFP+-40G-ER4 (aka QSFPP-40GBASE-ER4) SMF 40 km 1310 nm optic
>
>
>
> Optic is seen in cli, but I see no le
2017-10-05 1:00 GMT+02:00 Aaron Gould :
> Thanks Pavel, Ok here it is. Does this mean it should work ?
>
>
>
> Lane 0
>
> Laser bias current: 32.187 mA
>
> Laser output power: 1.135 mW / 0.55 dBm
>
> Laser receiver power
No TE, no problem. Extreme knows how to do it reeeally wrong :) At least,
last time I checked.
But yes, at the basic level it works. Adjacency, LSAs etc.
20 окт. 2017 г. 6:39 ПП пользователь написал:
> I had a hard time passing IS-IS thru Extreme Switch, give up after
> 5m and used OSPF fo
Reference bandwidth might however be useful for lags, when you may want to
lower the cost of a link if some members go down (though I prefer ECMP in
the core for most cases).
And you can combine the role/latency approach with automatic reference
bandwidth-based cost, if you configure 'bandwidth' p
In fact, the ring is "required" for each type of links: 32/40g stacking
ports, xe and ge separately.
This comes from the underlying ISIS LFA aka VC fast reroute feature. Two
alternative routes are installed into the FIB for each destination, if one
link fails, the corresponding route is withdrawn
u cannot commercially promise, you need
> strategic TE to move traffic on next-best-path when SPT is full.
>
>
> On 25 October 2017 at 23:25, Pavel Lunin wrote:
> > Reference bandwidth might however be useful for lags, when you may want
> to
> > lower the cost of a link if so
There were two versions of MPC3:
1. MPC3 non-NG, which has a single XM buffer manager and four LU chips (the
old good ~65 Mpps LUs as in "classic" MPC1/2/16XGE old trio PFEs).
2. MPC3-NG which is based on exactly the same chipset as MPC5, based on
XM+XL.
MPC4 is much like MPC3 non-NG though it ha
d XL-based
cards in the same box, your FIB is limited by the "lowest common
denominator".
2017-11-01 17:07 GMT+01:00 Pavel Lunin :
>
>
> There were two versions of MPC3:
>
> 1. MPC3 non-NG, which has a single XM buffer manager and four LU chips
> (the old good ~65 Mpps LUs
Is there anyone who can give more details about the enhanced midplane?
>
It's just more lines (wires) to provide more fabric bandwidth per-slot/PFE.
And maybe more power as well, I am not sure though.
It's been shipping for ages (since 2012 or something like). It had been
supposed to be required
Is this true about MX960? Does it have a midplane also ?
>
>
Yes though particular numbers might be different. MX960 has less backplane
capacity per slot / pfe than MX480.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/m
Yes, it's generally like that with all the absurd licenses on the low-end
> MX. Look at the price of an MX80, then look at the price of an MX5,
> upgraded gradually to an MX80 over time. Pay as you grow, indeed. It's
> actually cheaper to buy multiple other vendor routers entirely than to pay
> the
Not that brand new. MPC7-like, which has been around for quite some time.
What should be completely new in this box is the fabric.
The main gotcha is that they are still not shipping it. Same for mx204.
Respectively no software is available publicly for these platforms yet.
It means that you'll
Here (VPNv4/v6, BGP PIC Core + PIC Edge, no addpath as not supported in vpn
> AFI) we can see that, when possible:
>
No need for add-path in a VRF in fact. You always had it "for free" with
per PE route-distinguishers.
___
juniper-nsp mailing list junip
201 - 243 of 243 matches
Mail list logo
