- Bird-users - Mailing Lists

Question about filters
by Marek Wajdzik 18 Jan '11

18 Jan '11

Hi. I have a small problem with the configuration shown in the diagram below BGP_Peer1 ---\ BGP_Peer2 ----> --- My_BGP_Router ---- BGP_Peer5 BGP_Peer3 ---/ BGP_Peer4 --/

3 3

BIRDs allowas-in functionality
by Bartek Kois 18 Jan '11

18 Jan '11

Hi I`ve got two networks in different locations without any connection between them. In each of them I`ve got two BGP routers connected to two separate ISP`s. Both networks have the same AS number but their BGP routers propagate different prefixes (different /23 prefix for each network). The thing is that hosts inside one network don`t see hosts in the second network, because of BGP anti-loop mechanism. Typically this problem can be solved by using "allowas-in" directive. How to achieve the same functionality in BIRD configuration? Thanks for any help. Best regards Bartek

2 1

Looking glass for bird
by Denis Samsonov 14 Jan '11

14 Jan '11

who uses the looking glass for bird? I can not find a ready solution: ( who can share their interface or show where to download? PS. Thanks in advance. My English is very bad, sorry

2 1

Re: ECMP/multipath support
by Joakim Tjernlund 09 Jan '11

09 Jan '11

> >> Something else, in calc_next_hop: > >> don't you need to return all next hops for ptmp links now that you > >> support ECMP? > > > >The same as in ptp or bcast - multiple next hops are created > >by compositing returns of calc_next_hop(). Look at the caller > >of calc_next_hop(). > > Don't think it will work as intended(I am traveling and only have mail access) > but I think the find_neigh(ifa, rid); > will always find the same neighbor so any additional links > will be missed. Still think you need to do something like this: diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c index 2f9fe49..ea3b660 100644 --- a/proto/ospf/rt.c +++ b/proto/ospf/rt.c @@ -1360,6 +1360,9 @@ calc_next_hop(struct ospf_area *oa, struct top_hash_entry *en, /* The second case - ptp or ptmp neighbor */ if ((en->lsa.type == LSA_T_RT) && (par == oa->rt)) { + struct mpnh *nh, *p_nh; + struct ospf_neighbor *m; + ifa = rt_pos_to_ifa(oa, pos); if (!ifa) return NULL; @@ -1367,11 +1370,15 @@ calc_next_hop(struct ospf_area *oa, struct top_hash_entry *en, if (ifa->type == OSPF_IT_VLINK) return new_nexthop(po, IPA_NONE, NULL, 0); - struct ospf_neighbor *m = find_neigh(ifa, rid); - if (!m || (m->state != NEIGHBOR_FULL)) - return NULL; - - return new_nexthop(po, m->ip, ifa->iface, ifa->ecmp_weight); + nh = p_nh = NULL; + WALK_LIST(m, ifa->neigh_list) { + if (m->rid != rid || m->state != NEIGHBOR_FULL) + continue; + nh = new_nexthop(po, m->ip, ifa->iface, ifa->ecmp_weight); + nh->next = p_nh; + p_nh = nh; + } + return nh; } /* The third case - bcast or nbma neighbor */ But this will cause some extra work as originate_rt_lsa_body() adds identical entries to the RT LSA for multiple ptmp links between the same two routers. I am not sure what the point is with adding identical entries? Question, would this unrelated simplification work? diff --git a/proto/ospf/topology.c b/proto/ospf/topology.c index 9e693e1..da15e52 100644 --- a/proto/ospf/topology.c +++ b/proto/ospf/topology.c @@ -230,14 +230,6 @@ originate_rt_lsa_body(struct ospf_area *oa, u16 *length) { int net_lsa = 0; - if ((ifa->type == OSPF_IT_VLINK) && (ifa->voa == oa) && - (!EMPTY_LIST(ifa->neigh_list))) - { - neigh = (struct ospf_neighbor *) HEAD(ifa->neigh_list); - if ((neigh->state == NEIGHBOR_FULL) && (ifa->cost <= 0xffff)) - bitv = 1; - } - if ((ifa->oa != oa) || (ifa->state == OSPF_IS_DOWN)) continue; @@ -287,6 +279,8 @@ originate_rt_lsa_body(struct ospf_area *oa, u16 *length) ln->data = ipa_to_u32(ifa->addr->ip); ln->metric = ifa->cost; ln->padding = 0; + if (ifa->voa == oa) + bitv = 1; i++; } break;

1 1

[PATCH] find correct IP address for PTMP I/Fs in calc_next_hop
by Joakim Tjernlund 09 Jan '11

09 Jan '11

Currently calc_next_hop searches for the next hop IP with RID as search key. This will not work when there are multiple links with the same RID. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund(a)transmode.se> --- proto/ospf/rt.c | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c index 2f9fe49..e136aa3 100644 --- a/proto/ospf/rt.c +++ b/proto/ospf/rt.c @@ -1360,6 +1360,9 @@ calc_next_hop(struct ospf_area *oa, struct top_hash_entry *en, /* The second case - ptp or ptmp neighbor */ if ((en->lsa.type == LSA_T_RT) && (par == oa->rt)) { + struct ospf_neighbor *m; + s16 n_pos; + ifa = rt_pos_to_ifa(oa, pos); if (!ifa) return NULL; @@ -1367,8 +1370,14 @@ calc_next_hop(struct ospf_area *oa, struct top_hash_entry *en, if (ifa->type == OSPF_IT_VLINK) return new_nexthop(po, IPA_NONE, NULL, 0); - struct ospf_neighbor *m = find_neigh(ifa, rid); - if (!m || (m->state != NEIGHBOR_FULL)) + n_pos = ifa->rt_pos_beg; + WALK_LIST(m, ifa->neigh_list) { + if (m->state != NEIGHBOR_FULL) + continue; + if (n_pos++ == pos) + break; + } + if (!m || m->rid != rid) /* Check rid just to be sure */ return NULL; return new_nexthop(po, m->ip, ifa->iface, ifa->ecmp_weight); -- 1.7.3.4

1 0

illegal character for interace NIC name
by bird＠hkbsd.com 08 Jan '11

08 Jan '11

Dear all, Currently we are testing BIRD 1.2.5 at our Lab and found that there a illegal Character for NIC. We have tried install 1.2.4 and 1.2.5 even reinstall the OS. It still appear that illegal Character. For example. You can see below show interface output of bnx0 and bnx1. Thanks for help Rgds Derek Our OS is OpenBSD 4.8-STABLE Hardware: Dell Inc. PowerEdge 1950 with 4G RAM BIRD 1.2.5 ready. bird> show interfaces lo0 up (index=2) MultiAccess AdminUp LinkUp Loopback Ignored MTU=33200 113.10.xxx.xx/32 (Primary, broadcast 113.10.xxx.xx, scope univ) enc0 DOWN (index=1) MultiAccess AdminDown LinkDown MTU=0 bnx0¸¬ol} up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 113.10.xxx.xx/29 (Primary, broadcast 113.10.xxx.xx, scope univ) bnx1¸¬ol{ up (index=4) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 113.10.xxx.xx/29 (Primary, broadcast 113.10.xxx.xx, scope univ) pflog0 DOWN (index=5) MultiAccess AdminDown LinkDown MTU=33200 Also logging if related to interface name Jan 3 12:51:18 NWTRWPC-RR-2 bird: OSPF: Received non-hello packet from uknown neighbor (src 113.10.xxx.xx, iface bnx1\M-8\M-,o\^Vl{) Jan 3 12:51:18 NWTRWPC-RR-2 bird: OSPF: Received non-hello packet from uknown neighbor (src 113.10.xxx.xx, iface bnx0\M-8\M-,o\^Vl}) Jan 3 12:51:20 NWTRWPC-RR-2 bird: OSPF: Received non-hello packet from uknown neighbor (src 113.10.xxx.xx, iface bnx1\M-8\M-,o\^Vl{) Jan 3 12:51:21 NWTRWPC-RR-2 bird: OSPF: Received non-hello packet from uknown neighbor (src 113.10.xxx.xx, iface bnx0\M-8\M-,o\^Vl}) Jan 3 12:51:21 NWTRWPC-RR-2 bird: OSPF: Received non-hello packet from uknown neighbor (src 113.10.xxx.xx, iface bnx1\M-8\M-,o\^Vl{) Jan 3 12:51:23 NWTRWPC-RR-2 bird: OSPF: Received non-hello packet from uknown neighbor (src 113.10.xxx.xx, iface bnx0\M-8\M-,o\^Vl}) Jan 3 12:51:23 NWTRWPC-RR-2 bird: OSPF: Received non-hello packet from uknown neighbor (src 113.10.xxx.xx, iface bnx0\M-8\M-,o\^Vl}) Jan 3 12:51:24 NWTRWPC-RR-2 bird: OSPF: Received non-hello packet from uknown neighbor (src 113.10.xxx.xx, iface bnx1\M-8\M-,o\^Vl{)

4 6

Bug in current git concerning BGP neighbor search
by Matthias Schiffer 08 Jan '11

08 Jan '11

Hi, I noticed that the currect git version of bird always disables a BGP protocol instance when the neighbor address is unreachable. This is caused by changing the line if (!p->neigh) to if (!p->neigh || (p->neigh->scope == SCOPE_HOST)) in bgp.c; while formerly, the protocol was only disabled when the address was invalid, the new version also considers the address invalid when the neighbor isn't found. This problem occurs because SCOPE_HOST is equivalent to 0, but the scope is set to 0 by neigh_find() when a neighbor isn't found; I guess it is unintended that SCOPE_HOST is the same as an invalid scope. This bug currently blocks me fixing the problems you mentioned concerning my link-local v6 peering patch. Matthias Schiffer

2 1

interface name bug under *BSD?
by Aragon Gouveia 08 Jan '11

08 Jan '11

Hi, I'm running FreeBSD 8.1 and started using Bird 1.2.5 for the first time today, but it kept finding interfaces with garbled names, eg. Jan 7 20:10:23 <daemon.debug> soek bird: WUG < interface bridge0^B^KM- \xf8L\xf8 goes up Jan 7 20:10:23 <daemon.debug> soek bird: WUG < primary address 172.18.87.128/28 on interface bridge0^B^KM- \xf8L\xf8 added On closer inspection I think I've discovered a problem in sysdep/bsd/krt-sock.c in that it fails to use dl->sdl_nlen when extracting the interface name from dl->sdl_data. According to <net/if_dl.h> the interface name in sdl_data does not require null termination. Possible patch attached. Could someone review this please? Thanks, Aragon

2 1

BGP filtering for own AS number
by Ivo Smits 06 Jan '11

06 Jan '11

Hello, On the dn42 network (http://www.dn42.net) we have been seeing quite a few BGP ghost routes lately. After some research, it turns out that bird may not correctly handle received AS-paths containing the own AS number. Bird ignores incoming BGP routes containing the local AS number - completely. This may result in an older, now invalid, route not getting removed. I've reproduced this behaviour by sending fake BGP packets from AS1113 to AS1111. AS1111 is running bird, AS1113 is running a custom 'BGP speaker' which will send fake route updates. See below. Now I don't know whether it is appropriate to send routes with AS paths containing your peer's AS number (is it?), but it seems to happen in reality and bird does not handle this correctly, resulting in routing loops. I'm running bird version 1.2.5, the debian package. Reproducing the problem: -- Initially there is no such route bird> show route all for 1.3.3.99 1.3.3.0/24 unreachable [static1 17:36] * (200) Type: static unicast univ -- After sending a route for 1.3.3.99/32 via ASes 1113, 9992, 9991, 9993: bird> show route all for 1.3.3.99 1.3.3.99/32 via 10.11.1.7 on tap.ufonet [btest1 17:45 from 10.11.5.36] * (100) [AS9993i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 1113 9992 9991 9993 BGP.next_hop: 0.0.0.0 BGP.local_pref: 100 -- After sending a route for 1.3.3.99/32 via ASes 1113, 9991, 1111, 9993 bird> show route all for 1.3.3.99 1.3.3.99/32 via 10.11.1.7 on tap.ufonet [btest1 17:45 from 10.11.5.36] * (100) [AS9993i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 1113 9992 9991 9993 BGP.next_hop: 0.0.0.0 BGP.local_pref: 100 -- The route has not changed, but it should at least have been removed -- After sending an update marking the route unfeasible: bird> show route all for 1.3.3.99 -- Perhaps also interestingly, only after the BGP connection has been closed, bird contains to the earlier state: bird> show route all for 1.3.3.99 1.3.3.0/24 unreachable [static1 17:36] * (200) Type: static unicast univ

3 3

ECMP/multipath support
by Vincent Bernat 06 Jan '11

06 Jan '11

Hi! BIRD does not support EMCP yet. Looking at the source code, BIRD seems to be able to support ECMP routes internally by adding attaching several route attributes to the same route entry. Is there already someone working on this? ECMP is an important feature when dealing with redundancy. Thanks.

5 65