something strange about bgp community

Hi everyone,

Today when I check one route in Routeviews I find something strange as follows:

route-views>sh ip bgp 176.108.0.0
BGP routing table entry for 176.108.0.0/19, version 23405621
Paths: (33 available, best #28, table default)
   Not advertised to any peer
   Refresh Epoch 1
   202018 35320 35320 57800
     5.101.110.2 from 5.101.110.2 (5.101.110.2)
       Origin IGP, localpref 100, valid, external
       Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 20485:54050 47541:10001
       rx pathid: 0, tx pathid: 0

the AS-Path is "202018 35320 35320 57800" but the community is 702:120 2914:429 20485:52990 ....

According to RFC 1997, the community format is AA:NN and AA means the AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and as a result they should not appear in the community. Could anybody tell me what's the reason they do appear in the community of this route?

Thanks!

2914:429 is a community to signal to NTT to not announce the route to peers which would perhaps be why you don't see NTT doing that.

You can see the documented NTT communities here: http://www.us.ntt.net/support/policy/routing.cfm

Jared Mauch

2914:429 is a community to signal to NTT to not announce the route to peers which would perhaps be why you don't see NTT doing that.

it looks like this is the 'customer' of several networks (701, 2914)
and they just blindly add carrier communities to their routes
'everywhere'... Or perhaps they view the RV peer as a special place to
signal their intent on certain routes more clearly?

  "Hey, this route is going to get localpref 120 in 701 and NOT be
announced to 2914"

either way, unless someone strips them, the communities just stay
around until stripping...

-chris

Also note there is nothing stopping anyone from adding any community they want.
The effect and how long the community stays attached to a route is another matter.

2914:429 is ntt's do not advertise to any peer community

bgp communities are transitive attributes, e.g. you can just pass them
to peers unmolested. so someone that's presumably not ntt ( e.g. the
neighbor is digital ocean) is sending that commmunity to route views as
part of their export.

Their utility in routviews depends on context, when I see communities I
tagged on my own routes in routviews for example I can tell what pop the
announcement originated from which is rather useful. other's like the
one above do tell you something about the policy of somebody on the
internet. you can also tell who strips communities...

Thanks!

Because there is no standard syntax on the description of BGP community, I think the problem is hard to understand.

Hi Song,

that's normal. This is a signat to AS702 to do some special with this
route when it will see this route.

Community is transistive by its design, so you don't need to be directly
connected to AS702 to send some signal to it.

For example:

you->AS101-AS102-AS103-target
  \->AS104-/\/\/\-AS105-/

where /\/\/\ is disrupted path with packet loss. AS104-AS105 is better
as AS-PATH lengh. If "target" accepts community, I can add
"target:notaccept" to AS104 and avoid that path.

Some brain-dead :wink: transit providers clear all community when import
announces, but for me it is at least unfair.

hrm, it's possible that cleaning the communities (after dealing with
the local/customer-added ones) means you may not get multiple copies
that differ only in community in your network. this may have the
effect of you seeing less route 'churn' overall in your network.