summaryrefslogtreecommitdiffstats
path: root/bgpd/bgp_route.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* bgpd: Fix crash on shutdownDonald Sharp2018-05-191-5/+8
| | | | | | | | There exists code paths where the rn was being used after free. This eliminates these code paths. Fixes: CM-21019 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Merge pull request #2240 from donaldsharp/ubuntu_bullMartin Winter2018-05-161-1/+1
|\ | | | | Ubuntu 18.04 fixes
| * bgpd: Prevent possible uninited variable.Donald Sharp2018-05-151-1/+1
| | | | | | | | Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | bgpd: Improve JSON support for large communitiesPascal Mathis2018-05-131-6/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation of building JSON output is greatly different for large communities compared to standard communities. This is mainly noticeable by the missing 'list' attribute, which usually offers an array of all communities present on a BGP route. This commit adds the missing functionality of properly returning a 'list' attribute in JSON output and also tries a similar approach like the standard communities are using to implement this feature. Additionally, the 'format' specifier has been completely removed from large communities string/JSON rendering, as the official RFC8092 specifies that there is only one canonical representation: > The canonical representation of BGP Large Communities is three > separate unsigned integers in decimal notation in the following > order: Global Administrator, Local Data 1, Local Data 2. Numbers > MUST NOT contain leading zeros; a zero value MUST be represented with > a single zero. Each number is separated from the next by a single > colon. For example: 64496:4294967295:2, 64496:0:0. As the 'format' specifier has not been used/checked and only one canonical representation exists per today, there was no reason to keep the 'format' parameter in the function signature. Last but not least, the struct attribute 'community_entry.config' is no longer being used for large communities and instead 'lcommunity_str' is being called to maintain a similar approach to standard communities. As a side effect, this also fixed a memory leak inside 'community_entry_free' which did not free the allocated memory for the 'config' attribute when dealing with a large community. Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
* Merge pull request #2214 from donaldsharp/pointer_countingRuss White2018-05-121-0/+5
|\ | | | | More bgp fixes
| * bgpd: Update parent entry's refcount for imported routesvivek2018-05-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Imported routes in a VRF routing table have a reference to their parent route entry which resides in the EVPN or IPVPN routing table. Ensure that this reference uses appropriate locking so that the parent entry doesn't get freed prematurely. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> (cherry picked from commit 13cb6b22ba9d558b1b4a1e8752f63f13242462a7) Conflicts: bgpd/bgp_mplsvpn.c Ticket: CM-20471 Testing Done: a) Ran vrf_route_leak tests without fix and hit crash, ran twice with fix and did not see the crash. b) Ran evpn-smoke and ensured there were no new failures.
* | Merge pull request #2132 from donaldsharp/missed_stuffRuss White2018-05-121-8/+34
|\ \ | |/ |/| Missed stuff
| * bgpd, lib, zebra: Cleanup formatting issues foundDonald Sharp2018-05-091-8/+6
| | | | | | | | | | | | Cleanup the formating issues found. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
| * bgpd: enable neighbor-nexthop-self for l2vpn evpn address familyMitesh Kanjariya2018-05-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In the FRR implementation of EVPN, eBGP leaf-spine peering for EVPN is fully supported by allowing the next hop to be propagated and not rewritten at each hop. There are other changes also related to route import to facilitate this. However, propagating the next hop is not correct in some cases. Specifically, if the DC is comprised of multiple PODs with distinct intra-POD and inter-POD VxLAN tunnels, EVPN routes received from an adjacent POD by a border/exit leaf must be propagated into the local POD with the next hop rewritten (to self). Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
| * bgpd: modify route install/withdraw logic for evpn type-5 routes in vrfMitesh Kanjariya2018-05-091-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table. along with these routes, we also install the RMAC and the nexthop Neigh entries. There might be scenarios were the bestpath has changed and we are now pointing to a new nexthop with a different RMAC. As per BGP logic, we just send an update for the route and the nexthop is replaced. However, this causes problem because the RMAC and neigh entry corresponding to the previous nexthop are still lingering in the system. We need to clear those entries for proper functoning. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
| * bgpd: apply advertise ipv4 unicast route-map while advertising type-5 routesMitesh Kanjariya2018-05-091-6/+24
| | | | | | | | | | | | | | | | A newly added ipv4/ipv6 route in BGP RIB might be advertised as type-5 EVPN route. The user might have configured a route-map for advertising type-5 routes. We need to apply this route-map while advertising ipv4/ipv6 routes as type-5. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* | Merge pull request #2137 from mkanjari/evpn-addr-changeRuss White2018-05-091-9/+11
|\ \ | |/ |/| *: change struct evpn_addr to include a union of all evpn route types
| * *: change struct evpn_addr to include a union of all evpn route typesmitesh2018-05-031-9/+11
| | | | | | | | | | | | | | | | | | | | EVPN prefix depends on the EVPN route type. Currently, in FRR we have a prefix_evpn/evpn_addr which relates to a evpn prefix. We need to convert this to encompass an union of various EVPN route-types. This diff handles the necessary code changes to adopt the new struct evpn_addr. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
* | Merge pull request #2073 from pguibert6WIND/bgp_fs_pbrRuss White2018-05-031-1/+1
|\ \ | | | | | | Bgp Flowspec Policy Based Routing
| * | bgpd: add function handling flowspec entries to pass to zebraPhilippe Guibert2018-04-301-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | Add a policy-route API to handle flowspec entry. The entry is analysed, converted, and selected if it is possible to inject the flowspec entry in local policy routing entries. redirect IP and redirect VRF actions are handled. The former extracts the IPv4 address to redirect traffic to. The latter calculates the matching VRF to redirect traffic to. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* / bgpd: when showing routes, add nexthop vrf and announce-self flagG. Paul Ziemba2018-04-281-14/+159
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | As part of recent vpn-vrf leaking changes, it is now possible for a route to refer to a nexthop in a different vrf. There is also a new route flag that means "when announcing this route, indicate myself as the next-hop." route_vty_out(): nexthops are appended with: "@VRFID" (where VRFID is the numerical vrf id) when different from the route's vrf; "<" when the route's BGP_INFO_ANNC_NH_SELF is set This change also shows the route table's vrf id in the table header. route_vty_out_detail(): show nexthop's vrf and announce-nh-self flag if appropriate. Both functions are also augmented to add json elements nhVrfId, nhVrfName, and announceNexthopSelf as appropriate. The intent of these changes is to make it easier to understand/debug the relationship between a route and its nexthops. Signed-off-by: G. Paul Ziemba <paulz@labn.net>
* bgpd: Prevent vrf 2 vrf route leaking from going offbox.Donald Sharp2018-04-251-0/+10
| | | | | | | | | | | | | | The vrf 2 vrf route leaking auto-derives RD and RT and installs the routes into the appropriate vpn table. These routes when a operator configured ipv[4|6] vpn neighbors were showing up off box. The RD and RT values choosen are localy significant but globaly useless and may cause confusion. Put a special bit of code in to notice that we should not be advertising these routes off box. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd: move attr display into checked blockQuentin Young2018-04-131-24/+28
| | | | | | | | Here we have a block conditional on the nullity of a pointer, followed by a dereferennce of the same pointer. Move the deref into the conditional block. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* bgpd: Fix another aspath %d that should be %uDonald Sharp2018-04-131-1/+1
| | | | Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* bgpd: the nexthop IP is displayed for FS entries.Philippe Guibert2018-04-091-2/+14
| | | | | | | Most presumably, the nexthop IP is present, only when ECOM redirect IP is present. The nexthop is displayed. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* bgpd: nexthop tracking with labels for vrf-vpn leakingG. Paul Ziemba2018-04-041-13/+43
| | | | | | | | | | | | | | | Routes that have labels must be sent via a nexthop that also has labels. This change notes whether any path in a nexthop update from zebra contains labels. If so, then the nexthop is valid for routes that have labels. If a nexthop update has no labeled paths, then any labeled routes referencing the nexthop are marked not valid. Add a route flag BGP_INFO_ANNC_NH_SELF that means "advertise myself as nexthop when announcing" so that we can track our notion of the nexthop without revealing it to peers. Signed-off-by: G. Paul Ziemba <paulz@labn.net>
* Merge pull request #1993 from vivek-cumulus/evpn-fixesLou Berger2018-04-041-1/+1
|\ | | | | Evpn fixes
| * bgpd: Fix use of ROUTE_IMPORTED for EVPNvivek2018-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | Ensure that only EVPN routes are flagged as such when installing into or withdrawing from zebra, the earlier check broke L3VPN or VRF route-leaked routes. Also, fix an incorrect check related to imported routes in path selection. Updates: bgpd: Use BGP_ROUTE_IMPORTED for EVPN [vivek] Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
* | bgpd: enhance show bgp ipv4 flowspec <IP>Philippe Guibert2018-03-301-0/+13
| | | | | | | | | | | | | | | | This command gives detail about a FS entry which contains an IP that matches one of the rules of the FS entry. The output is the same output as when one does show bgp ipv4 flowspec detail Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | bgpd: support for json in show bgp ipv4 flowspec commandsPhilippe Guibert2018-03-301-3/+6
| | | | | | | | | | | | | | | | The json format is returd when requested from the two commands: - show bgp ipv4 flowspec - show bgp ipv4 flowspec detail Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | bgpd: support for show bgp ipv4 flowspecPhilippe Guibert2018-03-301-0/+40
| | | | | | | | | | | | | | | | | | | | The show bgp ipv4 flowspec routine is made available, displays the flowspec rules contained in the BGP FIB database, as well as the actions to be done on those rules. Two routines are available: show bgp ipv4 flowspec show bgp ipv4 flowspec detail Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | bgpd: disable aggregation for flowspec entriesPhilippe Guibert2018-03-301-2/+10
|/ | | | | | | | Flowspec entries do not need aggregation feature. Actually, all flowspec entries are unique. So, some check is done against aggregate functionalities in the code. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* *: use C99 standard fixed-width integer typesQuentin Young2018-03-271-65/+67
| | | | | | | | | | | | | | | | | | | | | | The following types are nonstandard: - u_char - u_short - u_int - u_long - u_int8_t - u_int16_t - u_int32_t Replace them with the C99 standard types: - uint8_t - unsigned short - unsigned int - unsigned long - uint8_t - uint16_t - uint32_t Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Merge pull request #1915 from vivek-cumulus/evpn-ipv6-external-routingPhilippe Guibert2018-03-271-2/+4
|\ | | | | EVPN IPv6 external routing
| * bgpd: Use BGP_ROUTE_IMPORTED for EVPNvivek2018-03-171-2/+4
| | | | | | | | | | | | | | | | | | Set EVPN routes imported into a VRF to (sub)type BGP_ROUTE_IMPORTED and use this for passing appropriate information to zebra. This is needed because relying on the Router MAC for this purpose was incorrect and impacted routing to/from external destinations, particularly for IPv6. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
* | bgpd: Use BGP instance to derive the VRF for route uninstallvivek2018-03-211-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When uninstalling routes from zebra, ensure that the BGP instance for which processing is being done is used to derive the VRF. It is incorrect to derive the VRF from the peer when dealing with scenarios like VRF route leaking, EVPN symmetric/external routing etc., where the peer which sourced the route could belong to a different VRF. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com> Ticket: CM-18413 Reviewed By: CCR-6778 Testing Done: Manual testing of BGP route withdraw/delete, bgp-min
* | bgpd: Fix peer withdrawal and route leaking for vpn's and vrf'sDonald Sharp2018-03-211-1/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a peer is removed the routes are withdrawn via bgp_process_main_one As such we need to put a bit of code in to handle this situation for the vpn/vrf route leaking code. I think this code path is also called for when a vrf's route is changed and I believe we will end up putting a bit more code here to handle the nexthop changes. I've also started trying to document the bgp_process_main_one function a bit better. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* | bgpd: Clean up peer status checking for a received nlriDonald Sharp2018-03-161-4/+0
|/ | | | | | | | | | | In bgp_update_receive the first thing we do is establish that the peer->status is Established. We then do a bunch of work and call bgp_nlri_parse where we break out for each address family. Each AFI is then checking for being peer->status is Established again. There is no point in checking this again. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Merge branch 'master' into working/master/bgp-vpn-vrf-leakingpaulzlabn2018-03-141-6/+41
|\
| * bgpd: Fix warningvivek2018-03-131-1/+2
| | | | | | | | Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
| * bgpd: Fix enum, use API for log stringvivek2018-03-131-4/+21
| | | | | | | | | | Suggested-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
| * Merge branch 'master' of https://github.com/frrouting/frr into ↵vivek2018-03-131-6/+7
| |\ | | | | | | | | | pmsi-parse-display
| | * Merge branch 'master' into type5-default-originateMitesh Kanjariya2018-03-121-25/+17
| | |\
| | * \ Merge branch 'master' into type5-default-originateMitesh Kanjariya2018-03-061-4/+7
| | |\ \
| | * | | bgpd: allow advertise-subnet cmd without enabling advertise ipv4 unicastMitesh Kanjariya2018-02-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Type-5 routes can be useful in multiple scenarios such as advertise-subnet, default-originate etc. Currently, the code has a restriction that to allow advertising type-5 routes, user has to first enable advertise ipvX command. This restriction is not necessary and should be removed. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
| * | | | Merge branch 'master' of https://github.com/frrouting/frr into ↵vivek2018-03-101-27/+21
| |\ \ \ \ | | | |_|/ | | |/| | | | | | | | | | | | | | | | | | | | | | pmsi-parse-display Conflicts: bgpd/bgp_attr.c
| * | | | bgpd: Fix warningsvivek2018-03-041-1/+0
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
| * | | | bgpd: Parse PMSI Tunnel Attribute and displayvivek2018-03-041-0/+17
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Received PMSI tunnel attributes (in EVPN type-3 route) were not recognized. Parse them and display the tunnel type when looking at routes. Note that the only tunnel type currently supported is ingress replication (IR). A warning message will be logged if the received tunnel type is something else, but the attribute is otherwise ignored. Updates: a21bd7a (bgpd: add PMSI_TUNNEL_ATTRIBUTE to EVPN IMET routes) Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
* | | | bgpd: vpn-vrf route leakingG. Paul Ziemba2018-03-091-13/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - add "debug bgp vpn label" CLI - improved debug messages for "debug bgp bestpath" - send vrf label to zebra after zebra informs bgpd of vrf_id - withdraw vrf_label from zebra if zebra informs bgpd that vrf_id is disabled Signed-off-by: G. Paul Ziemba <paulz@labn.net>
* | | | bgpd: some more debug info when 'debug updates out' is setG. Paul Ziemba2018-03-091-0/+7
| |/ / |/| | | | | | | | Signed-off-by: G. Paul Ziemba <paulz@labn.net>
* | | *: conform with COMMUNITY.md formatting rules, via 'make indent'Lou Berger2018-03-061-32/+23
| |/ |/| | | | | Signed-off-by: Lou Berger <lberger@labn.net>
* | Merge branch 'master' into evpn-bug-fixesMitesh Kanjariya2018-02-211-269/+246
|\|
| * Merge pull request #1701 from donaldsharp/zapi_vrf_labelMartin Winter2018-02-141-1/+1
| |\ | | | | | | Zapi vrf label
| | * *: Make code use a consisten definition of labelsDonald Sharp2018-02-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turns out we had 3 different ways to define labels all of them overlapping with the same meanings. Consolidate to 1. This one choosen is consistent naming wise with what the *bsd and linux kernels use. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
| * | whitespace/comment fixes per qlyoungG. Paul Ziemba2018-02-091-3/+3
| | | | | | | | | | | | Signed-off-by: G. Paul Ziemba <paulz@labn.net>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-21 03:44:00 +0100