Re: Large communities indicating RPKI VALID status
On 4/29/24 19:33, Job Snijders wrote: On Mon, 29 Apr 2024 at 21:27, Nigel Kukard via Bird-users wrote: Hi there Richard, On 4/29/24 19:14, Richard Laager wrote: Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and simply reject INVALID routes. Why would one want to accept INVALID at all? If we agree one would reject INVALID, then what is left to tag? For my specific use case I wanted to add a community for VALID and UNKNOWN. I'm going to look into the non-transitive extended communities to see how this works out. Sure, but why add such communities? It reduces performance and doesn’t add security benefits. OTOH - it can satisfy curiosity about where traffic is flowing - then again, using a traffic analyser like pmacct or Kentik helps offer insight how much traffic is going to Valid vs Not-Found destinations, without the need to add any communities. I’m not saying you shouldn’t pursue adding a few non-transitive extended communities here and there for your use case; just that generally speaking, operators probably should not apply different policies for Valid and Not-Found states. Well, basically to summarize, I have quite a number of edges. My filtering occurs on the edges, including filtering of INVALID. I'm using bird to gather all prefixes from all routers using add-paths so I can easily do searches on my dashboard and graphically map paths to destinations and visually see other possible paths that are not best path. As my filtering occurs on the edge I don't have a way on my dashboard to see if the prefix was VALID or UNKNOWN. I thought it would be something useful to see so I can color the routes that are VALID in a dark green or have a small green box with [RPKI VALID] in it next to the prefix. But I certainly see the points raised. It's not used for anything more than analysis and visual display. I'm looking into pmacct and Opensearch to see if I can get Netflow/IPFIX data to help with insight into traffic flows (slightly different to visually seeing possible traffic paths). I'm very new to Elasticseach and Opensearch though and would appreciate if anyone has any recommendations of opensource platforms I can use to give me some info from Netflow/IPFIX data I'd really appreciate it. I did check out Kentik and Elastiflow, but my network is small and doesn't really have the income to support a paid product right now if I can achieve reasonable results with other options. -N OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Large communities indicating RPKI VALID status
On Mon, 29 Apr 2024 at 21:27, Nigel Kukard via Bird-users < bird-users@network.cz> wrote: > Hi there Richard, > > On 4/29/24 19:14, Richard Laager wrote: > > Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge > and simply reject INVALID routes. > > Why would one want to accept INVALID at all? > > If we agree one would reject INVALID, then what is left to tag? > > For my specific use case I wanted to add a community for VALID and > UNKNOWN. I'm going to look into the non-transitive extended communities to > see how this works out. > Sure, but why add such communities? It reduces performance and doesn’t add security benefits. OTOH - it can satisfy curiosity about where traffic is flowing - then again, using a traffic analyser like pmacct or Kentik helps offer insight how much traffic is going to Valid vs Not-Found destinations, without the need to add any communities. I’m not saying you shouldn’t pursue adding a few non-transitive extended communities here and there for your use case; just that generally speaking, operators probably should not apply different policies for Valid and Not-Found states. Kind regards, Job >
Re: Large communities indicating RPKI VALID status
Hi there Richard, On 4/29/24 19:14, Richard Laager wrote: Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and simply reject INVALID routes. Why would one want to accept INVALID at all? If we agree one would reject INVALID, then what is left to tag? For my specific use case I wanted to add a community for VALID and UNKNOWN. I'm going to look into the non-transitive extended communities to see how this works out. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Large communities indicating RPKI VALID status
Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and simply reject INVALID routes. Why would one want to accept INVALID at all? If we agree one would reject INVALID, then what is left to tag? -- Richard
Re: " bfd1: Socket error: Destination address required"
Are your neighbors directly connected or by any chance multihop?
On 29.04.24 7:41 PM, Fran via Bird-users wrote:
> Hello Alexander,
>
> thanks for your email.
>
> I started without any neighbor config in the BFD section and the error
> message was there, while trying to get rid of the error I first added
> the "local " and then the "dev " options. The
> error message appears non the less.
>
> Best,
>
> fran
>
>
>
> On 29/04/2024 17:20, Alexander Zubkov wrote:
>> Hi,
>>
>> You do not need to define neighbors for BGP sessions explicitly in
>> your BFD config. They are created automatically for BGP sessions with
>> BFD enabled. In that case, I suppose, you won't get errors for the
>> missing neighbors.
>>
>> Regards,
>> Alexander
>>
>> On Mon, Apr 29, 2024 at 1:16 PM Fran via Bird-users
>> wrote:
>>>
>>> Hello there,
>>>
>>> I get the error message:
>>>
>>> " bfd1: Socket error: Destination address required"
>>>
>>> (ubuntu 22.04, bird via ppa 2.15.1) running BFD and MP-BGP via IPv6 over
>>> wireguard interfaces. Not all BGP neighbors are reachable.
>>>
>>> Relevant (I hope) config:
>>>
>>> log "/var/log/bird/bird.log" all;
>>>
>>> protocol device {
>>> }
>>>
>>> protocol bfd {
>>> accept ipv6 direct;
>>> interface "wg_blue*";
>>> interface "wg_green" {
>>> multiplier 3;
>>> interval 500 ms;
>>> };
>>> neighbor 2001:db8:f000::2 dev "wg_green" local 2001:db8:f000::1;
>>> neighbor 2001:db8:f000:::2 dev "wg_blue2" local
>>> 2001:db8:f000:::1;
>>> neighbor 2001:db8:f000:fffc::5 dev "wg_blue1" local
>>> 2001:db8:f000:fffc::1;
>>> neighbor 2001:db8:f000:fffc::4 dev "wg_blue1" local
>>> 2001:db8:f000:fffc::1;
>>> neighbor 2001:db8:f000:fffc::3 dev "wg_blue1" local
>>> 2001:db8:f000:fffc::1;
>>> neighbor 2001:db8:f000:fffc::2 dev "wg_blue1" local
>>> 2001:db8:f000:fffc::1;
>>> }
>>>
>>>
>>> protocol bgp EXAMPLE {
>>> local as 65001;
>>> neighbor 2001:db8:f000::2 as 65044;
>>> direct;
>>> med metric yes;
>>> ipv4 {
>>> ...
>>> };
>>> ipv6 {
>>> ...
>>> };
>>> bfd on;
>>> }
>>>
>>>
>>> If I remove the BFD config for the non-established BGP neighbors, the
>>> error message disappears (although there are still non-established BFD
>>> sessions for established BGP neighbors (BFD not yet confed on the other
>>> end)).
>>>
>>> At first I did not create neighbor statements for BFD, then I added
>>> "dev" and "local" options - no improvement.
>>>
>>> No revelations with "debug protocols all".
>>>
>>> Any ideas? Thanks a lot!
>>>
>>> Best,
>>>
>>> fran
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: " bfd1: Socket error: Destination address required"
Hello Alexander,
thanks for your email.
I started without any neighbor config in the BFD section and the error
message was there, while trying to get rid of the error I first added
the "local " and then the "dev " options. The
error message appears non the less.
Best,
fran
On 29/04/2024 17:20, Alexander Zubkov wrote:
Hi,
You do not need to define neighbors for BGP sessions explicitly in
your BFD config. They are created automatically for BGP sessions with
BFD enabled. In that case, I suppose, you won't get errors for the
missing neighbors.
Regards,
Alexander
On Mon, Apr 29, 2024 at 1:16 PM Fran via Bird-users
wrote:
Hello there,
I get the error message:
" bfd1: Socket error: Destination address required"
(ubuntu 22.04, bird via ppa 2.15.1) running BFD and MP-BGP via IPv6 over
wireguard interfaces. Not all BGP neighbors are reachable.
Relevant (I hope) config:
log "/var/log/bird/bird.log" all;
protocol device {
}
protocol bfd {
accept ipv6 direct;
interface "wg_blue*";
interface "wg_green" {
multiplier 3;
interval 500 ms;
};
neighbor 2001:db8:f000::2 dev "wg_green" local 2001:db8:f000::1;
neighbor 2001:db8:f000:::2 dev "wg_blue2" local
2001:db8:f000:::1;
neighbor 2001:db8:f000:fffc::5 dev "wg_blue1" local
2001:db8:f000:fffc::1;
neighbor 2001:db8:f000:fffc::4 dev "wg_blue1" local
2001:db8:f000:fffc::1;
neighbor 2001:db8:f000:fffc::3 dev "wg_blue1" local
2001:db8:f000:fffc::1;
neighbor 2001:db8:f000:fffc::2 dev "wg_blue1" local
2001:db8:f000:fffc::1;
}
protocol bgp EXAMPLE {
local as 65001;
neighbor 2001:db8:f000::2 as 65044;
direct;
med metric yes;
ipv4 {
...
};
ipv6 {
...
};
bfd on;
}
If I remove the BFD config for the non-established BGP neighbors, the
error message disappears (although there are still non-established BFD
sessions for established BGP neighbors (BFD not yet confed on the other
end)).
At first I did not create neighbor statements for BFD, then I added
"dev" and "local" options - no improvement.
No revelations with "debug protocols all".
Any ideas? Thanks a lot!
Best,
fran
Re: " bfd1: Socket error: Destination address required"
Hi,
You do not need to define neighbors for BGP sessions explicitly in
your BFD config. They are created automatically for BGP sessions with
BFD enabled. In that case, I suppose, you won't get errors for the
missing neighbors.
Regards,
Alexander
On Mon, Apr 29, 2024 at 1:16 PM Fran via Bird-users
wrote:
>
> Hello there,
>
> I get the error message:
>
> " bfd1: Socket error: Destination address required"
>
> (ubuntu 22.04, bird via ppa 2.15.1) running BFD and MP-BGP via IPv6 over
> wireguard interfaces. Not all BGP neighbors are reachable.
>
> Relevant (I hope) config:
>
> log "/var/log/bird/bird.log" all;
>
> protocol device {
> }
>
> protocol bfd {
>accept ipv6 direct;
>interface "wg_blue*";
>interface "wg_green" {
> multiplier 3;
> interval 500 ms;
>};
>neighbor 2001:db8:f000::2 dev "wg_green" local 2001:db8:f000::1;
>neighbor 2001:db8:f000:::2 dev "wg_blue2" local
> 2001:db8:f000:::1;
>neighbor 2001:db8:f000:fffc::5 dev "wg_blue1" local
> 2001:db8:f000:fffc::1;
>neighbor 2001:db8:f000:fffc::4 dev "wg_blue1" local
> 2001:db8:f000:fffc::1;
>neighbor 2001:db8:f000:fffc::3 dev "wg_blue1" local
> 2001:db8:f000:fffc::1;
>neighbor 2001:db8:f000:fffc::2 dev "wg_blue1" local
> 2001:db8:f000:fffc::1;
> }
>
>
> protocol bgp EXAMPLE {
>local as 65001;
>neighbor 2001:db8:f000::2 as 65044;
>direct;
>med metric yes;
>ipv4 {
> ...
>};
>ipv6 {
> ...
>};
>bfd on;
> }
>
>
> If I remove the BFD config for the non-established BGP neighbors, the
> error message disappears (although there are still non-established BFD
> sessions for established BGP neighbors (BFD not yet confed on the other
> end)).
>
> At first I did not create neighbor statements for BFD, then I added
> "dev" and "local" options - no improvement.
>
> No revelations with "debug protocols all".
>
> Any ideas? Thanks a lot!
>
> Best,
>
> fran
`default cost` setting is not applied
Hi,
I have the following configuration:
```
define ospf_v4_routes = [
198.19.0.0/16
];
filter ospf_export {
if (net.type = NET_IP4 && ! (net ~ [ 0.0.0.0/0 ])) then reject;
accept;
}
filter ospf_import {
if (net.type = NET_IP4 && net ~ ospf_v4_routes) then accept;
reject;
}
protocol ospf v2 ospfv4 {
debug all;
ipv4 {
import filter ospf_import;
export filter ospf_export;
};
area 0.0.0.0 {
interface "lo1" { stub yes; };
interface "vlan600" {
type ptp;
cost 15;
bfd on;
};
};}
```
I would expect the metric around 300 + cost of the interface but I get this
route metric
"E2 0.0.0.0/0 [15/1] via 198.19.4.65, vlan600"
in the switch.
When I set the metric manually in the export function:
```
filter ospf_export {
if (net.type = NET_IP4 && ! (net ~ [ 0.0.0.0/0 ])) then reject;
ospf_metric1 = 300; unset(ospf_metric2);
accept;}
```
I get the correct metric:
```
E1 0.0.0.0/0 [315] via 198.19.4.65, vlan600
```
Any idea what could be the issue ?
Did I misunderstood the usage of the `default cost` setting?
Benoît
Re: Large communities indicating RPKI VALID status
On Sun, Apr 28, 2024 at 01:00:40PM +0200, Job Snijders wrote: > On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote: > > On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote: > > > There's internet draft describing in detail, why it's not a good idea to > > > store RPKI validation state inside community variables at all.. > > > > > > https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-00.html > > > > Well, note that this draft is primarily about not announcing validation > > state in transitive attributes to the whole internet. > > Yes > > > But there are good reasons for having validation state in > > non-transitive BGP attributes (or communities properly filtered out on > > AS egress). Validating RPKI and marking routes at AS ingress ensures > > that all routers within AS have consistent routing state and thus > > avoiding routing loops. > > Perhaps I am missing something, but how does marking in itself help > avoid routing loops? > > I am under the impression that a requirement for intra-AS transitive > marking follows from non-standard modifying of non-transitive local > attributes (for example, 'weight' or 'preference') based on the > validation state - which is not what I'd recommend to begin with. Well, you are right. there are three ways how to define policy based on RPKI status: 1) Validate RPKI for all routes and apply policy based on the validation state on all routers. 2) Validate RPKI only for EBGP routes on border routers, mark result with communities, then apply policy based on marks on all routers. 3) Validate RPKI only for EBGP routes on border routers, apply policy based on validation state there and use (non-transitive) BGP attributes for policy (like bgp_local_pref) to propagate it through AS. The first approach is bad and can easily lead to inconsistent routing, the second is better as marking ensures that different routers have consistent view of validation states of routes, but the third approach is even better and does not require explicit marking of validation states (although one could argue that the validation state is implicitly encoded in the policy-carrying BGP attributes). > Merely rejecting RPKI-invalid routes at the AS ingress and *not* > manipulating any other local or transitive path attributes will also > ensure a consistent routing state. Obviously. > > Unfortunately large communities do not have transitive flag like > > extended ones > > so perhaps it would make sense to use extended community for this > > purpose. Or perhaps there should be well-known extended community for > > that ... > > https://www.rfc-editor.org/rfc/rfc8097.html ? Thanks, i was not aware of this. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Re: How to set ospf as external route as ext1?
On Sun, Apr 28, 2024 at 02:29:42PM +, chan alfie wrote: > The default ospf ASE will be set as rts_ospf_ext2, how to change it, and set > the ospf ASE as rts_ospf_ext1? Hi Set ospf_metric1 route attribute in export filters. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
" bfd1: Socket error: Destination address required"
Hello there,
I get the error message:
" bfd1: Socket error: Destination address required"
(ubuntu 22.04, bird via ppa 2.15.1) running BFD and MP-BGP via IPv6 over
wireguard interfaces. Not all BGP neighbors are reachable.
Relevant (I hope) config:
log "/var/log/bird/bird.log" all;
protocol device {
}
protocol bfd {
accept ipv6 direct;
interface "wg_blue*";
interface "wg_green" {
multiplier 3;
interval 500 ms;
};
neighbor 2001:db8:f000::2 dev "wg_green" local 2001:db8:f000::1;
neighbor 2001:db8:f000:::2 dev "wg_blue2" local
2001:db8:f000:::1;
neighbor 2001:db8:f000:fffc::5 dev "wg_blue1" local
2001:db8:f000:fffc::1;
neighbor 2001:db8:f000:fffc::4 dev "wg_blue1" local
2001:db8:f000:fffc::1;
neighbor 2001:db8:f000:fffc::3 dev "wg_blue1" local
2001:db8:f000:fffc::1;
neighbor 2001:db8:f000:fffc::2 dev "wg_blue1" local
2001:db8:f000:fffc::1;
}
protocol bgp EXAMPLE {
local as 65001;
neighbor 2001:db8:f000::2 as 65044;
direct;
med metric yes;
ipv4 {
...
};
ipv6 {
...
};
bfd on;
}
If I remove the BFD config for the non-established BGP neighbors, the
error message disappears (although there are still non-established BFD
sessions for established BGP neighbors (BFD not yet confed on the other
end)).
At first I did not create neighbor statements for BFD, then I added
"dev" and "local" options - no improvement.
No revelations with "debug protocols all".
Any ideas? Thanks a lot!
Best,
fran
Re: How to make ospf advertise stubnet base on the interface/subnet state?
Hey,
It's just a wild guess, but did you tried:
```
protocol ospf [v2|v3] {
...
interface [instance ] {
check link ;
};
..
}
```
I'm not sure if or what difference it would make if you add your prefix
to a static protocol and set the `check link` there, too.
Again, it's just a wild guess...
Good luck,
Bernd
On 28.04.24 11:30 AM, chan alfie wrote:
> Hi, community
>
> I have create a loopback interface on linux and assign 4 subnets on it.
>
> ```
> ip link add dev lo235 type dummy
> ip link set lo235 up
> ip addr add 10.23.5.1/30 dev lo235
> ip addr add 10.23.5.5/30 dev lo235
> ip addr add 10.23.5.9/30 dev lo235
> ip addr add 10.23.5.13/30 dev lo235
> ```
>
> stubnet { summary;}; is used on an originator routers(r235) ospf
> area, and it indeed propagted the summary prefix instead of subnets, here is
> the config:
>
> r235:
> ```
> area 10.23.0.0 {
> ...
> stubnet 10.23.5.0/28 {
> summary;
> }
> ...
> }
> ```
>
> r235:
> ```
> show ospf state
> ...
> router 10.23.0.5
> distance 0
> ...
> stubnet 10.23.5.0/28 metric 10
> ...
> ```
>
> but when I shutdown the lo235 or delete all of the subnets, the 10.23.5.0/28
> is still advertised by r235.
>
> r235
> ```
> ip link set lo235 down
> or
> ip addr del 10.23.5.1/30 dev lo235
> ip addr del 10.23.5.5/30 dev lo235
> ip addr del 10.23.5.9/30 dev lo235
> ip addr del 10.23.5.13/30 dev lo235
> ```
>
> r235
> ```
> bird> show ospf state
> router 10.23.0.5
> distance 0
> ...
> stubnet 10.23.5.0/28 metric 10
> ```
>
> How to make ospf advertise stubnet base on the interface/subnet state,
> (interface up/down, subnets existed or not)?
>
> By the way, networks{} clause works as expected. When the subnet of
> originator router is dismiss, the ABR's networks will take effect(disappear
> of appear).
OpenPGP_signature.asc
Description: OpenPGP digital signature
