DF (Designated forwarder) election is used for picking a single
BUM-traffic forwarded per-ES. RFC7432 specifies a mechanism called
service carving for DF election. However that mechanism has many
disadvantages -
1. LBs poorly.
2. Doesn't allow for a controlled failover needed in upgrade
scenarios.
3. Not easy to hw accelerate.
To fix the poor performance of service carving alternate DF mechanisms
have been proposed via the following drafts -
draft-ietf-bess-evpn-df-election-framework
draft-ietf-bess-evpn-pref-df
This commit adds support for the pref-df election mechanism which
is used as the default. Other mechanisms including service-carving
may be added later.
In this mechanism one switch on an ES is elected as DF based on the
preference value; higher preference wins with IP address acting
as the tie-breaker (lower-IP wins if pref value is the same).
Sample output
=============
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
torm-11# sh bgp l2vpn evpn es 03:00:00:00:00:01:11:00:00:01
ESI: 03:00:00:00:00:01:11:00:00:01
Type: LR
RD: 27.0.0.15:6
Originator-IP: 27.0.0.15
Local ES DF preference: 100
VNI Count: 10
Remote VNI Count: 10
Inconsistent VNI VTEP Count: 0
Inconsistencies: -
VTEPs:
27.0.0.16 flags: EA df_alg: preference df_pref: 32767
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
torm-11# sh bgp l2vpn evpn route esi 03:00:00:00:00:01:11:00:00:01
*> [4]:[03:00:00:00:00:01:11:00:00:01]:[32]:[27.0.0.15]
27.0.0.15 32768 i
ET:8 ES-Import-Rt:00:00:00:00:01:11 DF: (alg: 2, pref: 100)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Add numberical evpn route type support to some more
show commands.
Also, simplify some of the code there to call common type parsing
function. Some of the bounds checking there is also unncessary given
how our cli node matching works.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
1. Sample ES display
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
torm-11# sh bgp l2vpn evpn es
ES Flags: L local, R remote, I inconsistent
VTEP Flags: E ESR/Type-4, A active nexthop
ESI Flags RD #VNIs VTEPs
03:00:00:00:00:01:11:00:00:01 LR 27.0.0.15:15 10 27.0.0.16(EA)
03:00:00:00:00:01:22:00:00:02 LR 27.0.0.15:16 10 27.0.0.16(EA)
03:00:00:00:00:01:22:00:00:03 LR 27.0.0.15:17 10 27.0.0.16(EA)
03:00:00:00:00:02:11:00:00:01 R - 10 27.0.0.17(A),27.0.0.18(A)
03:00:00:00:00:02:22:00:00:02 R - 10 27.0.0.17(A),27.0.0.18(A)
03:00:00:00:00:02:22:00:00:03 R - 10 27.0.0.17(A),27.0.0.18(A)
torm-11#
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2. Sample ES-EVI display
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
torm-11# sh bgp l2vpn evpn es-evi
Flags: L local, R remote, I inconsistent
VTEP-Flags: E EAD-per-ES, V EAD-per-EVI
VNI ESI Flags VTEPs
1005 03:00:00:00:00:01:11:00:00:01 LR 27.0.0.16(EV)
1005 03:00:00:00:00:01:22:00:00:02 LR 27.0.0.16(EV)
1005 03:00:00:00:00:01:22:00:00:03 LR 27.0.0.16(EV)
1005 03:00:00:00:00:02:11:00:00:01 R 27.0.0.17(EV),27.0.0.18(EV)
1005 03:00:00:00:00:02:22:00:00:02 R 27.0.0.17(EV),27.0.0.18(EV)
1005 03:00:00:00:00:02:22:00:00:03 R 27.0.0.17(EV),27.0.0.18(EV)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
3. Sample EAD route display
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
torm-11# sh bgp l2vpn evpn route type ead
BGP table version is 19, local router ID is 27.0.0.15
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [4]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
Extended Community
Route Distinguisher: 27.0.0.15:5
*> [1]:[0]:[03:00:00:00:00:01:11:00:00:01]:[128]:[0.0.0.0]
27.0.0.15 32768 i
ET:8 RT:5550:1009
*> [1]:[0]:[03:00:00:00:00:01:22:00:00:02]:[128]:[0.0.0.0]
27.0.0.15 32768 i
ET:8 RT:5550:1009
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Re-org only; no other code changes. This is being done to make maintanence
of MH functionality (which will have more code added to it) easy.
The code moved here was originally committed via -
'commit 50f74cf131 ("*: support for evpn type-4 route")'
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Coverity has noticed that we are using bgp_evpn after
we have already NULL checked it one time. Add an assert
to make Coverity happy here, if we get to this point
something terrible has happened.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Remove mid-string line breaks, cf. workflow doc:
.. [#tool_style_conflicts] For example, lines over 80 characters are allowed
for text strings to make it possible to search the code for them: please
see `Linux kernel style (breaking long lines and strings)
<https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings>`_
and `Issue #1794 <https://github.com/FRRouting/frr/issues/1794>`_.
Scripted commit, idempotent to running:
```
python3 tools/stringmangle.py --unwrap `git ls-files | egrep '\.[ch]$'`
```
Signed-off-by: David Lamparter <equinox@diac24.net>
```
exit1-debian-9# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 192.168.0.1, local AS number 100 vrf-id 0
BGP table version 8
RIB entries 15, using 2880 bytes of memory
Peers 2, using 43 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt
192.168.0.2 4 200 10 6 0 0 0 00:00:35 8 8
2a02:4780::2 4 0 0 1 0 0 0 never Active 0
Total number of neighbors 2
exit1-debian-9# show bgp summary established
IPv4 Unicast Summary:
BGP router identifier 192.168.0.1, local AS number 100 vrf-id 0
BGP table version 8
RIB entries 15, using 2880 bytes of memory
Peers 2, using 43 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt
192.168.0.2 4 200 10 6 0 0 0 00:00:39 8 8
Total number of neighbors 2
exit1-debian-9# show bgp summary failed
IPv4 Unicast Summary:
BGP router identifier 192.168.0.1, local AS number 100 vrf-id 0
BGP table version 8
RIB entries 15, using 2880 bytes of memory
Peers 2, using 43 KiB of memory
Neighbor EstdCnt DropCnt ResetTime Reason
2a02:4780::2 0 0 never Waiting for peer OPEN
Total number of neighbors 2
exit1-debian-9#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
This is the bulk part extracted from "bgpd: Convert from `struct
bgp_node` to `struct bgp_dest`". It should not result in any functional
change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replace sprintf with snprintf where straightforward to do so.
- sprintf's into local scope buffers of known size are replaced with the
equivalent snprintf call
- snprintf's into local scope buffers of known size that use the buffer
size expression now use sizeof(buffer)
- sprintf(buf + strlen(buf), ...) replaced with snprintf() into temp
buffer followed by strlcat
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This fixes unnecessary whitespaces and makes capitalization
match for route type help strings.
Signed-off-by: Trey Aspelund <taspelund@cumulusnetworks.com>
Add new function `bgp_node_get_prefix()` and modify
the bgp code base to use it.
This is prep work for the struct bgp_dest rework.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
More second order effects of cleaning up rn usage
in bgp. Sprinkle the fairy const's all over the place.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Some were converted to bool, where true/false status is needed.
Converted to void only those, where the return status was only false or true.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Two of the evpn show commands with json option has memory leak.
1) show bgp l2vpn evpn route vni all json
2) show bgp l2vpn evpn route esi json
Before fix:
----------
Executed 'show bgp l2vpn evpn route vni all json' multiple times
used ordinary blocks continue to increase.
Note at the time of show command capture there were 22 evpn routes
in vni evpn route table.
Memory statistics for bgpd:
System allocator statistics:
Total heap allocated: 9152 KiB
Holding block headers: 0 bytes
Used small blocks: 0 bytes
Used ordinary blocks: 7300 KiB
Free small blocks: 1760 bytes
Free ordinary blocks: 1852 KiB
Ordinary blocks: 880
Small blocks: 51
Holding blocks: 0
Ticket:CM-27920
Reviewed By:
Testing Done:
After fix:
---------
Executed 'show bgp l2vpn evpn route vni all json' multiple times
Used ordinary blocks remains low.
Memory statistics for bgpd:
System allocator statistics:
Total heap allocated: 8356 KiB
Holding block headers: 0 bytes
Used small blocks: 0 bytes
Used ordinary blocks: 6492 KiB
Free small blocks: 1840 bytes
Free ordinary blocks: 1864 KiB
Ordinary blocks: 939
Small blocks: 52
Holding blocks: 0
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Found memory leak in json output of evpn's route
commands.
After executing 'show bgp l2vpn evpn route type prefix json'
and 'show bgp l2vpn evpn route type macip json' few times
(6 times) with more than 600 routes in total seeing
memory footprint for bgpd continue to grow.
Memory statistics for bgpd:
System allocator statistics:
Total heap allocated: 12 MiB
Holding block headers: 0 bytes
Used small blocks: 0 bytes
Used ordinary blocks: 8390 KiB
Free small blocks: 1760 bytes
Free ordinary blocks: 3762 KiB
Ordinary blocks: 1161
Small blocks: 51
Holding blocks: 0
Ticket:CM-27920
Testing Done:
After fix:
excute few times,
'show bgp l2vpn evpn route type prefix json'
and 'show bgp l2vpn evpn route type macip json'
commands where used ordinary blocks (uordblks) is
in steady state.
Memory statistics for bgpd:
System allocator statistics:
Total heap allocated: 9968 KiB
Holding block headers: 0 bytes
Used small blocks: 0 bytes
Used ordinary blocks: 6486 KiB
Free small blocks: 1984 bytes
Free ordinary blocks: 3482 KiB
Ordinary blocks: 1110
Small blocks: 54
Holding blocks: 0
Memory statistics for bgpd:
System allocator statistics:
Total heap allocated: 10100 KiB
Holding block headers: 0 bytes
Used small blocks: 0 bytes
Used ordinary blocks: 6488 KiB
Free small blocks: 1984 bytes
Free ordinary blocks: 3612 KiB
Ordinary blocks: 1113
Small blocks: 54
Holding blocks: 0
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
advertise pip running configuration should
display ip followed by mac parameters value as defined
in cli signature.
advertise-pip is enabled by default, when displaying the
running configuration, there is '\n' added after
ip and mac parameters which was not guarded around
the non-default parameters.
Currently, for every bgp vrf instance it ends up
displaying l2vpn address-family section due to
unguarded newline.
running config:
router bgp 6004 vrf vrf1
!
address-family l2vpn evpn
exit-address-family
!
Ticket:CM-26964
Testing Done:
With fix when only 'router bgp 6004 vrf vrf1' configured,
running config looks like:
!
router bgp 6004 vrf vrf1
!
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Instead of CMD_WARNING, use CMD_WARNING_CONFIG_FAILED
for any mis-configuration scenario.
Testing Done:
TOR(config)# router bgp 5548
TOR(config-router)# address-family l2vpn evpn
TOR(config-router-af)# no advertise-pip
This command is supported under L3VNI BGP EVPN VRF
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
By default announct Self Type-2 routes with
system IP as nexthop and system MAC as
nexthop.
An API to check type-2 is self route via
checking ipv4/ipv6 address from connected interfaces list.
An API to extract RMAC and nexthop for type-2
routes based on advertise-svi-ip knob is enabled.
When advertise-pip is enabled/disabled, trigger type-2
route update. For self type-2 routes to use
anycast or individual (rmac, nexthop) addresses.
Ticket:CM-26190
Reviewed By:
Testing Done:
Enable 'advertise-svi-ip' knob in bgp default instance.
the vrf instance svi ip is advertised with nexthop
as default instance router-id and RMAC as system MAC.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Evpn Primary IP advertisement feature uses
individual system IP and system MAC for prefix (type-5)
and self type-2 routes.
The PIP knob is enabled by default for bgp vrf instance.
Configuration CLI for enable/disable PIP feature knob.
User can configure PIP system IP and MAC to retain as
permanent values.
For the PIP IP, the default behavior is to accept bgp default
instance's router-id. When the default instance router-id change,
reflect PIP IP assignment.
Reflect type-5 to use system-IP and system MAC as nexthop and RMAC
values.
Ticket:CM-26190
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
PR 5118 introduce additional (prepend) keywords
like 'ip' to Route Distinguisher output which
breaks existing evpn route show commands parsing.
Restore to original behavior.
Testing Done:
vtysh -c 'show bgp l2vpn evpn route'
Before fix:
Route Distinguisher: ip 27.0.0.15:44
Post fix:
Route Distinguisher: 27.0.0.15:44
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Fixed memory leak and incorrect json output. Check the full output in the PR:
https://github.com/FRRouting/frr/pull/5118
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Fixed the following:
1. Print the complete header for 'show bgp l2vpn evpn' command
2. Print the Route Distinguisher header
3. Print all relevant routes in json (some were being skipped)
Signed-off-by: Kishore Aramalla <karamalla@vmware.com>
In a data center, having 32-128 peers is not uncommon. In such a situation, to find a
peer that has failed and why is several commands. This hinders both the automatability of
failure detection and the ease/speed with which the reason can be found. To simplify this
process of catching a failure and its cause quicker, this patch does the following:
1. Created a new function, bgp_show_failed_summary to display the
failed summary output for JSON and vty
2. Created a new function to display the reset code/subcode. This is now used in the
failed summary code and in the show neighbors code
3. Added a new variable failedPeers in all the JSON outputs, including the vanilla
"show bgp summary" family. This lists the failed session count.
4. Display peer, dropped count, estd count, uptime and the reason for failure as the
output of "show bgp summary failed" family of commands
5. Added three resset codes for the case where we're waiting for NHT, waiting for peer
IPv6 addr, waiting for VRF to init.
This also counts the case where only one peer has advertised an AFI/SAFI.
The new command has the optional keyword "failed" added to the classical summary command.
The changes affect only one existing output, that of "show [ip] bgp neighbors <nbr>". As
we track the lack of NHT resolution for a peer or the lack of knowing a peer IPv6 addr,
the output of that command will show a "waiting for NHT" etc. as the last reset reason.
This patch includes update to the documentation too.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
The `show bgp l2vpn evpn route type <es|prefix>` commands
only accepted 2 letters. You could not type `show bgp l2vpn evpn route type e`
or `show bgp l2vpn evpn route type p` although both are technically legal
since nothing overlaps with them.
Ticket: CM-25988
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
"show bgp l2vpn evpn neighbors <neighbor> [advertised-routes|routes]' did
not work due to various bugs. First, the command only accepted IPv4
addresses as valid neighbor ID, thereby rejecting unnumbered BGP and IPv6
neighbor address. Second, the SAFI was hardcoded to MPLS_VPN even though
we were passing the safi. Third, "all" made no sense in the command context
and to make the command uniform across all address families, I removed the
"all" keyword from the command.
Signed-off-by: Dinesh G Dutt <ddps4u@gmail.com>
EVPN route's extended community include
important informations like Mobility sequence,
router mac, and RT values, include the ecomm
in evpn brief output.
Ticket:CM-25353
Testing Done:
Validated in evpn deployment with routes.
TOR#show bgp l2vpn evpn route
...
Network Next Hop Metric LocPrf Weight Path
Extended Community
Route Distinguisher: 27.0.0.11:3
*> [2]:[0]:[0]:[48]:[00:02:00:00:00:04]:[128]:[fe80::202:ff:fe00:4]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8 ND:Router Flag
* [2]:[0]:[0]:[48]:[00:02:00:00:00:36]
36.0.0.11 0 4435 5546 i
RT:5546:1008 RT:5546:4003 ET:8 MM:0, sticky MAC Rmac:44:38:39:ff:ff:01
*> [2]:[0]:[0]:[48]:[00:02:00:00:00:36]
36.0.0.11 0 4435 5546 i
RT:5546:1008 RT:5546:4003 ET:8 MM:0, sticky MAC Rmac:44:38:39:ff:ff:01
* [3]:[0]:[32]:[36.0.0.11]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8
*> [3]:[0]:[32]:[36.0.0.11]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
There exists a state where we may have a rd node but no individual
evpn prefix nodes in the two level table:
(gdb) bt
at bgpd/bgp_evpn_vty.c:1190
filter=FILTER_RELAXED) at lib/command.c:1060
at lib/command.c:1119
vtysh=vtysh@entry=0) at lib/command.c:1273
(gdb) f 5
at bgpd/bgp_evpn_vty.c:1190
1190 bgpd/bgp_evpn_vty.c: No such file or directory.
(gdb) p buf
$1 = "[2]:[0]:[48]:[00:00:00:00:00:00]", '\000' <repeats 240 times>...
(gdb) p json_nroute
$2 = (json_object *) 0x0
(gdb) p rd_header
$3 = 1
(gdb) p buf
$4 = "[2]:[0]:[48]:[00:00:00:00:00:00]", '\000' <repeats 240 times>...
(gdb)
I'm not entirely sure that this is not a `different` problem in that the
rd node should have been removed. But I think preventing the crash
in a show command is probably the right thing to do here.
Fixes: #4501
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Instead of just passing in the prefix, pass in the particular
bgp_node we are using.
This is setup for a future commit to use this data.
The long term goal is to collect data about why
a particular bgp_path_info was selected as best and
to display that reason.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Bug: If there are 2 different prefixes under an rd, the
output of "show bgp l2vpn evpn json" would print only one of the
prefixes.
RCA: prefix info was added to the json_object once per rd. Hence,
prefix and rd were added just once, as the loop iterated over all
the prefixes and paths.
This is related to my earlier commit that went in via PR 4283:
https://github.com/FRRouting/frr/pull/4283
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
The vpn variable in bgp_evpn_advertise_svi_ip_vni must
be non-null as such it is impossible to ever need the
!vpn test case.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If PIM-SM if used for BUM flooding the multicast group address can be
configured per-vxlan-device. BGP receives this config from zebra via
the L2 VNI add/update.
Sample output -
root@TORS1:~# vtysh -c "show bgp l2vpn evpn vni 1000" |grep Mcast
Mcast group: 239.1.1.100
root@TORS1:~#
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This command is added to provide detailed information. It will be
useful in troubleshooting as we will be able to dump all detailed info
using a single command.
"show bgp l2vpn evpn route [detail] ...". Additional filtering
can be done by providing type of the route.
Command will display the detailed content for all rd and macs-ip as
displayed by "show bgp l2vpn evpn route rd <> mac <>" for a single
rd, mac, ip from the global bgp routing table.
Ticket: CM-24397
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by:
Testing-Done:
This command is added to provide detailed information. It will be
useful in troubleshooting as we will be able to dump all detailed info
using a single command.
"net show bgp evpn route vni <all|id> [detail]". Additional filtering
can be done by providing vtep ip.
Command will display the detailed content for all vni and macs as
displayed by "net show bgp evpn route vni <> mac <> ip <>" for a single
vni, mac, ip.
Ticket: CM-24397
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by:
Testing-Done:
This replaces manual checks of the flag with a wrapper macro to convey
the meaning "is evpn enabled on this vrf?"
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
During L3VNI add, non-default RD value is not replayed
correctly. Instead of picking non-default value it picks
up auto RD value which is derived based on router-id.
Indentation issue: Remove additional space from
L3VNI running config output.
Ticket:CM-24320
Reviewed By:CCR-8437
Testing Done:
Bring up evpn configuration with L3vni up with non-default
RD value, perform peerlink flap, l3vni flap which removes
all VNIS and readds with RD and RT values.
The configured RD and RTs are replayed.
Post L3VNI flap
router bgp 5546 vrf vrf2
!
address-family l2vpn evpn
rd 45.0.66.2:6
route-target import 20001:1
route-target export 20001:1
exit-address-family
TORC11# show bgp l2vpn evpn vni 4002
VNI: 4002 (known to the kernel)
Type: L3
Tenant VRF: vrf2
RD: 45.0.66.2:6
Originator IP: 36.0.0.11
Advertise-gw-macip : n/a
Import Route Target:
20001:1
Export Route Target:
20001:1
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Rename {bgp,zvrf}_def{ault} to {bgp,zvrf}_evpn where it makes sense,
i.e. when they contain the EVPN instance.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
If the EVPN VRF is not the default one (i.e. with advertise-all-vni),
this allows showing its information with `show bgp l2evpn evpn ...`
commands. They do not require adding `vrf VRFNAME` since we only
support a single EVPN VRF. The same is true for zebra-specific commands
(e.g. `show evpn ...`).
Configuration commands are not restricted to the default VRF but to
the EVPN one, that is to the one bearing `advertise-all-vni`.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
This makes the instance bearing the advertise-all-vni config option
register to zebra as the EVPN one, forwarding it the option.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
After a router reboot the L3 network via it converges before the L2
network. This is because MLAG intentionally holds down bridge-access
and vxlan-network ports for some time (MLAG init-delay) to prevent traffic
from switching to a router that is not fully ready. This also means that
routes (from vrf-peering sessions) that qualify for evpn type-5
advertisments are available long before the L3-VNI is available for that
tenant VRF. In these windows bgpd was adding these evpn-type-5 routes with
a L3-VNI of 0 (which was not fixed up after the L3-VNI became available) -
BGP routing table entry for 100.0.0.1:2:[5]:[0]:[0]:[32]:[200.1.1.1]
Paths: (1 available, best #1)
Advertised to non peer-group peers:
MSP1(uplink-1) MSP2(uplink-2)
Route [5]:[0]:[0]:[32]:[200.1.1.1] VNI 0 >>>>>>>>
65001 65535
36.0.0.9 from 0.0.0.0 (27.0.0.9)
Origin incomplete, metric 0, valid, sourced, local, bestpath-from-AS 65001, best
Extended Community: ET:8 RT:5544:4001 Rmac:44:38:39:ff:ff:01
AddPath ID: RX 0, TX 327
Last update: Wed Feb 27 18:37:10 2019
Fix is to defer creating type-5 routes till the L3-VNI is available for
that tenant VRF (this was already being done for most cases; fixup takes
care of some that missed the check).
Ticket: CM-24022
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Made changes and updated the routemap applied counter in the following flows.
1.Increment when route map attached to a list.
2.Decrement when route map removed / modified from a list.
3.Increment/decrement when route map create/delete callback triggered.
4.Besides ,This counter need not be updated when a route map is got updated.
i.e changing/adding a match value to the existing routemap.
In BGP , same update api called for all three add/delete/update operation .
But this counter have to be updated only for routemap addition.
Addressed this specific change by identifying the routemap operation based
on routemap pointer.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
Certain EVPN configuartions should only be applied
under DEFAULT VRF bgpd instance.
reject the cli for non default bgp instance
Ticket:CM-18950
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
During L3VNI add delete, configured non-default
route-target is not replayed correctly.
Non-default route-target should only be deleted
during unconfiguring under bgp vrf instance,
during delete of l3vni only unmap from the VRF.
during addition of l3vni map back to the VRF
Ticket:CM-21482
Testing Done:
Bring up evpn configuration with L3vni up with
non-default route-target.
Perform delete/add of L3vni and validated non-default
route-target is mapped back to vrf.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When "default-originate ipv4" is configured, a type-5 route is installed in
the local node and advertised to the peer with auto-rd.
When the above was followed by configuring an RD in IP VRF, Type-5 are
generated for only the non-default routes.
Fixed this issue by withdrawing the default route with auto-rd and advertising
the route with confiured RD.
Signed-off-by: Kishore Aramalla karamalla@vmware.com
When a VNI is unconfigured it deletes all of its import and export
route-targets. There is a export route-target link list and import
route-target linked list. There are redudant loops in the
route-target deletion code. In the first iteration it deleted the
route-target and freed the RT node, but not list node.
In the 2nd iteration it tries to free the RT node again, resulting in
the double free of RT node.
Signed-off-by: "Kishore Aramalla karamallavmware.com"
Duplicate address detection configuration clis
under bgp l2vpn evpn config mode.
- Enabled/Disable (global knob) for feature.
- Configure cli for duplicate detection action
freeze and freze until time (auto-recovery).
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The bgp_info data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the '[no] flood <disable|head-end-replication>' command
to the l2vpn evpn afi/safi sub commands for bgp. This command
when entered as 'flood disable' will turn off type 3 route
generation for the transmittal of the type 3 route necessary
for BUM replication on the remote VTEP. Additionally it will
turn off the BUM handling via the new zebra command,
ZEBRA_VXLAN_FLOOD_CONTROL.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Do a straight conversion of `struct bgp_info` to `struct bgp_path_info`.
This commit will setup the rename of variables as well.
This is being done because `struct bgp_info` is not descriptive
of what this data actually is. It is path information for routes
that we keep to build the actual routes nexthops plus some extra
information.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported that some bgp and ospf json commands did not return
any json output at all if the bgp/ospf instance did not exist.
Additionally, some bgp and ospf json commands did not return any json
output if the instance existed but no neighbors were defined. This
fix makes these commands more consistent in returning empty braces for
json output and issue a message if not using json output. Additionally,
made the flag "use_json" a bool to make it consistent since previously,
it had been defined as an int, char, u_char, and bool at various places.
Ticket: CM-21040
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Scan all bgp vrf instances and respective L3VNI against the VNI which is being configured.
Ticket:CM-21859
Testing Done:
Configure l3vni,
try to configure same vni as l2vni under router bgp, address-family
l2vpn evpn.
The configuration is rejected.
show evpn vni
VNI Type VxLAN IF # MACs # ARPs # Remote VTEPs Tenant VRF
4001 L3 vx-4001 0 0 n/a vrf1
TOR(config)# router bgp 5546
TOR(config-router)# address-family l2vpn evpn
TOR(config-router-af)# vni 4001
% Failed to create VNI
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
