- Bird-users - Mailing Lists

[PATCH 3/3] FEAT: Add protocol volatile
by Thierry FOURNIER 23 Aug '13

23 Aug '13

--- configure | 4 +- configure.in | 4 +- nest/proto.c | 3 + nest/protocol.h | 2 +- proto/Doc | 1 + proto/volatile/Doc | 1 + proto/volatile/Makefile | 6 ++ proto/volatile/config.Y | 75 ++++++++++++++++++ proto/volatile/volatile.c | 195 ++++++++++++++++++++++++++++++++++++++++++++++ proto/volatile/volatile.h | 46 +++++++++++ 10 files changed, 332 insertions(+), 5 deletions(-) create mode 100644 proto/volatile/Doc create mode 100644 proto/volatile/Makefile create mode 100644 proto/volatile/config.Y create mode 100644 proto/volatile/volatile.c create mode 100644 proto/volatile/volatile.h diff --git a/configure b/configure index 2f4cfd4..8ea9f37 100755 --- a/configure +++ b/configure @@ -2355,11 +2355,11 @@ esac if test "$enable_ipv6" = yes ; then ip=ipv6 SUFFIX=6 - all_protocols=bgp,ospf,pipe,radv,rip,static + all_protocols=bgp,ospf,pipe,radv,rip,static,volatile else ip=ipv4 SUFFIX="" - all_protocols=bgp,ospf,pipe,rip,static + all_protocols=bgp,ospf,pipe,rip,static,volatile fi if test "$given_suffix" = yes ; then diff --git a/configure.in b/configure.in index 96f2a50..227c241 100644 --- a/configure.in +++ b/configure.in @@ -47,11 +47,11 @@ AC_SUBST(runtimedir) if test "$enable_ipv6" = yes ; then ip=ipv6 SUFFIX=6 - all_protocols=bgp,ospf,pipe,radv,rip,static + all_protocols=bgp,ospf,pipe,radv,rip,static,volatile else ip=ipv4 SUFFIX="" - all_protocols=bgp,ospf,pipe,rip,static + all_protocols=bgp,ospf,pipe,rip,static,volatile fi if test "$given_suffix" = yes ; then diff --git a/nest/proto.c b/nest/proto.c index 60495aa..61b3882 100644 --- a/nest/proto.c +++ b/nest/proto.c @@ -718,6 +718,9 @@ protos_build(void) #ifdef CONFIG_BGP proto_build(&proto_bgp); #endif +#ifdef CONFIG_VOLATILE + proto_build(&proto_volatile); +#endif proto_pool = rp_new(&root_pool, "Protocols"); proto_flush_event = ev_new(proto_pool); proto_flush_event->hook = proto_flush_loop; diff --git a/nest/protocol.h b/nest/protocol.h index 033a0ed..6f54ae4 100644 --- a/nest/protocol.h +++ b/nest/protocol.h @@ -75,7 +75,7 @@ void protos_dump_all(void); extern struct protocol proto_device, proto_radv, proto_rip, proto_static, - proto_ospf, proto_pipe, proto_bgp; + proto_ospf, proto_pipe, proto_bgp, proto_volatile; /* * Routing Protocol Instance diff --git a/proto/Doc b/proto/Doc index 16b084f..cb16a43 100644 --- a/proto/Doc +++ b/proto/Doc @@ -5,4 +5,5 @@ C pipe C rip C radv C static +C volatile S ../nest/rt-dev.c diff --git a/proto/volatile/Doc b/proto/volatile/Doc new file mode 100644 index 0000000..2d34a68 --- /dev/null +++ b/proto/volatile/Doc @@ -0,0 +1 @@ +S volatile.c diff --git a/proto/volatile/Makefile b/proto/volatile/Makefile new file mode 100644 index 0000000..8388e27 --- /dev/null +++ b/proto/volatile/Makefile @@ -0,0 +1,6 @@ +source=volatile.c +root-rel=../../ +dir-name=proto/volatile + +include ../../Rules + diff --git a/proto/volatile/config.Y b/proto/volatile/config.Y new file mode 100644 index 0000000..ce9f795 --- /dev/null +++ b/proto/volatile/config.Y @@ -0,0 +1,75 @@ +/* + * BIRD -- Static Protocol Configuration + * + * (c) 2013--2013 Thierry FOURNIER <tfournier(a)exceliance.fr> + * + * Can be freely distributed and used under the terms of the GNU GPL. + */ + +CF_HDR + +#include "proto/volatile/volatile.h" + +CF_DEFINES + +#define VOLATILE_CFG ((struct volatile_config *) this_proto) + +CF_DECLS + +%type <px> prefix_autocorrect + +CF_KEYWORDS(VOLATILE, SET, DEL, CLEAR, GATEWAY) +CF_KEYWORDS(MULTIPATH, WEIGHT) + +CF_GRAMMAR + +CF_ADDTO(proto, volatile_proto '}') + +volatile_proto_start: proto_start VOLATILE { + this_proto = proto_config_new(&proto_volatile, sizeof(struct volatile_config), $1); + } + ; + +volatile_proto: + volatile_proto_start proto_name '{' + | volatile_proto GATEWAY ipa ';' { + VOLATILE_CFG->gateway = $3; + VOLATILE_CFG->use_gateway = 1; + } + ; + +prefix_autocorrect: + ipa pxlen { + $$.addr = $1; + $$.len = $2; + ip_addr mask = ipa_mkmask($2); + $$.addr = ipa_and($$.addr, mask); + } + ; + + +CF_CLI_HELP(CONFIGURE VOLATILE, {set|del|clear}, [[Configure volatile routes]]) + +CF_CLI(CONFIGURE VOLATILE SET, optsym prefix_autocorrect, + <name> <network>/<netmask>, + [[Add or set volatile routes]]) +{ volatile_configure_set(proto_get_named($4, &proto_volatile), $5); } ; + +CF_CLI(CONFIGURE VOLATILE DEL, optsym prefix_autocorrect, + <name> <natwork>/<netmask>, + [[Delete volatile routes]]) +{ volatile_configure_del(proto_get_named($4, &proto_volatile), $5); } ; + +CF_CLI(CONFIGURE VOLATILE CLEAR, optsym, + <name>, + [[Clear volatile routes]]) +{ volatile_configure_clear(proto_get_named($4, &proto_volatile)); } ; + +CF_CLI(SHOW VOLATILE, optsym, + <name>, + [[Show volatile routes]]) +{ volatile_show(proto_get_named($3, &proto_volatile)); } ; + +CF_CODE + +CF_END diff --git a/proto/volatile/volatile.c b/proto/volatile/volatile.c new file mode 100644 index 0000000..80518b9 --- /dev/null +++ b/proto/volatile/volatile.c @@ -0,0 +1,195 @@ +/* + * BIRD -- Volatile Route Generator + * + * (c) 2013--2013 Thierry FOURNIER <tfournier(a)exceliance.fr> + * + * Can be freely distributed and used under the terms of the GNU GPL. + */ + +/** + * DOC: Volatile + * + * The volatile protocol take routes from the cli. These routes are annouced + * to the peers. These routes cannot be exists on the host or cannot correspond + * to any ip address on any interface. + * + * This type of announce is useful for services using transparent binding. + * The transparent binding is used tipically with proxy for proxifying HTTP + * connections. The user add route announcement and the destination is rerouted + * to the transparent proxy. + */ + +#include "nest/bird.h" +#include "nest/iface.h" +#include "nest/protocol.h" +#include "nest/route.h" +#include "nest/cli.h" +#include "conf/conf.h" +#include "lib/string.h" +#include "lib/alloca.h" + +#include "volatile.h" + +struct iface any = { + .name = "auto" +}; + +static void +volatile_install(struct volatile_proto *p, ip_addr net, unsigned int masklen) +{ + struct network *network; + struct rta route_attr_lookup; + struct rta *route_attr; + struct rte *route; + struct neighbor *neigh; + struct iface *iface; + + /* find neighbor for the gateway */ + if (p->cf->use_gateway) { + neigh = neigh_find(&p->p, &p->cf->gateway, NEF_STICKY); + if (!neigh || !neigh->iface) { + log(L_INFO "Cannot find neighbor for the gateway %I", p->cf->gateway); + return; + } + iface = neigh->iface; + } + + else + iface = &any; + + /* prepare route attrinutes lookup */ + bzero(&route_attr_lookup, sizeof(struct rta)); + route_attr_lookup.proto = &p->p; + route_attr_lookup.scope = SCOPE_UNIVERSE; + route_attr_lookup.cast = RTC_UNICAST; + route_attr_lookup.iface = iface; + if (p->cf->use_gateway) { + route_attr_lookup.gw = p->cf->gateway; + route_attr_lookup.source = RTS_STATIC; + route_attr_lookup.dest = RTD_ROUTER; + } + else { + route_attr_lookup.source = RTS_DEVICE; + route_attr_lookup.dest = RTD_DEVICE; + } + + /* lookup or add route attribute entry. This call never fail */ + route_attr = rta_lookup(&route_attr_lookup); + + /* get network entry into the table. This function never fail */ + network = net_get(p->p.table, net, masklen); + + /* get temporary route, and set attributes */ + route = rte_get_temp(route_attr); + route->net = network; + route->pflags = 0; + + /* update the route */ + rte_update(p->p.table, network, &p->p, &p->p, route); +} + +static void +volatile_remove(struct volatile_proto *p, ip_addr net, unsigned int masklen) +{ + struct network *network; + + /* lookup for network entry. if found remove it */ + network = net_find(p->p.table, net, masklen); + if (network) + rte_update(p->p.table, network, &p->p, &p->p, NULL); +} + +/* this function initialize configuration structs */ +static struct proto * +volatile_init(struct proto_config *C) +{ + struct volatile_config *c = (struct volatile_config *) C; + struct proto *P = proto_new(C, sizeof(struct volatile_proto)); + struct volatile_proto *p = (struct volatile_proto *) P; + + p->cf = c; + return P; +} + +struct protocol proto_volatile = { + name: "Volatile", + template: "volatile%d", + init: volatile_init, +}; + +/* this fucntion install new route */ +void +volatile_configure_set(struct proto *P, struct prefix net) +{ + struct volatile_proto *p = (struct volatile_proto *) P; + + volatile_install(p, net.addr, net.len); + cli_msg(0, ""); +} + +/* this fucntion delete known route */ +void +volatile_configure_del(struct proto *P, struct prefix net) +{ + struct volatile_proto *p = (struct volatile_proto *) P; + + volatile_remove(p, net.addr, net.len); + cli_msg(0, ""); +} + +/* this cli function delete all route with restarting protocol */ +void +volatile_configure_clear(struct proto *P) +{ + proto_cmd_restart(P, 0, 0); + cli_msg(0, ""); +} + +void +volatile_show(struct proto *P) +{ + struct volatile_proto *p = (struct volatile_proto *) P; + struct rte *route; + struct rta *attrs; + struct network *network; + + FIB_WALK(&p->p.table->fib, fn) { + network = (struct network *)fn; + for (route = network->routes; + route; + route = route->next) { + + if (route->attrs->proto != P) + continue; + + network = route->net; + attrs = route->attrs; + + if (!network) { + cli_msg(-1009, "???"); + continue; + } + + switch (attrs->dest) { + + case RTD_ROUTER: + cli_msg(-1009, "%I/%2d via %I dev %s", + network->n.prefix, network->n.pxlen, attrs->gw, + attrs->iface ? attrs->iface->name : "???"); + break; + + case RTD_DEVICE: + cli_msg(-1009, "%I/%2d dev auto", + network->n.prefix, network->n.pxlen); + break; + + default: + cli_msg(-1009, "%I/%2d ???", + network->n.prefix, network->n.pxlen); + break; + } + } + } FIB_WALK_END; + + cli_msg(0, ""); +} diff --git a/proto/volatile/volatile.h b/proto/volatile/volatile.h new file mode 100644 index 0000000..fd43873 --- /dev/null +++ b/proto/volatile/volatile.h @@ -0,0 +1,46 @@ +/* + * BIRD -- Volatile Route Generator + * + * (c) 2013--2013 Thierry FOURNIER <tfournier(a)exceliance.fr> + * + * Can be freely distributed and used under the terms of the GNU GPL. + */ + +#ifndef _BIRD_VOLATILE_H_ +#define _BIRD_VOLATILE_H_ + +struct volatile_config { + struct proto_config c; + int use_gateway; + ip_addr gateway; +}; + +struct volatile_proto { + struct proto p; + struct volatile_config *cf; /* Shortcut to volatile configuration */ +}; + +void volatile_init_config(struct volatile_config *); + +struct volatile_route { + node n; + struct volatile_route *chain; /* Next for the same neighbor */ + ip_addr net; /* Network we route */ + int masklen; /* Mask length */ + int dest; /* Destination type (RTD_*) */ + ip_addr via; /* Destination router */ + struct neighbor *neigh; + byte *if_name; /* Name for RTD_DEVICE routes */ + struct volatile_route *mp_next; /* Nexthops for RTD_MULTIPATH routes */ + int installed; /* Installed in master table */ +}; + +/* Dummy nodes (parts of multipath route) abuses masklen field for weight + and if_name field for a ptr to the master (RTD_MULTIPATH) node. */ + +void volatile_configure_set(struct proto *P, struct prefix net); +void volatile_configure_del(struct proto *P, struct prefix net); +void volatile_configure_clear(struct proto *P); +void volatile_show(struct proto *P); + +#endif -- 1.8.1.1 --Multipart=_Tue__24_Sep_2013_16_35_48_+0200_AMU0Imo+Flc+Ayzu--

1 0

kernel: missing 'prefsrc' when installing route to KRT (original BIRD, no patches)
by Sergey Popovich 23 Aug '13

23 Aug '13

Hello community! While ago I write to list about importance of 'prefsrc' (BIRD's name krt_prefsrc) in Linux network stack (see thread "kernel: does not learn routes with RTPROT_KERNEL (proto kernel in ip-route(8) output)"). However there is another problem with kernel protocol, I spot when *restarting* bird: bird wont install krt_prefsrc attribute when installing route to KRT for routes learned via kernel syncer from another KRT and distributed between BIRD's routing tables via pipe protocol, after daemon restart. There is completely clear bird build without any patches (including patch in maillist thread I point above). Tests was done on Linux 3.8.13 and Linux 3.2.42 kernels. Also I try bird 1.3.9 among with 1.3.11 with some results as with 1.3.11. Here is simple configuration, steps and debugging output from BIRD. --------------------------------------------------------------------------------------- # Configure logging log syslog all; log stderr all; router id 172.16.1.1; protocol device devices { scan time 15; } ### KRT 10 table rt_10; protocol kernel kernel10 { table rt_10; debug all; persist no; scan time 15; learn yes; device routes no; kernel table 10; import where krt_source = ipp_static; export none; } ### KRT 20 table rt_20; protocol kernel kernel20 { table rt_20; debug all; persist no; scan time 15; learn no; device routes no; kernel table 20; import none; export all; } ### pipe 10->20 protocol pipe pipe10 { table rt_10; peer table rt_20; import none; export all; } Wery simple config: two bird RT, with kernel syncer attached to each, connected trought pipe protocol. "kernel10" only learns routes from KRT id 10 with RTPROTO_STATIC to rt_10 and then "pipe10" export these routes to rt_20 table, where kernel syncer installs everything from rt_20 to KRT id 20. Now, on console, before starting bird: ----------------------------------------------- # ip link set up dev lo255 # ip link set up dev lo254 # ip -4 addr add 172.16.254.1/24 dev lo254 # ip -4 addr add 172.16.255.1/24 dev lo255 # ip -4 addr show dev lo254 14: lo254: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN inet 172.16.254.1/24 scope global lo254 # ip -4 addr show dev lo255 15: lo255: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN inet 172.16.255.1/24 scope global lo255 # ip -4 route show table 10 # ip -4 route show table 20 Create, setup and configure two (lo254, Lo255) Linux dummy interfaces, show KRT id 10, 20. Starting bird in debug mode in foreground: ------------------------------------------------------ [root@tuxracer etc]# bird -d 22-08-2013 12:46:50 <TRACE> kernel10: Initializing 22-08-2013 12:46:50 <TRACE> kernel20: Initializing 22-08-2013 12:46:50 <TRACE> kernel10: Starting 22-08-2013 12:46:50 <TRACE> kernel10: Connected to table rt_10 22-08-2013 12:46:50 <TRACE> kernel10: State changed to feed 22-08-2013 12:46:50 <TRACE> kernel20: Starting 22-08-2013 12:46:50 <TRACE> kernel20: Connected to table rt_20 22-08-2013 12:46:50 <TRACE> kernel20: State changed to feed 22-08-2013 12:46:50 <INFO> Started 22-08-2013 12:46:50 <TRACE> kernel10: State changed to up 22-08-2013 12:46:50 <TRACE> kernel20: State changed to up 22-08-2013 12:46:50 <TRACE> kernel10: Scanning routing table 22-08-2013 12:46:50 <TRACE> kernel10: Pruning table rt_10 22-08-2013 12:46:50 <TRACE> kernel10: Pruning inherited routes 22-08-2013 12:46:50 <TRACE> kernel20: Pruning table rt_20 # birdc 'show route table rt_10' BIRD 1.3.11 ready. # birdc 'show route table rt_20' BIRD 1.3.11 ready. # birdc 'show route table master' BIRD 1.3.11 ready. # birdc 'show protocols' BIRD 1.3.11 ready. name proto table state since info devices Device master up 12:46 kernel10 Kernel rt_10 up 12:46 kernel20 Kernel rt_20 up 12:46 pipe10 Pipe rt_10 up 12:46 => rt_20 Then on another console: --------------------------------- # ip -4 route add 192.168.1.0/24 table 10 proto static src 172.16.255.1 via 172.16.254.254 # ip -4 route show table 10 192.168.1.0/24 via 172.16.254.254 dev lo254 proto static src 172.16.255.1 # ip -4 route show table 20 192.168.1.0/24 via 172.16.254.254 dev lo254 proto bird src 172.16.255.1 There is no problem with 'prefsrc' when received async notification from kernel. and BIRD debug output: ------------------------------- 22-08-2013 12:52:50 <TRACE> kernel10: Scanning routing table 22-08-2013 12:52:50 <TRACE> kernel10: Pruning table rt_10 22-08-2013 12:52:50 <TRACE> kernel10: Pruning inherited routes 22-08-2013 12:52:50 <TRACE> kernel20: Pruning table rt_20 22-08-2013 12:52:50 <TRACE> kernel10: 192.168.1.0/24: [alien async] created 22-08-2013 12:52:50 <TRACE> kernel10 > added [best] 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:52:50 <TRACE> kernel20 < added 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:52:50 <TRACE> kernel10 < rejected by protocol 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:53:05 <TRACE> kernel10: Scanning routing table 22-08-2013 12:53:05 <TRACE> kernel10: 192.168.1.0/24: [alien] seen 22-08-2013 12:53:05 <TRACE> kernel20: 192.168.1.0/24: seen 22-08-2013 12:53:05 <TRACE> kernel10: Pruning table rt_10 22-08-2013 12:53:05 <TRACE> kernel10: Pruning inherited routes 22-08-2013 12:53:05 <TRACE> kernel20: Pruning table rt_20 Terminate bird on console and flush KRT 10, 20: ------------------------------------------------------------ # ip -4 route show table 10 192.168.1.0/24 via 172.16.254.254 dev lo254 proto static src 172.16.255.1 # ip -4 route show table 20 192.168.1.0/24 via 172.16.254.254 dev lo254 proto bird src 172.16.255.1 # ip -4 route flush table 10 # ip -4 route flush table 20 # ip -4 route show table 10 # ip -4 route show table 20 Now add route to KRT 10 from previous example and start bird: -------------------------------------------------------------------------------- # ip -4 route add 192.168.1.0/24 table 10 proto static src 172.16.255.1 via 172.16.254.254 # ip -4 route show table 10 192.168.1.0/24 via 172.16.254.254 dev lo254 proto static src 172.16.255.1 # ip -4 route show table 20 # bird -d 22-08-2013 12:57:59 <TRACE> kernel10: Initializing 22-08-2013 12:57:59 <TRACE> kernel20: Initializing 22-08-2013 12:57:59 <TRACE> kernel10: Starting 22-08-2013 12:57:59 <TRACE> kernel10: Connected to table rt_10 22-08-2013 12:57:59 <TRACE> kernel10: State changed to feed 22-08-2013 12:57:59 <TRACE> kernel20: Starting 22-08-2013 12:57:59 <TRACE> kernel20: Connected to table rt_20 22-08-2013 12:57:59 <TRACE> kernel20: State changed to feed 22-08-2013 12:57:59 <INFO> Started 22-08-2013 12:57:59 <TRACE> kernel10: State changed to up 22-08-2013 12:57:59 <TRACE> kernel20: State changed to up 22-08-2013 12:57:59 <TRACE> kernel10: Scanning routing table 22-08-2013 12:57:59 <TRACE> kernel10: 192.168.1.0/24: [alien] created 22-08-2013 12:57:59 <TRACE> kernel10: Pruning table rt_10 22-08-2013 12:57:59 <TRACE> kernel10: Pruning inherited routes 22-08-2013 12:57:59 <TRACE> kernel10 > added [best] 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:57:59 <TRACE> kernel20 < added 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:57:59 <TRACE> kernel10 < rejected by protocol 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:57:59 <TRACE> kernel20: Pruning table rt_20 22-08-2013 12:57:59 <TRACE> kernel20: 192.168.1.0/24: reinstalling and catch: ------------- # ip -4 route show table 10 192.168.1.0/24 via 172.16.254.254 dev lo254 proto static src 172.16.255.1 # ip -4 route show table 20 192.168.1.0/24 via 172.16.254.254 dev lo254 proto bird and bird RT output: ------------------------ # birdc 'show route table rt_10 all' BIRD 1.3.11 ready. 192.168.1.0/24 via 172.16.254.254 on lo254 [kernel10 12:57] * (10) Type: inherit unicast univ Kernel.source: 4 Kernel.metric: 0 Kernel.prefsrc: 172.16.255.1 # birdc 'show route table rt_20 all' BIRD 1.3.11 ready. 192.168.1.0/24 via 172.16.254.254 on lo254 [kernel10 12:57] * (10) Type: inherit unicast univ Kernel.source: 4 Kernel.metric: 0 Kernel.prefsrc: 172.16.255.1 Why BIRD does not install/update route with correct 'prefsrc' it it is known even after pipe to another table? When deleting this route from '10' and then adding it again, everything is ok (as with previous example). -- SP5474-RIPE Sergey Popovich

2 3

High-availability BGP with BIRD
by Thomas Johnson 22 Aug '13

22 Aug '13

Please let me know if bird-users is not the appropriate place for this post; admittedly it is more of a "best practices" question... I am in the process of trying to develop a plan for deploying BGP in a high-availability configuration, using a pair of FreeBSD hosts running BIRD. A number of questions have come up, leaving me unsure how to proceed. The fact that this is my first experience with BGP doesn't help matters. The following diagram outlines how I envision the [physical] configuration. +----------+ +------+ router-a +-------+ xxxxxxxx +----------+ | xx xx +--+-----+ +------------+ xx LAN x + switch +-------| ISP router | x xx +--+-----+ +------------+ xx xxxxx +----------+ | xxxxx +------+ router-b +-------+ +----------+ I dumped this in a pastebin, in case my mail client mauls it..http://pastebin.com/rDTDMA7j In this scenario, router-a and router-b are running FreeBSD, with CARP to provide a virtual IP for failover. The two routers act in a failover manner, with router-b taking over the virtual IP upon failure of router-a. The goal is to maintain the fast failover (seconds) that I get from CARP in non-BGP configurations. I am wondering if the following method is a common/feasible/best solution. Under normal conditions. * BOTH router-a and router-b establish BGP sessions to the ISP. This way, each router has a copy of the BGP routing table in memory, ready to go. * router-a advertises my prefixes to the ISP router. * all regular traffic is handled by router-a. If router-a fails. * Programmatically update the router-b BIRD config to begin advertising prefixes. * router-b already has the BGP table in memory, so routing can resume immediately. Is there a better way to achieve this? Will my ISP laugh at me when I ask them to assign me a /29, and allow me to run two BGP sessions? Thank you! TJ -- This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender or call ClaimLynx at (952) 593-5969.

4 3

Re: Antwort: High-availability BGP with BIRD
by Thomas Johnson 22 Aug '13

22 Aug '13

Daniel, thanks for the confirmation that I'm not completely crazy. I probably should have mentioned it my initial message, but didn't in the interest of clarity. We will be connecting two uplinks to these routers, and the intention is to receive a full BGP table from each. Additionally, we are peering with a local exchange. The routers have 4GB RAM each, which we assumed would be more than sufficient. Is this accurate? How about with IPv6 on top? Thanks! TJ On Aug 22, 2013 4:05 AM, "Daniel Gomez" <Daniel.Gomez(a)synaix.de> wrote: > > > > > Hi Thomas, > > That is not a bad idea. It is possible to make High Availability on the LAN > interfaces and to have two different eBGP Sessions on the WAN interfaces. > > Since you are "peering" with just one ISP router do not accept Full BGP > Table from it. It will consume a hughe amount of RAM memory that your > system can use for forwarding puposes. > > Do not forget to do iBGP between your routers, it will save you from > routing loops. > > In relation to the /29, it depends on your provider. If you pay for it I do > not think it is a problem ;). > > Greetings, > > Daniel > > > > Von: Thomas Johnson <tom(a)claimlynx.com> > An: bird-users(a)trubka.network.cz > Datum: 22.08.2013 03:08 > Betreff: High-availability BGP with BIRD > Gesendet von: owner-bird-users(a)atrey.karlin.mff.cuni.cz > > > > Please let me know if bird-users is not the appropriate place for this > post; admittedly it is more of a "best practices" question... > > I am in the process of trying to develop a plan for deploying BGP in a > high-availability configuration, using a pair of FreeBSD hosts running > BIRD. A number of questions have come up, leaving me unsure how to > proceed. The fact that this is my first experience with BGP doesn't > help matters. The following diagram outlines how I envision the > [physical] configuration. > > +----------+ > +------+ router-a +-------+ > xxxxxxxx +----------+ | > xx xx +--+-----+ +------------+ > xx LAN x + switch +-------| ISP router | > x xx +--+-----+ +------------+ > xx xxxxx +----------+ | > xxxxx +------+ router-b +-------+ > +----------+ > > I dumped this in a pastebin, in case my mail client mauls > it..http://pastebin.com/rDTDMA7j > > In this scenario, router-a and router-b are running FreeBSD, with CARP > to provide a virtual IP for failover. The two routers act in a > failover manner, with router-b taking over the virtual IP upon failure > of router-a. The goal is to maintain the fast failover (seconds) that > I get from CARP in non-BGP configurations. I am wondering if the > following method is a common/feasible/best solution. > > Under normal conditions. > * BOTH router-a and router-b establish BGP sessions to the ISP. This > way, each router has a copy of the BGP routing table in memory, ready > to go. > * router-a advertises my prefixes to the ISP router. > * all regular traffic is handled by router-a. > > If router-a fails. > * Programmatically update the router-b BIRD config to begin > advertising prefixes. > * router-b already has the BGP table in memory, so routing can resume > immediately. > > Is there a better way to achieve this? Will my ISP laugh at me when I > ask them to assign me a /29, and allow me to run two BGP sessions? > > Thank you! > TJ > > -- > This e-mail and any files transmitted with it are confidential and are > intended solely for the use of the individual or entity to whom they are > addressed. If you are not the intended recipient or the individual > responsible for delivering the e-mail to the intended recipient, please be > advised that you have received this e-mail in error and that any use, > dissemination, forwarding, printing, or copying of this e-mail is strictly > prohibited. > > If you have received this communication in error, please return it to the > sender immediately and delete the original message and any copy of it from > your computer system. If you have any questions concerning this message, > please contact the sender or call ClaimLynx at (952) 593-5969. > > > > -- This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender or call ClaimLynx at (952) 593-5969.

2 1

filters[updated]: strange protocol restarts
by Sergey Popovich 21 Aug '13

21 Aug '13

Hello community!! * Sorry, in original mail (filters: strange protocol restarts) I fogot * to add kernel20 configuration. And again I need to spread some light on BIRD behavior: why bird restarts protocol instead of just reloading it when no filter changes in configuration when using prefix set constant? There is simple configuration and steps to reproduce this ------------------------------------------------------------------------- # Configure logging log syslog all; log stderr all; router id 172.16.1.1; protocol device devices { scan time 15; } ### KRT 10 table rt_10; # This function does not forces "kernel" protocol to reload. function f1(prefix pfx) { if pfx ~ [ 192.168.0.0/16+ ] then return false; return true; } protocol kernel kernel10 { table rt_10; persist no; scan time 15; learn yes; device routes yes; kernel table 10; import where f1(net); export none; } ### KRT 20 table rt_20; # And this does, "kernel" protocol restarts without changing PS_1. define PS_1 = [ 192.168.0.0/16+ ]; function f2(prefix pfx) { if pfx ~ PS_1 then return false; return true; } protocol kernel kernel20 { table rt_20; persist no; scan time 15; learn yes; device routes yes; kernel table 20; import where f2(net); export none; } There is nothing difficult in config: 2 functions f1() and f2() that do same thing except f2() matches specified as parameter prefix to a defined constant of type prefix set (PS_1). Starting bird, and invoking three times on console command to reconfigure bird (birdc configure) without altering configuration file I get following in my syslog: -------------------------------------------------------------------------------- Aug 21 18:50:54 gw1 bird: Started Aug 21 18:50:59 gw1 bird: Reconfiguring Aug 21 18:50:59 gw1 bird: Reloading protocol kernel20 Aug 21 18:50:59 gw1 bird: Restarting protocol kernel20 Aug 21 18:50:59 gw1 bird: Reconfigured Aug 21 18:51:08 gw1 bird: Reconfiguring Aug 21 18:51:08 gw1 bird: Reloading protocol kernel20 Aug 21 18:51:08 gw1 bird: Restarting protocol kernel20 Aug 21 18:51:08 gw1 bird: Reconfigured Aug 21 18:51:08 gw1 bird: Reconfiguring Aug 21 18:51:08 gw1 bird: Reloading protocol kernel20 Aug 21 18:51:08 gw1 bird: Restarting protocol kernel20 Aug 21 18:51:08 gw1 bird: Reconfigured Same thing can be reproduced with other protocols. This is not wery good to restart protocol when no REAL things changed in its filter, as it purges all routes from kernel table, and reinstalls them again causing flap when huge number of routes needed to be reinstalled. Can some one explain to me this behavior of BIRD? Does this mean that usage of constats with type prefix set is not recommended? Thanks for your support. -- SP5474-RIPE Sergey Popovich

1 0

kernel: does not learn routes with RTPROT_KERNEL (proto kernel in ip-route(8) output)
by Сергей Попович 20 Aug '13

20 Aug '13

Hello. Recently I spot following issue with BIRD: kernel syncer does not learn routes with RTPROT_KERNEL even with "learn" and "device routes" turned on. Config is wery simple: # Main routing table (master), mapped to ipt_main kernel table. # ipt_main == 254 (see /etc/iproute2/rt_tables) protocol kernel kernel254 { persist no; scan time 120; learn yes; device routes yes; kernel table ipt_main; import all; export all; } $ birdc 'show route' BIRD 1.3.10 ready. $ ip -4 route show table main 172.16.1.0/24 dev lo255 proto kernel scope link src 172.16.1.254 Can some one explain why this was done, and is there any way other than patching BIRD (at least sysdep/linux/netlink.c does checking and ignoring and sysdep/unix/krt.c makes its final verdict to ignore such route). Background of problem or why this might be important (at least for me). There is lot of text, and no need to read it, however it describes why learning routes with RTPROT_KENREL might be important. ----------------------------------------------------------------------------------------------- There is requirement to create separate Linux kernel RIB and install rules to direct traffic to it (ip-rules(8)). This is an PBR (Policy-Based Routing) BIRD has all necessary means to do that: protocols direct - to learn directly connected routes and pipe to import from main (master in BIRD) routing table some routes. And everything works as expected, except that protocol direct "imports" (better to say create may be?) routes based on interface ip address configuration. Contrary to this, kernel installs such directly connected routes with some attributes: like proto kernel, and very important as I discover src (krt_prefsrc attribute in BIRD). Actually attribute perfsrc used in kernel to determine outgoning source for packets that has no src addresses in it (application does not call bind(2), which is common for UDP). Without prefsrc on route, kernel uses fallback mechanism to find source: this is inet_select_addr() function, which is not ideal in functionality (in some cases strange source address might be choosen), and all it does it looks outgoing interface itself for primary address and other interfaces if interface has no such one). Recent kernels (linux-2.6.39+) has implemented genid table to cache information from inet_select_addr() (commits 436c3b66ec98 "ipv4: Invalidate nexthop cache nh_saddr more correctly." and 1fc050a13473 "ipv4: Cache source address in nexthop entries.") lookups, but implementation has also wholes (for example if interface has zero ip address on it and host on lan referenced by a route with interface as nexthop (so called ip unnumbered in proven vendor terms) as only event to regenerate (and thus recall inet_select_addr()) genid is changing state of the interface (i.e. changing route pointing to device has no chance to regenerate genid and packets might still go with source from previous call to inet_select_addr()). Some distributions with longterm support still provides 2.6.32 kernels. Having system with thousands interfaces and sending UDP for example over all of it is wery expensive in CPU terms. Thus I decided to learn routes from kernel protocol and then pass them trought pipe and install it in new kernel table for PBR. -- SP5474-RIPE Sergey Popovich

4 3

Re: OSPF HELLO wrong mask
by Slawa Olhovchenkov 19 Aug '13

19 Aug '13

On Wed, May 15, 2013 at 07:29:04PM +0200, Ondrej Zajicek wrote: > On Wed, May 15, 2013 at 08:33:08PM +0400, Slawa Olhovchenkov wrote: > > > Interesting > > > What 'show interfaces' and 'show ospf interface' return? > > > And also 'show status' for router id. > > > > ifconfig em0 (full) > > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > > options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO> > > ether 68:05:ca:0e:d3:e1 > > inet 10.254.0.2 netmask 0xffff0000 broadcast 10.254.255.255 > > inet6 fe80::6a05:caff:fe0e:d3e1%em0 prefixlen 64 scopeid 0x1 > > inet 185.17.0.1 netmask 0xffffff00 broadcast 185.17.0.255 > > inet 185.17.1.1 netmask 0xffffff00 broadcast 185.17.1.255 > > inet6 2a03:e2c0:0:1::1 prefixlen 64 > > inet 185.17.2.1 netmask 0xffffff00 broadcast 185.17.2.255 > > inet 185.17.3.1 netmask 0xffffff00 broadcast 185.17.3.255 > > inet 10.90.90.1 netmask 0xfffffff0 broadcast 10.90.90.15 > > inet 193.93.192.1 netmask 0xfffffc00 broadcast 193.93.195.255 > > nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> > > media: Ethernet autoselect (1000baseT <full-duplex>) > > status: active > > So this is a problem with multiple IPs on an iface. On BSD, we support > just one primary address in OSPF (others are just handled as stubs). > Lexicographically smallest address was chosen. Unfortunately the kernel > chose a different one as a source address. Why lexicographically smallest? Why not first from getifaddrs() list? > If you use multiple IPs on an iface in BSD with BIRD, you have to > use option 'primary' of device protocol to specify the proper one: > http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2 10x, working.

5 4

Re: infinite adding of ipv6 routes to kernel table which were recieved from ebgp peer and piped into kernel protocol
by Arnautov Artem 13 Aug '13

13 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is another interesting example on another router router i've added new vlan on physical interface 544 vconfig add enp2s0f1 544 added ipv6 addresses configured static ipv6 route through static protocol and got next strange results # for i in {1..10}; do > ip -6 ro sh dev enp2s0f1.544 echo "----------------------------" > done 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- 2a01:d0:0:31::/64 proto kernel metric 256 2a01:d0:26::/48 via 2a01:d0:0:31::2 proto bird metric 1024 fe80::/64 proto kernel metric 256 - ---------------------------- here is another strange thing # for i in {1..10}; do ip -6 ro sh | wc -l ; echo "----------------------------"; done 328063 - ---------------------------- 320890 - ---------------------------- 202481 - ---------------------------- 330761 - ---------------------------- 197992 - ---------------------------- 40152 - ---------------------------- 36968 - ---------------------------- 47729 - ---------------------------- 451970 - ---------------------------- 181288 - ---------------------------- # cat /proc/sys/net/ipv6/route/max_size 100000 On 08/08/2013 11:07 AM, Arnautov Artem wrote: > On 08/07/2013 08:10 PM, Ondrej Zajicek wrote: >> On Wed, Aug 07, 2013 at 06:33:02PM +0300, Arnautov Artem wrote: >>> today we connected another router to new ipv6 capable uplink >>> and established bgp same problem >> >> Well, i tested now to export 15k IPv6 routes (from static >> protocol) on linux 3.9.2 and didn't noticed any problems. Could >> you send me your output of 'show route' and 'ip ro sh'? >> > > > Hello > > we have such problem on all routers running bird6 and IPv6 full > view recieved through ebgp then piped into master table and then > exported to kernel protocol here is one thing and if we switch to > quagga for ipv6 bgp everything is OK > > output of 'show route' and 'ip ro sh' in attach. > - -- - --- Арнаутов Артем ISP NetAssist +380 44 2398989 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSA2jSAAoJEGj9FDZFr3kFC5AH+wf9cz1sqeDFLJXxJZstszD/ lI4rhRLfyF9iWGZk1fI64VGmUiuMUW8YA9nunpCcYBUwbT3qSTEImsqO56L/OqRI 5w6aQMlPUa/UcejuPU0hW4qpmYwKKgquRtf1IOXNttkT/510lUA6g1cxRTvsLMC1 QwUEDroCex/5ebMcCYMs2cQ0c0AVIQYks/77+4luvCuqT1Ds/mAMNMQXJiiWE4xX 40nTpFto4ZJDTiu35x85hadspwSxcaHmHd1xQGhctDJR0nmSXGKgTXrn/qrnNA8M YxzGvL9MTvYEBN7cmeoE2hKRxUewUK28YIGxCHLoizHIJASuktHceBq39abEfCA= =EiUf -----END PGP SIGNATURE-----

2 1

Determine Address Family (IPv4 or IPv6) in configuration file at runtime
by Sergey Popovich 13 Aug '13

13 Aug '13

Having mostly identical configurations for IPv4 and IPv6 BIRD (especially routing policies) with few AFI specific parts we try to aggregate common part for both IPv4 and IPv6 in external include file. However there is need in some branch parts to known address family at configuration file processing by bird: for example to properly use maximum prefix length (IPv4: 32, IPv6: 128). Is there are any way to known (some constant, etc.) in configuration for which AFI bird was build? -- SP5474-RIPE Sergey Popovich

2 1

Re: infinite adding of ipv6 routes to kernel table which were recieved from ebgp peer and piped into kernel protocol
by Ondrej Zajicek 07 Aug '13

07 Aug '13

On Wed, Aug 07, 2013 at 06:33:02PM +0300, Arnautov Artem wrote: > today we connected another router to new ipv6 capable uplink and > established bgp > same problem Well, i tested now to export 15k IPv6 routes (from static protocol) on linux 3.9.2 and didn't noticed any problems. Could you send me your output of 'show route' and 'ip ro sh'? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago(a)crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

1 0