December 2015 - Bird-users

KRT: Received route with strange next-hop
by Brian Rak 05 Dec '15

05 Dec '15

I'm trying to figure out why BIRD is throwing this error every time it scans the kernel routing table: <ERR> KRT: Received route 216.155.132.254/32 with strange next-hop 45.63.4.188 <WARN> Netlink: File exists I have two routes relevant to this one: # ip route | grep 45.63.4.188 45.63.4.188 dev veth0 scope link 216.155.132.254 via 45.63.4.188 dev veth0 proto bird The 45.63.4.188 route was added by me (manually), the 216.155.132.254 was added via BIRD (BIRD learned it via BGP). So, to me this looks like bird adding the route to the kernel, then getting confused why the route exists. Aside from this warning, everything appears to be working fine. Linux routes the traffic properly, BIRD readvertises this route properly. Any thoughts here? I think I can probably suppress this warning by removing the 'ng->scope == SCOPE_HOST' check from netlink.c, but I'm not entirely sure why that's there to begin with.

2 5

need some help with filters
by D.Wesołowski 05 Dec '15

05 Dec '15

Hi, I made bird.conf based on examples http://wklej.org/id/1862384/ import: ARPNET - full BGP table EPIX - IX openpeerint EP_GLOBAL - full BGP table export: ARPNET full BGP table EPIX - only statc_bgp, ARPNET prefix EP_GLOBAL - only static, bgp, ARPNET prefix I want to export to other bgp session prefix from ARPNET only when path is direct function rt_export() { if proto = "static_bgp" then return true; if source != RTS_BGP then return false; if net_martian() then return false; if bgp_path.len > 64 then return false; #return bgp_next_hop ~ [ 193.151.48.18 ]; return (bgp_path.first ~ [ 51931, 51944 ]); #if bgp_path.first ~ [ 51931, 51944 ] then return true; } the last two line don't works. I'm looking for some hint to make it work as I want ;) TIA -- D.Wesolowski

2 1

help
by Rohrmann Sascha 03 Dec '15

03 Dec '15

1 0

looking for some help with bgp extended communities
by Warren Turkal 01 Dec '15

01 Dec '15

Hi networkers, I'd like to use bgp extended communities instead of communities for my routing policy so that I can use the 4-octet ASN. However, I am a bit confused by the route target vs route origin (and not having other kinds). Would it be appropriate to use the route origin (as opposed to the route target) kind of ECs to hold the community data that I will use for routing policies? Or maybe is there a way to use the generic 0x04 sub type instead of ro and rt kinds? Also, is it legitimate to use some private ASN for global communities that can be set by any of my routers when talking to one another? Thanks, wt

2 1

RR reflects customer routes, the route is not delivered to the forwarding table.
by 曾小小 01 Dec '15

01 Dec '15

Hi All, I have 3 routers connected like this. R1 （RR） / \ / \ （AS100） / \ R2 R3 (client_1） (client_2） I am using Ubuntu 14.04, bird version is 1.5.0 Between the R1, R2, R3 OSPF establish IGP full mesh. R1 is configured as RR, R1 and R2, R1 and R3 establish IBGP connections . R2 redistribute static routes via BGP, to AS100, R3 can receive routing information from R2, and R1 (RR) can also receive R2 advertised routing information, and delivered to the forwarding. If this routes by the R1 will be sent to the forwarding, it will directly affect the business. How to use the BIRD in BGP configuration commands let R1 is not delivered to the forwarding? another question: Also on the use of “next hop self”, and what is the use in BGP as well? I know that within an AS, if learned from EBGP routing information, you can modify the next hop address of the border router interface. ===== about r3 routeing information link this: 6.6.6.6/32 via 192.168.1.68 on vlan2 [bgp_r1 07:27:16 from 192.168.10.126] * (100/?) [i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 192.168.1.68 BGP.local_pref: 100 BGP.originator_id: 192.168.1.68 BGP.cluster_list: 1.1.1.1 all configuration information is as follows R1： ==== ##template about rr template bgp rr_client { debug { states,interfaces,events }; description "ibgp-rr1"; local 192.168.10.126 as 64600; multihop; rr client; rr cluster id 1.1.1.1; } filter bgp_out_r1 { if net ~ [ 6.6.6.6/32, 7.7.7.7/32 ] then accept; reject; } protocol bgp rr_r2 from rr_client { neighbor 192.168.1.68 as 64600; export filter bgp_out_r1; import all; #next hop self; } protocol bgp rr_r3 from rr_client { neighbor 192.168.2.69 as 64600; export filter bgp_out_r1; import all; #next hop self; } ==== R2： filter bgp_out_r2 { if net ~ [ 6.6.6.6/32, 7.7.7.7/32 ] then accept; reject; } protocol bgp bgp_r2 { debug { states,interfaces,events }; description "ibgp-rr1"; import all; export filter bgp_out_r2; local as 64600; neighbor 192.168.10.126 as 64600; source address 192.168.1.68; next hop self; } === R3: protocol bgp bgp_r3 { debug { states,interfaces,events }; description "ibgp-rr1"; import all; export all; local as 64600; neighbor 192.168.10.126 as 64600; source address 192.168.2.69; next hop self; }

2 1