- Bird-users - Mailing Lists

BGP TTL Hack and BIRD
by Kris Pederson 07 Apr '14

07 Apr '14

Hi, Does BIRD support the "TTL Hack"? If so, please advise on configuration recommendations. Thanks! Details on this hack: === The Generalized TTL Security Mechanism (GTSM, RFC 3682 [39]), often referred to as the "TTL hack", is a simple but effective defense that takes advantage of TTL processing. As noted, normal communications such as e-mail or Web browsing often require 20 or more nodes to reach their destination, and this value varies depending on the application. With BGP, however, peers are normally adjacent, thus only one hop should be required for a packet sent in a BGP message. A BGP message that has passed through multiple nodes is therefore almost certainly either an error or a packet from an attacker. The TTL hack sets the TTL to 255 on outgoing packets. Since routers decrement the TTL field by one when a packet is forwarded, adjacent peers should see incoming packets with TTL = 255. (Note that some implementations decrement the TTL before processing, in which case the incoming packets should have TTL = 254.) A lower value is an indication that the packet originated from somewhere other than the neighboring peer router (see Fig. 4-3). (Note that it is impossible for the packet to start with an initial value above 255, because the TTL field is an 8-bit value.) When implementing the TTL hack, it is also possible to set an expected incoming value below 255 on a per-peer basis when the peer is a known number of hops away, allowing a small variation to allow for changes in topology. For example, if the peer is known to be one hop away, the adjacent peer should reject packets with a TTL < 254. One limitation with the TTL hack is its availability. Code implementing RFC 3682 is provided on newer routers from major vendors, but may not always be included on older, or "legacy", routers, so not all organizations may be able to deploy it. Kris Pederson Equinix

2 1

Cnange next-hop
by Alexander Shikov 04 Apr '14

04 Apr '14

Hi, continuing the implemetation of blackhole in our IXP, I've faced with problem of changing next-hop for the route. Construction looks like if (net.len = 32 && bgp_community ~ [ (31210,*) ] && bgp_community ~ [ (0,666) ] ) then { gw = 193.25.181.253; return true; } results in : bird> show route for 95.67.13.2/32 all 95.67.13.2/32 via 193.25.181.253 on bge0 [COSMONOVA2 2014-04-04 17:59:19 from 193.25.180.133] * (50) [AS34867i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 34867 BGP.next_hop: 193.25.180.133 BGP.local_pref: 100 BGP.community: (0,666) (31210,31210) And when this route is announced to other peer, next-hop remains unchanged: Peerings.inet.0: 16708 destinations, 50556 routes (16627 active, 0 holddown, 88 hidden) + = Active Route, - = Last Active, * = Both 95.67.13.2/32 *[BGP/170] 00:12:14, localpref 100, from 193.25.180.255 AS path: 34867 I > to 193.25.180.133 via xe-1/0/0.777 As far as I understand from User's Guide, gw is an read-write attribute, so why it didn't change next-hop? Thanks in advance! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 http://dtel-ix.net/

3 3

BIRD 1.4.2 compile fails with debug option
by Bahram BahramBeigy 04 Apr '14

04 Apr '14

Hi, When I want to compile BIRD with --enable-debug option, it fails with the following error. while without the debug option it compiles fine. [Archlinux gcc 4.8.2 20140206 (prerelease), kernel 3.13.8] gcc -I../ -I../.. -g -O2 -pthread -Wall -Wstrict-prototypes > -Wno-parentheses -Wno-pointer-sign -fno-strict-aliasing > -fno-strict-overflow -o proto.o -c ../../nest/proto.c > In file included from ../../nest/bird.h:13:0, > from ../../nest/proto.c:11: > ../../nest/proto.c: In function ‘proto_want_export_up’: > ../../nest/proto.c:1238:27: error: ‘CS_HAPPY’ undeclared (first use in > this function) > ASSERT(p->core_state == CS_HAPPY); > ^ > ../lib/birdlib.h:125:30: note: in definition of macro ‘ASSERT’ > #define ASSERT(x) do { if (!(x)) bug("Assertion `%s' failed at %s:%d", > #x, __FILE__, __LINE__); } while(0) > ^ > ../../nest/proto.c:1238:27: note: each undeclared identifier is reported > only once for each function it appears in > ASSERT(p->core_state == CS_HAPPY); > ^ > ../lib/birdlib.h:125:30: note: in definition of macro ‘ASSERT’ > #define ASSERT(x) do { if (!(x)) bug("Assertion `%s' failed at %s:%d", > #x, __FILE__, __LINE__); } while(0) > ^ > ../../nest/proto.c: In function ‘proto_want_core_down’: > ../../nest/proto.c:1261:27: error: ‘CS_HAPPY’ undeclared (first use in > this function) > ASSERT(p->core_state == CS_HAPPY); > ^ > ../lib/birdlib.h:125:30: note: in definition of macro ‘ASSERT’ > #define ASSERT(x) do { if (!(x)) bug("Assertion `%s' failed at %s:%d", > #x, __FILE__, __LINE__); } while(0) > ^ > ../Rules:76: recipe for target 'proto.o' failed -- Best wishes, Bahram BahramBeigy http://www.bahrambeigy.ir

2 1

Version 1.4.2
by Ondrej Filip 02 Apr '14

02 Apr '14

Hi! To release a new version on April 1st was of course a joke. :-( So here is a new version with important bugfix in BFD implementation. Ondrej

1 0

OSPF interface going down, why?
by Ruben Laban 02 Apr '14

02 Apr '14

Hi, I was wondering about possible causes for the following log message: 2014-04-02 05:14:02 <TRACE> ospf1: Changing state of iface vlan0251 from ptp to down No other log messages prior to this one currently. I did enable debug logging hoping it would shed some more light on the issue. But I don't know when it'll happen again. This is bird 1.3.8 running in a vSphere VM, so there's plenty of areas where network issues could arise. Regards, Ruben Laban

1 0

ospf ecmp with ipv6
by Vasiliy Tolstov 02 Apr '14

02 Apr '14

Hello. Does bird supports ecmp on ipv6 and how can i test that ecmp works? -- Vasiliy Tolstov,

1 0

Version 1.4.1
by Ondrej Filip 01 Apr '14

01 Apr '14

Hi guys! Net BIRD version is out: Version 1.4.1 o BGP add-path support (RFC draft). o BGP graceful restart (RFC 4724). o OSPF: many changes in socket layer. o OSPF: support for secondary addresses in BSD. o OSPF: names for vlink pseudointerfaces (vlinkX). o Several bugfixes. Ondrej

1 0

L2VPN
by Tom Berryman 26 Mar '14

26 Mar '14

Hey Everyone, Anyone using BIRD for route reflector with VPNV4 AND L2VPN ? I presently have VPNV4 perfect, no issues. Wondering if there are any additional considerations for adding L2VPN to the peers. TIA. Tom

1 0

Combining routes in BIRD BGP export
by Andy Linton 26 Mar '14

26 Mar '14

I saw a recent post about combining routes in OSPF and wanted the answer to the BGP version of the question. I have a /24 split into several subnets on my BGP speaking box. I only want to export the /24. On quagga or cisco I'd use a "network" statement.

4 4

Prioritising default routes
by Michael Ludvig 25 Mar '14

25 Mar '14

Hi Short version: Can I assign different priorities (metrics?) to the same route inserted by Bird into different routing tables? Long version: I've got a main office router with these uplinks: - 1x SDSL with BGP, receives national routes - 1x ADSL with OSPF Cisco modem that advertises default route - 2x OpenVPN tunnel to our Datacentre (one over each physical connection) with OSPF that's primarily for internal nets. The SDSL and Datacentre are with the same ISP and I can propagate our DMZ subnets over BGP from either location. Then I've got two routing tables - one for internal LAN and one for DMZ which has different rules. In normal circumstances the LAN traffic goes out over ADSL unless there is a better route learnt from BGP in which case it'd go out over SDSL. The DMZ traffic (public IPs) always goes out over SDSL, and the DMZ routing table has a static default rule in that sense. Now if SDSL goes down - as it did yesterday after a fibre cut down the road... - all LAN traffic goes out over ADSL, that's good - DMZ subnet advertised from DC router over BGP and incoming traffic arrives over the OpenVPN tunnel (which still works over ADSL). - all DMZ egress is blocked though until I replace the default route in DMZ routing table to go via the tunnel to datacentre and from there to the internet. If ADSL goes down... - LAN traffic is restricted to BGP learned routes (national traffic) until I add a static default route via SDSL - DMZ is fine What I want is an automatic fail over for both LAN and DMZ if any one of the links fails. My idea is to advertise a default route over all the uplinks and for the LAN routing table use them in this order of preference: 1. ADSL (OSPF), 2. SDSL (BGP), 3. one of the tunnels (unlikely if both physical links are down) For DMZ routing table do this order: 1. SDSL (BGP), 2. tunnel over ADSL (OSPF), 3. plain ADSL (OSPF) I know I can manage different routing tables from Bird but how do I assign different priorities (metrics?) for the same route going into different tables? Thanks! Michael

2 2