Re: [j-nsp] BGP timer
On 5/3/24 19:54, Lee Starnes wrote: Hello Mark, Thanks for asking. This is eBGP and the issue is that there have been failures whereby the link does not fail, and thus can't track that routes should be removed. BGP session has stayed up in some cases as well, yet no traffic. Yeah, if the physical media is unable to indicate link-layer failure to the system, BFD is probably you best bet at detecting link failure. Have you worked with your eBGP neighbor (I'm guessing your transit provider) to see what they can do to improve link failure detection at the link layer? Perhaps avoid an intermediate Ethernet switch between both your routers, e.t.c. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP timer
Hello Mark, Thanks for asking. This is eBGP and the issue is that there have been failures whereby the link does not fail, and thus can't track that routes should be removed. BGP session has stayed up in some cases as well, yet no traffic. On Mon, Apr 29, 2024 at 9:31 AM Mark Tinka via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > > > On 4/29/24 17:42, Lee Starnes via juniper-nsp wrote: > > As for BFD and stability with aggressive settings, we don't run too > > aggressive on this, but certainly do require it because the physical > links > > have not gone down in our cases when we have had issues, causing a larger > > delay in killing the routes for that path. Not being able to rely on link > > state failure leaves us with requiring the use of BFD. > > Is this link carrying eBGP or iBGP? > > If the latter, have you considered using BFD to track the IGP instead of > BGP? > > Mark. > ___ > 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: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
Martin-
Yes, we use the source-prefix-list autogenerated with external scripting based
on config parsing of eBGP peers with ttl 255 set. Below is what our BGP RE
rules look like on a PE; it probably has its own problems deserving feedback.
I show v4 but we have corresponding for v6.
You can also see below I take shortcuts to reuse a single filter for deployment
in global vs VPN vs LS, as always, "we could do better here". In my example
the source-prefix-lists starting with "^BGP-Peers" are JunOS apply-paths. I
think previously Saku [or others] made a case for treating RRs differently
since it is known with an RR both ends of the BGP peer are under the same admin
domain [ie, RR doesn't need to allow inbound initiation]. So the rules for an
RR could be tighter than below.
-Michael
===/===
term BGP-ttl-security-allow-1 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
ttl 255;
source-port bgp;
destination-port 1024-65535;
}
then {
count :accept:tcp:bgp-ttl;
accept;
}
}
term BGP-ttl-security-reject-1 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
source-port bgp;
destination-port 1024-65535;
}
then {
count :discard:tcp:bgp-ttl;
discard;
}
}
term BGP-ttl-security-allow-2 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
ttl 255;
source-port 1024-65535;
destination-port bgp;
}
then {
count :accept:tcp:bgp-ttl;
accept;
}
}
term BGP-ttl-security-reject-2 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count :discard:tcp:bgp-ttl;
discard;
}
}
term BGP-Allow-1 {
from {
source-prefix-list {
BGP-Peers-v4;
BGP-Peers-v4-VPN;
BGP-Peers-v4-LS;
}
protocol tcp;
source-port bgp;
destination-port 1024-65535;
}
then {
count :accept:tcp:BGP;
accept;
}
}
term BGP-Allow-2 {
from {
source-prefix-list {
BGP-Peers-v4;
BGP-Peers-v4-VPN;
BGP-Peers-v4-LS;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count :accept:tcp:BGP;
accept;
}
}
> -Original Message-
> From: juniper-nsp On Behalf Of Martin
> Tonusoo via juniper-nsp
> Sent: Thursday, May 2, 2024 9:32 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of
> 'things to
> think about'?
>
> Hi.
>
> Thanks for the feedback and remarks. I have updated the RE filters:
> https://urldefense.com/v3/__https://gist.github.com/tonusoo/efd9ab4fcf2bb5a4
> 5d34d5af5e3f3e0c__;!!Mak6IKo!N5k2EhZxDwIf5W9ZpqDjz_jriaKLPB2zu5Q4Uv8F
> A80q0_LrJSqI5m95HP0NSSUcqOD1H-xllqhzwfvGwr1ZBq3Tw2I$
>
> Few comments:
>
> * I used the ephemeral range of 49160 - 65535 based on "sysctl
> net.inet.ip.portrange.first" and "sysctl net.inet.ip.portrange.last"
> on FreeBSD shell
>
> * the "router-v4" was carried over from inet6 filters as I wanted to
> keep the v4 and v6 rules as identical as possible. It also helps to
> filter malformed packets addressed
> to multicast. For example TCP SYN packets addressed to dport 179 with
> destination IP set to 224.0.0.6
>
>
> Michael,
>
> regarding the GTSM for BGP and related filters. Do you group the BGP
> neighbors into different prefix lists based on the expected TTL?
> Something like this:
>
> root@vmx1> show configuration firewall family inet filter accept-bgp-v4
> term accept-bgp-ttl-255-v4 {
> from {
> source-prefix-list {
> /* adjacent BGP neighbors with TTL set to 255 */
> bgp-neighbors-ttl-255-v4;
> }
> destination-prefix-list {
> router-v4;
> }
> protocol tcp;
> ttl 255;
> destination-port bgp;
> }
> then {
> count accept-bgp-ttl-255-v4;
> accept;
> }
> }
> term accept-bgp-v4 {
> from {
> source-prefix-list {
> /* rest of the BGP neighbors */
> bgp-neighbors-v4;
> }
> destination-prefix-list {
> router-v4;
> }
> protocol tcp;
> destination-port bgp;
> }
> then {
> count accept-bgp-v4;
> accept;
> }
> }
>
> root@vmx1>
>
>
> Martin
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-
> nsp__;!!Mak6IKo!N5k2EhZxDwIf5W9ZpqDjz_jriaKLPB2zu5Q4Uv8FA80q0_LrJSqI5
> m95HP0NSSUcqOD1H-xllqhzwfvGwr1ZPj6yIMU$
