summaryrefslogtreecommitdiff
path: root/bgpd/bgp_ecommunity.h
AgeCommit message (Collapse)Author
2024-02-09bgpd: Optimize memory for ecommunity structDonatas Abraitis
``` struct ecommunity { long unsigned int refcnt; /* 0 8 */ uint8_t unit_size; /* 8 1 */ _Bool disable_ieee_floating; /* 9 1 */ /* XXX 2 bytes hole, try to pack */ uint32_t size; /* 12 4 */ uint8_t * val; /* 16 8 */ char * str; /* 24 8 */ /* size: 32, cachelines: 1, members: 6 */ /* sum members: 30, holes: 1, sum holes: 2 */ /* last cacheline: 32 bytes */ }; /* saved 8 bytes! */ ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-11-21bgpd: fix export prefixes when rt extcomm set by route-mapPhilippe Guibert
When exporting BGP prefixes, it is necessary to configure the route target extended communities with the following command: > rt vpn export <RouteTarget> But the customer may need to configure the route-target to apply to bgp updates, solely based on a route-map criterium. by using the below route-map configured like that: > route-map vpn export <routemapname> Fix this by allowing to export bgp updates based on the presence of route-targets on either route-map or vpn configured rt. the exportation process is stopped if no route target is available in the ecommunity list. Fixes: ddb5b4880ba8 ("bgpd: vpn-vrf route leaking") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-06-27Merge pull request #13722 from fdumontet6WIND/color_extcommDonatas Abraitis
bgpd,lib,yang: add colored extended communities support
2023-06-26bgpd: add functions related to srte_color managementFrancois Dumontet
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
2023-06-26bgpd: add colored extended communities supportFrancois Dumontet
add support of color extended community, conforming to RFC 9012. This extended community will be added to the existing one, RT,SOO and Node Target. The configuration will be made through the route-map service. find above a configuration example: router bgp 65001 bgp router-id 192.168.1.1 no bgp ebgp-requires-policy no bgp network import-check neighbor 192.168.1.2 remote-as external neighbor 192.168.1.3 remote-as external neighbor 192.168.1.4 remote-as external address-family ipv4 unicast network 10.10.10.10/24 route-map rmap exit-address-family ! route-map rmap permit 10 set extcommunity color 55555 200 exit Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
2023-05-30bgpd: Add MAC-VRF Site-of-Origin supportTrey Aspelund
Initial support for configuring an SoO for all MAC-VRFs (EVIs/L2VNIs). This provides a topology-independent method of preventing EVPN routes from one MAC-VRF "site" (an L2 domain) from being imported by other PEs in the same MAC-VRF "site", similar to how SoO is traditionally used in L3VPN to identify and break loops for an L3/IP-VRF "site". One example of where a MAC-VRF SoO can be used to avoid an L2 control plane loop is with Active/Active MLAG VTEPs. For a given L2 site only one control plane should be active. SoO can be used to ID/ignore entries originated from the local MAC-VRF site so that EVPN will not attempt to manage entries that are already handled by MLAG. Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
2023-04-14bgpd: Reuse encode_route_target_ip() functionDonatas Abraitis
Before this patch, this function wasn't used in the code. Let's reuse this since it's uses the same pattern for encoding route-target extcommunity. Also reuse encode_route_target_as[4]() as well. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-04-14bgpd: Implement Node Target Extended CommunitiesDonatas Abraitis
kttps://datatracker.ietf.org/doc/html/draft-ietf-idr-node-target-ext-comm unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.2 adver' BGP table version is 1, local router ID is 192.168.1.1, vrf id 0 Default local pref 100, local AS 65001 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 10.10.10.10/32 0.0.0.0 0 32768 i Total number of prefixes 1 unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.3 adver' BGP table version is 1, local router ID is 192.168.1.1, vrf id 0 Default local pref 100, local AS 65001 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 10.10.10.10/32 0.0.0.0 0 32768 i Total number of prefixes 1 unet> sh r2 vtysh -c 'show ip bgp 10.10.10.10/32' % Network not in table unet> sh r3 vtysh -c 'show ip bgp 10.10.10.10/32' BGP routing table entry for 10.10.10.10/32, version 1 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.1.1 65001 192.168.1.1 from 192.168.1.1 (192.168.1.1) Origin IGP, metric 0, valid, external, best (First path received) Extended Community: NT:192.168.1.3 NT:192.168.1.4 Last update: Tue Apr 11 23:19:33 2023 unet> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-09*: auto-convert to SPDX License IDsDavid Lamparter
Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2022-09-04bgpd: Handle Origin Validation State extended community via route-map matchDonatas Abraitis
Add an ability to match via route-maps. An additional route-map command `match rpki-extcommunity <invalid|notfound|valid>` added. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-09-04bgpd: Add Origin Validation State extended communityDonatas Abraitis
``` spine1-debian-11# sh ip bgp 100.100.100.101/32 BGP routing table entry for 100.100.100.101/32, version 21 Paths: (1 available, best #1, table default) Not advertised to any peer Local fe80::ca5d:fd0d:cd8:1bb7 from eth3 (172.17.0.3) (fe80::ca5d:fd0d:cd8:1bb7) (used) Origin incomplete, metric 0, localpref 100, valid, internal, best (First path received) Extended Community: OVS:invalid Last update: Wed Aug 31 19:31:46 2022 spine1-debian-11# sh ip bgp 100.100.100.100/32 BGP routing table entry for 100.100.100.100/32, version 17 Paths: (1 available, best #1, table default) Not advertised to any peer Local fe80::ca5d:fd0d:cd8:1bb7 from eth3 (172.17.0.3) (fe80::ca5d:fd0d:cd8:1bb7) (used) Origin incomplete, metric 0, localpref 100, valid, internal, best (First path received) Extended Community: OVS:not-found Last update: Wed Aug 31 19:31:46 2022 spine1-debian-11# ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-08-19bgpd: Rename ecomm_intersect() to ecommunity_include()Donatas Abraitis
Makes more sense. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2021-08-30bgpd: Add `neighbor PEER link-bw-encoding-ieee`Donatas Abraitis
This is to avoid breaking changes between existing deployments of extended community for bandwidth encoding. By default FRR uses uint32 to encode bandwidth, which is not as the draft requires (IEEE floating-point). This switch enables the required encoding per-peer. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-08-29bgpd: Use IEEE-754 Floating Point for storing extcommunity bandwidthDonatas Abraitis
https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 says: The bandwidth of the link is expressed as 4 octets in IEEE floating point format, units being bytes (not bits!) per second. It is carried in the Local Administrator subfield of the Value Field. Before: ``` Extended Community (16), length: 8, Flags [OT]: unknown extd community typecode (0x0004), Flags [none] 0x0000: 0004 fdeb 0001 e848 0x0000: 0004 fdeb 0001 e848 Updated routes: 172.16.16.1/32 ``` 0001 e848 - means 125000 (1Mbps), which is encoded incorrect. After: ``` Extended Community (16), length: 8, Flags [OT]: unknown extd community typecode (0x0004), Flags [none] 0x0000: 0004 fdeb 47f4 2400 0x0000: 0004 fdeb 47f4 2400 Updated routes: 172.16.16.1/32 ``` 47f4 2400 - means the same, but in floating point format. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-08-24lib: remove the dependency on bgpd codeIgor Ryzhov
The library code should not depend on a specific daemon's code. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
2021-08-03bgpd: Keep extcommunity bandwidth commands persistent in route-mapsDonatas Abraitis
~/frr# vtysh -c 'conf' -c 'route-map testas permit 10' -c 'set extcommunity bandwidth 321' ~/frr# vtysh -c 'show route-map testas' | grep 321 extcommunity bandwidth 321 non-transitive ~/frr# vtysh -c 'sh run' | grep 321 ~/frr# Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-02-02bgpd: expose ecommunity string lengthPat Ruddy
Expose the max ecommunity string length for range checking in SNMP route-target string processing. Signed-off-by: Pat Ruddy <pat@voltanet.io>
2021-01-18bgpd: Use uint32_t for size value instead of int in ecommunity structDonald Sharp
The `struct ecommunity` structure is using an int for a size value. Let's switch it over to a uint32_t for size values since a size value for data can never be negative. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-11-15bgpd: Allow NULL to be passed in for ecommunity_freeDonald Sharp
Allow some cleanup of if statements to just make ecommunity_free() check this. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-10-26bgpd: support for DF election in EVPN-MHAnuradha Karuppiah
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>
2020-08-21bgp, zebra: add some alignments with remarks from communityPhilippe Guibert
align the code to remarks from community. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-08-21bgpd: support for bgp ipv6 ext community, and flowspec redirect ipv6Philippe Guibert
rfc 5701 is supported. it is possible to configure in bgp vpn, a list of route target with ipv6 external communities to import. it is to be noted that this ipv6 external community has been developed only for matching a bgp flowspec update with same ipv6 ext commmunity. adding to this, draft-ietf-idr-flow-spec-v6-09 is implemented regarding the redirect ipv6 option. Practically, under bgp vpn, under ipv6 unicast, it is possible to configure : [no] rt6 redirect import <IPV6>:<AS> values. An incoming bgp update with fs ipv6 and that option matching a bgp vrf, will be imported in that bgp vrf. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-08-21bgpd: support for redirect ipv6 simpson methodPhilippe Guibert
this commit supports [0] where ipv6 address is encoded in nexthop attribute of nlri, and not in bgp redirect ip extended community. the community contains only duplicate information or not. Adding to this, because an action or a rule needs to apply to either ipv4 or ipv6 flow, modify some internal structures so as to be aware of which flow needs to be filtered. This work is needed when an ipv6 flowspec rule without ip addresses is mentioned, we need to know which afi is served. Also, this work will be useful when doing redirect VRF. [0] draft-simpson-idr-flowspec-redirect-02.txt Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2020-08-05bgpd: extended-community and attrs for MAC-IP SYNC route handlingAnuradha Karuppiah
A new proxy flag has been added to the already existing NA extended community to allow proxy advertisment of a local host by a VTEP that is yet to indpendently establish local reachability. Reference: draft-rbickhart-evpn-ip-mac-proxy-adv The extendend mac-mobility sequence number needs to be synced across the ES peers. However we cannot let a ES-peer path win over a local path on the same ES. To accomplish that some parameters such as the MM seq number are bubbled up from the non-best path to the local path. This mechanism is explained further in the path-selection patch. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-08-05bgpd: extended community for EAD routesAnuradha Karuppiah
1. EAD routes require support for ESI_LABEL extended community. The primary info in this EC is a flags the specifies if the ES is Single-active or active-acive. 2. Also fixed up ES_IMPORT_RT string. Support was added a long time ago for ESR/Type-4 routes but it has not really been exercised for MH functionality till now. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-03-30bgpd: Announce cumulative link bandwidth to EBGP peersvivek
When announcing ourselves as the next hop (e.g., to EBGP peers), if the best path has the link bandwidth extended community and it is transitive, change the value of the link bandwidth to the cumulative downstream bandwidth (sum of the link bandwidths of all our multipaths) as this makes the most sense. It is also implied by https://tools.ietf.org/html/draft-mohanty-bess-ebgp-dmz. Of course, do not override the link bandwidth if it has been specified by policy. Note: Transitive extended communities will be automatically passed along to EBGP peers; this commit is updating the value that is announced to something that is the most appropriate. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
2020-03-30bgpd: Ability to add/update unique extended communitiesvivek
Certain extended communities cannot be repeated. An example is the BGP link bandwidth extended community. Enhance the extended community add function to ensure uniqueness, if requested. Note: This commit does not change the lack of uniqueness for any of the already-supported extended communities. Many of them such as the BGP route target can obviously be present multiple times. Others like the Router's MAC should most probably be present only once. The portions of the code which add these may already be structured such that duplicates do not arise. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
2020-03-30bgpd: Check and extract link bandwidth valuevivek
Extract link bandwidth value into attribute from the extended community, if present. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
2020-03-30bgpd: Display link bandwidth extended communityvivek
Additional extended community definitions and display of link-bandwidth extended community. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
2020-03-30bgpd: Add link bandwidth route-map commandsvivek
Implement route-map option to set the link-bandwidth extended community. The command is of the form: set extcommunity bandwidth <(1-26214400)|cumulative|num-multipaths> [non-transitive] The options available are to specify the actual bandwidth value in Mbps, base it on the cumulative downstream bandwidth or base it on the number of multipaths. The last option is based on https://tools.ietf.org/html/draft-mohanty-bess-ebgp-dmz. Further, in alignment with the use case described in this IETF draft, the extended community is encoded as transitive by default. There is an option available to specify that it should be non-transitive. The link-bandwidth itself is carried in bytes per second as specifed in https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth Note: This commit only handles the processing for bandwidth specifed as a value; subsequent commits will handle the processing of the other options. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
2020-03-30bgpd: Add link bandwidth extended community definitionvivek
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
2020-03-21bgpd: Convert lots of int type functions to bool/voidDonatas Abraitis
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>
2020-03-18bgpd: Strip Route Targets during VRF-to-VRF route leakvivek
During VRF-to-VRF route leaking, strip any extraneous route targets. This ensures that source-VRF-specific route targets or route targets that are internally assigned for the VRF-to-VRF route leaking don't get attached to the route in the target VRF. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
2019-11-22bgpd: use safe functions to work with ecom attrsQuentin Young
Tons of insane just-so pointer math here where it is not needed. This is too smart. Use safer methods. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2019-09-24bgpd : route agg. with ecomm attribute is consuming lot of cycles.vdhingra
While configuring aggregate route prepare the hash table first, then prepare the aggregated ecomm value and then do the unique sort once for ecommunity. Signed-off-by: vishaldhingra<vdhingra@vmware.com>
2019-05-16Merge pull request #4340 from qlyoung/hash-key-constRuss White
lib: hashing functions should take const arguments
2019-05-14lib: hashing functions should take const argumentsQuentin Young
It doesn't make much sense for a hash function to modify its argument, so const the hash input. BGP does it in a couple places, those cast away the const. Not great but not any worse than it was. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2019-05-14bgpd: Extract tunnel type from extended communitiesLakshman Krishnamoorthy
This diff contains 2 parts: 1. Extract the tunnel type info from bgp extended communities. 2. Make rfapi use this common tunnel type ap Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
2019-02-28bgpd: Code to handle BGP aggregate's e-communities.Naveen Thanikachalam
With this commit: 1) The code to manage the extended-communities attribute of the routes that are aggregatable under a configured aggregate-address is introduced. 2) The code to compute the aggregate-route's extended-communities attribute is introduced. Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
2018-11-30bgpd: add new draft for redirect ip for flowspecPhilippe Guibert
that new option will overwrite simpson draft. There is a new ecommunity option whose type is 0x1 and subtype is 0xc. That option is defined here on iana.org/assignments/bgp-extended-communities page: - bgp-extended-communities.xhtml#trans-ipv4 It contains the IP address to redirect traffic to. The understanding of the draft is the following one: - if that community is only present, then the ip contained inside will be chosen as nexthop. - if that community is provided along with simpson extended community, then only the new redirect ip draft will be used. however, both will be displayed. - in other cases, if there is only the simpson extended community, then the nexthop IP of the NLRI will be chosen. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-10-19*: Replace hash_cmp function return value to a boolDonald Sharp
The ->hash_cmp and linked list ->cmp functions were sometimes being used interchangeably and this really is not a good thing. So let's modify the hash_cmp function pointer to return a boolean and convert everything to use the new syntax. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-07-17bgpd: support evpn nd ext communityChirag Shah
EVPN ND ext community support NA flag R-bit, to have proxy ND. Set R-bit in EVPN NA if a given router is default gateway or there is a local router attached, which can be determine based on local neighbor entry. Implement BGP ext community attribute to generate and parse R-bit and pass along zebra to program neigh entry in kernel. Upon receiving MAC/IP update with community type 0x06 and sub_type 0x08, pass the R-bit to zebra to program neigh entry. Set NTF_ROUTER in neigh entry and inform kernel to do proxy NA for EVPN. Ref: https://tools.ietf.org/html/draft-ietf-bess-evpn-na-flags-01 Ticket:CM-21712, CM-21711 Reviewed By: Testing Done: Configure Local vni enabled L3 Gateway, which would act as router, checked show evpn arp-cache vni x ip <ip of svi> on originated and remote VTEPs. "Router" flag is set. Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
2018-05-16bgpd: Fix memory leak of ecommunity_ecom2strDonald Sharp
The creation of a temporary string for the ecommunity was being leaked when debugging is enabled. Write a bit of code to prevent this. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-04-30bgpd: utility routine to convert flowspec actions into pbr actionsPhilippe Guibert
This utility routine in bgp ecommunity converts the flowspec actions into a readable format in a policy routing action context. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-04-25bgpd: Fixes for VRF route leakingvivek
Implement fixes for route leaking between VRFs through BGP, especially for the scenario where routes are leaked from a VRF X to multiple other VRFs. This include making sure that import and export happen via the global VPN table, setting RD correctly and proper handling for multiple import/export. Ticket: CM-20256 Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-04-09bgpd: handle ecom redirect-ipPhilippe Guibert
This extended ecommunity is defined with draft-ietf-idr-flowspec-redirect-ip-02 and is read from the BGP update received. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-30bgpd: ecommunity show bgp ipv4 flowspecPhilippe Guibert
ecommunity library is modified to return the flowspec ecommunities in display format. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-30bgpd: add flowspec featurejaydom
This work is derived from a work done by China-Telecom. That initial work can be found in [0]. As the gap between frr and quagga is important, a reworks has been done in the meantime. The initial work consists of bringing the following: - Bringing the client side of flowspec. - the enhancement of address-family ipv4/ipv6 flowspec - partial data path handling at reception has been prepared - the support for ipv4 flowspec or ipv6 flowspec in BGP open messages, and the internals of BGP has been done. - the memory contexts necessary for flowspec has been provisioned In addition to this work, the following has been done: - the complement of adaptation for FS safi in bgp code - the code checkstyle has been reworked so as to match frr checkstyle - the processing of IPv6 FS NLRI is prevented - the processing of FS NLRI is stopped ( temporary) [0] https://github.com/chinatelecom-sdn-group/quagga_flowspec/ Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: jaydom <chinatelecom-sdn-group@github.com>
2018-03-27*: use C99 standard fixed-width integer typesQuentin Young
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>
2017-09-13bgpd: deduplicate struct definitionQuentin Young
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>