Mailing List Archive

Simulate minimum-links for ordinary interfaces?
Hi!

I have not been able to figure out how to "disable" the remaining
interfaces among a set of interfaces when one goes down. Is it even
possible? I'm looking for something like "minimum-links" for LAGs.

The background is that we are using an external service that is
filtering our outbound traffic. The connection is set up using IPsec
tunnels. One tunnel is not enough, we have to load-balance over more
than one to have enough total bandwidth (load-balancing is set up and
works well).

There is one primary filtering site, and a secondary site. All traffic
is routed to the same IPv4-address that exists in both sites.

Here is a configuration example:

ladmin@srx-1> show configuration routing-instances outbound-vr
instance-type virtual-router;
interface st0.1; # Primary site
interface st0.2; # Primary site
interface st0.3; # Secondary site
interface st0.4; # Secondary site
routing-options {
static {
route 1.2.3.4/32 {
qualified-next-hop st0.1 {
metric 1;
}
qualified-next-hop st0.2 {
metric 1;
}
qualified-next-hop st0.3 {
metric 2;
}
qualified-next-hop st0.4 {
metric 2;
}
}
}
}

If st0.1 goes down, st0.2 cannot handle all of the load, so we want to
move all of the traffic to st0.3 and st0.4 instead. Ideally, once st0.1
recovers, the traffic should move back to st0.1 and st0.2.

Is this possible to do in a good way?

I know that almost anything can be solved with event-scripts triggered
by link-up/down for st0.X, but that kind of configuration is somewhat
hidden, and also probably difficult to get completely correct.


Any hints appreciated.

/Per Westerlund
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Simulate minimum-links for ordinary interfaces? [ In reply to ]
On 10/06/2019 09:44, p1@westerlund.se wrote:
> I know that almost anything can be solved with event-scripts triggered
> by link-up/down for st0.X, but that kind of configuration is somewhat
> hidden, and also probably difficult to get completely correct.

Either the event-scripts triggering you wan to initially avoid or
alternatively change to do dynamic routing between the sites?

Static routes with Remote Probe Monitoring is my suggestion.

https://www.juniper.net/documentation/en_US/release-independent/nce/topics/task/configuration/internet-protocol-route-monitoring.html

Christoffer
Re: Simulate minimum-links for ordinary interfaces? [ In reply to ]
Thanks, good suggestion.

Haven’t used that before. Given that input, this is what I will try:

- Add a dummy linknet to each tunnel interface, since RPM and
IP-monitoring works with addresses and not interfaces directly
- Use two RPM-probes on the primary links to be able to have independent
failure tests
- Use one IP-monitoring policy matching on both RPM-probes, so I can
change routing as soon as one of the two links fail

/Per

PS: Results will be reported once I’m done


On 10 Jun 2019, at 16:34, Hansen, Christoffer wrote:

> On 10/06/2019 09:44, p1@westerlund.se wrote:
>> I know that almost anything can be solved with event-scripts
>> triggered
>> by link-up/down for st0.X, but that kind of configuration is somewhat
>> hidden, and also probably difficult to get completely correct.
>
> Either the event-scripts triggering you wan to initially avoid or
> alternatively change to do dynamic routing between the sites?
>
> Static routes with Remote Probe Monitoring is my suggestion.
>
> https://www.juniper.net/documentation/en_US/release-independent/nce/topics/task/configuration/internet-protocol-route-monitoring.html
>
> Christoffer
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Simulate minimum-links for ordinary interfaces? [ In reply to ]
Interim followup:

This is probably the bestpath to follow, but I have not been able to
make the RPM probes work. I’ll follow that up in a separate thread.

Once that is cleared, there will be a final followup

/Per


On 10 Jun 2019, at 21:18, Per Westerlund wrote:

> Thanks, good suggestion.
>
> Haven’t used that before. Given that input, this is what I will try:
>
> - Add a dummy linknet to each tunnel interface, since RPM and
> IP-monitoring works with addresses and not interfaces directly
> - Use two RPM-probes on the primary links to be able to have
> independent failure tests
> - Use one IP-monitoring policy matching on both RPM-probes, so I can
> change routing as soon as one of the two links fail
>
> /Per
>
> PS: Results will be reported once I’m done
>
>
> On 10 Jun 2019, at 16:34, Hansen, Christoffer wrote:
>
>> On 10/06/2019 09:44, p1@westerlund.se wrote:
>>> I know that almost anything can be solved with event-scripts
>>> triggered
>>> by link-up/down for st0.X, but that kind of configuration is
>>> somewhat
>>> hidden, and also probably difficult to get completely correct.
>>
>> Either the event-scripts triggering you wan to initially avoid or
>> alternatively change to do dynamic routing between the sites?
>>
>> Static routes with Remote Probe Monitoring is my suggestion.
>>
>> https://www.juniper.net/documentation/en_US/release-independent/nce/topics/task/configuration/internet-protocol-route-monitoring.html
>>
>> Christoffer
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp