Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: refactor
Change-Id: I5235bf3e9aff58af6ba2c14e8c6529c4fc9ec86c
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I4c3144794dd0bd7de6150929e53f6d305c496b17
Type: fix
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I7b0c2c2dec5e867970599b8f2f2da17f2ff0b17c
|
|
To allow a more flexible throttling configuration, the number of bits
used in the throttling bitmap can be chosen.
Type: improvement
Signed-off-by: Maxime Peim <mpeim@cisco.com>
Change-Id: I7bfe391dd64729011b03f3e5b89408dfc340e036
|
|
Type: improvement
plus the addition of the 'thorttle' counter of IP6.
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: Ic845247a9f3288caa755c33e79ae2eb6d2029d09
|
|
Type: feature
stats of the like from:
https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-arp-yang-model-03#section-4
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: Icb1bf4f6f7e6ccc2f44b0008d4774b61cae96184
|
|
https://gerrit.fd.io/r/c/vpp/+/30197 introduced SAS and inadvertently
broke ping in a variety of situations:
https://jira.fd.io/browse/VPP-1992
https://jira.fd.io/browse/VPP-1970
https://lists.fd.io/g/vpp-dev/topic/84038840
all of which seem to be rooted in situations where there's literally
nothing smarter ping can do for source address selection than
to pick the first IP on the interface. This can happen for:
1. P2P interfaces, see attempted fix: https://gerrit.fd.io/r/c/vpp/+/32801
2. Interfaces with /32 IP addresses intentionally assigned
After some discussion, this problem was partially fixed in
https://gerrit.fd.io/r/c/vpp/+/33449
Unforunately, while source selection was fixed in ping, it continued
to be broken in arp/nd. This gerrit builds on
https://gerrit.fd.io/r/c/vpp/+/33449
and fixes arp/nd.
Type: fix
Ticket: VPP-1970
Ticket: VPP-1992
Fixes: e2fe097424fb169dfe01421ff17b8ccd0c26b4a6
Change-Id: Ief60c321676a15f4f30bf4cd84d50b2f1efec432
Signed-off-by: Ed Warnicke <hagbard@gmail.com>
|
|
The function ip4_neighbor_advertise may be called with NULL addr. In
that case, it looks up addr from fib by calling fib_sas4_get which
returns true or false to indicate whether there is an ip address
associated with the interface or not. But the caller to fib_sas4_get
does not check the return code and blindly assumes there is always an
ip address associated with the interface. As a result, it ends up
sending GARP to the bogus ip address if there is no ip address
associated with the interface.
Type: fix
Signed-off-by: Steven Luong <sluong@cisco.com>
Change-Id: I7aa0270766c3943ed8ca8f8a092cae34567fd30e
|
|
Replace clib_warning with vlog_log_debug when sending garp. There is nothing
to alert/warn the operator about sending garp. vlib_log is more appropriate.
Type: fix
Signed-off-by: Steven Luong <sluong@cisco.com>
Change-Id: Ib88a2b46d2ab8b3c35162538ead0dd0983fb7093
|
|
Type: feature
Use the FIB to provide SAS (in so far as it is today)
- Use the glean adjacency as the record of the connected prefixes
= there's a glean per-{interface, protocol, connected-prefix}
- Keep the glean up to date with whatever the recieve host prefix is
(since it can change)
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
Change-Id: I0f3dd1edb1f3fc965af1c7c586709028eb9cdeac
|
|
Type: refactor
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
Change-Id: Id1801519638a9b97175847d7ed58824fb83433d6
|
|
Type: feature
- ip-neighbour: generic neighbour handling; APIs, DBs, event handling,
aging
- arp: ARP protocol implementation
- ip6-nd; IPv6 neighbor discovery implementation; separate ND,
MLD, RA
- ip6-link; manage link-local addresses
- l2-arp-term; events separated from IP neighbours, since they are not
the same.
vnet retains just enough education to perform ND/ARP packet
construction.
arp and ip6-nd to be moved to plugins soon.
Change-Id: I88dedd0006b299344f4c7024a0aa5baa6b9a8bbe
Signed-off-by: Neale Ranns <nranns@cisco.com>
|