Large BGP Communities beacon in the wild
Dear all, Large BGP Communities are a novel way to signal information between networks. An example of a Large BGP Communities is: 2914:4056024901:80. Large BGP Communities are composed of three 4-octet integers, separated by something like a colon. This is easy to remember and accommodates advanced routing policies in relation to 4-Byte ASNs. It is the tool that has been missing since 4-octet ASNs were introduced. IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group. The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-large-community Additional information about Large BGP Communities can be found here: http://largebgpcommunities.net/ Starting today (2016.10.11), the following two BGP beacons are available to the general public, with AS_PATH 2914_15562$ Both these prefixes have a Large BGP Community attached: 2001:67c:208c::/48 192.147.168.0/24 Large BGP Community - 15562:1:1 The NLNOG RING BGP Looking Glass is running the latest version of BIRD which understands the Large BGP Community Path Attribute. IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24 IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48 In theory, since this is an optional transitive BGP Path Attribute, all the Looking Glass' peers should boomerang the Large Community back to the LG. However we currently observe that 50 out of 75 peers propagate the Large BGP Community to the LG. Relevant Router commands to see if you receive the attribute, or whether one of intermediate networks has stripped the attribute from the route: IOS: show ip bgp path-attribute unknown shows all prefixes with unknown path attributes. IOS #2 - like on route views: route-views>sh ip bgp 192.147.168.0 BGP routing table entry for 192.147.168.0/24, version 98399100 Paths: (39 available, best #30, table default) Not advertised to any peer Refresh Epoch 1 701 2914 15562 137.39.3.55 from 137.39.3.55 (137.39.3.55) Origin IGP, localpref 100, valid, external unknown transitive attribute: flag 0xE0 type 0x1E length 0xC value 0000 3CCA 0000 0001 0000 0001 rx pathid: 0, tx pathid: 0 IOS-XR: (you must look at specific prefixes) RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 unknown-attributes BGP routing table entry for 2001:67c:208c::/48 Community: 2914:370 2914:1206 2914:2203 2914:3200 Unknown attributes have size 15 Raw value: e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ JunOS: user@JunOS-re6> show route 2001:67c:208c::/48 detail 2001:67c:208c::/48 (1 entry, 1 announced) AS path: 15562 I Unrecognized Attributes: 15 bytes Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A note about router Configurations: Ensure you are not fitlering the path attributes, eg: JunOS: [edit protocols bgp] user@junos# delete drop-path-attributes 30 XR: configure router bgp YourASN attribute-filter group ReallyBadIdea ! avoid creating bogons no attribute 30 ! ! Contact persons: myself or Jared Mauch or NTT NOC. BGP Session identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562. Kind regards, Job
Hi This looks like this on the ZTE M6000 platform: ballerup-edge1#show bgp vpnv4 unicast vrf internet detail 192.147.168.0 255.255.255.0 BGP routing table entry for 192.147.168.0/24 25w4d received from 149.6.136.169 (154.26.32.23), path-id 0 Origin i, nexthop 149.6.136.169, metric 100, localpref 100,weight 0, rtpref 200, best, block best, selected, Community 174:21100 174:22010 60876:174 *Unknown attribute type 30 flag e0 len 12* As path [174 2914 15562] As4 path Received label notag 25w4d received from 216.66.83.101 (216.218.252.202), path-id 0 Origin i, nexthop 216.66.83.101, metric 25, localpref 100,weight 0, rtpref 200, Community 60876:6939 *Unknown attribute type 30 flag e0 len 12* As path [6939 1299 2914 15562] As4 path Received label notag Regards, Baldur Den 11/10/2016 kl. 17.01 skrev Job Snijders:
Dear all,
Large BGP Communities are a novel way to signal information between networks. An example of a Large BGP Communities is: 2914:4056024901:80.
Large BGP Communities are composed of three 4-octet integers, separated by something like a colon. This is easy to remember and accommodates advanced routing policies in relation to 4-Byte ASNs. It is the tool that has been missing since 4-octet ASNs were introduced.
IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group.
The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-large-community
Additional information about Large BGP Communities can be found here: http://largebgpcommunities.net/
Starting today (2016.10.11), the following two BGP beacons are available to the general public, with AS_PATH 2914_15562$
Both these prefixes have a Large BGP Community attached:
2001:67c:208c::/48 192.147.168.0/24
Large BGP Community - 15562:1:1
The NLNOG RING BGP Looking Glass is running the latest version of BIRD which understands the Large BGP Community Path Attribute.
IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24 IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48
In theory, since this is an optional transitive BGP Path Attribute, all the Looking Glass' peers should boomerang the Large Community back to the LG. However we currently observe that 50 out of 75 peers propagate the Large BGP Community to the LG.
Relevant Router commands to see if you receive the attribute, or whether one of intermediate networks has stripped the attribute from the route:
IOS: show ip bgp path-attribute unknown shows all prefixes with unknown path attributes.
IOS #2 - like on route views: route-views>sh ip bgp 192.147.168.0 BGP routing table entry for 192.147.168.0/24, version 98399100 Paths: (39 available, best #30, table default) Not advertised to any peer Refresh Epoch 1 701 2914 15562 137.39.3.55 from 137.39.3.55 (137.39.3.55) Origin IGP, localpref 100, valid, external unknown transitive attribute: flag 0xE0 type 0x1E length 0xC value 0000 3CCA 0000 0001 0000 0001 rx pathid: 0, tx pathid: 0
IOS-XR: (you must look at specific prefixes) RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 unknown-attributes BGP routing table entry for 2001:67c:208c::/48 Community: 2914:370 2914:1206 2914:2203 2914:3200 Unknown attributes have size 15 Raw value: e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
JunOS: user@JunOS-re6> show route 2001:67c:208c::/48 detail 2001:67c:208c::/48 (1 entry, 1 announced) AS path: 15562 I Unrecognized Attributes: 15 bytes Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A note about router Configurations:
Ensure you are not fitlering the path attributes, eg:
JunOS: [edit protocols bgp] user@junos# delete drop-path-attributes 30
XR: configure router bgp YourASN attribute-filter group ReallyBadIdea ! avoid creating bogons no attribute 30 ! !
Contact persons: myself or Jared Mauch or NTT NOC. BGP Session identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562.
Kind regards,
Job
Dear Internet, Through this beacon it was discovered that a vendor was squatting on BGP Path Attribute value 30. And another vendor sat on 31. So, a twisted turn of events, the Large BGP Communities effort has ended up with BGP Path Attribute value 32 - very befitting if you look at the very problem we're trying to solve :-) The beacon has been updated to use the new IANA assigned value, nothing else was changed. Hopefully we are in the clear this time around! Please verify if you can see 192.147.168.0/24 and 2001:67c:208c::/48 Kind regards, Job On Tue, Oct 11, 2016 at 05:01:56PM +0200, Job Snijders wrote:
Large BGP Communities are a novel way to signal information between networks. An example of a Large BGP Communities is: 2914:4056024901:80.
Large BGP Communities are composed of three 4-octet integers, separated by something like a colon. This is easy to remember and accommodates advanced routing policies in relation to 4-Byte ASNs. It is the tool that has been missing since 4-octet ASNs were introduced.
IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group.
The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-large-community
Additional information about Large BGP Communities can be found here: http://largebgpcommunities.net/
Starting today (2016.10.11), the following two BGP beacons are available to the general public, with AS_PATH 2914_15562$
Both these prefixes have a Large BGP Community attached:
2001:67c:208c::/48 192.147.168.0/24
Large BGP Community - 15562:1:1
The NLNOG RING BGP Looking Glass is running the latest version of BIRD which understands the Large BGP Community Path Attribute.
IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24 IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48
In theory, since this is an optional transitive BGP Path Attribute, all the Looking Glass' peers should boomerang the Large Community back to the LG. However we currently observe that 50 out of 75 peers propagate the Large BGP Community to the LG.
Relevant Router commands to see if you receive the attribute, or whether one of intermediate networks has stripped the attribute from the route:
IOS: show ip bgp path-attribute unknown shows all prefixes with unknown path attributes.
IOS #2 - like on route views: route-views>sh ip bgp 192.147.168.0 BGP routing table entry for 192.147.168.0/24, version 98399100 Paths: (39 available, best #30, table default) Not advertised to any peer Refresh Epoch 1 701 2914 15562 137.39.3.55 from 137.39.3.55 (137.39.3.55) Origin IGP, localpref 100, valid, external unknown transitive attribute: flag 0xE0 type 0x1E length 0xC value 0000 3CCA 0000 0001 0000 0001 rx pathid: 0, tx pathid: 0
IOS-XR: (you must look at specific prefixes) RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 unknown-attributes BGP routing table entry for 2001:67c:208c::/48 Community: 2914:370 2914:1206 2914:2203 2914:3200 Unknown attributes have size 15 Raw value: e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
JunOS: user@JunOS-re6> show route 2001:67c:208c::/48 detail 2001:67c:208c::/48 (1 entry, 1 announced) AS path: 15562 I Unrecognized Attributes: 15 bytes Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A note about router Configurations:
Ensure you are not fitlering the path attributes, eg:
JunOS: [edit protocols bgp] user@junos# delete drop-path-attributes 30
XR: configure router bgp YourASN attribute-filter group ReallyBadIdea ! avoid creating bogons no attribute 30 ! !
Contact persons: myself or Jared Mauch or NTT NOC. BGP Session identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562.
Kind regards,
Job
I don’t mind the move to 32, but I hope the vendors are getting appropriately smacked for squatting and that those attributes are not allowed to be misappropriated by the vendors. We have a standards process for a reason and vendors simply squatting on numbers is a violation of that process which cannot be allowed to stand unless we wish to establish that as precedent and simply allow vendors to claim numbers as they wish. This already happened with the BSD community in their implementation of a pseudo-VRRP like capability and now two different vendors have abused BGP path attributes. This is not a good path for us to continue. Owen
On Oct 26, 2016, at 11:19 PM, Job Snijders <job@ntt.net> wrote:
Dear Internet,
Through this beacon it was discovered that a vendor was squatting on BGP Path Attribute value 30. And another vendor sat on 31.
So, a twisted turn of events, the Large BGP Communities effort has ended up with BGP Path Attribute value 32 - very befitting if you look at the very problem we're trying to solve :-)
The beacon has been updated to use the new IANA assigned value, nothing else was changed. Hopefully we are in the clear this time around!
Please verify if you can see 192.147.168.0/24 and 2001:67c:208c::/48
Kind regards,
Job
On Tue, Oct 11, 2016 at 05:01:56PM +0200, Job Snijders wrote:
Large BGP Communities are a novel way to signal information between networks. An example of a Large BGP Communities is: 2914:4056024901:80.
Large BGP Communities are composed of three 4-octet integers, separated by something like a colon. This is easy to remember and accommodates advanced routing policies in relation to 4-Byte ASNs. It is the tool that has been missing since 4-octet ASNs were introduced.
IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group.
The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-large-community
Additional information about Large BGP Communities can be found here: http://largebgpcommunities.net/
Starting today (2016.10.11), the following two BGP beacons are available to the general public, with AS_PATH 2914_15562$
Both these prefixes have a Large BGP Community attached:
2001:67c:208c::/48 192.147.168.0/24
Large BGP Community - 15562:1:1
The NLNOG RING BGP Looking Glass is running the latest version of BIRD which understands the Large BGP Community Path Attribute.
IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24 IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48
In theory, since this is an optional transitive BGP Path Attribute, all the Looking Glass' peers should boomerang the Large Community back to the LG. However we currently observe that 50 out of 75 peers propagate the Large BGP Community to the LG.
Relevant Router commands to see if you receive the attribute, or whether one of intermediate networks has stripped the attribute from the route:
IOS: show ip bgp path-attribute unknown shows all prefixes with unknown path attributes.
IOS #2 - like on route views: route-views>sh ip bgp 192.147.168.0 BGP routing table entry for 192.147.168.0/24, version 98399100 Paths: (39 available, best #30, table default) Not advertised to any peer Refresh Epoch 1 701 2914 15562 137.39.3.55 from 137.39.3.55 (137.39.3.55) Origin IGP, localpref 100, valid, external unknown transitive attribute: flag 0xE0 type 0x1E length 0xC value 0000 3CCA 0000 0001 0000 0001 rx pathid: 0, tx pathid: 0
IOS-XR: (you must look at specific prefixes) RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 unknown-attributes BGP routing table entry for 2001:67c:208c::/48 Community: 2914:370 2914:1206 2914:2203 2914:3200 Unknown attributes have size 15 Raw value: e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
JunOS: user@JunOS-re6> show route 2001:67c:208c::/48 detail 2001:67c:208c::/48 (1 entry, 1 announced) AS path: 15562 I Unrecognized Attributes: 15 bytes Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A note about router Configurations:
Ensure you are not fitlering the path attributes, eg:
JunOS: [edit protocols bgp] user@junos# delete drop-path-attributes 30
XR: configure router bgp YourASN attribute-filter group ReallyBadIdea ! avoid creating bogons no attribute 30 ! !
Contact persons: myself or Jared Mauch or NTT NOC. BGP Session identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562.
Kind regards,
Job
On 27 October 2016 at 16:47, Owen DeLong <owen@delong.com> wrote:
I don’t mind the move to 32, but I hope the vendors are getting appropriately smacked for squatting and that those attributes are not allowed to be misappropriated by the vendors.
We have a standards process for a reason and vendors simply squatting on numbers is a violation of that process which cannot be allowed to stand unless we wish to establish that as precedent and simply allow vendors to claim numbers as they wish.
This already happened with the BSD community in their implementation of a pseudo-VRRP like capability and now two different vendors have abused BGP path attributes.
This is not a good path for us to continue.
Owen
Here here! Name and shame, it is not acceptable! James.
On Thu, Oct 27, 2016 at 5:28 PM, James Bensley <jwbensley@gmail.com> wrote:
Name and shame, it is not acceptable!
read the IDR thread(1), the vendors in question actually self reported. I don't think 'shame' here is quite appropriate, but certainly owen's note about: "Hey, pls don't do this again" with the added: ""this is not a good path to continue" were noted by several folks on the IDR list. -chris 1: https://www.ietf.org/mail-archive/web/idr/current/msg16556.html
read the IDR thread(1), the vendors in question actually self reported. I don't think 'shame' here is quite appropriate, but certainly owen's note about: "Hey, pls don't do this again" with the added: ""this is not a good path to continue" were noted by several folks on the IDR list.
luckily we have never seen something like this before. </sarcasm>
Hello Owen, While I agree ( and cudos to Job for noticing the issue while the document is still at the draft stage), the current process for allocation is not developer friendly. For ExaBGP, I also had to squat a code point to implement draft-frs-bgp-operational-message. I doubt it will eve cause an operational issue, ExaBGP is not used to route packets in anyone's core, but but the current process gave me no choice: it takes implementation to find issues with drafts and/or interrop problems, unexpected behaviours or simply provide a feature to a crying customer even if a draft is never created / never reach RFC status. I remember reading a draft from John which attempted to allocate some code points for experimentation - my memory is fuzzy on the details sorry - but even then this would require re numbering which is not ideal. So perhaps in addition to recognising the squatting issue, "we" should look at how the current IETF process works and can be changed to improve experimentation. Thomas Sent from my iPad
On 27 Oct 2016, at 16:47, Owen DeLong <owen@delong.com> wrote:
I don’t mind the move to 32, but I hope the vendors are getting appropriately smacked for squatting and that those attributes are not allowed to be misappropriated by the vendors.
We have a standards process for a reason and vendors simply squatting on numbers is a violation of that process which cannot be allowed to stand unless we wish to establish that as precedent and simply allow vendors to claim numbers as they wish.
This already happened with the BSD community in their implementation of a pseudo-VRRP like capability and now two different vendors have abused BGP path attributes.
This is not a good path for us to continue.
Owen
On Oct 26, 2016, at 11:19 PM, Job Snijders <job@ntt.net> wrote:
Dear Internet,
Through this beacon it was discovered that a vendor was squatting on BGP Path Attribute value 30. And another vendor sat on 31.
So, a twisted turn of events, the Large BGP Communities effort has ended up with BGP Path Attribute value 32 - very befitting if you look at the very problem we're trying to solve :-)
The beacon has been updated to use the new IANA assigned value, nothing else was changed. Hopefully we are in the clear this time around!
Please verify if you can see 192.147.168.0/24 and 2001:67c:208c::/48
Kind regards,
Job
On Tue, Oct 11, 2016 at 05:01:56PM +0200, Job Snijders wrote: Large BGP Communities are a novel way to signal information between networks. An example of a Large BGP Communities is: 2914:4056024901:80.
Large BGP Communities are composed of three 4-octet integers, separated by something like a colon. This is easy to remember and accommodates advanced routing policies in relation to 4-Byte ASNs. It is the tool that has been missing since 4-octet ASNs were introduced.
IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in the "BGP Path Attributes" registry under the "Border Gateway Protocol (BGP) Parameters" group.
The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-large-community
Additional information about Large BGP Communities can be found here: http://largebgpcommunities.net/
Starting today (2016.10.11), the following two BGP beacons are available to the general public, with AS_PATH 2914_15562$
Both these prefixes have a Large BGP Community attached:
2001:67c:208c::/48 192.147.168.0/24
Large BGP Community - 15562:1:1
The NLNOG RING BGP Looking Glass is running the latest version of BIRD which understands the Large BGP Community Path Attribute.
IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24 IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48
In theory, since this is an optional transitive BGP Path Attribute, all the Looking Glass' peers should boomerang the Large Community back to the LG. However we currently observe that 50 out of 75 peers propagate the Large BGP Community to the LG.
Relevant Router commands to see if you receive the attribute, or whether one of intermediate networks has stripped the attribute from the route:
IOS: show ip bgp path-attribute unknown shows all prefixes with unknown path attributes.
IOS #2 - like on route views: route-views>sh ip bgp 192.147.168.0 BGP routing table entry for 192.147.168.0/24, version 98399100 Paths: (39 available, best #30, table default) Not advertised to any peer Refresh Epoch 1 701 2914 15562 137.39.3.55 from 137.39.3.55 (137.39.3.55) Origin IGP, localpref 100, valid, external unknown transitive attribute: flag 0xE0 type 0x1E length 0xC value 0000 3CCA 0000 0001 0000 0001 rx pathid: 0, tx pathid: 0
IOS-XR: (you must look at specific prefixes) RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 unknown-attributes BGP routing table entry for 2001:67c:208c::/48 Community: 2914:370 2914:1206 2914:2203 2914:3200 Unknown attributes have size 15 Raw value: e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
JunOS: user@JunOS-re6> show route 2001:67c:208c::/48 detail 2001:67c:208c::/48 (1 entry, 1 announced) AS path: 15562 I Unrecognized Attributes: 15 bytes Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A note about router Configurations:
Ensure you are not fitlering the path attributes, eg:
JunOS: [edit protocols bgp] user@junos# delete drop-path-attributes 30
XR: configure router bgp YourASN attribute-filter group ReallyBadIdea ! avoid creating bogons no attribute 30 ! !
Contact persons: myself or Jared Mauch or NTT NOC. BGP Session identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562.
Kind regards,
Job
participants (8)
-
Baldur Norddahl -
Christopher Morrow -
Exa -
James Bensley -
Job Snijders -
Mark Tinka -
Owen DeLong -
Randy Bush