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 not
On 2016-06-19 17:59, Ondrej Zajicek wrote:
That is true. For historical reasons, BIRD handles interface without IP
addresses as down.
Well... does it mean that it has to stay like this or it makes sense
to fix this behavior? At least, an option in config would be nice,
if changing actual behav
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
cover
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 addr
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
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 the
Hi,
Any reason why 240.0.0.0/4+ routes are ignored by bird (1.6.3)?
I have tried to blackhole this range in static protocol, but got this
message.
Attempts to manually add any kernel route from this range were silently
ignored.
--
With best regards,
Alexander.
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 addressi
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
fac
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 - j
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
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 ove
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 linux
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
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 192.168.128.0/2
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
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. regardles
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.
Hi,
On 2014-11-05 12:18, Ondrej Filip wrote:
A new version of BIRD is close to be released. However there were a
lot of changes mainly in OSPF code.
It seems that none of the problems I've reported (related to recursive
route handling) are addressed in this release?
Best regards,
Alexander.
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 thre
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 all
21 matches
Mail list logo