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,
>
>
>
> > 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
>
>
> 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
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.
dering 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 Lunin
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
In this setup it's not 6PE but just classic IP over MPLS, where vanilla
inet/inet6 iBGP resolves it's protocol next-hop with a labeled LDP/RSVP
forwarding next hop.
It works much the same way for v6 as for v4, except that the v6 header is
exposed to the last P router, when it performs PHP. It
Richard McGovern :
> Felt need to jump in here, and hopefully get some of the real facts
> straight. Prior to ELS CLI Juniper had basically 2 different CLI’s – one
> for EX Products and branch SRX one for MX and a like. M/MX CLI came first
> and used the terminology IRB and Bridge Domains.
> Richard McGovern :
>
> I am not sure that the MX logic is from the 1990s. It should be first
>> released with the MX in... was it 2006 or 2007? While the first EX came
>> around in 2008. Not that big gap between the two.
>>
>
>
> ð First came M before MX in mid-90s, I believe.
>
I might be
Mark Tinka :
>
>
> On 12/Jul/18 23:07, Pavel Lunin wrote:
>
> That's normal. Government and financial sectors always use the most
> outdated solutions because of bureaucracy, compliance, certifications and
> all those WTF reasons :)
>
>
> Probably with a big fat vend
On Sun, Jul 22, 2018 at 9:45 PM, Andrey Kostin wrote:
> Hi Pavel,
>
> Thanks for replying. I understand how it works as soon as proper next-hop
> is present in a route. My attention was attracted by implicit next-hop
> conversion from pure IPv4 address to IPv4-mapped IPv6 next-hop from
>
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:
&
amor...@orion.amorsen.dk wrote:
>Maintaining scripts is a bit of a pain.
It's not maintaining scripts which is a bit of pain. It's on-box automaton
which is hell a lot of pain and there is very little reason to use it
nowadays. At least at any larger scale than a SOHO gateway for ten users,
doing
> 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
On Tue, Jul 17, 2018 at 10:52 AM, Mark Tinka wrote:
>
> Or because they just don't want to bother with the new Junos switching CLI
> for Broadcom-based models ;)
>
>
> Well, looks like Juniper are horny for that moving forward, so the only
> solution there is to move to another vendor :-).
>
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
On Tue, Jul 10, 2018 at 2:32 AM, Aaron Gould wrote:
> My entire Ethernet cellular backhaul architecture is based an a pair of
> pseudowires per cell tower. We are making money off of pw's.
>
>
Yep, mobile backhaul is a classic example. But it's also a case when
business model permits the
We run MPLS all the way into the access, on ASR920's. So pw's are
> end-to-end, and the Provisioning/NOC teams only need to look at the end
> boxes. I found the whole idea of centralized "gateways" in the core to be a
> bit clunky.
>
I have no doubt that you know how to run MPLS in the access
On Thu, Jul 12, 2018 at 7:19 PM, Aaron Gould wrote:
> I hear some chatter about systems getting old and incapable and allegedly
> being end of life or end of serviced... I just saw these links, dated July
> 10, 2018 so very recent, they mentioned how this company is using these two
> platforms
Btw, it's a very good question if anyone here has more or less close to
real-world experience with L3 gw and evpn type 5 routes on QFX5110 or maybe
any other trident 2+ based box.
Would much appreciate your input.
Regards,
Pavel
July 3, 2018, 18:48 Roger Wiklund :
> Hi Scott
>
> Should be fine
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
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.
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
201 - 224 of 224 matches
Mail list logo
