search

xddxdd / bird-lg-go

BIRD looking glass in Go, for better maintainability, easier deployment & smaller memory footprint
GNU General Public License v3.0
141 stars 27 forks source link

BGPmap improvements #36

Closed jlu5 closed 3 years ago

jlu5 commented 3 years ago

Note: to implement non-BGP routes, I changed the split code from "\t via" to "unicast", as static routes don't always include a via 1.2.3.4 argument (in my case, they tend to use dev <ifacename> instead. This seems to work fine in my testing so far, but I'm not sure if there are other cases that this will miss.

Some before and after examples can be found at https://highdef.network/static/bgpmap-tweaks/index.html

xddxdd commented 3 years ago

When considering protocols other than BGP, "unicast" doesn't always work. I have route 172.22.76.120/29 reject; in my bird config on my node, and show route for 172.22.76.125 all produces the following output:

Table master4:
172.22.76.120/29     unreachable [static_v4 2021-08-06] * (10000)
    Type: static univ
                     unicast [ltnet_hostdare 2021-08-23 from fdbc:f9dc:67ad:3::1] (100/?) [i]
    via fe80::3 on lt4-hostdare
    Type: BGP univ
    BGP.origin: IGP
    BGP.as_path: 
    BGP.next_hop: fdbc:f9dc:67ad:3::1
    BGP.local_pref: 95

The best way seems to be checking that either a line starts with either 21 spaces, and split on the first word, or a line starts with no spaces at all, and split on the second word.

For lines starting with a long prefix, "unreachable/unicase/whatever" isn't guaranteed to start at character 22:

fd10:127:10:2547::53/128 unicast [ltdocker_v6 2021-08-22] * I (150/1) [10.127.10.253]
    via fe80::42:acff:fe12:335 on ltnet
                     unicast [ltnet_oracle_vm1 2021-08-23 from fdbc:f9dc:67ad:5::1] (100/?) [I]

Otherwise the change seems great.

jlu5 commented 3 years ago

Hmm, what about doing a regex split on all the possible values for destination type? Based on https://gitlab.nic.cz/labs/bird/-/blob/master/nest/rt-attr.c#L81-87 and https://gitlab.nic.cz/labs/bird/-/blob/master/nest/rt-show.c#L68-69 these seem to be unicast, blackhole, unreachable, prohibited, or an empty string (though I'm not sure what scenarios would cause the last one)

For reference, here's an example where splitting on via doesn't work - the first route uses dev igp-dummy2 instead:

Table master4:
172.22.108.22/32     unicast [direct1 2021-08-27] * (240)
    dev igp-dummy2
    Type: device univ
                     unicast [int_babel 23:01:50.895 from fe80::122] (130/39) [00:00:00:00:ac:14:e5:7a]
    via 192.168.88.122 on igp-us-lax01
    Type: Babel univ
    Babel.metric: 39
    Babel.router_id: 00:00:00:00:ac:14:e5:7a
xddxdd commented 3 years ago

Hmm, what about doing a regex split on all the possible values for destination type? Based on https://gitlab.nic.cz/labs/bird/-/blob/master/nest/rt-attr.c#L81-87 and https://gitlab.nic.cz/labs/bird/-/blob/master/nest/rt-show.c#L68-69 these seem to be unicast, blackhole, unreachable, prohibited, or an empty string (though I'm not sure what scenarios would cause the last one)

Sounds OK, I guess the list of values won't change anytime soon.