Is there any plan to add support for Large BGP communities (1)? ExaBGP and Cisco (IOS XR) already implemented it (2), other vendors are moving too. Since almost one in four ASNs in the DFZ are 4-byte ASNs, 4-byte ASNs cannot properly use RFC1997 communities - the internet has a problem, especially newcomers. RIPE and ARIN are scraping the bottom of the barrel for 2-byte ASNs (they both only have tens left). The Large BGP Community is specifically designed with simplicity in mind. Will Quagga (and with them, all distros using Quagga) add support for it? [1] https://tools.ietf.org/html/draft-heitz-idr-large-community [2] http://largebgpcommunities.net/implementations/
There's a discussion on IDR at the moment on this about what to standardise. Some kind of common header would be good to avoid future-mess potential.
Created attachment 496 [details] Add support for Large BGP Communities on Quagga 1.1.0 This patch adds support for Large BGP Communities as defined in draft-ietf-idr-large-community-05 with Early IANA Allocation BGP Path Attribute value 32. Patch applies clean on the Quagga 1.1.0 release. Tested against ExaBGP and OpenBGPD. Build on Debian Jessie with automake-1.15. The patch provides route-map/filtering support, diagnostics/show support, etc. Feature parity with RFC1997 communities was the goal. Authors: Keyur Patel <keyur@arrcus.com>, Job Snijders <job@instituut.net>
Created attachment 497 [details] 0002-quagga-1.1.0-large-bgp-communities.patch This is version 2 of the patch. 1 bug fixed and removed a few lines of unnecessary code. Thanks to Pier Carlo Chiodi for spotting the bug!
It seems that this patch only supports one large community at once; I have not been able to add 2 large communities: QuaggaBGPD(config-route-map)# set large-community 1:2:3 <?> <cr> QuaggaBGPD(config-route-map)# set large-community 1:2:3 4:5:6 % [BGP] Unknown command: set large-community 1:2:3 4:5:6 The standard community command accepts more than 1 value: QuaggaBGPD(config-route-map)# set community 1:2 3:4 5:6
Oops! I will get that fixed asap
I have done new tests using this patch and I've found some issues: - I have not been able to use the `additive` statement to add communities to an existing set: QuaggaBGPD(config-route-map)# set large-community 65539:10:10 additive % [BGP] Unknown command: set large-community 65539:10:10 additive - I have not been able to find a way similar to `set comm-list xxx delete` to delete communities. Are these features really missing or it's simply my fault?
Hi Pier, Version 3 of the patch will have those features. We should be able to upload it somewhere in the next few days!
Created attachment 499 [details] 0003-quagga-1.1.0-large-bgp-communities This third version of the patch allows you to specify multiple large communities, to set large-communities in an 'additive' fashion, and to delete with 'set large-comm-list XXX delete'.
Created attachment 500 [details] 0004-quagga-1.1.0-large-bgp-communities.patch and now hopefully without bugs! :-)
Far better now, but I have not been able to delete large communities received from a peer: any hint? ip large-community-list 10 permit 65537:3:3 ip large-community-list standard DelTwo permit 65537:4:4 ip large-community-list standard DelTwo permit 65537:5:5 ip prefix-list DelOneLC seq 1 permit 203.0.113.23/32 ip prefix-list DelTwoLC seq 1 permit 203.0.113.24/32 route-map UseLargeCommunities permit 30 match ip address prefix-list DelOneLC set large-comm-list 10 delete route-map UseLargeCommunities permit 40 match ip address prefix-list DelTwoLC set large-comm-list DelTwo delete (full config here https://github.com/pierky/large-bgp-communities-playground/blob/master/tests/02/quagga.conf)
Will work on reproduction and update the patch
Created attachment 501 [details] 0005-quagga-1.1.0-large-bgp-communities.patch @Pier, can you test the new patch?
Created attachment 502 [details] 0008-quagga-1.1.0-large-bgp-communities This patch is still work in progress, feature complete but crashes sometimes.
Following on some notes from this link, https://github.com/pierky/bgp-large-communities-playground/blob/master/tests/02/quagga.conf I get the following errors when trying to set a community on a 32 bit ASN. Switched to 16 bit ASN and still see it. 2016/12/03 03:24:03 BGP: %ADJCHANGE: neighbor 100.125.255.61 Up 2016/12/03 03:24:04 BGP: 100.125.255.61: BGP attribute LARGE_COMMUNITY, fetch error 2016/12/03 03:24:04 BGP: %NOTIFICATION: sent to neighbor 100.125.255.61 3/5 (UPDATE Message Error/Attribute Length Error) 0 bytes 2016/12/03 03:24:04 BGP: Notification sent to neighbor 100.125.255.61: type 3/5 2016/12/03 03:24:04 BGP: %ADJCHANGE: neighbor 100.125.255.61 Down BGP Notification send To try and set the community, I'm using route-map rm-tag-subnets-out permit 010 match ip address prefix-list pl-dc-xxx set large-community 4200125501:10000:0 Thoughts? All quagga instances compiled with the 0008 patch and the following config options. ./configure --enable-vtysh --localstatedir=/var/run/quagga --enable-vty-group=quagga --disable-ripd --disable-ripngd --disable-ospfd --disable-ospf6d --disable-isisd --disable-pimd --enable-tcp-zebra --disable-ospfapi --disable-ospf-client --disable-rtadv --disable-doc
Created attachment 503 [details] 0009-quagga-1.1.0-large-bgp-communities.patch @Eric please try this one, this should address the length issue. (The crash issue patch is forthcoming)
Still seeing the same thing: 2016/12/03 11:38:46 BGP: %ADJCHANGE: neighbor 100.125.255.63 Down BGP Notification send 2016/12/03 11:38:49 BGP: %ADJCHANGE: neighbor 100.125.255.63 Up 2016/12/03 11:38:50 BGP: 100.125.255.63: BGP attribute LARGE_COMMUNITY, fetch error 2016/12/03 11:38:50 BGP: %NOTIFICATION: sent to neighbor 100.125.255.63 3/5 (UPDATE Message Error/Attribute Length Error) 0 bytes 2016/12/03 11:38:50 BGP: Notification sent to neighbor 100.125.255.63: type 3/5 2016/12/03 11:38:50 BGP: %ADJCHANGE: neighbor 100.125.255.63 Down BGP Notification send Simply commenting it out stops it. Uncommenting breaks it. Here's the peer configs .62 Router neighbor 100.125.255.63 remote-as 4200125501 neighbor 100.125.255.63 update-source 100.125.255.62 neighbor 100.125.255.63 route-map rm-default-accept-all out neighbor 100.125.255.63 route-map rm-default-accept-all in neighbor 100.125.255.63 ebgp-multihop neighbor 100.125.255.63 next-hop-self all .63 Router neighbor 100.125.255.62 remote-as 4200100000 neighbor 100.125.255.62 update-source 100.125.255.63 neighbor 100.125.255.62 next-hop-self all neighbor 100.125.255.62 send-community all neighbor 100.125.255.62 route-map rm-tag-chandler-2c-out out route-map rm-tag-chandler-2c-out permit 10 call rm-tag-subnets-out set local-preference 200 route-map rm-tag-subnets-out permit 010 match ip address prefix-list pl-chandler-ncs ! set large-community 4200125501:0:10000 route-map rm-tag-subnets-out permit 020 match ip address prefix-list pl-chandler-nashua ! set large-community 4200125501:0:10001
Created attachment 504 [details] 0010-quagga-1.1.0-large-bgp-communities.patch This should be the one! Many thanks to Keyur and Pier for development and debugging! Eric, do you want to give this a spin?
It doesn't flap anymore (as long all peers in the config have this patch). Keep it open though. I'm testing some configs. EKG
I could use some assistance in making it work. It doesn't flap/crash anymore, but it doesn't appear to be propogating the communities either. For router .61 neighbor 100.125.255.60 remote-as 4200100000 neighbor 100.125.255.60 update-source 100.125.255.61 neighbor 100.125.255.60 next-hop-self all neighbor 100.125.255.60 send-community all neighbor 100.125.255.60 route-map rm-tag-chandler-2a-out out route-map rm-tag-chandler-2a-out permit 10 call rm-tag-subnets-out route-map rm-tag-subnets-out permit 10 match ip address prefix-list pl-aaaa set large-community 4200125501:0:10000 route-map rm-tag-subnets-out permit 20 match ip address prefix-list pl-bbbb set large-community 4200125501:0:10001 route-map rm-tag-subnets-out permit 30 match ip address prefix-list pl-cccc set large-community 4200125501:0:10002 route-map rm-tag-subnets-out permit 40 match ip address prefix-list pl-dddd set large-community 4200125501:0:10041 route-map rm-tag-subnets-out permit 50 match ip address prefix-list pl-eeee set large-community 4200125501:0:10038 For router .60 neighbor 100.125.255.61 remote-as 4200125501 neighbor 100.125.255.61 update-source 100.125.255.60 neighbor 100.125.255.61 route-map rm-default-accept-all out neighbor 100.125.255.61 route-map rm-default-accept-all in neighbor 100.125.255.61 ebgp-multihop neighbor 100.125.255.61 send-community all neighbor 100.125.255.61 next-hop-self all route-map rm-default-accept-all permit 10 match ip address all On .60 sh ip bgp summ BGP router identifier 100.125.1.5, local AS number 4200100000 RIB entries 260, using 28 KiB of memory Peers 9, using 80 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 100.125.254.5 4 4200100000 2370 2240 0 0 0 05:09:10 117 100.125.255.2 4 4200000000 2358 2324 0 0 0 05:05:28 59 100.125.255.11 4 4200600000 2313 2338 0 0 0 05:01:41 36 100.125.255.13 4 4200700000 2273 2350 0 0 0 04:59:56 42 100.125.255.23 4 4201000000 3759 8101 0 0 0 04:19:29 59 100.125.255.39 4 4200300000 2306 2316 0 0 0 05:04:05 32 100.125.255.46 4 4201100000 2289 2331 0 0 0 04:30:20 74 100.125.255.61 4 4200125501 1977 2612 0 0 0 00:59:23 28 100.125.255.69 4 4200100100 2143 2943 0 0 0 04:32:25 4 Total number of neighbors 9 .61 shows the correct number of routes that are in the route maps (28). If I comment those out of the access lists on the .61 peer, the routes disappear on the .60 side, as expected, so the match ip address portion and sequencing are working correctly. However, sh bgp large-community 4200125501:0:10000 on .60 shows nothing. What am I doing wrong that the routes propogate correctly, but don't carry the communities along with them. In fact, the communities appear at no peers in the global topology, but the routes do. My apologies, but the Quagga docs seem a bit sparse on this. Thanks for any input. EKG
@Eric, Can you try "send-community both" or "send-community large" ?
(In reply to Eric Germann from comment #19) Hello Eric, what do you get if you run a show bgp ipv4 unicast XXX command? (where XXX = IP prefix that is expected to have the 4200125501:0:10000 large community) I ask just to be sure the issue isn't something related to the 'sh bgp large-community' command.
sh bgp large-community <nothing> sh ip bgp 10.100.0.0/24 BGP routing table entry for 10.100.0.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 100.125.255.72 4200000000 4200100000 4200125501 100.125.255.72 from 100.125.255.72 (100.125.0.18) Origin IGP, localpref 100, valid, external Large Community: 4200125501:0:10000 Last update: Wed Dec 7 03:17:01 2016 4200000000 4200100000 4200125501 100.125.255.74 from 100.125.255.74 (100.125.0.152) Origin IGP, localpref 100, valid, external, best Large Community: 4200125501:0:10000 Last update: Wed Dec 7 03:16:30 2016 It's there sh ip bgp ipv4 unicast 10.100.0.0/24 BGP routing table entry for 10.100.0.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 100.125.255.72 4200000000 4200100000 4200125501 100.125.255.72 from 100.125.255.72 (100.125.0.18) Origin IGP, localpref 100, valid, external Large Community: 4200125501:0:10000 Last update: Wed Dec 7 03:17:01 2016 4200000000 4200100000 4200125501 100.125.255.74 from 100.125.255.74 (100.125.0.152) Origin IGP, localpref 100, valid, external, best Large Community: 4200125501:0:10000 Last update: Wed Dec 7 03:16:30 2016 It's there Appears to be a bug in "sh bgp large-community". I will try with match lists this afternoon to make sure they work properly. Thanks for all your hard work on this. EKG
Along the lines of the last bug report, could someone provide a simple example of inbound filtering of route based on large communities. I've tried several different combinations and don't get anywhere, so not sure if it's my issue or a bug. EKG
Eric, 1/ I don't think "sh bgp large-community" is supposed to work, you should always specify the fully written out AFI/SAFI: "sh bgp ipv4 unicast large-community" 2/ Can you share what you have so far? Example config: router bgp 65000 bgp router-id 1.2.3.44 neighbor 165.254.255.16 remote-as 65001 neighbor 165.254.255.16 update-source 165.254.255.17 neighbor 165.254.255.16 route-map test-in in neighbor 165.254.255.23 remote-as 15562 neighbor 165.254.255.23 update-source 165.254.255.17 neighbor 165.254.255.23 route-map test-out out neighbor 165.254.255.26 remote-as 15562 neighbor 165.254.255.26 update-source 165.254.255.17 neighbor 165.254.255.26 route-map test-out out exit ! ip community-list 1 permit 666:666 ip community-list standard satan permit 666:666 ip community-list standard test permit 1:2 ip large-community-list 4 permit 2914:0:666 ip large-community-list standard foo permit 2914:0:666 ip large-community-list standard testlc permit 2914:0:666 ip large-community-list expanded testlc2 permit 55:.* ! route-map test-in permit 10 set large-comm-list foo delete ! route-map test-out permit 10 match large-community testlc set community 81:71 additive set large-community 2:4:5 additive ! route-map test-out permit 20
1/ As a suggestion, if it shouldn't work, I'd take it out of the parser as an option. ip-100-124-0-232.us-east-2.compute.internal# sh bgp <cr> X:X::X:X Network in the BGP routing table to display X:X::X:X/M IPv6 prefix <network>/<length> community Display routes matching the communities community-list Display routes matching the community-list encap Address Family modifier filter-list Display routes conforming to the filter-list ipv4 Address Family ipv6 Address Family large-community Display routes matching the large-communities large-community-list Display routes matching the large-community-list ip-100-124-0-232.us-east-2.compute.internal# sh bgp large-community <cr> AA:BB:CC large-community number sh bgp large-community 4200125501:0:10000 <blank> 2/ This is odd. This is what is in bgpd.conf: neighbor 100.125.255.64 remote-as 4200300000 neighbor 100.125.255.64 update-source 100.125.255.65 neighbor 100.125.255.64 route-map rm-default-outbound out neighbor 100.125.255.64 route-map PermitN in neighbor 100.125.255.64 send-community all neighbor 100.125.255.64 next-hop-self all neighbor 100.125.255.66 remote-as 4200300000 neighbor 100.125.255.66 update-source 100.125.255.67 neighbor 100.125.255.66 route-map rm-default-outbound out neighbor 100.125.255.66 route-map PermitN in neighbor 100.125.255.66 ebgp-multihop neighbor 100.125.255.66 send-community all neighbor 100.125.255.66 next-hop-self all route-map rm-default-inbound permit 10 match ip address all route-map rm-default-outbound permit 10 match ip address all ip large-community-list standard PermitN permit 4200125501:0:10000 This is what sh run shows: ip-100-124-0-232.us-east-2.compute.internal# sh run Building configuration... Current configuration: ! hostname us-east-2a-test hostname test log file /var/log/bgpd.log log stdout ip large-community-list standard PermitN permit 4200125501:0:10000 ! <trimmed passwords and interfaces> ! router bgp 4200300100 bgp router-id 100.124.0.232 network 100.124.0.0/16 redistribute connected timers bgp 10 30 neighbor 100.125.255.64 remote-as 4200300000 neighbor 100.125.255.64 update-source 100.125.255.65 neighbor 100.125.255.64 next-hop-self all neighbor 100.125.255.64 route-map PermitN in neighbor 100.125.255.64 route-map rm-default-outbound out neighbor 100.125.255.66 remote-as 4200300000 neighbor 100.125.255.66 ebgp-multihop 255 neighbor 100.125.255.66 update-source 100.125.255.67 neighbor 100.125.255.66 next-hop-self all neighbor 100.125.255.66 route-map PermitN in neighbor 100.125.255.66 route-map rm-default-outbound out ! route-map rm-default-inbound permit 10 match ip address all ! route-map rm-default-outbound permit 10 match ip address all ! the list moved to the top of the config. Not sure if that is an issue. Anyways, "sh ip bgp" shows no routes coming in other than the local routes. Before, it shows the proper routes. Seems like it's not filtering and bring them in. EKG
I think you want something like, you can't match directly on a community-list, you have to use a route-map. ip large-community-list standard PermitN permit 4200125501:0:10000 route-map PermitN permit 10 match large-community PermitN
And that was it. Thanks for the assist. Working now. EKG
I'm happy to report the patches seem to be stable in our network. I've pushed this in to quagga-users, but thought here would be applicable also for those trying to configure use of large communities. I'm having (probably a syntax) an issue in tagging a network with multiple large communities. The entirety of the issue is as follows: I will describe the issue, then attach the config for reference. I have a router that will advertise 13 subnets into our private cloud. We’re using the large communities patch and it seems to work well and is stable. The issue I have is this. I want to be able to tag the same subnet with multiple communities. The below config works, sort of. It stops at the “permit 10” stanza of rm-tag-subnets-out. I presume this is because it matches so it gives up on the rest of the map. Fair enough. I add a “continue” clause under the set command and it does continue on down the chain, but the number of advertised networks dwindle. It’s as if it’s AND’ing them together What I want for it to do is if it matches, add the community, if not, move on down the list, but don’t strip out that network from being advertised upstream. The purpose is to group networks so we can import elsewhere on matches in any of the various 3 fields. Thoughts? Thanks for any assistance. EKG ===== Config hostname sales-us-east-1a password <redacted> enable password <redacted> router bgp 4200000300 bgp router-id 10.220.64.237 timers bgp 10 30 bgp log-neighbor-changes redistribute connected network 10.220.64.0/24 network 10.220.68.0/24 network 10.220.69.0/24 network 10.220.70.0/24 network 10.220.71.0/24 network 10.220.72.0/24 network 10.220.73.0/24 network 10.220.74.0/24 network 10.220.75.0/24 network 10.220.95.0/24 network 10.220.101.0/24 network 10.220.103.0/24 network 10.220.107.0/24 neighbor 100.125.255.84 remote-as 4200000000 neighbor 100.125.255.84 update-source 100.125.255.85 neighbor 100.125.255.84 route-map rm-tag-subnets-out out neighbor 100.125.255.84 route-map rm-default-accept-all in neighbor 100.125.255.84 ebgp-multihop neighbor 100.125.255.84 send-community all neighbor 100.125.255.84 next-hop-self all neighbor 100.125.255.86 remote-as 4200000000 neighbor 100.125.255.86 update-source 100.125.255.87 neighbor 100.125.255.86 route-map rm-tag-subnets-out out neighbor 100.125.255.86 route-map rm-default-accept-all in neighbor 100.125.255.86 ebgp-multihop neighbor 100.125.255.86 send-community all neighbor 100.125.255.86 next-hop-self all !#######################################################################3 ! Route maps to propagate to WAN !#######################################################################3 route-map rm-default-accept-all permit 10 match ip address all !#######################################################################3 ! Route maps for tagging !#######################################################################3 ! xyzsales VPC Subnets route-map rm-tag-subnets-out permit 10 match ip address prefix-list pl-xyzsales-all set large-community 4200000300:0:0 additive ! xyzsales-all Subnets route-map rm-tag-subnets-out permit 20 match ip address prefix-list pl-xyzsales-all set large-community 4200000300:2:0 additive ! xyzsales-aaa VPC Subnets route-map rm-tag-subnets-out permit 30 match ip address prefix-list pl-xyzsales-aaa set large-community 4200000300:2:1 additive ! xyzsales-bbb VPC Subnets route-map rm-tag-subnets-out permit 40 match ip address prefix-list pl-xyzsales-bbb set large-community 4200000300:2:3 additive ! xyzsales-ccc VPC Subnets route-map rm-tag-subnets-out permit 50 match ip address prefix-list pl-xyzsales-ccc set large-community 4200000300:2:4 additive ! xyzsales-ddd VPC Subnets route-map rm-tag-subnets-out permit 60 match ip address prefix-list pl-xyzsales-ddd set large-community 4200000300:2:5 additive ! xyzsales-eee VPC Subnets route-map rm-tag-subnets-out permit 70 match ip address prefix-list pl-xyzsales-eee set large-community 4200000300:2:6 additive ! xyzsales-fff VPC Subnets route-map rm-tag-subnets-out permit 80 match ip address prefix-list pl-xyzsales-fff set large-community 4200000300:2:7 additive #######################################################################3 ! Prefix lists to match for tagging !#######################################################################3 ! xyzsales-all prefixes ip prefix-list pl-xyzsales-all seq 100 permit 10.220.64.0/24 ip prefix-list pl-xyzsales-all seq 110 permit 10.220.68.0/24 ip prefix-list pl-xyzsales-all seq 120 permit 10.220.69.0/24 ip prefix-list pl-xyzsales-all seq 130 permit 10.220.70.0/24 ip prefix-list pl-xyzsales-all seq 140 permit 10.220.71.0/24 ip prefix-list pl-xyzsales-all seq 150 permit 10.220.72.0/24 ip prefix-list pl-xyzsales-all seq 160 permit 10.220.73.0/24 ip prefix-list pl-xyzsales-all seq 170 permit 10.220.74.0/24 ip prefix-list pl-xyzsales-all seq 180 permit 10.220.75.0/24 ip prefix-list pl-xyzsales-all seq 190 permit 10.220.95.0/24 ip prefix-list pl-xyzsales-all seq 200 permit 10.220.101.0/24 ip prefix-list pl-xyzsales-all seq 210 permit 10.220.103.0/24 ip prefix-list pl-xyzsales-all seq 220 permit 10.220.107.0/24 ip prefix-list pl-xyzsales-all seq 999 deny 0.0.0.0/0 ! xyzsales-aaa prefixes ip prefix-list pl-xyzsales-aaa seq 100 permit 10.220.64.0/24 ip prefix-list pl-xyzsales-aaa seq 110 permit 10.220.68.0/24 ip prefix-list pl-xyzsales-aaa seq 120 permit 10.220.72.0/24 ip prefix-list pl-xyzsales-aaa seq 999 deny 0.0.0.0/0 ! xyzsales-bbb ip prefix-list pl-xyzsales-bbb seq 100 permit 10.220.68.0/24 ip prefix-list pl-xyzsales-bbb seq 110 permit 10.220.72.0/24 ip prefix-list pl-xyzsales-bbb seq 999 deny 0.0.0.0/0 ! xyzsales-ccc ip prefix-list pl-xyzsales-ccc seq 100 permit 10.220.69.0/24 ip prefix-list pl-xyzsales-ccc seq 110 permit 10.220.73.0/24 ip prefix-list pl-xyzsales-ccc seq 120 permit 10.220.101.0/24 ip prefix-list pl-xyzsales-ccc seq 999 deny 0.0.0.0/0 ! xyzsales-ddd ip prefix-list pl-xyzsales-ddd seq 100 permit 10.220.71.0/24 ip prefix-list pl-xyzsales-ddd seq 110 permit 10.220.75.0/24 ip prefix-list pl-xyzsales-ddd seq 120 permit 10.220.103.0/24 ip prefix-list pl-xyzsales-ddd seq 130 permit 10.220.107.0/24 ip prefix-list pl-xyzsales-ddd seq 999 deny 0.0.0.0/0 ! xyzsales-eee ip prefix-list pl-xyzsales-eee seq 100 permit 10.220.70.0/24 ip prefix-list pl-xyzsales-eee seq 110 permit 10.220.74.0/24 ip prefix-list pl-xyzsales-eee seq 999 deny 0.0.0.0/0 ! xyzsales-fff ip prefix-list pl-xyzsales-fff seq 100 permit 10.220.95.0/24 ip prefix-list pl-xyzsales-fff seq 999 deny 0.0.0.0/0 ! access-list all permit any ! log file /var/log/bgpd.log ! log stdout
Queueing this up. Thanks.
Things like this seem to work OK. Non-regex's work also. neighbor 100.125.255.66 route-map rm-test-inbound in route-map rm-test-inbound permit 10 match large-community PermitN ip large-community-list expanded PermitN permit 42.*\:.*\:[5]
Hi, In bgp_routemap.c, line 1603 in what I have has: else new = lcommunity_dup (rcs->lcom); /* will be interned by caller if required */ if (attr->extra) { attr->extra->lcommunity = new; } attr->flag |= ATTR_FLAG_BIT (BGP_ATTR_LARGE_COMMUNITIES); The indentation suggests the "if (attr->extra)" block is meant to be guarded by (only active with) the 'else', but that's not the case. Can I assume the indentation shows what was intended, and the fix is to enclose it all with { }?
I am not sure, that logic was copied over from the "additive" case" code for rfc1997 communities.
Job, I changed the indentation to match the existing logic. Also, changed the test on attr->extra with bgp_attr_extra_get. Queued up in next.
In Quagga 1.2.0, thanks.