summaryrefslogtreecommitdiffstats
path: root/Makefile.am (unfollow)
Commit message (Collapse)AuthorFilesLines
2019-02-02doc: fix up mangled config example in ipv6.rstLars Seipel1-4/+11
Appears to be a remaining artifact of the Sphinx conversion. Signed-off-by: Lars Seipel <ls@slrz.net>
2019-02-02zebra: avoid exceeding link MTU through RA optionsLars Seipel1-6/+31
Signed-off-by: Lars Seipel <ls@slrz.net>
2019-02-02zebra: support DNS configuration options in rtadvLars Seipel7-1/+470
Add support for the RDNSS and DNSSL router advertisement options described in RFC 8106. Signed-off-by: Lars Seipel <ls@slrz.net>
2019-01-31lib: snprintf to strlcpy in frr_pthread.cDonald Sharp1-2/+2
Convert to using strlcpy to erase those pesky little gcc warnings->errors Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-31Revert "include: Add linux header mroute.h to our build"David Lamparter2-180/+0
This reverts commit 086841cf0bddebc21e72dcb24755c222ed29072c. Oops, broke the build... shoulda waited for CI... Signed-off-by: David Lamparter <equinox@diac24.net>
2019-01-30build: fix a whole bunch of *FLAGSDavid Lamparter23-38/+47
- some target_CFLAGS that needed to include AM_CFLAGS didn't do so - libyang/sysrepo/sqlite3/confd CFLAGS + LIBS weren't used at all - consistently use $(FOO_CFLAGS) instead of @FOO_CFLAGS@ - 2 dependencies were missing for clippy Signed-off-by: David Lamparter <equinox@diac24.net>
2019-01-30build, lib/yang: bake in extensions if possible (v2)David Lamparter1-3/+3
LIBS<>LDFLAGS was wrong on this one. Fixes: 02a0df1f22c5cef8e4d3392d56e7db82da0d49cf Signed-off-by: David Lamparter <equinox@diac24.net>
2019-01-30include: Add linux header mroute.h to our buildDonald Sharp2-0/+180
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-30zebra: On route update context is sometimes indeterminate in post-processingDonald Sharp1-1/+10
When we get into rib_process_result and the operation we are handling is DPLANE_OP_ROUTE_UPDATE *and* the route entry being looked at is a route replace, we currently have no way to decode to the old_re and the re due to how we have stored context. As such they are the same pointer. As such the route replace for the same route type is causing the re to set the installed flag and then immediately unset the installed flag, leaving us in a state where the kernel has the route but the rib thinks we are not installed. Since the true old_re( the one being replaced by the update operation ) is going away( as that it zebra deletes the old one for us already ) this fix is not optimal but will get us moving forward. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-30zebra: When the kernel passes up a onlink route respect those flagsDonald Sharp1-0/+7
Read the onlink flag from the kernel for routes and pass them up and through to zebra so that we are consistent with what the kernel is telling us. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-30zebra: Trust kernel and System routesDonald Sharp1-0/+8
If we receive a valid message from the kernel that is either a kernel or system route, we should trust that the route is legit and just use it. Old behavior: K * 172.22.0.0/15 [0/0] via 172.22.2.254, eva_dummy1 inactive, 00:00:16 New Behavior: K>* 172.22.0.0/15 [0/0] via 172.22.2.254, eva_dummy1, 00:02:35 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-30zebra: Convert route entry id number to string in debugsDonald Sharp2-34/+38
The route entry being displayed in debugs was displaying the originating route type as a number. While numbers are cool, I for one am not terribly interested in memorizing them. Modify the (type %d) to a (%s) to just list the string type of the route. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-29bgpd: fix valgrind flagged errorsNitin Soni3-6/+12
Executed some evpn related tests with valgrind and saw some errors related to uninitialized memory and overlapping memcpy. This commit fixes those. Ticket: CM-21218 Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com> Reviewed-by: CCR-8249
2019-01-29zebra: add fwmark information at netlink levelPhilippe Guibert1-1/+2
ip rule configuration is being equipped with extra log information for fwmark information. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: display the list of iprules attached to a fs entryPhilippe Guibert6-11/+63
the list of iprules is displayed in the 'show bgp ipv4 flowspec detail' The list of iprules is displayed, only if it is installed. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: change priority of fs pbr rulesPhilippe Guibert3-2/+12
two kind of rules are being set from bgp flowspec: ipset based rules, and ip rule rules. default route rules may have a lower priority than the other rules ( that do not support default rules). so, if an ipset rule without fwmark is being requested, then priority is arbitrarily set to 1. the other case, priority is set to 0. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: notify callback when ip rule from/to rule has been configuredPhilippe Guibert3-8/+60
because ip rule creation is used to not only handle traffic marked by fwmark; but also for conveying traffic with from/to rules, a check of the creation must be done in the linked list of ip rules. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: conversion from fs to pbr: support for ip rule from/toPhilippe Guibert1-2/+161
adding/suppressing flowspec to pbr is supported. the add and the remove code is being added. now,bgp supports the hash list of ip rule list. The removal of bgp ip rule is done via search. The search uses the action field. the reason is that when a pbr rule is added, to replace an old one, the old one is kept until the new one is installed, so as to avoid traffic to be cut. This is why at one moment, one can have two same iprules with different actions. And this is why the algorithm covers this case. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: ip rule zebra layer adapted to handle both casesPhilippe Guibert3-26/+64
now, ip rule can be created from two differnt ways; however a single zebra API has been defined. so make it consistent by adding a parameter to the bgp zebra layer. the function will handle the rest. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: the fs entry is valid for any rule only, by using ipruleset cmdPhilippe Guibert1-4/+36
Before, it was not possible to create any rules. Now, it is possible to have flowspec rules relying only on ip rule command. The check is done here. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: an hash list of pbr iprule is createdPhilippe Guibert3-0/+93
that iprule list stands for the list of fs entries that are created, based only on ip rule from/to rule. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: upon bgp fs study, determine if iprule can be usedPhilippe Guibert3-2/+26
instead of using ipset based mechanism to forward packets, there are cases where it is possible to use ip rule based mechanisms (without ipset). Here, this applies to simple fs rules with only 'from any' or 'to any'. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: remove useless fields in bgp_pbr_entry_mainPhilippe Guibert1-13/+0
main bgp structure that contains fs information is being cleaned. some fields are removed. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2019-01-29bgpd: detach vrf labels allocated, when removing bgp instancePhilippe Guibert1-0/+4
bgp instance is disabling the label allocated to reach vrf entity. previously, only vrf disabling was removing the label. now, when bgp leaves, bgp instance also frees the label used. PR=62306 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Acked-by: Julien Floret <julien.floret@6wind.com>
2019-01-28zebra: Use the kernel flags from the IFA_FLAGS if it is availableDonald Sharp1-3/+10
The ifa_flags value in the netlink message was originally a uint8_t value. The linux kernel quickly ran out of 8 bits of data to pass and the IFA_FLAGS value was added to the netlink message to allow more than 8 bits of data to be passed. So replace the ifa_flags with the IFA_FLAGS value if it exists in the interface netlink message. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-28lib: protect termtable from bad fmt stringQuentin Young1-1/+1
Termtable can write out-of-bounds if given a format string with too many column separators. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2019-01-28ospfd: ospfd core if hello packet exceeds link MTUNitin Soni3-0/+25
Ospfd cored because of an assert when we try to write more than the MTU size to the ospf packet buffer stream. The problem is - we allocate only MTU sized buffer. The expectation is that Hello packets are never large enough to approach MTU. Instead of crashing, this fix discards hello and logs an error. One should not have so many neighbors behind an interface. Ticket: CM-22380 Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com> Reviewed-by: CCR-8204
2019-01-27*: The onlink attribute should be owned by the nexthop not the route.Donald Sharp7-17/+25
The onlink attribute was being passed from upper level protocols as an attribute of the route *not* the individual nexthop. When we pass this data to the kernel, we treat the onlink as a attribute of the nexthop. This commit modifies the code base to allow us to pass the ONLINK attribute as an attribute of the nexthop. This commit also fixes static routes that have multiple nexthops some onlink and some not. ip route 4.5.6.7/32 192.168.41.1 eveth1 onlink ip route 4.5.6.7/32 192.168.42.2 S>* 4.5.6.7/32 [1/0] via 192.168.41.1, eveth1 onlink, 00:03:04 * via 192.168.42.2, eveth2, 00:03:04 sharpd@robot ~/frr2> sudo ip netns exec EVA ip route show 4.5.6.7 proto 196 metric 20 nexthop via 192.168.41.1 dev eveth1 weight 1 onlink nexthop via 192.168.42.2 dev eveth2 weight 1 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-26ospf6d: fix FreeBSD IPv6 multicast group join raceRafael Zalamena1-0/+16
Avoid a IPv6 multicast group join race by delaying the group install before processing all event queue. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2019-01-26bgpd: interface based peers should automatically override it's peer groupDonald Sharp3-10/+13
When a interface based peer is setup and if it is part of a peer group we should ignore this and just use the PEER_FLAG_CAPABILITY_ENHE no matter what. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-26bgpd: Fix crash in various 'show bgp neighbor json' commandsDonald Sharp1-0/+1
bgp would crash with various `show bgp neighbor json` commands based upon whether or not it did a pretty print of the output or not. This is because we were freeing the data 2 times. Cleanup so that we free the json data 1 time. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-26zebra: Keep track of when routes are queued/dequeued from the dataplaneDonald Sharp1-28/+21
When we process the dataplane data, keep track of whether or not a route is in transit or not. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-26zebra: Use ROUTE_ENTRY_INSTALLED as decision for route is installedDonald Sharp4-61/+110
zebra is using NEXTHOP_FLAG_FIB as the basis of whether or not a route_entry is installed. This is problematic in that we plan to separate out nexthop handling from route installation. So modify the code to keep track of whether or not a route_entry is installed/failed. This basically means that every place we set/unset NEXTHOP_FLAG_FIB, we actually also set/unset ROUTE_ENTRY_INSTALLED on the route_entry. Additionally where we check for route installed via NEXTHOP_FLAG_FIB switch over to checking if the route think's it is installed. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-26lib, zebra: Abstract character selection for nexthop displayDonald Sharp2-16/+16
When we are selecting nexthops for disply, abstract the notion of what character we display to the end user about the status of the nexthop. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-26zebra: Fix use before initializedDonald Sharp1-3/+2
When we discover that a command given to the route add/delete function in rt_socket.c is bogus, print out a debug message but don't attempt to actually use a nexthop that we have not figured out yet as part of the data. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-26zebra: Having one goto in a function to just return is sillyDonald Sharp1-4/+1
Just return right there, goto's are useful if you have common code that needs to be cleaned up before exiting this function, of which this function has none and there is only one goto. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-25zebra: fix dup addr detect remote macip add caseChirag Shah1-3/+8
A MACIP is detected as duplicate and after that the host continue to move behind different VTEPs results in local VTEP receiving remote mobility events. In remote_macip_add, ensure to trigger dad if MAC is marked as duplicate. In case of freeze action enabled, is_dup_detect will be set to avoids installing frozen MAC into kernel. Ticket:CM-23649 Testing Done: Configured detection action freeze with detection count as 7 at DUT and >7 at remote VTEP, trigger MAC-IP mobility between VTEPs. once tdetection count reached, MAC detected as duplicate, post detection move the host to remote. The local VTEP receives remote macip add and entry is not installed into kernel with fix. root@VTEP1:~# net show evpn mac vni 1002 mac aa:aa:aa:aa:aa:aa MAC: aa:aa:aa:aa:aa:aa Remote VTEP: 27.0.0.16 Local Seq: 7 Remote Seq: 8 Duplicate, detected at Fri Jan 25 05:03:29 2019 Neighbors: 11.11.11.11 Inactive Kernel entry still points to LOCAL root@VTEP1:~# bridge fdb show | grep aa:aa:aa aa:aa:aa:aa:aa:aa dev hostbond3 vlan 1002 master VxLanA-1 Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
2019-01-25zebra: display metric for connected routesAnuradha Karuppiah1-6/+6
In a VRR/VRRP setup we can have connected routes with different costs. So this change eliminates suppressing metric display for connected routes. Sample output - root@TORC11:~# vtysh -c "show ipv6 route vrf vrf1" Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, > - selected route, * - FIB route VRF vrf1: K * ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:36 C * 2001:aa:1::/64 [0/100] is directly connected, vlan1002-v0, 00:00:36 C>* 2001:aa:1::/64 [0/90] is directly connected, vlan1002, 00:00:36 Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2019-01-25zebra: set connected route metric based on the devaddr metricAnuradha Karuppiah9-14/+110
MACVLAN devices are typically used for applications such as VRR/VRRP that require a second MAC address (virtual). These devices have a corresponding SVI/VLAN device - root@TORC11:~# ip addr show vlan1002 39: vlan1002@bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default link/ether 00:02:00:00:00:2e brd ff:ff:ff:ff:ff:ff inet6 2001:aa:1::2/64 scope global valid_lft forever preferred_lft forever root@TORC11:~# ip addr show vlan1002-v0 40: vlan1002-v0@vlan1002: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default link/ether 00:00:5e:00:01:01 brd ff:ff:ff:ff:ff:ff inet6 2001:aa:1::a/64 metric 1024 scope global valid_lft forever preferred_lft forever root@TORC11:~# The macvlan device is used primarily for RX (VR-IP/VR-MAC). And TX is via the SVI. To acheive that functionality the macvlan network's metric is set to a higher value. Zebra currently ignores the devaddr metric sent by the kernel and hardcodes it to 0. This commit eliminates that hardcoding. If the devaddr metric is available (METRIC_MAX) it is used for setting up the connected route otherwise we fallback to the dev/interface metric. Setting the macvlan metric to a higher value ensures that zebra will always select the connected route on the SVI (and subsequently use it for next hop resolution etc.) - root@TORC11:~# vtysh -c "show ip route vrf vrf1 2001:aa:1::/64" Routing entry for 2001:aa:1::/64 Known via "connected", distance 0, metric 1024, vrf vrf1 Last update 11:30:56 ago * directly connected, vlan1002-v0 Routing entry for 2001:aa:1::/64 Known via "connected", distance 0, metric 0, vrf vrf1, best Last update 11:30:56 ago * directly connected, vlan1002 root@TORC11:~# Ticket: CM-23511 Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2019-01-25bgpd: reinstate current bgp best route on an inactive neigh delAnuradha Karuppiah4-22/+44
When an inactive-neigh delete is rxed bgp will not have a local path to remove (and re-run path selection). Instead it simply re-installs the current best remote path if any. Ticket: CM-23018 Testing Done: evpn-min Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2019-01-25zebra: propagate inactive neigh deletes to bgpdAnuradha Karuppiah3-20/+23
When a local neigh is added with a MAC that is remote or absent the neigh is kept in zebra as local/in-active. But not propagated to bgpd. Similarly when an inactive neigh is deleted the del-msg is not propagated to bgpd. Without this change bgp and zebra would fall out of sync as that bgp would not know to rerun bestpath and for it to reinstall a known remote path for the mac-ip in question. To fix this we now propagate inactive neigh deletes to bgpd. Ticket: CM-23018 Testing Done: 1. evpn-min 2. manually triggered the out-of-sync state and verified the fix Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2019-01-25bgpd: fill the zebra mac-ip route via a common apiAnuradha Karuppiah1-42/+22
Move the info filling for zebra mac-ip install (sent by bgpd) to a common place. The commit also fixes missing ROUTER flag for one of the cases added in a code branch that doesn't have the ROUTER changes - [ 6d8c603a bgpd: use IP address as tie breaker if the MM seq number is the same ] Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2019-01-25pimd: Convert to using an ifindex_t for the vifDonald Sharp1-1/+1
Let's stay consistent in the data type for the vif index Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-25pimd: Prevent crash from using pim static mroutesDonald Sharp1-1/+1
If you have an interface being added to a static mroute and that interface has been configured w/ pim but does not have a valid ip address yet, we do not create a VIF for that device yet. As such when we attempt to assign the vif array in the pim static data structure we attempt to write into -1 of that array. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-25doc: fix mistaken indentationQuentin Young1-1/+1
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2019-01-24lib: don't disable "log file" on "log syslog"David Lamparter1-2/+0
FRR log targets are independent, so "log syslog" must not disable "log file" output. Fixes: #3551 Fixes: 0204baa87630b210c71d9ae0e2569cff0fb0539b Signed-off-by: David Lamparter <equinox@diac24.net>
2019-01-24build, lib/yang: bake in extensions if possibleDavid Lamparter5-0/+64
Starting with libyang 0.16.74, we can load internally embedded yang extensions instead of going through the file system/dlopen. Detect support for this at build time and use if available. NB: the fallback mechanism will go away in a short while. Signed-off-by: David Lamparter <equinox@diac24.net>
2019-01-24zebra: Add code to track sequence number from zebra_routerDonald Sharp3-2/+21
The sequence number used should be unique and increase by 1 for netlink commands. This will allow the code to match up batched commands to actual requests, so that we can signal the failure correctly back. So start the movement and tracking of sequence numbers as an atomic uint32_t in zebra_router. Modify the dataplane code to start tracking contexts from this value. In future commits we will move more of the sequencing data into using this value. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-01-24Treewide: use ANSI function definitionsRuben Kerkhof78-127/+121
Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
2019-01-24bgpd: route-map fails to filter type-5 routesNitin Soni1-2/+8
Route-map filtering is based on the value of "bgp->adv_cmd_rmap[afi][safi].map". For example, we advertise routes in bgp_evpn_advertise_type5_routes() based on the value of "bgp->adv_cmd_rmap[afi][safi].map". This variable gets populated in vty handler bgp_evpn_advertise_type5. This variable will not get populated if we have not yet applied the route-map configuration. The fix is to correctly populate "bgp->adv_cmd_rmap[afi][safi].map" in bgp_route_map_process_update() if it has not been populated before. Ticket: CM-23263 Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com> Reviewed-by: CCR-8163
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-15 02:01:06 +0100