Re: BGP with ECMP and weight control

2020-12-02 Thread Alexander Demenshin
Hi Ondrej, On 2020-12-02 17:48, Ondrej Zajicek wrote: You can try this patch and set 'weight' during export to kernel protocol. Cool! Works as expected - and this actually opens many interesting opportunities. Thank you! Regards, Alexander.

Re: BGP with ECMP and weight control

2020-11-20 Thread Alexander Demenshin
On 2020-11-19 22:25, Maria Matějka wrote: Would it be feasible for you to have a special route attribute to be set in filters that would control the nexthop weight? Sure, this is quite feasible, especially if this attribute could be applied to any route (exported to kernel), i.e.

BGP with ECMP and weight control

2020-11-19 Thread Alexander Demenshin
Hi, I have two uplinks (different AS), and one is more stable/preferred, but when "merge paths" is set to on, all routes are generated with weight 1: 5.21.41.0/24 proto bird nexthop via 10.16.0.1 dev uplink1 weight 1 nexthop via 10.17.0.1 dev uplink2 weight 1 Is there any way

Re: Difference between loopback and dummy interfaces for use in Linux routing

2018-04-27 Thread Alexander Demenshin
On 2018-04-27 12:59, Alexander Zubkov wrote: One of the differences is when you configure some prefix on lo you get route like this: local 127.0.0.0/8 [1] dev lo ... And with dummy it is not the case. It could be done manually with any interface, actually: # ip route add local

Re: Bird 1.5 and 1.6 memory leak

2018-04-17 Thread Alexander Demenshin
On 2018-04-17 13:31, wi...@mailoo.org wrote: As I said, the mem leak does not apppear in the `birdc show memory` command. It is shown at the OS level, and is shown via the `free` command. What do you mean by "OS level"? Which exactly level? What is the actual process size as reported by ps

local address as next-hop

2018-04-15 Thread Alexander Demenshin
Hi, When next-hop specified as a local address, bird 2 produces a warning like: 2018-04-15 18:34:31.136 Next hop address 192.168.100.100 is a local address of iface routers and the route itself is installed as "unreachable". Is there any reason for this? It is completely legal under

Re: bird 2.0.2 does not propagate krt_metric set in static routes when exporting to kernel (and couple other small issues in static protocol)

2018-04-15 Thread Alexander Demenshin
On 2018-04-15 06:42, Radu Anghel wrote: You need to set metric 0; in your kernel protocol in order to have custom krt_metric per route. Now I see, thank you... how could I miss it in docu :) Though, this has a nasty side effect - it is impossible to set "default" metric on export and then

bird 2.0.2 does not propagate krt_metric set in static routes when exporting to kernel (and couple other small issues in static protocol)

2018-04-14 Thread Alexander Demenshin
Hi, Looks like setting of krt_metric in bird 2.0.2 does not work like in bird 1.6. Construction like: protocol static static4 { route 0.0.0.0/0 via 1.1.1.1 { krt_metric = 1; }; } is accepted, I see the route exported to the kernel, but with default bird metric 32. Yes, I know

Re: Ignoring bogus route 240.0.0.0/4

2017-09-20 Thread Alexander Demenshin
On 2017-09-20 15:06, Ondrej Zajicek wrote: If Linux and BSD kernels does accept such routes, than it is a strong reason to support that in BIRD, even if only for purpose of defining blackhole static route. I could not say about BSD, but in Linux this is definitely possible (I have tried it -

Re: Ignoring bogus route 240.0.0.0/4

2017-09-19 Thread Alexander Demenshin
On 2017-09-20 01:12, Jonathan Stewart wrote: I'd say their behaviour is undefined--do routers just use them like unicast addresses? Exactly - at least cisco & linux (the primary reason why I wanted to blackhole it). There are lists and documents about special-purpose IPv4 addresses. In

Re: Ignoring bogus route 240.0.0.0/4

2017-09-19 Thread Alexander Demenshin
On 2017-09-20 00:12, Alarig Le Lay wrote: Because this range is not aimed to be routed or added to any host, cf. https://tools.ietf.org/html/rfc1112 section 4. Section 4 defines only 224.0.0.0/4 (multicast), but in my case it is 240.0.0.0/4 Though this space is "reserved for future

Re: Unexpected behavior of static routes

2017-05-10 Thread Alexander Demenshin
On 2017-05-10 13:16, Ondrej Zajicek wrote: But such design would bring plenty of issues w.r.t. multiple routing tables - may next hops resolve just in the same routing table or also in another routing table? Well, at least in Linux device/direct routes may exist in any table, so where is

Re: Unexpected behavior of static routes

2017-05-10 Thread Alexander Demenshin
On 2017-05-10 03:01, Ondrej Zajicek wrote: It is expected behavior. It is not optimal, but it is how it works. Is it limitation by design or just "not implemented"? If you have a recursive route that is resolved to a device route, then the original gateway is kept. Yes, indeed, this works

Re: Unexpected behavior of static routes

2017-05-09 Thread Alexander Demenshin
On 2017-05-09 20:18, Michael McConnell wrote: You have a physical interface (e.g. eth0) with an address assigned to the 10.1.0.1/24 on the system? No, I don't - this is exactly the problem. It has a completely different address in different network, and I do not want a router to have an

Unexpected behavior of static routes

2017-05-09 Thread Alexander Demenshin
Hi, I have something like this in my config (bird 1.6.3 @linux): protocol static { route 10.1.0.0/24 via "eth1"; route 10.2.0.0/24 via 10.1.0.1; } Route to 10.1.0.0/24 is installed as expected, but, route to 10.2.0.0/24 is not showing up anywhere, while it seems logical that once its

Static routes on (active) interfaces without IP address set

2016-06-17 Thread Alexander Demenshin
Hi, Is there any specific reason why bird (1.6.0 @linux in particular) does not process static routes like: route 10.101.0.0/24 via "eth1"; when eth1 has no assigned IP address (but is up & active)? This route is completely legal but it is invisible anywhere, simply ignored (even does

Re: password for BGP in clear-text in bird.conf file?

2015-04-25 Thread Alexander Demenshin
On 2015-04-25 18:25, Christopher Jay Manders wrote: Even loose encryption like XORing or something would be better than storing a password in clear-text. It would not be better, as any kind of reversible encryption will give a false sense of security, while security will not be improved at

Re: OSPF sequence mismatch occurring regularly

2014-11-11 Thread Alexander Demenshin
On 2014-11-10 18:58, Martin Mares wrote: Unfortunately, non-blocking operations on plain files are not supported by most operating systems, including Linux. It is supported though is not perfect (yet): http://man7.org/linux/man-pages/man7/aio.7.html It would be logical to have separate