Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
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. It looks like this time is the one to have vendors implementing them!
Ciao Pier Carlo,
You raise a very good point. Skimming through the draft, it looks the implementation will not require much effort. Let me spend some time on this later in the week. As a result of this PR now http://largebgpcommunities.net/implementations/ shows pmacct as 'planned'.
With commit 514c44e this is now done. My bad i did not reference this issue in the commits to link all nicely.
Large Communities are both part of the output (log or dump) of pmbgpd and are a new aggregation primitive.
All is QA'd in lab and anything unexpected is at this point a bug :)
I'm having some issues with the pmacctd 1.6.2-git (20161016-00) version, compiled from master.
I have an host (192.0.2.3) pinging the host where pmacctd runs (192.0.2.5). I also have a BGP speaker that announces 192.0.2.2/32, 192.0.2.3/32 and 192.0.2.4/32 with large communities.
I start with a simple configuration:
I got the following:
Everything is fine.
Then I change the aggregate[plugin1], I add
pmacctd starts and after 3 seconds quits. Log says:
What am I missing?
I have some news about this issue.
In order to be sure my config was fine with regards of BGP I tried to originate a standard community too from ExaBGP and to use it in plugins'
This is what I got in the BGP table dump:
So, 192.0.2.3/32 was also tagged with 2:2.
This is what I got in the plugins' output:
LCOMMS and SRC_LCOMMS was totally missing from the
Then I tried to modify the
This is what I got:
LCOMMS and SRC_LCOMMS was there but this time they did not contain any value, even if BGP table was the same as above.
There were a couple of commits. Specifically bc6d273 relates to your point of not seeing Large Communities as part of CSV print plugin output. And 29f5510 is to properly honour 'bgp_src_lrg_comm_type: bgp' and 'bgp_src_std_comm_type: bgp' in the config - both should be there and it is intended that default is none, ie. do not present any value. The rest i could not really reproduce: it may help having access, if possible, to your environment. Any chance you can give it another round of test?
@paololucente, now the print plugin's output includes LCOMMS and SRC_LCOMMS columns but I'm still experiencing issues with the values.
If I use only
If I add
I send you a email to see if we can arrange a remote session.
@paololucente, after your last commit plugins' output looks fine!
I'll do more tests but I believe I can close this issue now.
Thanks for your support.