[192433] in North American Network Operators' Group
Re: [routing-wg] Large BGP Communities beacon in the wild
daemon@ATHENA.MIT.EDU (Exa)
Fri Oct 28 04:30:13 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <270091A8-32B1-4519-A578-383C5A97332F@delong.com>
From: Exa <thomas.mangin@exa-networks.co.uk>
Date: Fri, 28 Oct 2016 09:27:05 +0100
To: routing-wg-bounces@ripe.net
Cc: Jared Mauch <jmauch@us.ntt.net>, nanog@nanog.org, routing-wg@ripe.net,
Job Snijders <job@ntt.net>
Errors-To: nanog-bounces@nanog.org
Hello Owen,
While I agree ( and cudos to Job for noticing the issue while the document i=
s still at the draft stage), the current process for allocation is not devel=
oper friendly.
For ExaBGP, I also had to squat a code point to implement draft-frs-bgp-oper=
ational-message.
I doubt it will eve cause an operational issue, ExaBGP is not used to route p=
ackets in anyone's core, but but the current process gave me no choice: it t=
akes implementation to find issues with drafts and/or interrop problems, une=
xpected 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 p=
oints for experimentation - my memory is fuzzy on the details sorry - but ev=
en then this would require re numbering which is not ideal.
So perhaps in addition to recognising the squatting issue, "we" should look a=
t how the current IETF process works and can be changed to improve experimen=
tation.
Thomas
Sent from my iPad
> On 27 Oct 2016, at 16:47, Owen DeLong <owen@delong.com> wrote:
>=20
> I don=E2=80=99t mind the move to 32, but I hope the vendors are getting ap=
propriately smacked for squatting and that those attributes are not allowed t=
o be misappropriated by the vendors.
>=20
> We have a standards process for a reason and vendors simply squatting on n=
umbers is a violation of that process which cannot be allowed to stand unles=
s we wish to establish that as precedent and simply allow vendors to claim n=
umbers as they wish.
>=20
> This already happened with the BSD community in their implementation of a p=
seudo-VRRP like capability and now two different vendors have abused BGP pat=
h attributes.
>=20
> This is not a good path for us to continue.
>=20
> Owen
>=20
>> On Oct 26, 2016, at 11:19 PM, Job Snijders <job@ntt.net> wrote:
>>=20
>> Dear Internet,
>>=20
>> Through this beacon it was discovered that a vendor was squatting on BGP
>> Path Attribute value 30. And another vendor sat on 31.
>>=20
>> So, a twisted turn of events, the Large BGP Communities effort has ended u=
p
>> with BGP Path Attribute value 32 - very befitting if you look at the very=
>> problem we're trying to solve :-)
>>=20
>> 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!
>>=20
>> Please verify if you can see 192.147.168.0/24 and 2001:67c:208c::/48
>>=20
>> Kind regards,
>>=20
>> Job
>>=20
>>> 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.
>>>=20
>>> 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 tha=
t has
>>> been missing since 4-octet ASNs were introduced.
>>>=20
>>> 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.
>>>=20
>>> The draft can be read here: https://tools.ietf.org/html/draft-ietf-idr-l=
arge-community
>>>=20
>>> Additional information about Large BGP Communities can be found here:
>>> http://largebgpcommunities.net/
>>>=20
>>> Starting today (2016.10.11), the following two BGP beacons are available=
>>> to the general public, with AS_PATH 2914_15562$
>>>=20
>>> Both these prefixes have a Large BGP Community attached:
>>>=20
>>> 2001:67c:208c::/48
>>> 192.147.168.0/24
>>>=20
>>> Large BGP Community - 15562:1:1
>>>=20
>>> The NLNOG RING BGP Looking Glass is running the latest version of BIRD
>>> which understands the Large BGP Community Path Attribute.
>>>=20
>>> IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=3D192.147.16=
8.0/24
>>> IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=3D2001:67c:2=
08c::/48
>>>=20
>>> 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.
>>>=20
>>> Relevant Router commands to see if you receive the attribute, or whether=
>>> one of intermediate networks has stripped the attribute from the route:
>>>=20
>>> IOS: show ip bgp path-attribute unknown=20
>>> shows all prefixes with unknown path attributes.
>>>=20
>>> 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 0=
xC
>>> value 0000 3CCA 0000 0001 0000 0001
>>> rx pathid: 0, tx pathid: 0
>>> =20
>>> IOS-XR: (you must look at specific prefixes)
>>> RP/0/RSP0/CPU0:Router#show bgp ipv6 unicast 2001:67c:208c::/48 un=
known-attributes=20
>>> 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=20
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>=20
>>> JunOS:
>>> user@JunOS-re6> show route 2001:67c:208c::/48 detail=20
>>> 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
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>=20
>>> A note about router Configurations:
>>>=20
>>> Ensure you are not fitlering the path attributes, eg:
>>>=20
>>> JunOS:
>>> [edit protocols bgp]
>>> user@junos# delete drop-path-attributes 30
>>>=20
>>> XR:
>>> configure
>>> router bgp YourASN
>>> attribute-filter group ReallyBadIdea ! avoid creating bogons
>>> no attribute 30=20
>>> !
>>> !
>>>=20
>>> Contact persons: myself or Jared Mauch or NTT NOC. BGP Session
>>> identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562.
>>>=20
>>> Kind regards,
>>>=20
>>> Job
>=20
>=20
