When we have both a LL and a Global address,
use what the attribute wants for comparison
instead of assuming Global than LL.
This was causing BGP to install v6 routes
that used the LL as the nexthop, where
the global address was different and
being used as the basis for comparison.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The code path for a deleted interface was calling
zebra with a IFINDEX_DELETED, which caused zebra
to bitch and moan about the issue. Since the
only thing this function does is call zebra
to deregister the RA stuff, don't set the
ifindex to DELETED till afterwords.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
- The 'reject' keyword was being lost
- Hide the "ip route A.B.C.D A.B.C.D" config options since these will be
displayed as "ip route A.B.C.D/X"
Also:
- Add documentation on mailing list
- Update mentions of unit tests
- Update process description
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Commit 8f942af90 introduced a bug while silencing a clang warning. Silence
the warning in a different way to fix our red-black tree implementation.
Fixes#841.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We should preserve the original indentation to make it easier to keep
these files in sync with the upstream.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This reverts commit c14777c6bf.
clang 5 is not widely available enough for people to indent with. This
is particularly problematic when rebasing/adjusting branches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Before the fix NHT had each path resolving via swp1
cel-redxp-10# show ip route 20.0.11.253
Routing entry for 20.0.11.0/24
Known via "bgp", distance 20, metric 0, best
Last update 00:00:20 ago
* 169.254.0.1, via swp1
* 169.254.0.17, via swp2
cel-redxp-10#
cel-redxp-10# show ip nht
[snip]
20.0.11.253
resolved via bgp
via 169.254.0.1, swp1
via 169.254.0.1, swp1
Client list: pim(fd 19)
After the fix
cel-redxp-10# show ip nht
[snip]
20.0.11.253
resolved via bgp
via 169.254.0.1, swp1
via 169.254.0.17, swp2
Client list: pim(fd 19)
This tries to heave a branch over the reindentation step. Somewhat
tested, don't trust it blindly...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
eigrpd will successfully accept `(conf)# route-map foo ...` because it
is not sent to eigrpd from vtysh, but of course, this is the classic
node sync syndrome.
Since eigrpd apparently doesn't support proper routemaps yet just add
the cli so we can suppress the vtysh errors.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Problem found in testing where ipv6 labeled-unicast prefixes were not received
on the peers if a "service networking restart" was issued. Same problem would
happen with an ifdown/ifup on the link to the peer. Found the problem to be
that peers would establish for labeled-unicast even if a link-local address was
not yet available on the interface toward the peer, causing updates to be sent
without a nexthop value. These were then rejected by the peer. Fix is to delay
peer establishment until after the link-local addresses are available.
Ticket: CM-16779
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed By: Donald Sharp <sharpd@cumulusnetworks.com>
Testing Done: Manual testing successful. Bgp-smoke completed with no new failures
