Mailing List Archive

[PATCH] Fix bgpd NH validation for directly connected peers
Hello,

Since quagga-1.2.0, the Next Hop validation for directly connected peers
using IPv6 does not work.
In this setup, BGP updates contain two next hops: a global IPv6 address
and a link-local IPv6 address (a correct behavior according to RFC 2545).
This means that the length of the next hop attribute is 32 and not 16.

The problem comes from the function "make_prefix()" in "bgpd/bgp_nht.c".
It refuses to build a prefix structure for a route when the length of
the next hop attribute is different from 16, even if a valid global IPv6
address is available.
The route is mistakenly considered invalid and thus, it is not installed
in the routing table.

Therefore, I propose the attached patch to fix this issue.
This should solve Bug-946
<https://bugzilla.quagga.net/show_bug.cgi?id=946> and the message
[quagga-users 14883]
<https://lists.quagga.net/pipermail/quagga-users/2017-December/014917.html>.

Regards,
Mathieu

Details: "make_prefix()" was not modified in quagga-1.2.0 but its
interpretation was changed in commit
3dda6b3eccb9a2a88d607372c83c04c796e7daac
<https://git.savannah.gnu.org/gitweb/?p=quagga.git;a=commit;h=3dda6b3eccb9a2a88d607372c83c04c796e7daac>.
Before this commit, the failure of "make_prefix()" was interpreted as a
successful validation of the next hop.
Re: [PATCH] Fix bgpd NH validation for directly connected peers [ In reply to ]
Thank you very much. Applied.

regards,

Paul

On Thu, 14 Dec 2017, Mathieu Jadin wrote:

> Hello,
>
> Since quagga-1.2.0, the Next Hop validation for directly connected peers
> using IPv6 does not work.
> In this setup, BGP updates contain two next hops: a global IPv6 address and a
> link-local IPv6 address (a correct behavior according to RFC 2545).
> This means that the length of the next hop attribute is 32 and not 16.
>
> The problem comes from the function "make_prefix()" in "bgpd/bgp_nht.c".
> It refuses to build a prefix structure for a route when the length of the
> next hop attribute is different from 16, even if a valid global IPv6 address
> is available.
> The route is mistakenly considered invalid and thus, it is not installed in
> the routing table.
>
> Therefore, I propose the attached patch to fix this issue.
> This should solve Bug-946 <https://bugzilla.quagga.net/show_bug.cgi?id=946>
> and the message [quagga-users 14883]
> <https://lists.quagga.net/pipermail/quagga-users/2017-December/014917.html>.
>
> Regards,
> Mathieu
>
> Details: "make_prefix()" was not modified in quagga-1.2.0 but its
> interpretation was changed in commit 3dda6b3eccb9a2a88d607372c83c04c796e7daac
> <https://git.savannah.gnu.org/gitweb/?p=quagga.git;a=commit;h=3dda6b3eccb9a2a88d607372c83c04c796e7daac>.
> Before this commit, the failure of "make_prefix()" was interpreted as a
> successful validation of the next hop.
>
>

--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
QOTD:
"If he learns from his mistakes, pretty soon he'll know everything."
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
Re: [PATCH] Fix bgpd NH validation for directly connected peers [ In reply to ]
If anyone wants to test, it's in the volatile/next head on Savannah, or
'next' on Gogs:

https://gogs.quagga.net/Quagga/quagga/src/next

http://git.savannah.gnu.org/cgit/quagga.git/log/?h=volatile/next

regards,

Paul

On Tue, 19 Dec 2017, Paul Jakma wrote:

> Thank you very much. Applied.
>
> regards,
>
> Paul
>
> On Thu, 14 Dec 2017, Mathieu Jadin wrote:
>
>> Hello,
>>
>> Since quagga-1.2.0, the Next Hop validation for directly connected peers
>> using IPv6 does not work.
>> In this setup, BGP updates contain two next hops: a global IPv6 address
>> and a link-local IPv6 address (a correct behavior according to RFC 2545).
>> This means that the length of the next hop attribute is 32 and not 16.
>>
>> The problem comes from the function "make_prefix()" in "bgpd/bgp_nht.c".
>> It refuses to build a prefix structure for a route when the length of the
>> next hop attribute is different from 16, even if a valid global IPv6
>> address is available.
>> The route is mistakenly considered invalid and thus, it is not installed
>> in the routing table.
>>
>> Therefore, I propose the attached patch to fix this issue.
>> This should solve Bug-946
>> <https://bugzilla.quagga.net/show_bug.cgi?id=946> and the message
>> [quagga-users 14883]
>> <https://lists.quagga.net/pipermail/quagga-users/2017-December/014917.html>.
>>
>> Regards,
>> Mathieu
>>
>> Details: "make_prefix()" was not modified in quagga-1.2.0 but its
>> interpretation was changed in commit
>> 3dda6b3eccb9a2a88d607372c83c04c796e7daac
>> <https://git.savannah.gnu.org/gitweb/?p=quagga.git;a=commit;h=3dda6b3eccb9a2a88d607372c83c04c796e7daac>.
>> Before this commit, the failure of "make_prefix()" was interpreted as a
>> successful validation of the next hop.
>>
>>
>
>

--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
You will probably marry after a very brief courtship.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev