This option probably did not have enough of a please be careful
warning around it. Let's add a bit more.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Further refine the previous commit to store the hash value in
both the `struct community_list` as well as the `struct rmap_community`
structures. This allows us to know a priori what our hash value
is. This change cuts another couple of seconds of convergence
off to ~55 seconds and further reduces cpu load of bgp:
16 40061.706 433732 92 330102 129 1242965 RWTEX TOTAL
Down from ~43 seconds previously.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The community_list_lookup function in a situation where you have
a large number of communities and route-maps that reference them
becomes a very expensive operation( effectively a linked list walk
per route per route-map you apply per peer that has a routemap that
refereces a community, ecommunity or lcommunity. This is a very
expensive operation.
In my testbed, I have a full bgp feed that feeds into 14 namespace
view based bgp processes and finally those 14 feed into a final
namespace FRR instance that has route-maps applied to each
incoming peer for in and out:
!
router bgp 65033
bgp bestpath as-path multipath-relax
neighbor 192.168.41.1 remote-as external
neighbor 192.168.42.2 remote-as external
neighbor 192.168.43.3 remote-as external
neighbor 192.168.44.4 remote-as external
neighbor 192.168.45.5 remote-as external
neighbor 192.168.46.6 remote-as external
neighbor 192.168.47.7 remote-as external
neighbor 192.168.48.8 remote-as external
neighbor 192.168.49.9 remote-as external
neighbor 192.168.50.10 remote-as external
neighbor 192.168.51.11 remote-as external
neighbor 192.168.52.12 remote-as external
neighbor 192.168.53.13 remote-as external
neighbor 192.168.54.14 remote-as external
!
address-family ipv4 unicast
neighbor 192.168.42.2 prefix-list two-in in
neighbor 192.168.42.2 route-map two-in in
neighbor 192.168.42.2 route-map two-out out
neighbor 192.168.43.3 prefix-list three-in in
neighbor 192.168.43.3 route-map three-in in
neighbor 192.168.43.3 route-map three-out out
neighbor 192.168.44.4 prefix-list four-in in
neighbor 192.168.44.4 route-map four-in in
neighbor 192.168.44.4 route-map four-out out
neighbor 192.168.45.5 prefix-list five-in in
neighbor 192.168.45.5 route-map five-in in
neighbor 192.168.45.5 route-map five-out out
neighbor 192.168.46.6 prefix-list six-in in
neighbor 192.168.46.6 route-map six-in in
neighbor 192.168.46.6 route-map six-out out
neighbor 192.168.47.7 prefix-list seven-in in
neighbor 192.168.47.7 route-map seven-in in
neighbor 192.168.47.7 route-map seven-out out
neighbor 192.168.48.8 prefix-list eight-in in
neighbor 192.168.48.8 route-map eight-in in
neighbor 192.168.48.8 route-map eight-out out
neighbor 192.168.49.9 prefix-list nine-in in
neighbor 192.168.49.9 route-map nine-in in
neighbor 192.168.49.9 route-map nine-out out
neighbor 192.168.50.10 prefix-list ten-in in
neighbor 192.168.50.10 route-map ten-in in
neighbor 192.168.50.10 route-map ten-out out
neighbor 192.168.51.11 prefix-list eleven-in in
neighbor 192.168.51.11 route-map eleven-in in
neighbor 192.168.51.11 route-map eleven-out out
neighbor 192.168.52.12 prefix-list twelve-in in
neighbor 192.168.52.12 route-map twelve-in in
neighbor 192.168.52.12 route-map twelve-out out
neighbor 192.168.53.13 prefix-list thirteen-in in
neighbor 192.168.53.13 route-map thirteen-in in
neighbor 192.168.53.13 route-map thirteen-out out
neighbor 192.168.54.14 prefix-list fourteen-in in
neighbor 192.168.54.14 route-map fourteen-in in
neighbor 192.168.54.14 route-map fourteen-out out
exit-address-family
!
This configuration on my machine before this change takes about 2:45 to converge
and bgp takes:
Total thread statistics
16 151715.050 493440 307 3464919 335 7376696 RWTEX TOTAL
CPU time as reported by 'show thread cpu'.
After this change BGP takes 58 seconds to converge and uses:
Total thread statistics
-------------------------
16 42954.284 350319 122 295743 157 1194820 RWTEX TOTAL
almost 43 seconds of CPU time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The community_list_lookup function is being changed in a future
commit. As such we want to use the `struct rmap_community` data
structure for storing compiled information about communities,ecommunities
or lcommunities.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
User data might not be stored in the files in etc. getent is the
dedicated tool to extract those information, regardless of where the
user data is stored
Signed-off-by: Rhonda D'Vine <rhonda@proxmox.com>
When an empty netmask a wrong end size is calculated, lets handle this
corner case to avoid spurious warning messages.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Handle corner case where a warning log message is issued on interface
address netmask handling with sockaddr type AF_LINK: it may come empty
or with match all (all 0xFF).
In the first case all lengths are zero and we only need to copy the
first bytes, second case it comes with a zero index and all 0xFF bytes.
In any case we only need to figure out a few of the first bytes instead
of all data.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When porting routing socket macro data handling to functions, the
attribute function was forgotten. The only difference between the
attribute and address handler is the family type check.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The End of Rib notification in BGP is useful to know no matter
the circumstances. So change this from a debug message to
an info and cleanup the message a bit and add vrf we are in.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
`isis network point-to-point` was being rejected from the configuration
file as it was being processed before the reception of the UP zebra
notification for the interface. This meant that the `circ_type` was set
at CIRCUIT_T_UNKNOWN, which led the northbound callback to fail. This
check was removed as it was not really necessary; when the zebra
notification is received, the correct circuit type will be enforced,
but now the point-to-point config will be saved and correctly applied
when zebra recognizes the interface as a broadcast one.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
For neigh check duplicate flag as it can be inherited from
duplicate detected MAC (count could be 0).
Ticket:CM-23316
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Below are cases where EVPN duplicate detection
Freeze and Unfreeze required fixes:
Auto recovery needs to check neighbor's duplicate flag
to take action, as neigh could be marked duplicate
via inherited from MAC where IP detection count could be 0.
MAC duplicate detection needs to set flag to true
if freeze action is configured.
Local MAC add update should not send update to bgp
if MAC is in frozen state.
Remote MAC-IP update should not process neigh update if MAC
is detected as duplicate during remote update.
Ticket:CM-23344
Testing Done:
Trigger duplicate detection via both local and remote update trigger,
Validate clear command and other changes expected behavior.
Auto-recovery takes appropriate action on inherited IPs.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The pimg data structure is only used in one spot to send the default
vrf id to zebra upon startup. Add the default vrf id to the struct pim_router
data structure and remove the pimg pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Create a `struct pim_router` and move the thread master into it.
Future commits will further move global varaibles into the pim_router
structure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Just add the ability to notice the capabilities on startup,
but don't do anything with it yet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to retrieve the current role of mlag for this machine.
If mlag is not setup we will always return MLAG_ROLE_NONE.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is the start of a series of commits that will allow FRR to
be integrated into mlag.
Zebra and Pim will both need mlag state for the router. As such we will
need to provide a abstract about this state through the zapi.
This is the start of the common header that both Pim and Zebra will
be using.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The zebra_delete_rnh function is not needed to be exposed
to the entire world. Limit it's scope.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The deletion of a rnh is always proceeded by the same checks
to see if it is done. Just let zebra_delete_rnh do this test.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
