infrastation at yandex
Jun 14, 2012, 1:27 AM
Post #2 of 4
16.04.2012, 16:26, "Joakim Tjernlund" <joakim.tjernlund [at] transmode>:
Re: Better type checking for IPV4_DDR_XXX ?
[In reply to]
> could be improved with a patch I sent long ago:
> That way we actually get type checking and don't have to find abuse
> later on.
I have studied the history of this and can deliver the following updates.
1. Your patch dated 18 Nov 2009 addresses the problem better than mine committed 2 Jan 2012. I really overlooked it by that time.
2. Your patch has been adopted for a RE smoke test with a change about in6_addr.s6_addr for consistency and a few functions to make it compile. See commit message of commit 0b9d2ac.
3. Most interestingly, the discrepancy you mention in bgp_announce_check() stands for a real problem. The code in question was added in commit 35be31b, which tried enforcing the norm currently known as "RFC4271 5.1.3. NEXT_HOP":
A route originated by a BGP speaker SHALL NOT be advertised to a peer
using an address of that peer as NEXT_HOP. A BGP speaker SHALL NOT
install a route with itself as the next hop.
As far as I take it, especially in the view of IPv6, the first statement means comparing IPv4/IPv6 NEXT_HOP being sent with IPv4/IPv6 address of remote peer session, not remote Router-ID; the second statement means comparing IPv4/IPv6 NEXT_HOP being received with addresses of all local interfaces. However, both check conditions added in that commit are built on Router-ID. This is plain wrong in the IPv6 case and removing the AF_INET6 branch of that check is a bugfix. Regarding the remaining AF_INET branch, the test condition is harmless, but will do its intended job only for a remote IPv4 peer having its Router-ID equal to the IP address of the BGP session. I would guess, that it was the case for the test rig behind "UNH IOL BGP-4.1.12f" failed (and supposedly fixed by that patch) test.
Fixing this properly is, well, a demanding task.
Quagga-dev mailing list
Quagga-dev [at] lists