Hello,
On 25/01/2019 16:50, Luis Balbinot wrote:
Please let me know if you find some other approach.
The overload bit helps but in the absence of another path the RSVP FRR
mechanism will setup a bypass LSP through a node with the overload bit
set. And link coloring does not help, at least in my
I've tried that before but those settings under RSVP don't seem to
affect FRR LSPs. I tried that at the node I don't want to allow
transit LSPs and at the previous node to that.
Am I missing something? There has to be a way to avoid it. I have
around 5000 tunnels in my production network and I don
So I missed your specific comment about being concerned about the bypass
LSPs.
I think (although I haven't tested this in forever) if you enable
no-node-protection under RSVP , that will prevent those interfaces from
being available for any node or link bypass LSP to use.
On Fri, Jan 25, 2019 at
Please let me know if you find some other approach.
The overload bit helps but in the absence of another path the RSVP FRR
mechanism will setup a bypass LSP through a node with the overload bit
set. And link coloring does not help, at least in my case.
Luis
On Fri, Jan 25, 2019 at 11:20 AM Jason
Hi Melchior,
> Thanks for pointing this out. Please have a look at
> https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1379433 and
> let me know your ideas.
Yep, that sounds exactly like what's happening!
"Resolved In 15.1X49-D160 17.4R3 18.1R3 18.2R2 18.3R1 18.4R1" sounds hope
I’m testing a similar approach (except using the ISIS overload bit) that aims
to prevent the path between a pair of LSRs via the links to and through my RRs
from being considered as a possible transit path. Seems to work just fine in
the lab.
> On Jan 24, 2019, at 3:24 PM, Luis Balbinot wrote
On 25/Jan/19 14:53, Luis Balbinot wrote:
> It works. The only drawback is that all metrics on the local routing
> table (not only for advertised LSAs) were increased by 65535. That's a
> bit annoying but works just fine. The increase is relative to the
> actual metric so we'll see values above
It works. The only drawback is that all metrics on the local routing
table (not only for advertised LSAs) were increased by 65535. That's a
bit annoying but works just fine. The increase is relative to the
actual metric so we'll see values above 65535.
Not sure if I'm moving to this approach or ju
One of our SRXes was blocking EDNSv1, and so we disabled the DNS ALG to
resolve our issue; this might be a prudent approach depending on your
environment.
Not sure this will help the OP as the device(s) in question are outside
their administrative domain. :)
HTH,
Niall
-Original Message-
> What they told you sounds like bullshit to me. From 10.2 on
> there are no special settings required. Maybe they don't know
> how to do it?
>
> So I guess they are just very lazy or don't know better and
> blame the firewall... I pray for you that they don't run Code
> below 10.2...
>
> https://
It would mean that they run something older than 10.2 JunOS, that is a
prehistoric release, which would be criminal in term of security.
Anyway, putting stateful firewalls in front of DNS servers is a nonsense from
the beginning.
> Le 25 janv. 2019 à 13:06, Christian Scholz a écrit :
>
> What
What they told you sounds like bullshit to me. From 10.2 on there are no
special settings required. Maybe they don’t know how to do it?
So I guess they are just very lazy or don’t know better and blame the
firewall... I pray for you that they don’t run Code below 10.2...
https://kb.juniper.net/
> When doing some investigation for the upcoming DNS Flag Day
> (https://dnsflagday.net: February 1st 2019) I got some bad news from one of
> the service providers: they use Juniper SRX firewalls, and claim that they
> can't properly support EDNS because of a bug in their SRX firewalls. This
>
Hi,
When doing some investigation for the upcoming DNS Flag Day
(https://dnsflagday.net: February 1st 2019) I got some bad news from one of the
service providers: they use Juniper SRX firewalls, and claim that they can't
properly support EDNS because of a bug in their SRX firewalls. This seems
Hi Charles,
> fe80:0001::::/64 is not valid as a link-local address and I've run
> into vendors that have issues with such addresses.
Oh, ok. I understand now what you meant. Good to know.
Martin
___
juniper-nsp mailing list juniper-nsp@puck.
On 24/Jan/19 22:24, Luis Balbinot wrote:
> That’s a good idea. I’m not 100% sure that this will prevent the creation
> of bypass LSPs but I’ll give it a try.
In theory, that should work, as the node will, effectively, be taken out
of the IS-IS path (and all ensuing support services).
Would be
16 matches
Mail list logo
