- Bird-users - Mailing Lists

BGP MD5 with Juniper Router
by Rashed Alwarrag 26 Mar '13

26 Mar '13

Dear birds Experts we have a BGP peer between Bird server and Juniper devices , we mentioned that in our Juniper router wrong MD5 password log appear as below kernel: %KERN-4: tcp_auth_ok: Packet from 192.168.0.10:179 wrong MD5 digest when we capture the BGP update we mentioned that the bird server is sending to the router the update with an unexpected MD5 key and The router ignore this update then again the bird server retransmit the same update with correct MD5 is this issue is expected in bird server or is there any known bug/PR for this issue in Bird *Rashed Alwarrag *

4 5

Review my BGP configuration
by Andre Nathan 25 Mar '13

25 Mar '13

Hello I have just put my first bird router up in production. Everything is working fine, but I wonder if there are any modifications that I can do to my configuration to optimize it and/or adhere best practicess. My prefix is, in the configuration bellow, a.b.0.0/23, but I want to export it as two separate /24 prefixes, a.b.0.0/24 and a.b.1.0/24. Aditional information: Router ID: x.y.z.w Local AS: 1234 Neighbor ID: w.z.y.x Neighbor AS: 4321 The neighbor router is not directly connected to my router, so I'm using multihop. The part that is bugging me about this configuration is the need for a kernel protocol black list filter. Is there a cleaner way to do this? Bellow is my bird.conf: # Protocol kernel: the black list is so that the routes for # the two /24 reject routes from the static protocol are not # added to the kernel routing table. This kinda smells fishy. # Is there a way around this? filter kernel_filter prefix set KERNEL_BLACKLIST; { KERNEL_BLACKLIST = [ a.b.0.0/24, a.b.1.0/24 ]; if net ~ KERNEL_BLACKLIST then { reject; } accept; } protocol kernel { scan time 20; export filter kernel_filter; } protocol device { scan time 10; } # Prefixes to be exported to BGP, plus a route to the BGP neighbor: protocol static mynetwork { route a.b.0.0/24 reject; route a.b.1.0/24 reject; route w.z.y.x/32 via w.z.y.1; } # The file below contains a single definition: define BGP_MED=200. # This is used when, due to failover, the iBGP peer becomes the # preferred router. A script is executed changing the MED value to # 100 and bird is reloaded. The iBGP peer (which has MED 100) will # analogously be modified to 200, and thus become the preferred # router from my provider's router's point of view. include "/etc/bird-med.conf" # BGP export filter: export my prefixes. filter ebgp_out prefix set EXPORT_WHITELIST; { EXPORT_WHITELIST = [ a.b.c.0/23, a.b.c.0/24, a.b.c.1/24 ]; if net ~ EXPORT_WHITELIST then { bgp_med = BGP_MED; accept; } reject; } # BGP import filters: reject RFC1918 stuff. filter ebgp_in prefix set IMPORT_BLACKLIST; { IMPORT_BLACKLIST = [...]; if net ~ IMPORT_BLACKLIST then { printn "Discarding received route to "; print net; reject; } accept; } # # BGP sessions # protocol bgp eBGP { description "eBGP"; local as 1234; source address x.y.z.w; neighbor w.z.y.x as 4321; multihop 2; default bgp_local_pref 200; export filter ebgp_out; import filter ebgp_in; } protocol bgp iBGP { description "iBGP"; local as 1234; source address x.y.z.w; neighbor x.y.z.k as 262672; next hop self; gateway direct; default bgp_local_pref 100; } Thanks in advance, Andre

3 23

bird 1.3.9 - show bgp summary command
by Javor Kliachev 24 Mar '13

24 Mar '13

2 1

Pipe collision detected - how to merge tables?
by Dan Rimal 21 Mar '13

21 Mar '13

Hello, I have problem with pipe collision detected with bird.. i would like to have separate routing table for tranzit bgp peers and another table for internet exchange peers, but i need merge routes from this two tables to master table.. but there is problem with Pipe collision detected, because there is a lot of the same routes from both tables. Is there any way how to merge tables with aware of localpref or something like this? Maybe protocol preference? Regards, Dan

1 1

bird is in use by cloudflare
by Allan Pinto 07 Mar '13

07 Mar '13

hit hackernews today http://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p -- Thanx and regd's. Allan. http://tamahatta.com

1 1

Export static route without inserting it into the kernel table
by listas＠adminlinux.com.br 03 Mar '13

03 Mar '13

Hi!   I have a prefix 192.168.32.0/23 and its route is already in the kernel table. But I want to export two prefixes / 24 (192.168.32.0/24 and 192.168.33.0/24) without necessarily insert in kernel static routes for the two prefixes / 24.   What a better way to do this? Thanks -- Thiago Henrique www.adminlinux.com.br

2 1

Latency based path selection
by Ryan Whelan 01 Mar '13

01 Mar '13

Is it possible to make route selection based on path latency? (or even delegate path selection to an external app/program/api?) I'm currently using ospf (but can really use any igp) to manage routing in a system with many end nodes all connected together via a handful of servers (via vpn links) which are spread across the country. The problem is, the 'end nodes' are always moving/relocating and currently have to be manually updated to use which ever server(s) are closest / quickest. It would be nice if there was a method or protocol that could make path selection based on lowest avg latency. The applications that transverse the network aren't bandwidth intensive, but are very latency sensitive so detecting and using the lowest latency path would ideal. Any input / suggestions would be greatly appreciated!

5 5

[PATCH 1/1] Add 'real netmask' OSPF option improving interoperability.
by Alexander V. Chernikov 01 Mar '13

01 Mar '13

--- doc/bird.sgml | 8 ++++++++ proto/ospf/config.Y | 3 ++- proto/ospf/hello.c | 3 ++- proto/ospf/iface.c | 1 + proto/ospf/ospf.h | 2 ++ 5 files changed, 15 insertions(+), 2 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index e83cf0e..4d6212d 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -1935,6 +1935,7 @@ protocol ospf <name> { nonbroadcast|nbma|pointomultipoint|ptmp]; strict nonbroadcast <switch>; real broadcast <switch>; + real netmask <switch>; check link <switch>; ecmp weight <num>; authentication [none|simple|cryptographic]; @@ -2178,6 +2179,13 @@ protocol ospf <name> { probably is not interoperable with other OSPF implementations. Default value is no. + <tag>real netmask<m/switch/</tag> + In <cf/type ptp/ network configuration, hello packets are sent + with netmask of 0.0.0.0. Some OSPF implementations perform + strict netmask checking even for point-to-point links. This + option enables sending real network mask for <cf/type ptp/ + interfaces. Default value is no. + <tag>check link <M>switch</M></tag> If set, a hardware link state (reported by OS) is taken into consideration. When a link disappears (e.g. an ethernet cable is diff --git a/proto/ospf/config.Y b/proto/ospf/config.Y index 3f09afb..8078f99 100644 --- a/proto/ospf/config.Y +++ b/proto/ospf/config.Y @@ -131,7 +131,7 @@ CF_KEYWORDS(NONE, SIMPLE, AUTHENTICATION, STRICT, CRYPTOGRAPHIC) CF_KEYWORDS(ELIGIBLE, POLL, NETWORKS, HIDDEN, VIRTUAL, CHECK, LINK) CF_KEYWORDS(RX, BUFFER, LARGE, NORMAL, STUBNET, HIDDEN, SUMMARY, TAG, EXTERNAL) CF_KEYWORDS(WAIT, DELAY, LSADB, ECMP, LIMIT, WEIGHT, NSSA, TRANSLATOR, STABILITY) -CF_KEYWORDS(GLOBAL, LSID, ROUTER, SELF, INSTANCE, REAL) +CF_KEYWORDS(GLOBAL, LSID, ROUTER, SELF, INSTANCE, REAL, NETMASK) %type <t> opttext %type <ld> lsadb_args @@ -289,6 +289,7 @@ ospf_iface_item: | TYPE POINTOMULTIPOINT { OSPF_PATT->type = OSPF_IT_PTMP ; } | TYPE PTMP { OSPF_PATT->type = OSPF_IT_PTMP ; } | REAL BROADCAST bool { OSPF_PATT->real_bcast = $3; if (OSPF_VERSION != 2) cf_error("Real broadcast option requires OSPFv2"); } + | REAL NETMASK bool { OSPF_PATT->real_netmask = $3; if (OSPF_VERSION != 2) cf_error("Real netmask option requires OSPFv2"); } | TRANSMIT DELAY expr { OSPF_PATT->inftransdelay = $3 ; if (($3<=0) || ($3>65535)) cf_error("Transmit delay must be in range 1-65535"); } | PRIORITY expr { OSPF_PATT->priority = $2 ; if (($2<0) || ($2>255)) cf_error("Priority must be in range 0-255"); } | STRICT NONBROADCAST bool { OSPF_PATT->strictnbma = $3 ; } diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c index 6ec5c51..cc82a2d 100644 --- a/proto/ospf/hello.c +++ b/proto/ospf/hello.c @@ -253,7 +253,8 @@ ospf_hello_send(struct ospf_iface *ifa, int kind, struct ospf_neighbor *dirn) #ifdef OSPFv2 pkt->netmask = ipa_mkmask(ifa->addr->pxlen); ipa_hton(pkt->netmask); - if ((ifa->type == OSPF_IT_VLINK) || (ifa->type == OSPF_IT_PTP)) + if ((ifa->type == OSPF_IT_VLINK) || + ((ifa->type == OSPF_IT_PTP) && !ifa->real_netmask)) pkt->netmask = IPA_NONE; #endif diff --git a/proto/ospf/iface.c b/proto/ospf/iface.c index 290a863..e439d61 100644 --- a/proto/ospf/iface.c +++ b/proto/ospf/iface.c @@ -537,6 +537,7 @@ ospf_iface_new(struct ospf_area *oa, struct ifa *addr, struct ospf_iface_patt *i #ifdef OSPFv2 ifa->autype = ip->autype; ifa->passwords = ip->passwords; + ifa->real_netmask = ip->real_netmask; #endif #ifdef OSPFv3 diff --git a/proto/ospf/ospf.h b/proto/ospf/ospf.h index 7111a13..0bba301 100644 --- a/proto/ospf/ospf.h +++ b/proto/ospf/ospf.h @@ -273,6 +273,7 @@ struct ospf_iface u16 rxbuf; /* Buffer size */ u8 check_link; /* Whether iface link change is used */ u8 ecmp_weight; /* Weight used for ECMP */ + u8 real_netmask; /* Send real netmask for P2P */ }; struct ospf_md5 @@ -810,6 +811,7 @@ struct ospf_iface_patt u8 check_link; u8 ecmp_weight; u8 real_bcast; /* Not really used in OSPFv3 */ + u8 real_netmask; /* Not really used in OSPFv3 */ #ifdef OSPFv2 list *passwords; -- 1.7.3.2 --------------040401090006070400080809--

1 0

OSPF: network mask for PtP links
by Alexander V. Chernikov 28 Feb '13

28 Feb '13

Hello list! Currently bird uses '0.0.0.0' network mask in OSPF hello messages for ptp links. This is (at least originally) done to catch possible misconfiguration at the other end. RFC 2328 sec 10.5 tells us that this is perfectly OK and network mask should be ignored for p2p and virtual links. However, Juniper interprets RFC more formally and their point is that Ethernet is not real point-to-point interface, so network mask is checked anyway. See http://kb.juniper.net/InfoCenter/index?page=content&id=KB23533 for more detailed explanation. This check kills bird ability to establish p2p link with Juniper boxes. Cisco and Huawei (at least some models) ignores netmask as they should, but sends real network mask in hello messages. Maybe it will be useful to make bird behavior configurable: patch adding 'real mask <switch>' interface option is attached.

1 0

bird: show route behaviour
by Dan Rimal 25 Feb '13

25 Feb '13

Hello all, I make some testbed and testing some scenarios and i found weird "show route" behaviour. I have 2 bgp peers without filter. First router, called testr1, has 3 tables: master, t_nix and t_tranzit. Second router called "nix1_nix" has quite default settings. Conf file from testr1 is attached. To every single table on testr1 is imported 1 different static route via protocol static. Tables t_nix and t_tranzit are "piped" to master table, opposite direction is filtered. BGP peer nix1_nix is defined with "table t_nix". This is "show protocols" on tesr1: device1 Device master up 00:29 kernel1 Kernel master up 00:29 k_nix Kernel t_nix up 00:29 k_tranzit Kernel t_tranzit up 00:29 p_nix Pipe t_nix up 00:29 => master p_tranzit Pipe t_tranzit up 00:29 => master s_master Static master up 00:29 s_nix Static t_nix up 00:29 s_tranzit Static t_tranzit up 00:29 nix1_nix BGP t_nix up 00:29 Established There is route tables print. Table t_nix has imported default route from nix1_nix and table master has the same default route imported through pipe from t_nix (this is correct, just explanation): bird> show route table master 0.0.0.0/0 via 192.168.1.3 on eth1 [nix1_nix 00:29] ! (100) [AS65000i] 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) bird> show route table t_nix 0.0.0.0/0 via 192.168.1.3 on eth1 [nix1_nix 00:29] * (100) [AS65000i] 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) bird> show route table t_tranzit 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) Weird show behaviour comes now: bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:29] * (200) 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:29] * (200) 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:29] * (200) It show all routes from all tables, although table t_nix is defined on this peer. But, nix1_nix receive only one route, correct route from t_nix table: bird> show protocols name proto table state since info device1 Device master up 00:28 kernel1 Kernel master up 00:28 r1 BGP master up 00:29 Established bird> show route protocol r1 5.5.5.0/24 via 192.168.1.1 on eth1 [r1 00:29] * (100) [AS64000i] I tryid simplify scenario and delete pipes to master table temporarily and situation looks this way: testr1: bird> show protocols name proto table state since info device1 Device master up 00:31 kernel1 Kernel master up 00:31 k_nix Kernel t_nix up 00:31 k_tranzit Kernel t_tranzit up 00:31 s_master Static master up 00:31 s_nix Static t_nix up 00:31 s_tranzit Static t_tranzit up 00:31 nix1_nix BGP t_nix up 00:31 Established bird> bird> show route table master 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:31] * (200) bird> show route table t_nix 0.0.0.0/0 via 192.168.1.3 on eth1 [nix1_nix 00:31] * (100) [AS65000i] 5.5.5.0/24 via 172.17.1.1 on eth0 [s_nix 00:31] * (200) bird> show route table t_tranzit 6.6.6.0/24 via 172.17.1.1 on eth0 [s_tranzit 00:31] * (200) and now, command show route from master table only bird> show route export nix1_nix 4.4.4.0/24 via 172.17.1.1 on eth0 [s_master 00:31] * (200) although peer receive correct route: bird> show route protocol r1 5.5.5.0/24 via 192.168.1.1 on eth1 [r1 00:31] * (100) [AS64000i] It looks like "show" command bug only, which is good, but it is pretty confusing :) Both peers is: Linux testr1 3.4.4-5.fc17.x86_64 #1 SMP Thu Jul 5 20:20:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux running latest: bird> show status BIRD 1.3.9 Regards, Dan

3 11