a
> virtual or real physical router.
>
> - Jared
>
> On Sun, Jul 07, 2024 at 11:07:48AM +0300, Saku Ytti via juniper-nsp wrote:
> > For things like TAC use, what I've previously done is made a vendor
> > shell, where the shell program is screen instead of
For things like TAC use, what I've previously done is made a vendor
shell, where the shell program is screen instead of shell, and screen
is set up to log.
On Sat, 6 Jul 2024 at 16:50, Job Snijders wrote:
>
> Perhaps it’s just about wanting to keep track “what happened?!?”
>
> For such a
I don't believe there is any supported way to do this, an unsupported
way, probably, but also probably an educated operator could circumvent
it anyhow.
You probably shouldn't allow untrusted users to access the shell.
On Sat, 6 Jul 2024 at 09:26, Phil Mawson via juniper-nsp
wrote:
>
> Hi,
>
>
On Wed, 19 Jun 2024 at 20:35, heasley wrote:
> And enemy of security is lack of effort? Current BMCs would be
> a step backward, imiho. I wish they were better; a lot of
> potential..
What is the benchmark? Is benchmark NOS fate-sharing control-plane
ethernet? Or RS232? How do they outperform
On Tue, 18 Jun 2024 at 21:23, heasley wrote:
> Yes, do that, please, but that does not really address the security
> problems. BMCs typically are not updated by their owners, s/w updates
> for them are rarely offered by the vendor, usually have limited filtering
> & security capabilities, and
On Tue, 18 Jun 2024 at 18:56, Jason Iannone via juniper-nsp
wrote:
> I suppose the root question is do I have to apply a management filter on my
> transit interfaces for in-band management traffic? Does ACX have a new (not
> fxp1) relationship between the RE and the external re0:mgmt-0/em0/fxp0
On Mon, 3 Jun 2024 at 05:26, Gustavo Santos via juniper-nsp
wrote:
> We will try it again later this year. If update threading / rib-sharding
> works as expected it will be better than having non stop routing running.
I think you need to contact support and work with them, NOS SW quality
is
On Fri, 17 May 2024 at 10:36, Antti Ristimäki wrote:
> iACL design becomes a bit more challenging if you want to keep the
> link-local things link local (e.g. there are legit ND packets with
> link-local srcaddr and GUA dstaddr). It is doable, though.
Not disagreeing, but what are these
On Thu, 16 May 2024 at 21:23, Antti Ristimäki via juniper-nsp
wrote:
> Does anyone have any insight into this? This issue was discussed on
> this list already over 10 years ago, for example:
> https://puck.nether.net/pipermail/juniper-nsp/2012-April/023134.html
Personally I'm not convinced I'd
How IP options work is platform specific.
It used to be that _transited_ IP-options were not subject to the lo0
filter, while still being risk for RE, so you'd implement
forwarding-filter, where you'd police IP-options or drop out right.
In more recent junipers, this behaviour has been changed
On Mon, 29 Apr 2024 at 10:13, Mark Tinka via juniper-nsp
wrote:
> It comes down to how you classify stable (well-behaved) vs. unstable
> (misbehaving) interfaces.
You are making this unnecessarily complicated.
You could simply configure that first down event doesn't add enough
points to damp,
On Mon, 29 Apr 2024 at 10:07, Gert Doering via juniper-nsp
wrote:
> The interesting question is "how to react when underlay seems to be stable
> again"? "bring up upper layers right away, with exponential decay flap
> dampening" or "always wait 15 minutes to be SURE it's stable!!!"...
100%,
On Sun, 28 Apr 2024 at 21:20, Jeff Haas via juniper-nsp
wrote:
> BFD holddown is the right feature for this.
> WARNING: BFD holddown is known to be problematic between Juniper and Cisco
> implementations due to where each start their state machines for BFD vs. BGP.
>
> It was a partial
Some comments from quick read of just IPv4.
- I don't like the level of abstraction, seems it just ensures no one
will bother reading it up and reuse of the filters and terms wont
happen anyhow. It feels like first time learning OO language, and
making everything modular, while adding overhead
On Sat, 27 Apr 2024 at 14:29, Rolf Hanßen via juniper-nsp
wrote:
> at least for link flapping issues (but not other session flapping reasons)
> you could set the hold-time:
> set interfaces xy hold-time up 30
Since Junos 14.1 it has caught up with Cisco, and it has implemented
exponential
; import-rib [ inet.0 L3VPN-4205.inet.0 ];
> }
> ...
> rib-interface-routes-v6 {
> import-rib [ inet6.0 L3VPN-4205.inet6.0 ];
> }
> ...
> }
>
> > -Original Message-
> > From: juniper-nsp On Behalf Of
> > Saku Ytti via juniper-
On Wed, 3 Apr 2024 at 09:45, Saku Ytti wrote:
> Actually I think I'm confused. I think it will just work. Because even
> as the EgressPE does IP lookup due to table-label, the IP lookup still
> points to egressMAC, instead looping back, because it's doing it in
> the CleanVRF.
> So I think it
On Wed, 3 Apr 2024 at 09:37, Mark Tinka via juniper-nsp
wrote:
> At old job, we managed to do this with a virtual-router VRF that carried
> traffic between the scrubbing PE and the egress PE via MPLS, to avoid
> the IP loop.
Actually I think I'm confused. I think it will just work. Because even
On Tue, 2 Apr 2024 at 18:25, Michael Hare via juniper-nsp
wrote:
> We're a US research and education ISP and we've been tasked for coming up
> with an architecture to allow on premise DDoS scrubbing with an appliance.
> As a first pass I've created an cleanL3VPN routing-instance to function
On Tue, 19 Mar 2024 at 19:44, Lee Starnes via juniper-nsp
wrote:
> The blackhole peer does receive the /32 announcement, but the aggregate
> route also becomes discarded and thus routes to the other peers stop
> working.
I couldn't follow this, and the output you shared didn't support it.
So it
On Thu, 7 Mar 2024 at 03:08, Lee Starnes via juniper-nsp
wrote:
> Any tips or help on the best practice implementation would be greatly
> appreciated.
While what you want obviously is possible to accomplish. Is it a thing
you actually need? I don't personally really see any need to ever
carry
On Mon, 12 Feb 2024 at 09:44, james list wrote:
> I'd like to test with LACP slow, then can see if physical interface still
> flaps...
I don't think that's good idea, like what would we know? Would we have
to wait 30 times longer, so month-3months, to hit what ever it is,
before we have
On Sun, 11 Feb 2024 at 17:52, james list wrote:
> - why physical interface flaps in DC1 if it is related to lacp ?
16:39:35.813 Juniper reports LACP timeout (so problem started at
16:39:32, (was traffic passing at 32, 33, 34 seconds?))
16:39:36.xxx Cisco reports interface down, long after
On Sun, 11 Feb 2024 at 15:24, james list wrote:
> While on Juniper when the issue happens I always see:
>
> show log messages | last 440 | match LACPD_TIMEOUT
> Jan 25 21:32:27.948 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp
> current while timer expired current Receive State: CURRENT
Hey James,
You shared this off-list, I think it's sufficiently material to share.
2024 Feb 9 16:39:36 NEXUS1
%ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface
port-channel101 is down (No operational members)
2024 Feb 9 16:39:36 NEXUS1 %ETH_PORT_CHANNEL-5-PORT_DOWN:
port-channel101:
I want to clarify, I meant this in the context of the original question.
That is, if you have a BGP specific problem, and no FCS errors, then
you can't have link problems.
But in this case, the problem is not BGP specific, in fact it has
nothing to do with BGP, since the problem begins on
I don't think any of these matter. You'd see FCS failure on any
link-related issue causing the BGP packet to drop.
If you're not seeing FCS failures, you can ignore all link related
problems in this case.
On Sun, 11 Feb 2024 at 14:13, Havard Eidnes via juniper-nsp
wrote:
>
> > DC technicians
On Sun, 11 Feb 2024 at 13:51, james list via juniper-nsp
wrote:
> One think I've omit to say is that BGP is over a LACP with currently just
> one interface 100 Gbs.
>
> I see that the issue is triggered on Cisco when eth interface seems to go
> in Initializing state:
Ok, so we can forget BGP
Open JTAC and CTAC cases.
The amount of information provided is wildly insufficient.
'BGP flaps' what does that mean, is it always the same direction? If
so, which direction thinks it's not seeing keepalives? Do you also
observe loss in 'ping' between the links during the period?
Purely
On Fri, 9 Feb 2024 at 17:50, Tom Beecher wrote:
> Completely fair, yes. My comments were mostly aimed at a vMX/cRPD comparison.
> I probably wasn't clear about that. Completely agree that it doesn't make
> much sense to move from an existing vRR to cRPD just because. For a
> greenfield thing
On Thu, 8 Feb 2024 at 17:11, Tom Beecher via juniper-nsp
wrote:
> For any use cases that you want protocol interaction, but not substantive
> traffic forwarding capabilities , cRPD is by far the better option.
No one is saying that cRPD isn't the future, just that there are a lot
of existing
On Thu, 8 Feb 2024 at 16:07, Mark Tinka via juniper-nsp
wrote:
> So internally, if it attracts any traffic for non-specific destinations,
> does Junos send it /dev/null in hardware? I'd guess so...
In absence of more specifics, junos by default doesn't discard but
reject. There is essentially
On Thu, 8 Feb 2024 at 10:16, Mark Tinka wrote:
> Is the MX150 still a current product? My understanding is it's an x86
> platform running vMX.
No longer orderable.
--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
On Thu, 8 Feb 2024 at 09:51, Roger Wiklund via juniper-nsp
wrote:
> I'm curious, when moving from vRR to cRPD, how do you plan to manage/setup
> the infrastructure that cRPD runs on?
Same concerns, I would just push it back and be a late adopter. Rock
existing vRR while supported, not pre-empt
On Tue, 6 Feb 2024 at 18:35, Mark Tinka wrote:
> IME, when we got all available paths, ORR was irrelevant.
>
> But yes, at the cost of some control plane resources.
Not just opinion, fact. If you see everything, ORR does nothing but adds cost.
You only need AddPath and ORR, when everything is
What do we think of HPE acquiring JNPR?
I guess it was given that something's gotta give, JNPR has lost to
dollar as an investment for more than 2 decades, which is not
sustainable in the way we model our economy.
Out of all possible outcomes:
- JNPR suddenly starts to grow (how?)
- JNPR
tsc...@digitalocean.com
>
>
> On Fri, Dec 8, 2023 at 11:57 AM Saku Ytti via juniper-nsp
> wrote:
>>
>> On Fri, 8 Dec 2023 at 18:42, Vincent Bernat via juniper-nsp
>> wrote:
>>
>> > On 2023-12-07 15:21, Michael Hare via juniper-nsp wrote:
>&g
On Fri, 8 Dec 2023 at 18:42, Vincent Bernat via juniper-nsp
wrote:
> On 2023-12-07 15:21, Michael Hare via juniper-nsp wrote:
> > I recognize Saku's recommendation of rib sharding is a practical one at 20M
> > routes, I'm curious if anyone is willing to admit to using it in production
> > and
On Thu, 7 Dec 2023 at 16:22, Michael Hare via juniper-nsp
wrote:
> I recognize Saku's recommendation of rib sharding is a practical one at 20M
> routes, I'm curious if anyone is willing to admit to using it in production
> and on what version of JunOS. I admit to have not played with this in
From a RPD, not cRPD perspective.
- 64GB is certainly fine, you might be able to do with 32GB
- Unless RRs are physically next to clients, you want to bump default
16kB TCP window to maximum 64kB window, and probably ask account team
for window scaling support (unsure if this is true for cRPD, or
On Thu, 9 Nov 2023 at 10:38, Chen Jiang via juniper-nsp
wrote:
> Just want to confirm if Juniper backup routing engine could authenticate
> users from in-band interface like ge-0/0/0 to the AAA server?
>
> If not, do we have a solution? The scenario is MX960 with dual RE and no
> OOB network.
On Thu, 26 Oct 2023 at 16:40, Mark Tinka via juniper-nsp
wrote:
> I'd suggest staying very close to our SE's for the desired outcome we
> want for this development. As we have seen before, Juniper appear
> reasonably open to operator feedback, but we would need to give it to
> them to begin
On Thu, 26 Oct 2023 at 07:45, Mark Tinka via juniper-nsp
wrote:
> While there are some women who enjoy engineering, and some men who enjoy
> nursing, most women don't enjoy engineering, and most men don't enjoy
> nursing. I think we would move much farther ahead if we accepted this,
> If you
On Wed, 25 Oct 2023 at 15:26, Aaron1 via juniper-nsp
wrote:
> Years ago I had to get a license to make my 10g interfaces work on my MX104
I think we need to be careful in what we are saying.
We can't reject licences out right, that's not a fair ask and it won't happen.
But we can reject
On Tue, 24 Oct 2023 at 22:21, Aaron Gould via juniper-nsp
wrote:
> My MX304 trial license expired last night, after rebooting the MX304,
> various protocols no longer work. This seems more than just
> honor-based... ospf, ldp, etc, no longer function. This is new to me;
> that Juniper is
On Wed, 27 Sept 2023 at 03:50, Barry Greene via juniper-nsp
wrote:
> Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP
> peering Sessions?
>
> I’m not touching routers right now. I’m wondering if anyone has deployed,
> your experiences, and thoughts?
For the longest time
On Sun, 16 Jul 2023 at 19:47, Tim Franklin via juniper-nsp
wrote:
> You missed the fun part where you have to explain *again* every few
> months to the CISO and their minions why you can't adhere to the
> written-by/for-Windows-admins "Patching Policy" that says everything in
> the company is
On Wed, 5 Jul 2023 at 04:45, Mark Tinka wrote:
> This is one of the reasons I prefer to use Ethernet switches to
> interconnect devices in large data centre deployments.
>
> Connecting stuff directly into the core routers or directly together
> eats up a bunch of ports, without necessarily using
On Tue, 4 Jul 2023 at 08:34, Mark Tinka wrote:
> Yes, I watched this NANOG session and was also quite surprised when they
> mentioned that they only plan for 25% usage of the deployed capacity.
> Are they giving themselves room to peak before they move to another chip
> (considering that they
On Sun, 2 Jul 2023 at 17:15, Mark Tinka wrote:
> Technically, do we not think that an oversubscribed Juniper box with a
> single Trio 6 chip with no fabric is feasible? And is it not being built
> because Juniper don't want to cannibalize their other distributed
> compact boxes?
>
> The MX204,
On Sun, 2 Jul 2023 at 15:53, Mark Tinka via juniper-nsp
wrote:
> Well, by your definition, the ASR9903, for example, is a distributed
> platform, which has a fabric ASIC via the RP, with 4x NPU's on the fixed
> line card, 2x NPU's on the 800Gbps PEC and 4x NPU's on the 2Tbps PEC.
Right as is
On Sun, 2 Jul 2023 at 12:11, Mark Tinka wrote:
> Well, for data centre aggregation, especially for 100Gbps transit ports
> to customers, centralized routers make sense (MX304, MX10003, ASR9903,
> e.t.c.). But those boxes don't make sense as Metro-E routers... they can
> aggregate Metro-E
On Sun, 2 Jul 2023 at 11:38, Mark Tinka wrote:
> So all the above sounds to me like scenarios where Metro-E rings are
> built on 802.1Q/Q-in-Q/REP/STP/e.t.c., rather than IP/MPLS.
Yes. Satellite is basically VLAN aggregation, but a little bit less
broken. Both are much inferior to MPLS. But
On Tue, 27 Jun 2023 at 19:47, Tarko Tikan via juniper-nsp
wrote:
> Single NPU doesn't mean non-redundant - those devices run two (or 4 in
> ACX case) BCM NPUs and switch "linecards" over to backup NPU when
> required. All without true fabric and distributed NPUs to keep the cost
> down.
This
On Tue, 27 Jun 2023 at 19:32, Mark Tinka wrote:
> > Yes.
>
> How?
Apart from obvious stuff like QoS getting difficult, not full feature
parity with VLAN and main interface, or counters becoming less useful
as many are port level so identifying true source port may not be
easy. There are things
On Tue, 27 Jun 2023 at 17:40, Mark Tinka wrote:
> Would that be high-density face-plate solutions for access aggregation
> in the data centre, that they are> Are you suggesting standard 802.1Q/Q-in-Q
> trunking from a switch into a
> "pricey" router line card that support locally-significant
On Tue, 27 Jun 2023 at 06:02, Mark Tinka via juniper-nsp
wrote:
> > Similar use case here but we use a QFX as a fusion satellite if port
> > expansion is required.
> > Works well as an small site start up option.
>
> Are vendors still pushing their satellite switches :-)?
>
> That technology
Do you monitor RPD task memory use and Freebsd process memory use?
Is it possible you are leaking memory over time, and getting DRAM
pressure at the 1500d mark?
It might be this:
https://prsearch.juniper.net/problemreport/PR108
Initially as you said it happens at strenuous SSD access, I was
Either will help, configure either or both and you're good.
Actual fixed release will behave the same as if drop-path-attribute 28
had been configured. That is read T, read L, seek past V, without
parsing.
On Sun, 11 Jun 2023 at 19:36, Einar Bjarni Halldórsson wrote:
>
> On 6/11/23 15:24, Saku
set protocols bgp drop-path-attributes 28 works if your release is too
old for set protocols bgp bgp-error-tolerance, and is preferable in
some ways, as it will protect your downstream as well.
On Sun, 11 Jun 2023 at 17:25, Einar Bjarni Halldórsson via juniper-nsp
wrote:
>
> Hi,
>
> We have two
On Fri, 9 Jun 2023 at 20:37, Andrey Kostin wrote:
> Sounds more like a datacenter setup, and for DC operator it could be
> attractive to do at scale. For a traditional ISP with relatively small
> PoPs spread across the country it may be not the case.
Sure, not suggesting everyone is in the
On Fri, 9 Jun 2023 at 19:15, Andrey Kostin wrote:
> Can anything else be inserted in this socket? If not, then what's the
> point? For server CPUs there are many models with different clocking and
> number of cores, so socket provides a flexibility. If there is only one
> chip that fits the
On Fri, 9 Jun 2023 at 18:46, Andrey Kostin wrote:
> I'm not in this market, have no qualification and resources for
> development. The demand in such devices should be really massive to
> justify a process like this.
Are you not? You use a lot of open source software, because someone
else did
On Fri, 9 Jun 2023 at 17:26, Mark Tinka wrote:
> Well, the story is that Cisco are doing this with Meta and Microsoft on
> their C8000 platform, and apparently, doing billions of US$ in business
> on the back of that.
I'm not convinced at all that leaba is being sold. I think it's sold
On Fri, 9 Jun 2023 at 16:58, Andrey Kostin via juniper-nsp
wrote:
> Not sure why it's eye-watering. The price of fully populated MX304 is
> basically the same as it's predecessor MX10003 but it provides 3.2T BW
> capacity vs 2.4T. If you compare with MX204, then MX304 is about 20%
> expensive
On Tue, 6 Jun 2023 at 06:54, Mark Tinka via juniper-nsp
wrote:
> > While I have a lot of sympathy for Saku's pragmatism, I prefer to file off
> > the ugly edges of old justifications when I can... but it's done one commit
> > at a time.
>>
> Going back to re-do the implementation from scratch
On Mon, 5 Jun 2023 at 11:13, Lukas Tribus via juniper-nsp
wrote:
> in Cisco land I worked around VRF or source interface selection
> limitations for RTR by using SSH as a transport method, which then
> used SSH client source-vrf/source-interface configurations.
>
> I don't know if JunOS supports
I totally agree this should work, and it is unfortunate that you are
struggling to make it work.
Having said that, it is asking for trouble managing your devices in a
VRF, you will continue to find issues and spend time/money working
with vendors to solve those.
It is safer to put the service
Heh,
That makes sense. So in QFX5k 'VXLAN' classifier can contain anything
inside the VXLAN, like ARP? Instead of it being classified ARP, they
all share VXLAN classifier?
So this could also be VXLAN TTL exceeded? Which would happen every
time you have some kind of convergence event, and you'll
The 'max arrival rate' is pre-policer, not the admitted rate.
I don't use VXLAN, and I can't begin to guess what VXLAN traffic needs
to punt. But this is not your transit VXLAN traffic. This is some
VXLAN traffic that the platform thought it needed to process in the
software.
I would personally
Hey,
Before any potential trashing, I'd like to say that as far as I am
aware Juniper (MX) is the only platform on the market which isn't
trivial to DoS off the network, despite any protection users may have
tried to configure.
> How do you identify the source problem of DDOS violations that
I would still consider as-override, or at least I would figure out the
reason why it is not a good solution.
On Tue, 15 Nov 2022 at 15:40, niklas rehnberg via juniper-nsp
wrote:
>
> Hi,
> Thanks for the quick reply, I hope following very simple picture may help
>
>
Hey Niklas,
My apologies, I do not understand your topology or what you are trying
to do, and would need a lot more context.
In my ignorance I would still ask, have you considered 'as-override' -
On Fri, 21 Oct 2022 at 16:39, Chuck Anderson wrote:
> Also, it appears that when Junos was changed to support DHCP Snooping,
> Dynamic ARP Inspection, and IP Source Guard on trunk ports, even
> though trunk ports are in "trusted" mode by default, the switch is
> learning bindings on the trusted
I think you're gonna need JTAC.
My first guess would be that this is not a supported config on the
platform, but it also may be actual TCAM starvation. I'd be curious to
learn what the problem was.
On Thu, 13 Oct 2022 at 14:41, Chuck Anderson wrote:
>
> It's an internal filter created by
You chose a filter which doesn't seem to complain about TCAM in the
initial post. Two filters just state 'not programmed' Others about
TCAM? Could you choose another filter which complains about TCAM?
But certainly that output confirms 'Programmed: NO', just not entirely
clear why. Maybe TCAM
Hey,
Can you please provide
- show filter dram
- show filter hw X
- show filter hw X show_term_info
I lost a fight with JTAC about whether the TCAM exhausting filter
should be a commit failure or not. Argument was along the line 'well
you can keep adding routes even if you exhaust TCAM, so
I can't blame the port=0, even though I agree with the explanation
that you shouldn't rely on it for identifying fragmentation. Looking
at the program, whenever the counter you mentioned
(1x8.2x8.84.34,*,proto=17,port=0) is punched, it is also discarded.
And you can observe the counter being
Actually I think I'm confused, I'm just not accustomed to seeing other
than 0:0 as rate, but it may be thaat the first 0 doesn't matter.
I would verify 'show route flow validation detail' as well as verify
presence of policers if any (in PFE 'show filter counters').
I'd also look at the filter
Are you exceeding the configured rate for the policer? Did you expect
to drop at any rate? The rule sets a non-0 policing rate.
On Sat, 17 Sept 2022 at 17:42, Gustavo Santos wrote:
>
> Hi Saku,
>
> PS: Real ASN was changed to 65000 on the configuration snippet.
>
>
>
> show route table
Can you provide some output.
Like 'show route table inetflow.0 extensive' and config.
On Sat, 17 Sept 2022 at 05:05, Gustavo Santos via juniper-nsp
wrote:
>
> Hi,
>
> We have noticed that flowspec is not working or filtering as expected.
> Trying a DDoS detection and rule generator tool, and we
On Fri, 16 Sept 2022 at 22:12, Jason Healy via juniper-nsp
wrote:
Hey Jason,
> My question is, what would be the logical "step up" from the qfx on a small
> network? I'm thinking the MX240 as it's the smallest router that has
> redundant REs. However, I have no experience with the router
I believe this is best you can do:
y...@a03.labxtx03.us.bb-re0# show|display set |match deny
set system login class tacacs-user deny-commands "clear pppoe
sessions($| no-confirm$)"
y...@a03.labxtx03.us.bb-re0> clear pppoe sessions ?
Possible completions:
Name of PPPoE logical
I don't believe what you're doing is tacacs command authorization, that is
junos is not asking the tacacs server if or not it can execute the command,
something IOS and SROS can do, but which makes things like loading config
very brutal (except SROS has way to skip authorization for config loads).
I don't believe Junos has tacacs command authorization.
You can add do allow/deny commands regexp in the user class to achieve the
same without introducing the RTT lag.
On Mon, 4 Jul 2022 at 15:52, Pierre Emeriaud via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hi
>
> i've been trying
On Fri, 24 Jun 2022 at 10:54, Mark Tinka via juniper-nsp
wrote:> After failing to get Netscout to
natively support IS-IS, we came up with
> a rather convoluted - but elegant - way to transport on-ramp/off-ramp
> traffic into and out of our scrubbers.
>
> Basically, we use lt-* (logical tunnel)
Tunnel interfaces are not supported on PE/Paradise, I don't think this
changed in BT/Triton either.
However you can decapsulate/encapsulate on ingress firewall filter, e.g.:
term cleanPipe:xe-0-4-1-1 {
from {
source-address {
a.b.c.d/32;
Hi,
I'd like to return to this topic. I was confused earlier,
misattributing the issue I'm seeing to MX. And now it is clear it must
be on PTX.
I'd again solicit for input for anyone seeing in their syslogs:
a) junos: 'received pdu - length mismatch for lacp'
b) iosxr:
Hey,
I'd like Trio EA operators to verify two things for me
a) Bad LACP PDU on both sides of EA link
- in syslog something like this:
- kernel: et-0/0/0: received pdu - length mismatch for lacp : len 143, pdu 124
b) L3 incompletes increasing on backbone facing interface on both
sides of EA link
Hey,
> On MX204 with ~4M routes, after upgrading from 18.2 to 20.2 the RPD is
> way slower in processing BGP policies and sending the routes to neighbors.
> For example, on a BGP group with one neighbor and an export policy
> containing 5 terms each matching a community it takes ~1min ( 100% RPD
Hey Aaron,
> I'm wondering if the BA classifier stops working once an MFC is applied. It
> sure seems to in testing. I feel like I've seen a diagram at some point or
> document stating that MFC comes before BA in the CoS process chain. but I'm
> not sure. If anyone has that link/doc please
On Wed, 9 Mar 2022 at 19:48, Gert Doering via juniper-nsp
wrote:
> We use different classes for UDP/123, UDP/53 (exclude well-known
> recursives), fragments, ... and are currently using between 20 and 100
> mbit/s for these classes. What is the right number for you depends
> on "how much can
On Fri, 19 Nov 2021 at 17:12, Thomas Bellman via juniper-nsp
wrote:
> Cut-through actually *can* help a little bit. The buffer space in
> the Trident and Tomahawk chips is mostly shared between all ports;
> only a small portion of it is dedicated per port[1]. If you have
> lots of traffic on
On Fri, 19 Nov 2021 at 11:50, james list wrote:
> I also understood cut through cannot help but obviously I cannot change QFX
> switches because we loss few udp packets for a single application, the idea
> could be to change shared buffers for unused queues and add to used one,
> correct ?
On Fri, 19 Nov 2021 at 10:49, james list wrote:
Hey,
> I try to rephrase the question you do not understand: if I enable cut through
> or change buffer is it traffic affecting ?
There is no cut-through and I was hoping after reading the previous
email, you'd understand why it won't help you
On Thu, 18 Nov 2021 at 23:20, james list via juniper-nsp
wrote:
> 1) is MX family switching by default in cut through or store and forward
> mode? I was not able to find a clear information
Store and forward.
> 2) is in general (on MX or QFX) jeopardizing the traffic the action to
> enable cut
On Wed, 1 Sept 2021 at 20:35, Chuck Anderson via juniper-nsp
wrote:
> Eventually during the ISSU process, the line card software needs to be
> upgraded. During that part, each line card goes offline one at a
> time. If you have multiple line cards, design your network such that
> redundant
You could have something like this:
groups {
IRR {
...
}
}
Then always generate complete new prefix lists in NMS into a single file.
And have script do:
edit groups
delete IRR
load merge https://nms/irr.junos
commit and-quit
On Thu, 12 Aug 2021 at 21:47, Alain Hebert via
On Fri, 9 Jul 2021 at 13:24, embolist wrote:
> So, I can match a bit pattern within the first 256 bytes from the start of
> the IP header, is that correct?
> How many bits can I match within that first 256 bytes?
You can set the match-start from L3, L4 or payload and take 256 bytes
offset
Hey,
I'm not sure I can parse what you are asking. I thought you're asking
how far in the packet you can match with flexible-match-mask, which I
can commit up-to 255 byte offset, but didn't test. I know the original
Trio gets about 320B of the packet in the LU, but newer Trio's get a
little bit
100 matches
Mail list logo
