Re: IPv4 next-hops over IPv6
To me, the better part is to imagine that IPv6 only Link-Layer(on IXPs and Transit providers) will make PMTUD better working. Em ter., 23 de abr. de 2024 11:57, Ondrej Zajicek via Bird-users < bird-users@network.cz> escreveu: > On Fri, Apr 19, 2024 at 02:29:44PM -0500, Jay Hanke via Bird-users wrote: > > Has anyone implemented lab or production IPv4 next hops over an IPv6 > > only IX vlan with BIRD as the route server? > > > > I'm interested to hear your experiences. Specifically router vendor > interop. > > Note that there is an Euro-IX working group targetting this issue: > > https://github.com/euro-ix/rfc8950-ixp > > -- > 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." >
How to set ospf as external route as ext1?
The default ospf ASE will be set as rts_ospf_ext2, how to change it, and set the ospf ASE as rts_ospf_ext1?
Re: Large communities indicating RPKI VALID status
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. 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. > 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 ? Kind regards, Job
How to make ospf advertise stubnet base on the interface/subnet state?
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).
