FRRouting operator can install seg6 route via ZAPI,
But linux kernel operator also can install seg6 route
via Netlink directry (i.e. iproute2)
This commit make zebra to parse non-frr seg6 route
configuration via netlink and audit Zebra's RIB.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
With this patch, zclient can intall seg6 rotues when
they set properties "nh_seg6_segs" on struct nexthop
and set ZEBRA_FLAG_SEG6_ROUTE on zapi_route's flag.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of #5853 works that add new clis to
configure SRv6 locator and its show commands.
Following clis are added on this commit.
vtysh -c 'conf te' \
-c 'segment-routing' \
-c ' srv6' \
-c ' locators' \
-c ' locator LOC1' \
-c ' prefix A::/64'
- "show segment-routing srv6 sid [json]"
- "show segment-routing srv6 locator [json]"
- "show segment-routing srv6 locator NAME detail [json]"
- "show runnning-config" (make it to print srv6 configuration)
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of #5853 works that add new ZAPI to
configure SRv6 locator which manages chunk prefix for
SRv6 SID IPv6 address for each routing protocol daemons.
NEW-ZAPIs:
* ZEBRA_SRV6_LOCATOR_ADD
* ZEBRA_SRV6_LOCATOR_DELETE
* ZEBRA_SRV6_MANAGER_CONNECT
* ZEBRA_SRV6_MANAGER_GET_LOCATOR_CHUNK
* ZEBRA_SRV6_MANAGER_RELEASE_LOCATOR_CHUNK
Zclient can connect to zebra's srv6-manager with
ZEBRA_SRV6_MANAGER_CONNECT api like a label-manager.
Then zclient uses ZEBRA_SRV6_MANAGER_GET_LOCATOR_CHUNK to
allocated dedicated locator chunk for it's routing protocol.
Zebra works for only prefix reservation and distribute
the ownership of the locator chunks for zcliens.
Then, zclient installs SRv6 function with
ZEBRA_ROUTE_ADD api with nh_seg6local_* fields.
This feature is already implemented by another PR(#7680).
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of #5853 that add new cmd-node for SRv6 configuration.
This commit just add cmd-node and moving node cli only, acutual SRv6 config
command isn't added. (that is added later commit. of this branch)
new cli nodes:
* SRv6
* SRv6-locators
* SRv6-locator
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
FRRouting operator can install seg6local route via ZAPI,
But linux kernel operator also can install seg6local route
via Netlink directry (i.e. iproute2)
This commit make zebra to parse non-frr seg6local
route configuration via netlink and audit Zebra's RIB.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
With this patch, zclient can intall seg6local rotues whem
they set properties nh_seg6local_{action,ctx} on struct nexthop
and set ZEBRA_FLAG_SEG6LOCAL_ROUTE on zapi_route's flag.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This includes community and large-community data.
```
exit1-debian-9# show ip route 172.16.16.1/32
Routing entry for 172.16.16.1/32
Known via "bgp", distance 20, metric 0, best
Last update 00:00:23 ago
* 192.168.0.2, via eth1, weight 1
AS-Path : 65030
Communities : 65001:1 65001:2 65001:3 65001:4 65001:5 65001:6
Large-Communities: 65001:123:1 65001:123:2
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Track 'down' state of connected addresses with a new flag. We
may have multiple addresses on an interface that share a prefix;
in those cases, we need to determine when the first address
is valid, to install a connected route, and similarly detect
when the last address goes 'down', to remove the connected
route.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
if_netlink.c created it's on nested parsing #define which
is identical to netlink_parse_rtattr_nested. Consolidate
on one instead of having this duality.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In order to parse the netlink message into the
`struct rtattr *tb[size]` it is assumed that the buffer is
memset to 0 before the parsing. As such if you attempt
to read a value that was not returned in the message
you will not crash when you test for it.
The code has places were we memset it and places where we don't.
This *will* lead to crashes when the kernel changes. In
our parsing routines let's have them memset instead of having
to remember to do it pre pass in to the parser.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When clagd is stopped on secondary device,
all vxlan interfaces (vnis) are kept in protodown state.
FRR treats protodown vxlan interfaces (vnis) as interface down
and sends vni delete to bgpd.
In the event of clagd down, SVIs are flapping as underlying
bridge is going through churn.
When FRR receives SVI up notification do not trigger event to bgpd
if vnis are operationaly down.
Ticket:#2600210 CM-22929
Reviewed By:CCR-11544
Testing Done:
Performed CLAG stop/start on secondary device, all vxlan devices
remained in protodown along with this validated the vnis are cleaned up
and added back in bgpd.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Description:
Added a new show command("show ip zebra route dump") to dump all routes
with detailed information including nexthops,flags, status ..etc.
This helps for dubugging and added to support_bundle_command.conf.
Defined this command as a hidden command.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
When creating a large number of vrf's we are creating a fairly
large number of hash tables per vrf. Reduce memory usage on
startup as well as let us identify the table these things come
from.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We are creating 2 hash tables per vni in zebra. Once we start to
scale the number of vni's we start to see some serious memory
usage in zebra. Let's reduce the memory usage at startup
for scale of vni's.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Current code has an inconsistent behavior with redistribute routes.
Suppose you have a kernel route that is being read w/ a distance
of 255:
eva# show ip route kernel
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 192.168.161.1, enp39s0, 00:06:39
K>* 4.4.4.4/32 [255/8192] via 192.168.161.1, enp39s0, 00:01:26
eva#
If you have redistribution already turned on for kernel routes
you will be notified of the 4.4.4.4/32 route. If you turn
on kernel route redistribution watching after the 4.4.4.4/32 route
has been read by zebra you will never learn of it.
There is no need to look for infinite distance in the redistribution
code. Either we are selected or not. In other words non kernel routes
with an 255 distance are never installed so the checks were pointless.
So let's just remove the distance checking and tell interested parties
about the 255 kernel route if it exists.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently FRR reads the kernel for interface state and FRR
creates a connected route per address on an interface. If
you are in a situation where you have multiple addresses
on an interface just create 1 connected route for them:
sharpd@eva:/tmp/topotests$ vtysh -c "show int dummy302"
Interface dummy302 is up, line protocol is up
Link ups: 0 last: (never)
Link downs: 0 last: (never)
vrf: default
index 3279 metric 0 mtu 1500 speed 0
flags: <UP,BROADCAST,RUNNING,NOARP>
Type: Ethernet
HWaddr: aa:4a:ed:95:9f:18
inet 10.4.1.1/24
inet 10.4.1.2/24 secondary
inet 10.4.1.3/24 secondary
inet 10.4.1.4/24 secondary
inet 10.4.1.5/24 secondary
inet6 fe80::a84a:edff:fe95:9f18/64
Interface Type Other
Interface Slave Type None
protodown: off
sharpd@eva:/tmp/topotests$ vtysh -c "show ip route connected"
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* 10.4.1.0/24 is directly connected, dummy302, 00:10:03
C>* 192.168.161.0/24 is directly connected, enp39s0, 00:10:03
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Since _rnode_zlog was wrapping zlog(), these messages weren't getting an
unique ID assigned through the xref mechanism. Replace macro with a
small extension that prints (almost) the same thing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Initially the reading of the speed of an interface happened
upon interface creation and happened until the speed of a link
settled down to a single value. The speed of an interface
can also change as that a new optic can be inserted that
changes the speed, in which case FRR would see a interface
down (optic removal) and then a interface up (optic insertion).
In this case FRR would not treat this as an event that changed
the speed. Let's expand the checking a bit more.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
- gre keys are collected and stored locally.
- when gre source set is requested, and the link interface
configured is different, the gre information collected is
pushed in the query, namely source ip or gre keys if present.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
preserve mtu upon interface flapping and tunnel source change.
Signed-off-by:Reuben Dowle <reuben.dowle@4rf.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This action is initiated by nhrp and has been stubbed when
moving to zebra. Now, a netlink request is forged to set
the link interface of a gre interface if that gre interface
does not have already a link interface.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
