It is not possible to flush all the incoming as-path list
from a given BGP update.
Add a route-map set command to remove all as-paths
from a given AS path. Add the necessary tests.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Looks like people don't find what does it mean (Policy) at first shot, let's
try giving more hints here.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently, delayed reflooding on P2MP interfaces for LSAs received
from neighbors on the interface is unconditionally (see commit
c706f0e32b). In some cases, this
change wasn't desirable and this feature makes delayed reflooding
configurable for P2MP interfaces via the CLI command:
"ip ospf network point-to-multipoint delay-reflood" in interface
submode.
Signed-off-by: Acee <aceelindem@gmail.com>
`ccls` needs information from FRR build configuration to work,
so allow creation of a custom ccls config during autoconf.
Paraphrasing the doc entry: ccls is a very powerful tool that allows
dev environments to provide sophisticated IDE functionality, e.g.,
semantically aware jumps and code refactoring...
Signed-off-by: Christian Hopps <chopps@labn.net>
This command makes unplanned GR more reliable by manipulating the
sending of Grace-LSAs and Hello packets for a certain amount of time,
increasing the chance that the neighboring routers are aware of
the ongoing graceful restart before resuming normal OSPF operation.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In practical terms, unplanned GR refers to the act of recovering
from a software crash without affecting the forwarding plane.
Unplanned GR and Planned GR work virtually the same, except for the
following difference: on planned GR, the router sends the Grace-LSAs
*before* restarting, whereas in unplanned GR the router sends the
Grace-LSAs immediately *after* restarting.
For unplanned GR to work, ospf6d was modified to send a
ZEBRA_CLIENT_GR_CAPABILITIES message to zebra as soon as GR is
enabled. This causes zebra to freeze the OSPF routes in the RIB as
soon as the ospf6d daemon dies, for as long as the configured grace
period (the defaults is 120 seconds). Similarly, ospf6d now stores in
non-volatile memory that GR is enabled as soon as GR is configured.
Those two things are no longer done during the GR preparation phase,
which only happens for planned GRs.
Unplanned GR will only take effect when the daemon is killed
abruptly (e.g. SIGSEGV, SIGKILL), otherwise all OSPF routes will be
uninstalled while ospf6d is exiting. Once ospf6d starts, it will
check whether GR is enabled and enter in the GR mode if necessary,
sending Grace-LSAs out all operational interfaces.
One disadvantage of unplanned GR is that the neighboring routers
might time out their corresponding adjacencies if ospf6d takes too
long to come back up. This is especially the case when short dead
intervals are used (or BFD). For this and other reasons, planned
GR should be preferred whenever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In practical terms, unplanned GR refers to the act of recovering
from a software crash without affecting the forwarding plane.
Unplanned GR and Planned GR work virtually the same, except for the
following difference: on planned GR, the router sends the Grace-LSAs
*before* restarting, whereas in unplanned GR the router sends the
Grace-LSAs immediately *after* restarting.
For unplanned GR to work, ospf6d was modified to send a
ZEBRA_CLIENT_GR_CAPABILITIES message to zebra as soon as GR is
enabled. This causes zebra to freeze the OSPF routes in the RIB as
soon as the ospfd daemon dies, for as long as the configured grace
period (the defaults is 120 seconds). Similarly, ospfd now stores in
non-volatile memory that GR is enabled as soon as GR is configured.
Those two things are no longer done during the GR preparation phase,
which only happens for planned GRs.
Unplanned GR will only take effect when the daemon is killed
abruptly (e.g. SIGSEGV, SIGKILL), otherwise all OSPF routes will
be uninstalled while ospfd is exiting. Once ospfd starts, it will
check whether GR is enabled and enter in the GR mode if necessary,
sending Grace-LSAs out all operational interfaces.
One disadvantage of unplanned GR is that the neighboring routers
might time out their corresponding adjacencies if ospfd takes too
long to come back up. This is especially the case when short dead
intervals are used (or BFD). For this and other reasons, planned
GR should be preferred whenever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Until now, the bgp local paths were using the default null label
defined. It was not possible to select the null label for the ipv4
or the ipv6 address families.
This commit addresses this issues by adding two extra-parameters
to the BGP labeled-unicast command.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Let users know about the RIP BFD integration commands and increment the
used RFCs reference.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Debugging-isis tag was moved.
Move it to right place.
Fixes: 9389175b75 ("doc: add documentation for IS-IS Segment Routing")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
1. Added interface name, group address and detail option to existing
"show ip igmp groups" so that user can retrieve all the groups
or a particular group for an interface. Detail option shows the source
information for the group. With that, the show command
looks like:
"show ip igmp [vrf NAME$vrf_name] groups [INTERFACE$ifname [GROUP$grp_str]] [detail$detail] [json$json]"
2. Changed pim_cmd_lookup_vrf() to return empty JSON if VRF is not present
3. Changed "detail" option to print non pretty JSON
4. Added interface name and group address to existing
"show ip igmp sources" so that user can retrieve all the sources for
all the groups or, all the sorces for a particular group for an
interface. With that, the show command looks like:
"show ip igmp [vrf NAME$vrf_name] sourcess [INTERFACE$ifname [GROUP$grp_str]] [json$json]"
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
In BGP labeled unicast address-family, it is not possible to
send explicit-null label values with redistributed or network
declared prefixes.
A new CLI command is introduced:
> [no] bgp labeled-unicast explicit-null
When used, the explicit-null value for IPv4 ('0' value) or
IPv6 ('2' value) will be used.
It is necessary to reconfigure the networks or the
redistribution in order to inherit this new behaviour.
Add the documentation.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Since mgmtd no longer supports the frr_startup.json, removing the
documentation related to that. Proper documentation will be added
when/if the frr_startup.json is ever supported.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
Implement NSSA address ranges as specified by RFC 3101:
NSSA border routers may be configured with Type-7 address ranges.
Each Type-7 address range is defined as an [address,mask] pair. Many
separate Type-7 networks may fall into a single Type-7 address range,
just as a subnetted network is composed of many separate subnets.
NSSA border routers may aggregate Type-7 routes by advertising a
single Type-5 LSA for each Type-7 address range. The Type-5 LSA
resulting from a Type-7 address range match will be distributed to
all Type-5 capable areas.
Syntax:
area A.B.C.D nssa range A.B.C.D/M [<not-advertise|cost (0-16777215)>]
Example:
router ospf
router-id 1.1.1.1
area 1 nssa
area 1 nssa range 172.16.0.0/16
area 1 nssa range 10.1.0.0/16
!
Since regular area ranges and NSSA ranges have a lot in common,
this commit reuses the existing infrastructure for area ranges as
much as possible to avoid code duplication.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add the "default-information-originate" option to the "area X nssa"
command. That option allows the origination of Type-7 default routes
on NSSA ABRs and ASBRs.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This commit adds user documentation for the new MGMT daemon and
new FRR Management Framework.
Co-authored-by: Yash Ranjan <ranjany@vmware.com>
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Co-authored-by: Ujwal P <ujwalp@vmware.com>
Signed-off-by: Pushpasis Sarkar <pushpasis@gmail.com>
It's not allowed to install routes with zero distance, let's disallow this
for route-maps as well.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There are some specific edge-cases when is a need to run FRR and another FRR
and/or another BGP implementation on the same box. Relaxing 127.0.0.0/8 for
this case might be reasonable.
An example below peering via 127.0.0.0/8 between FRR and GoBGP:
```
% ss -ntlp | grep 179
LISTEN 0 4096 127.0.0.1:179 0.0.0.0:*
LISTEN 0 128 127.0.0.2:179 0.0.0.0:*
% grep 127.0.0.2 /etc/frr/daemons
bgpd_options=" -A 127.0.0.1 -l 127.0.0.2"
% grep local /etc/gobgp/config.toml
local-address-list = ["127.0.0.1"]
donatas-pc# sh ip bgp summary
IPv4 Unicast Summary (VRF default):
BGP router identifier 192.168.10.17, local AS number 65001 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 725 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
127.0.0.1 4 65002 7 7 0 0 0 00:02:02 0 0 N/A
Total number of neighbors 1
donatas-pc#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This option is useful to dump detailed information about the LSDB using
a single command (instead of one command per LSA type).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Combine all variations of this command into a single DEFPY to
improve maintainability. No behavioral changes intended.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Note that `ASNUM` in table, it is missing right parenthesis for
`(1-4294967295)`. So, adjust this table.
And correct other words for doc.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Quite a few well-known communities from IANA's list do
not receive special treatment in Cisco IOS XR, and at least one
community on Cisco IOS XR's special treatment list, internet == 0:0,
is not formally a well-known community as it is not in [IANA-WKC] (it
is taken from the Reserved range [0x00000000-0x0000FFFF]).
https://datatracker.ietf.org/doc/html/rfc8642
This is Cisco-specific command which is causing lots of questions when it
comes to debugging and/or configuring it properly, but overall, this behavior
is very odd and it's not clear how it should be treated between different
vendor implementations.
Let's deprecate it and let the operators use 0:0/0 communities as they want.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add a keyword self-originate" to extend current CLI commands to filter out self-originated routes only
a\) CLI to show ipv4/ipv6 self-originated routes
"show [ip] bgp [afi] [safi] [all] self-originate [wide|json]"
b\) CLI to show evpn self-originated routes
"show bgp l2vpn evpn route [detail] [type <ead|macip|multicast|es|prefix|1|2|3|4|5>] self-originate [json]"
Signed-off-by: Karl Quan <kquan@nvidia.com>
Implement: https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability
Tested with GoBGP:
```
% ./gobgp neighbor 192.168.10.124
BGP neighbor is 192.168.10.124, remote AS 65001
BGP version 4, remote router ID 200.200.200.202
BGP state = ESTABLISHED, up for 00:01:49
BGP OutQ = 0, Flops = 0
Hold time is 3, keepalive interval is 1 seconds
Configured hold time is 90, keepalive interval is 30 seconds
Neighbor capabilities:
multiprotocol:
ipv4-unicast: advertised and received
ipv6-unicast: advertised
route-refresh: advertised and received
extended-nexthop: advertised
Local: nlri: ipv4-unicast, nexthop: ipv6
UnknownCapability(6): received
UnknownCapability(9): received
graceful-restart: advertised and received
Local: restart time 10 sec
ipv6-unicast
ipv4-unicast
Remote: restart time 120 sec, notification flag set
ipv4-unicast, forward flag set
4-octet-as: advertised and received
add-path: received
Remote:
ipv4-unicast: receive
enhanced-route-refresh: received
long-lived-graceful-restart: advertised and received
Local:
ipv6-unicast, restart time 10 sec
ipv4-unicast, restart time 20 sec
Remote:
ipv4-unicast, restart time 0 sec, forward flag set
fqdn: advertised and received
Local:
name: donatas-pc, domain:
Remote:
name: spine1-debian-11, domain:
software-version: advertised and received
Local:
GoBGP/3.10.0
Remote:
FRRouting/8.5-dev-MyOwnFRRVersion-gdc92f44a45-dirt
cisco-route-refresh: received
Message statistics:
```
FRR side:
```
root@spine1-debian-11:~# vtysh -c 'show bgp neighbor 192.168.10.17 json' | \
> jq '."192.168.10.17".neighborCapabilities.softwareVersion.receivedSoftwareVersion'
"GoBGP/3.10.0"
root@spine1-debian-11:~#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Adjust doc:
1. Correct the pid path for daemons
2. Add empty line before `kill` command
3. Remove one useless line in "ripd.rst"
Signed-off-by: anlan_cs <vic.lan@pica8.com>
A new keyword permits changing the BGP as-notation output:
- [no] router bgp <> [vrf BLABLA] [as-notation [<dot|plain|dot+>]]
At the BGP instance creation, the output will inherit the way the
BGP instance is declared. For instance, the 'router bgp 1.1'
command will configure the output in the dot format. However, if
the client wants to choose an alternate output, he will have to
add the extra command: 'router bgp 1.1 as-notation dot+'.
Also, if the user wants to have plain format, even if the BGP
instance is declared in dot format, the keyword can also be used
for that.
The as-notation output is only taken into account at the BGP
instance creation. In the case where VPN instances are used,
a separate instance may be dynamically created. In that case,
the real as-notation format will be taken into acccount at the
first configuration.
Linking the as-notation format with the BGP instance makes sense,
as the operators want to keep consistency of what they configure.
One technical reason why to link the as-notation output with the
BGP instance creation is that the as-path segment lists stored
in the BGP updates use a string representation to handle aspath
operations (by using regexp for instance). Changing on the fly
the output needs to regenerate this string representation to the
correct format. Linking the configuration to the BGP instance
creation avoids refreshing the BGP updates. A similar mechanism
is put in place in junos too.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
1. When OSPF unnumbered neighbor doesn't exist in any VRF,
OSPFD prints a bunch of empty JSON objects. Fixed it
by adding an outer JSON object with VRF information in it
2. Added "vrf" option to this command so that per VRF
unnumbered OSPF neighbor information can be retrieved
JSON output:
nl1# show ip ospf neighbor swp1 detail json
{
"default":{
},
"vrf1012":{
},
"vrf1013":{
},
"vrf1014":{
}
}
nl1# show ip ospf vrf vrf1012 neighbor swp4.2 detail json
{
"9.9.12.10":[
{
"ifaceAddress":"200.254.2.46",
"areaId":"0.0.0.0",
"ifaceName":"swp4.2",
"localIfaceAddress":"200.254.2.45",
"nbrPriority":1,
"nbrState":"Full",
"role":"DR",
"stateChangeCounter":6,
"lastPrgrsvChangeMsec":1462758,
"routerDesignatedId":"200.254.2.46",
"routerDesignatedBackupId":"200.254.2.45",
"optionsCounter":2,
"optionsList":"*|-|-|-|-|-|E|-",
"routerDeadIntervalTimerDueMsec":37140,
"databaseSummaryListCounter":0,
"linkStateRequestListCounter":0,
"linkStateRetransmissionListCounter":0,
"threadInactivityTimer":"on",
"threadLinkStateRequestRetransmission":"on",
"threadLinkStateUpdateRetransmission":"on"
}
]
}
nl1#
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Consider this scenario:
Lots of peers with a bunch of route information that is changing
fast. One of the peers happens to be really slow for whatever
reason. The way the output queue is filled is that bgpd puts
64 packets at a time and then reschedules itself to send more
in the future. Now suppose that peer has hit it's input Queue
limit and is slow. As such bgp will continue to add data to
the output Queue, irrelevant if the other side is receiving
this data.
Let's limit the Output Queue to the same limit as the Input
Queue. This should prevent bgp eating up large amounts of
memory as stream data when under severe network trauma.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Let the user know how to use the static route monitoring commands.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The override.css/js files for sphinx docs were not being included into
the tarball created by `make dist`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Added ipv4 and ipv6 option to existing "show bgp nexthop"
command to be able to query nexthops that belong to a
particular address-family.
Also fixed the warnings of MR 12171
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
New show command "show evpn mac vni xx detail [json]"
to display details of all the mac entries for the
requested VNI.
Output of show evpn mac vni xx detail json:
{
"numMacs":2,
"macs":{
"ca:be:63:7c:81:05":{
"type":"local",
"intf":"veth100",
"ifindex":8,
"uptime":"00:06:55",
"localSequence":0,
"remoteSequence":0,
"detectionCount":0,
"isDuplicate":false,
"syncNeighCount":0,
"neighbors":{
"active":[
"fe80::c8be:63ff:fe7c:8105"
],
"inactive":[
]
}
}
}
}
Also added remoteEs field in the JSON output of
"show evpn mac vni xx json".
Output of show evpn mac vni xx json:
"00:02:00:00:00:0d":{
"type":"remote",
"remoteEs":"03:44:38:39:ff:ff:02:00:00:02",
"localSequence":0,
"remoteSequence":0,
"detectionCount":0,
"isDuplicate":false
}
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
```
donatas-pc# show bgp all detail-routes
For address family: IPv4 Unicast
BGP table version is 11, local router ID is 192.168.10.17, vrf id 0
Default local pref 100, local AS 65002
BGP routing table entry for 10.0.2.0/24, version 1
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.10.124
65001
192.168.10.124 from 192.168.10.124 (200.200.200.202)
Origin incomplete, metric 0, valid, external, otc 65001, best (First path received)
Last update: Tue Dec 20 12:11:52 2022
BGP routing table entry for 10.10.100.0/24, version 2
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.10.124
65001
192.168.10.124 from 192.168.10.124 (200.200.200.202)
Origin IGP, metric 0, valid, external, otc 65001, best (First path received)
Last update: Tue Dec 20 12:11:52 2022
BGP routing table entry for 172.16.31.1/32, version 3
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.10.124
65001
192.168.10.124 from 192.168.10.124 (200.200.200.202)
Origin incomplete, metric 0, valid, external, otc 65001, best (First path received)
Last update: Tue Dec 20 12:11:52 2022
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The command of "show ip ospf" is incomplete. But "show ipv6 ospf" is fine.
Just complete it with actual parameters.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
The existing EVPN documentation in bgp.rst does not provide a holistic
configuration, just examples of individual features, and doesn't give
an operator any idea of what a compatible Linux netdev configuration
might look like. This introduces evpn.rst which includes a sample
frr.conf and corresponding Linux interface config (via iproute2) that
an operator can use to setup a basic EVPN topology and model their
interface manager's config from.
This initial version of evpn.rst shows Linux netdev config for
traditional bridges (vlan_filtering=0) and traditional vxlan devices
(single VNI). Later changes to this file will cover the use of
VLAN-aware bridges (vlan_filtering=1), single VXLAN devices
(multi VNI), and eventually bonds (for EVPN-MH).
Eventually the plan is to move the existing EVPN content from bgp.rst
into evpn.rst, but for now let's get some user-facing documentation in
place for interface configs.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Documentation ways that community-list works as OR when multiple community
values specified per entry, but it's wrong. It must be AND, let's fix this.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add "show motd" commad.
The vtysh user can call the "show motd" command to re-show the welcome message.
This is necessary if the user saves frequently used commands in motd.
Signed-off-by: Sergei Rozhkov <gh@zserg.ru>
The `sid vpn per-vrf export` VTY command in bgpd has been extended to
support up to 1048575 SIDs.
This commit updates the documentation of the `sid vpn per-vrf export`
command.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
We already have a global knob for graceful-shutdown, but it's handy having
per neighbor knob as well.
Especially when a single neighbor needs to be restarted/shutdown gracefuly.
We can do this route-maps, but this is a faster/cleaner way doing the same
for an operator.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add a new cli command to troubleshoort pathd daemon.
Some traces initially enabled are hidden behind this
cli command.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add the documentation for the `behavior usid` command to zebra.
When the `behavior usid` command is set, a flag is added to the locator
to indicate that the locator is a uSID locator. When a locator is
specified as a uSID locator, the bgpd will install SRv6 behaviors with
the uSID in the dataplane and use the SRv6 uSID codepoints in the BGP
update message.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Some results:
```
====
PCRE
====
% ./a.out "^65001" "65001"
comparing: ^65001 / 65001
ret status: 0
[14:31] donatas-pc donatas /home/donatas
% ./a.out "^65001_" "65001"
comparing: ^65001_ / 65001
ret status: 0
=====
PCRE2
=====
% ./a.out "^65001" "65001"
comparing: ^65001 / 65001
ret status: 0
[14:30] donatas-pc donatas /home/donatas
% ./a.out "^65001_" "65001"
comparing: ^65001_ / 65001
ret status: 1
```
Seems that if using PCRE2, we need to escape outer `()` chars and `|`. Sounds
like a bug.
But this is only with some older PCRE2 versions. With >= 10.36, I wasn't able
to reproduce this, everything is fine and working as expected.
Adding _FRR_PCRE2_POSIX definition because pcre2posix.h does not have
include's guard.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Remove the nexthop groups documentation from pbr.rst and
make it `generic`. Add the resilient buckets nexthop
group type.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
"on-shutdown" and "on-startup" have the different timeout range.
Correct the timeout range for "on-shutdown" based on the current code:
```
(ospf) max-metric router-lsa on-shutdown (5-100)
```
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Add a default limit to the InQ for messages off the bgp peer
socket. Make the limit configurable via cli.
Adding in this limit causes the messages to be retained in the tcp
socket and allow for tcp back pressure and congestion control to kick
in.
Before this change, we allow the InQ to grow indefinitely just taking
messages off the socket and adding them to the fifo queue, never letting
the kernel know we need to slow down. We were seeing under high loads of
messages and large perf-heavy routemaps (regex matching) this queue
would cause a memory spike and BGP would get OOM killed. Modifying this
leaves the messages in the socket and distributes that load where it
should be in the socket buffers on both send/recv while we handle the
mesages.
Also, changes were made to allow the ringbuffer to hold messages and
continue to be filled by the IO pthread while we wait for the Main
pthread to handle the work on the InQ.
Memory spike seen with large numbers of routes flapping and route-maps
with dozens of regex matching:
```
Memory statistics for bgpd:
System allocator statistics:
Total heap allocated: > 2GB
Holding block headers: 516 KiB
Used small blocks: 0 bytes
Used ordinary blocks: 160 MiB
Free small blocks: 3680 bytes
Free ordinary blocks: > 2GB
Ordinary blocks: 121244
Small blocks: 83
Holding blocks: 1
```
With most of it being held by the inQ (seen from the stream datastructure info here):
```
Type : Current# Size Total Max# MaxBytes
...
...
Stream : 115543 variable 26963208 15970740 3571708768
```
With this change that memory is capped and load is left in the sockets:
RECV Side:
```
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 265350 0 [fe80::4080:30ff:feb0:cee3]%veth1:36950 [fe80::4c14:9cff:fe1d:5bfd]:179 users:(("bgpd",pid=1393334,fd=26))
skmem:(r403688,rb425984,t0,tb425984,f1816,w0,o0,bl0,d61)
```
SEND Side:
```
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 0 1275012 [fe80::4c14:9cff:fe1d:5bfd]%veth1:179 [fe80::4080:30ff:feb0:cee3]:36950 users:(("bgpd",pid=1393443,fd=27))
skmem:(r0,rb131072,t0,tb1453568,f1916,w1300612,o0,bl0,d0)
```
Signed-off-by: Stephen Worley <sworley@nvidia.com>
This command adds the documentation for the "sid vpn per-vrf export (1..255)|auto" command to bgpd.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
This commit adds the documentation of the two optional parameters "block-len" and "node-len" of the SRv6 locator.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Add new `show bgp vni ...` command to docs. This command
is used to show the per-VNI EVPN tables in BGP.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Docs were recommending both integrated and non-integrated
config in different sections. Remove the recommendation
for non-integrated config from vtysh.rst.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
RFC4364 describes peerings between multiple AS domains, to ease
the continuity of VPN services across multiple SPs. This commit
implements a sub-set of IETF option b) described in chapter 10 b.
The ASBR to ASBR approach is taken, with an EBGP peering between
the two routers. The EBGP peering must be directly connected to
the outgoing interface used. In those conditions, the next hop
is directly connected, and there is no need to have a transport
label to convey the VPN label. A new vty command is added on a
per interface basis:
This command if enabled, will permit to convey BGP VPN labels
without any transport labels (i.e. with implicit-null label).
restriction:
this command is used only for EBGP directly connected peerings.
Other use cases are not covered.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When a route imported from l3vpn is analysed, the nexthop from default
VRF is looked up against a valid MPLS path. Generally, this is done on
backbones with a MPLS signalisation transport layer like LDP. Generally,
the BGP connection is multiple hops away. That scenario is already
working.
There is case where it is possible to run L3VPN over GRE interfaces, and
where there is no LSP path over that GRE interface: GRE is just here to
tunnel MPLS traffic. On that case, the nexthop given in the path does not
have MPLS path, but should be authorized to convey MPLS traffic provided
that the user permits it via a configuration command.
That commit introduces a new command that can be activated in route-map:
> set l3vpn next-hop encapsulation gre
That command authorizes the nexthop tracking engine to accept paths that
o have a GRE interface as output, independently of the presence of an LSP
path or not.
A configuration example is given below. When bgp incoming vpnv4 updates
are received, the nexthop of NLRI is 192.168.0.2. Based on nexthop
tracking service from zebra, BGP knows that the output interface to reach
192.168.0.2 is r1-gre0. Because that interface is not MPLS based, but is
a GRE tunnel, then the update will be using that nexthop to be installed.
interface r1-gre0
ip address 192.168.0.1/24
exit
router bgp 65500
bgp router-id 1.1.1.1
neighbor 192.168.0.2 remote-as 65500
!
address-family ipv4 unicast
no neighbor 192.168.0.2 activate
exit-address-family
!
address-family ipv4 vpn
neighbor 192.168.0.2 activate
neighbor 192.168.0.2 route-map rmap in
exit-address-family
exit
!
router bgp 65500 vrf vrf1
bgp router-id 1.1.1.1
no bgp network import-check
!
address-family ipv4 unicast
network 10.201.0.0/24
redistribute connected
label vpn export 101
rd vpn export 444:1
rt vpn both 52:100
export vpn
import vpn
exit-address-family
exit
!
route-map rmap permit 1
set l3vpn next-hop encapsulation gre
exit
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
