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
On Tue, Sep 19, 2017 at 10:32:34PM +0200, Alexander Demenshin wrote:
> Hi,
>
> Any reason why 240.0.0.0/4+ routes are ignored by bird (1.6.3)?
Hi
I do not know why it was implemented in BIRD originally in such way
and i had to need to question that, so it stayed is it was.
If Linux and BSD kern
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
Though this space is "reserved for future addressing modes", I see no reason
> why it is "bogus", especially when routers perfectly accept them.
>
I'd say their behaviour is undefined--do routers just use them like unicast
addresses?
Reserved for future use is still the status according to IANA:
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 mar. 19 sept. 22:32:34 2017, Alexander Demenshin wrote:
> 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
>
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.
