Also fixes some issues related to -
show evpn arp-cache vni xx vtep yy
Ticket: CM-25380
Signed-off-by: Nitin Soni<nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8858
Testing-Done: Evpn scale test with 30K neighs
The failed neighbor event logging that was recently added in
commit: 3acae086ba
cast a bit too broad of a stroke. We should only inform
the user that we were ignoring the RTM_NEWNEIGH FAIL callback
when we believe it was one of our own 5549 entries.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When dumping rib data about a route for `debug rib detail`
modify the dump command to display the prefix as part
of every line so that we can use a grep on the log
file.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When BGP daemon is down, Clean up its configuration state from zebra.
When the BGP daemon is up again, it will push its configuration to zebra
Delete the MAC and neighbor information received on the BGP session,
while retaining the local MAC and local ARP entries.
Signed-off-by: Kishore Aramalla karamalla@vmware.com
Problem discovered in testing that occasionally when an interface
address was flushed, the corresponding route would be removed from
the kernel and zebra but remain in the bgp table and be advertised
to peers. Discovered that when zebra_rib_evaluate_nexthops spun
thru the tree list of rns, if the timing and circumstances were
right, it would move elements and miss evaluating some. Changed
from frr_each to frr_each_safe and the problem is now gone.
Ticket: CM-25301
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Add a expected count for the route node we will be processing
as part of nexthop resolution and modify the type to display
a useful string of what the type is instead of a number.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add a bit of extra code to indicate to the operator why
we intentionally rejected a kernel route from being used.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- When the connection with the FPM socket is established, iterate through all the
L3VNIs and send all the RMACs for FPM processing zfpm_conn_up_thread_cb"
- We have already handled connection down even in previous commits. When the FPM
connection goes down, empty mac_q and FPM mac info hash table
"zfpm_conn_down_thread_cb"
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
- FPM write thread calls "zfpm_build_updates()" to process mac_q and dest_q and
to write update buffer over the FPM socket.
- "zfpm_build_updates()" processes all the update queues one by one in a while
loop. It will break the while loop and return if Queue processing function
returns "FPM_WRITE_STOP" OR FPM write buffer is full OR all the queues are
empty (no more update to process).
- "zfpm_build_route_updates()" dequeues and processes route nodes from "dest_q".
- "zfpm_build_mac_updates()" dequeues and processes MAC nodes from "mac_q"
- These queue processing functions return with "FPM_WRITE_STOP" if the write
buffer is full. Return value is "FPM_GOTO_NEXT_Q" if enough updates are
processed from this queue and we want to move on to the next queue.
- In each call, a queue processing function will process max
"FPM_QUEUE_PROCESS_LIMIT (10000)" updates to avoid starvation of other queues.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
- Define a hook "zebra_mac_update" which can be registered by multiple
data plane components (e.g. FPM, dplane).
DEFINE_HOOK(zebra_rmac_update, (zebra_mac_t *rmac, zebra_l3vni_t *zl3vni, bool
delete, const char *reason), (rmac, zl3vni, delete, reason))
- While performing RMAC add/delete for an L3VNI, call "zebra_mac_update" hook.
- This hook call triggers "zfpm_trigger_rmac_update". In this function, we do a
lookup for the RMAC in fpm_mac_info_table. If already present, this node is
updated with the latest RMAC info. Else, a new fpm_mac_info_t node is created
and inserted in the queue and hash data structures.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
- FPM MAC structure: This data structure will contain all the information
required for FPM message generation for an RMAC.
struct fpm_mac_info_t {
struct ethaddr macaddr;
uint32_t zebra_flags; /* Could be used to build FPM messages */
vni_t vni;
ifindex_t vxlan_if;
ifindex_t svi_if; /* L2 or L3 Bridge interface */
struct in_addr r_vtep_ip; /* Remote VTEP IP */
/* Linkage to put MAC on the FPM processing queue. */
TAILQ_ENTRY(fpm_mac_info_t) fpm_mac_q_entries;
uint8_t fpm_flags;
};
- Queue structure for FPM processing:
For FPM processing, we build a queue of "fpm_mac_info_t". When RMAC is
added or deleted from zebra, fpm_mac_info_t node is enqueued in this queue
for the corresponding operation. FPM thread will dequeue these nodes one by
one to generate a netlink message.
TAILQ_HEAD(zfpm_mac_q, fpm_mac_info_t) mac_q;
- Hash table for "fpm_mac_info_t"
When zebra tries to enqueue fpm_mac_info_t for a new RMAC add/delete
operation, it is possible that this RMAC is already present in the queue. So,
to avoid multiple messages for duplicate RMAC nodes, insert fpm_mac_info_t
into a hash table.
struct hash *fpm_mac_info_table;
- Before enqueueing any MAC, try to fetch the fpm_mac_info_t from the hash
table first.
- Entry is deleted from the hash table when the node is dequeued.
- For hash table key generation, parameters used are "mac adress" and "vni"
This will provide a fairly unique key for a MAC(fpm_mac_info_hash_keymake).
- Compare function uses "mac address", "RVTEP address" and "VNI" as the key
which is sufficient to distinguish any two RMACs. This compare function is
used for fpm_mac_info_t lookup (zfpm_mac_info_cmp).
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Found that the "show interface brief" command was missing the
ability to specify all vrfs. Added that capability via this
fix.
Ticket: CM-25139
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
If we get a neighbor entry for 5549 failure notice
from the kernel that means that something has probably
gone terribly wrong. Let's notice and not reinstall.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is mostly relevant for Solaris, where config.h sets up some #define
that affect overall header behaviour, so it needs to be before anything
else.
Signed-off-by: David Lamparter <equinox@diac24.net>
Field vrf_id is replaced by the pointer of the struct vrf *.
For that all other code referencing to (interface)->vrf_id is replaced.
This work should not change the behaviour.
It is just a continuation work toward having an interface API handling
vrf pointer only.
some new generic functions are created in vrf:
vrf_to_id, vrf_to_name,
a zebra function is also created:
zvrf_info_lookup
an ospf function is also created:
ospf_lookup_by_vrf
it is to be noted that now that interface has a vrf pointer, some more
optimisations could be thought through all the rest of the code. as
example, many structure store the vrf_id. those structures could get
the exact vrf structure if inherited from an interface vrf context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
vrf_id parameter is replaced with struct vrf * parameter. It is
needed to create vrf structure before entering in the fuction.
an error is generated in case the vrf parameter is missing.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
there may be cases where the vrf is yet allocated from the vty, and the
discovery process did not make the relationship between the vrf_id and
the name of the vrf. For instance, by parsing an interface belonging to
vrf-id X, it is not sure that vrf-id X and vrfname XX are talking about
the same vrf. For that, lets allocate the vrf, and lets try to detect
there is a duplicate case in vrf, so that the merge can be done without
any impact for the user.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
the interface search is based on vrfs. As at startup, some interfaces
may be configured, there is need to have vrfs contexts present. A macro
is being appended with an extra parameter that permits create a vrf and
return the context. This macro is also used by some show routines, but
will not create vrfs, because that extra parameter will be set to false,
on that case.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Upon accessing interface NB API, the interface is created, if the vrf
is available. the commit does not change the behaviour, since at this
commit, this is not yet possible to have vrf contexts, while zebra did
not connect to daemons. However, that commit adds some work, so that it
will be possible to work on a vrf context, without having the vrf_id
completely resolved. for instance, if we suppose a vrf is created by
command 'vrf TOTO' in the starting configuration of a daemon, then 'interface
TITI vrf TOTO' will permit to create interface TITI within vrf TOTO.
the macro VRF_GET_INSTANCE will return the vrf context, if available or
not.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
the vrf_id parameter is replaced by struct vrf * parameter.
this impacts most of the daemons that look for an interface based on the
name and the vrf identifier.
Also, it fixes 2 lookup calls in zebra and sharpd, where the vrf_id was
ignored until now.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
vrf pointer is used as reference when calling if_get_by_name() function.
this will permit to create interfaces with an unknown vrf_id, since it
is only necessary to get the vrf structure to store the interfaces.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Update pbrd to properly handle nexthop tracking.
When we get a notification that a change happened on a nexthop,
re-install it if its still valid.
Before, we were running over all routes and re-queueing them if they
were PBR routes. This commit removes that and puts all the processing
in PBR instead.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
in the case the vrf backend is vrf-lite, there is no need to have
separate sockets. use a socket located in zrouter, so that when needing
the socket, a common API is used. that API will return the appropriate
socket value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
when network namespace is used as vrf backend, there is need to have
separate contexts for rtadv contexts.
route advertisements have to look for appropriate interface based on
zvrf context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
In a variety of places we are using DAEMON_VTY_DIR, convert
to use frr_vtydir. This will allow us in a future commit
to have the -N namespace option be automatically used.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the local and remote sequence number to the `show evpn arp-cache vni XX` command.
VNI 1000111 #ARP (IPv4 and IPv6, local and remote) 15
IP Type State MAC Remote VTEP Seq #'s
fe80::202:ff:fe00:15 remote active 00:02:00:00:00:15 6.0.0.31 0/0
fe80::202:ff:fe00:8 local active 00:02:00:00:00:08 0/0
60.1.1.111 local active 00:02:00:00:00:08 0/0
2060:1:1:1::11 local active 00:e0:ec:38:49:a1 0/0
fe80::202:ff:fe00:11 remote active 00:02:00:00:00:11 6.0.0.30 0/0
2060:1:1:1::211 remote active 00:02:00:00:00:11 6.0.0.30 0/0
2060:1:1:1::121 remote active 00:02:00:00:00:0c 6.0.0.29 0/0
60.1.1.211 remote active 00:02:00:00:00:11 6.0.0.30 0/0
fe80::202:ff:fe00:c remote active 00:02:00:00:00:0c 6.0.0.29 0/0
60.1.1.11 local active 00:e0:ec:38:49:a1 0/0
fe80::2e0:ecff:fe38:49a1 local active 00:e0:ec:38:49:a1 0/0
60.1.1.221 remote active 00:02:00:00:00:15 6.0.0.31 0/0
2060:1:1:1::111 local active 00:02:00:00:00:08 0/0
2060:1:1:1::221 remote active 00:02:00:00:00:15 6.0.0.31 0/0
60.1.1.121 remote active 00:02:00:00:00:0c 6.0.0.29 0/0
The seq numbers are at 0/0 because we have had no mobility events.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
