iBGP and next hop - bird router
Hi Bird users,
I need your kind assistance. We are running bird router in container
and peering with one of the edge routers using iBGP. This for a
looking glass.
All the routes are becoming unreachable due to next hops since the
bird router is not feed with all the next hops in the network. How can
get the issue resolved ? I want to the change the next hop on the bird
router(I don’t want the peering router to be next-hop-self.). Sofar,
I am unsuccessful. By hashing out disable under the protocol, we see
the interfaces in the routing table.
I have done so far following things and unsuccessful.
protocol direct {
#
disabled; #
Disable by default
ipv4;
# Connect to default IPv4 table
ipv6;
# ... and to default IPv6 table
}
filter looking_glass
if ( net ~ [ 0.0.0.0/0{0,32} ] ) then
{
bgp_next_hop = 10.252.40.X; (tried
both VM or gateway address for VM. Not successful sofar)
accept;
}
Please kindly advise for a working solution.
Regards,
Skanda Arasalingam
PS: first time Bird user
Re: bird not exporting OSPF route
Hey Ondrej, Ondrej Zajicek writes: > On Wed, Feb 28, 2024 at 04:15:32PM +0900, Nico Schottelius via Bird-users > wrote: > Also note you can write the condition using sets: > > if source ~ [ RTS_STATIC, RTS_BGP, RTS_OSPF, RTS_OSPF_IA, RTS_OSPF_EXT1, > RTS_OSPF_EXT2 ] then ... Thank you, twice! Changed it to set and to include all OSPF types and now everything internally looks good! Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch
Re: bird not exporting OSPF route
On Wed, Feb 28, 2024 at 04:15:32PM +0900, Nico Schottelius via Bird-users wrote:
>
> Good morning,
>
> after switching over to the following filter, as mentioned in the last
> mails:
>
> filter static_and_bgp_and_ospf {
> if(source = RTS_STATIC || source = RTS_BGP || source = RTS_OSPF) then
> accept;
> reject;
> }
Hi
OSPF generates routes with four source values:
RTS_OSPF, RTS_OSPF_IA, RTS_OSPF_EXT1 and RTS_OSPF_EXT2.
(for internal, inter-area, type 1 external and type 2 external routes).
So in your case you just export internal OSPF routes, not the E2 route.
Also note you can write the condition using sets:
if source ~ [ RTS_STATIC, RTS_BGP, RTS_OSPF, RTS_OSPF_IA, RTS_OSPF_EXT1,
RTS_OSPF_EXT2 ] then ...
>
> bird> show route all for 2a0a:e5c0:2:a::b
> Table master6:
> 2a0a:e5c0:2:a::b/128 unicast [ospf6 2024-02-26] * E2 (150/10/1)
> [147.78.194.129]
> via fe80::3eec:efff:fecb:d81a on eth0
> Type: OSPF-E2 univ
> OSPF.metric1: 10
> OSPF.metric2: 1
> OSPF.tag: 0x
> OSPF.router_id: 147.78.194.129
>
> And is there actually a CLI syntax for
> verifying that a route is accepted by a filter?
show route export
(for should be exported)
or
show route exported
(for was exported)
--
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: IPv6 routes not imported into Kernel
Hi Robert, On 27/02/2024 22:58, Robert Finze wrote: In the meantime I've setup a clean new VM with Ubuntu 22.04 and the same issues occurred. I've upgraded that new VM to 24.04 and still the same. Next I want to try a fresh 20.04 install and see what happens. I would try a fresh install of Ubuntu 20.04 with the same kernel as the machine that currently works, indeed. If the problem goes away, it might be an issue between Ubuntu 20.04 and 22.04. If the problem persists, it might be some subtle configuration difference. I wouldn't yet upgrade to BIRD 3.0alpha because that changes too many variables in order to debug the problem. >> ip -6 route add 2607:ff00:b::/40 via 2a0e:3940:dead::1 table 254 protocol bird scope global src 2a0e:3940:1000::2 dev 2 - where dev 2 indicates the network interface with index 2, this is probably ens20 in your setup? It should be ens19. I'm currently not sure how to verify that. "ip a" shows: 1: lo 2: ens18 3: ens19 4: ens20 5: dummy0 The number before ":" is the interface index. It seems BIRD wants to add the route on device ens18 (at least, at the time). Besides, in your initial post, you pasted a few routes from BIRD that were using protocols "upstream_1v6" and "upstream_2v6". They seem to be missing from the bird.conf you posted. The route addition in the netlink dump is different from the routes you showed in BIRD, which makes it more difficult to pinpoint the problem. I think it's a good idea to focus on getting just one route exported from BIRD to the kernel successfully. If it's possible in your setup, perhaps just configure 1 upstream, and only import 1 route from that upstream in BIRD, and export the same route through the kernel protocol. Best regards, Gerdriaan Mulder
