sbezverk / gobmp Goto Github PK

Found a segmentation fault while gobmp is running, and a switch is connected to gobmp.

I0111 21:56:07.285544       1 gobmpsrv.go:33] Starting gobmp server on [::]:5000, intercept mode: false
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x697d8e]

goroutine 18 [running]:
github.com/sbezverk/gobmp/pkg/message.(*producer).marshalAndPublish(0xc000020d00, {0x7705e0, 0xc0000de300}, 0x1, {0xc0000b46e0, 0x20, 0x20}, 0x0)
	/home/sbezverk/projects/go/workspace/gobmp/pkg/message/route-monitor.go:93 +0x12e
github.com/sbezverk/gobmp/pkg/message.(*producer).producePeerMessage(0xc000020d00, 0x0, {0xc0000da700, {0x770120, 0xc00005c9b0}})
	/home/sbezverk/projects/go/workspace/gobmp/pkg/message/peer.go:100 +0xc9a
github.com/sbezverk/gobmp/pkg/message.(*producer).producingWorker(0xc0000f20c0, {0xc0000da700, {0x770120, 0xc00005c9b0}})
	/home/sbezverk/projects/go/workspace/gobmp/pkg/message/producer.go:44 +0x55
created by github.com/sbezverk/gobmp/pkg/message.(*producer).Producer
	/home/sbezverk/projects/go/workspace/gobmp/pkg/message/producer.go:33 +0x4c

After gdb into the system, I found the following information:

(gdb) bt
#0  0x0000000000697d8e in github.com/sbezverk/gobmp/pkg/message.(*producer).marshalAndPublish (p=0xc00001ed80, msg=..., msgType=10, 
    hash=..., debug=false) at /home/sbezverk/projects/go/workspace/gobmp/pkg/message/route-monitor.go:93
#1  0x000000000069533a in github.com/sbezverk/gobmp/pkg/message.(*producer).producePeerMessage (p=0xc00001ed80, op=0, msg=...)
    at /home/sbezverk/projects/go/workspace/gobmp/pkg/message/peer.go:100
#2  0x00000000006973d5 in github.com/sbezverk/gobmp/pkg/message.(*producer).producingWorker (p=0xc000112700, msg=...)
    at /home/sbezverk/projects/go/workspace/gobmp/pkg/message/producer.go:44
#3  0x0000000000697352 in github.com/sbezverk/gobmp/pkg/message.(*producer).Producer·dwrap·1 ()
    at /home/sbezverk/projects/go/workspace/gobmp/pkg/message/producer.go:33
#4  0x0000000000467861 in runtime.goexit () at /usr/local/go/src/runtime/asm_amd64.s:1581
#5  0x0000000000000000 in ?? ()
(gdb) f 0
#0  0x0000000000697d8e in github.com/sbezverk/gobmp/pkg/message.(*producer).marshalAndPublish (p=0xc00001ed80, msg=..., msgType=10, 
    hash=..., debug=false) at /home/sbezverk/projects/go/workspace/gobmp/pkg/message/route-monitor.go:93
93	in /home/sbezverk/projects/go/workspace/gobmp/pkg/message/route-monitor.go
(gdb) p msgType
$21 = 10
(gdb) p hash
$22 = {array = 0xc0000b46e0 "ea0d77a96a81113a03ca512039964028", len = 32, cap = 32}
(gdb) printf "%s", j.array
{"action":"add","router_hash":"ea0d77a96a81113a03ca512039964028","remote_bgp_id":"172.16.100.200","router_ip":"169.254.100.10","timestamp":"Jan 11 22:05:25.000839","remote_asn":4210020000,"remote_ip":"169.254.100.11","peer_rd":"0:0","remote_port":179,"local_asn":4200000000,"local_ip":"169.254.100.10","local_port":40443,"local_bgp_id":"10.100.0.1","adv_cap":{"1":[{"capability_value":"AAEAAQ==","capability_descr":"Multiprotocol Extensions for BGP-4 : afi=1 safi=1 Unicast IPv4"}],"2":[{"capability_descr":"Route Refresh Capability for BGP-4"}],"64":[{"capability_value":"QSw=","capability_descr":"Graceful Restart Capability"}],"65":[{"capability_value":"+lbqAA==","capability_descr":"Support for 4-octet AS number capability"}],"69":[{"capability_value":"AAEBAw==","capability_descr":"ADD-PATH Capability"}]},"recv_cap":{"1":[{"capability_value":"AAEAAQ==","capability_descr":"Multiprotocol Extensions for BGP-4 : afi=1 safi=1 Unicast IPv4"}],"128":[{"capability_descr":"Prestandard Route Refresh (deprecated)"}],"2":[{"capability_descr":"Route Refresh Capability for BGP-4"}],"5":[{"capability_value":"AAEAAQACAAEAgAAC","capability_descr":"Extended Next Hop Encoding"}],"64":[{"capability_value":"AHgAAQEA","capability_descr":"Graceful Restart Capability"}],"65":[{"capability_value":"+u/OoA==","capability_descr":"Support for 4-octet AS number capability"}],"66":[{"capability_descr":"Unknown capability 66"}],"67":[{"capability_value":"AgFA","capability_descr":"Support for Dynamic Capability (capability specific)"}]},"remote_holddown":9,"adv_holddown":9,"is_l":false,"is_prepolicy":false,"is_ipv4":true,"is_locrib":false,"is_locrib_filtered":false}(gdb) p p
$23 = (github.com/sbezverk/gobmp/pkg/message.producer *) 0xc00001ed80
(gdb) p p.publisher
$24 = {tab = 0x0, data = 0x0}
(gdb) p p.publisher.PublishMessage
There is no member named PublishMessage.

Seems like the p.publisher is not valid somehow, whereas the json message, MsgType, Hash seems to be correct. Please help take a look and let me know if you need more information on the coredump or more gdb info.

TLV 1095 is only applicable to Link NLRI, but not Prefix NLRI (https://www.rfc-editor.org/rfc/rfc7752.html#section-3.3.3)

I discovered that I was getting nonsensical values in the 'max_link_bw'. Upon investigation my 10G and beyond link BW values were overflowing the uint32 type for this value set at bps. I have updated my local code to set this at mbps inside the uint32 type. This works for myself but could invalidate use case for anyone still running T1/E1 very small link speeds. OpenBMP uses kbps in its object specification but with 400G in production and 800G specs out and about I fear the 4.2 tbps limit of kbps will be overflowed sooner than later. Open to talking about modifying these attributes to more exotic types (jsons double float or even stringify) but again wanted to see where inertia for existing data is at.

I have a setup with 4 kafka brokers, and 4 partitions per gobmp topic. All topics are pre-created, replication factor is set to 4. However, in gobmp kafka-server variable it seems I cannot provide all the brokers, but it accepts only one https://github.com/sbezverk/gobmp/blob/master/pkg/kafka/kafka-publisher.go#L206
Which is not a correct practice in kafka, since it needs all broker endpoints to be provided for the process to work correctly.
Can the kafka-server support the typical use case, which is a comma-separated list of brokers?
Note that if I simply supply only one broker, sarama complains underneath

gobmp.go:74] failed to initialize Kafka publisher with error: kafka server: This is not the correct controller for this cluster.

because of course any of the 4 brokers may be the leader at any time (so if I set only one broker, there is no guarantee that this will apply for every topic, since it is the protocol's job to define the leader dynamically).
Could you help me with a refactoring of the validation process for kafka endpoints please?

when testing IPv6 SR-policies I do not see messages from GoBMP in kafka sr_policy_v6 topic. Instead the messages come into the sr_policy_v4 topic, thus Topology does not find them and write them to arango.

Example v6 policy pushed to XR BGP-TE controller:

curl --request POST --url http://10.0.0.10:8081/srpolicy-install --header 'cache-control: no-cache' --header 'content-type: application/json' --data '{"source" : "10.0.0.7", "end-point" : "2001:420:ffff:1013::1", "binding-sid" : 900006, "color" : 6, "preference" : 66, "route-distinguisher" : 6, "path-list" : [{"label-stack" : [100012], "weight" : 1},{"label-stack" : [100013, 24001], "weight" : 3}]}'

Hi,

Would it be possible to decode the SID label/index in the following TLVs to an integer value?

• SID/Label TLV ref1
• Adjacency SID TLV ref2
• LAN Adjacency SID TLV ref3
• Prefix SID TLV ref4

Thanks!

Couple cosmetic changes:

local_block_length to locator_block_length
local_node_length to locator_node_length

optional: send Argument field even when empty

Router has these SIDs:

RP/0/RP0/CPU0:R03#sho segment-routing srv6 sid all
Tue Aug 11 19:51:49.624 PDT

*** Locator: 'MAIN' ***

SID Behavior Context Owner State RW

2001:1:1:f003:1:: End (PSP) 'default':1 sidmgr InUse Y
2001:1:1:f003:11:: End.OP 'default' sidmgr InUse Y
2001:1:1:f003:40:: End.X (PSP) [Gi0/0/0/1, Link-Local] isis-100 InUse Y
2001:1:1:f003:41:: End.X (PSP) [Gi0/0/0/0, Link-Local] isis-100 InUse Y
2001:1:1:f003:42:: End.X (PSP) [Gi0/0/0/2, Link-Local] isis-100 InUse Y

The End (PSP) and End.OP SIDs come thru in ls_srv6_sid message. However, I believe the End.X ones come in ls_link messages:

https://tools.ietf.org/html/draft-ietf-idr-bgpls-srv6-ext-03#section-4

With GoBMP on log level 6 I see these entries the last one being an End.X SID TLV:

I0812 03:48:20.803082 1 ls-nlri71.go:83] LSNLRI71 Raw: [ 0x00, 0x02, 0x00, 0x73, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x1a, 0x02, 0x00, 0x00, 0x04, 0x00, 0x01, 0x86, 0xa0, 0x02, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x03, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x1a, 0x02, 0x00, 0x00, 0x04, 0x00, 0x01, 0x86, 0xa0, 0x02, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x03, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x01, 0x05, 0x00, 0x10, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x01, 0x06, 0x00, 0x10, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x23, 0x01, 0x07, 0x00, 0x02, 0x00, 0x02 ]
I0812 03:48:20.803141 1 link-nlri.go:123] LinkNLRI Raw: [ 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x1a, 0x02, 0x00, 0x00, 0x04, 0x00, 0x01, 0x86, 0xa0, 0x02, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x03, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x1a, 0x02, 0x00, 0x00, 0x04, 0x00, 0x01, 0x86, 0xa0, 0x02, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x03, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x01, 0x05, 0x00, 0x10, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x01, 0x06, 0x00, 0x10, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x23, 0x01, 0x07, 0x00, 0x02, 0x00, 0x02 ]
I0812 03:48:20.803161 1 node-descriptor.go:82] NodeDescriptor Raw: [ 0x01, 0x00, 0x00, 0x1a, 0x02, 0x00, 0x00, 0x04, 0x00, 0x01, 0x86, 0xa0, 0x02, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x03, 0x00, 0x06, 0x00, 0x00 ]
I0812 03:48:20.803183 1 node-descriptor.go:82] NodeDescriptor Raw: [ 0x01, 0x01, 0x00, 0x1a, 0x02, 0x00, 0x00, 0x04, 0x00, 0x01, 0x86, 0xa0, 0x02, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x03, 0x00, 0x06, 0x00, 0x00 ]
I0812 03:48:20.803209 1 link-descriptor.go:66] LinkDescriptor Raw: [ 0x01, 0x05, 0x00, 0x10, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x01, 0x06, 0x00, 0x10, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x23, 0x01, 0x07, 0x00, 0x02, 0x00, 0x02 ]
I0812 03:48:20.803262 1 bgpls-nlri.go:565] BGPLSNLRI Raw: [ 0x01, 0x02, 0x00, 0x08, 0x00, 0x00, 0x00, 0x0b, 0x00, 0x00, 0x00, 0x07, 0x04, 0x06, 0x00, 0x04, 0x0a, 0x00, 0x00, 0x03, 0x04, 0x47, 0x00, 0x03, 0x00, 0x00, 0x01, 0x04, 0x52, 0x00, 0x1e, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x20, 0x01, 0x00, 0x01, 0x00, 0x01, 0xf0, 0x00, 0x00, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0xe4, 0x00, 0x04, 0x28, 0x18, 0x10, 0x00 ]
I0812 03:48:20.803296 1 bgpls-tlv.go:22] BGPLSTLV Raw: [ 0x01, 0x02, 0x00, 0x08, 0x00, 0x00, 0x00, 0x0b, 0x00, 0x00, 0x00, 0x07, 0x04, 0x06, 0x00, 0x04, 0x0a, 0x00, 0x00, 0x03, 0x04, 0x47, 0x00, 0x03, 0x00, 0x00, 0x01, 0x04, 0x52, 0x00, 0x1e, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x20, 0x01, 0x00, 0x01, 0x00, 0x01, 0xf0, 0x00, 0x00, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0xe4, 0x00, 0x04, 0x28, 0x18, 0x10, 0x00 ]
I0812 03:48:20.803320 1 srv6-endxsidtlv.go:33] SRv6 End.X SID TLV Raw: [ 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x20, 0x01, 0x00, 0x01, 0x00, 0x01, 0xf0, 0x00, 0x00, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0xe4, 0x00, 0x04, 0x28, 0x18, 0x10, 0x00 ]

To make Prefix Attribute TLVs to follow a structure outlined in RFC

Git clone with the latest code and build it, exit with an error.

go: finding github.com/nats-io/nats.go v1.25.0
go: finding github.com/nats-io/nkeys v0.4.4
go: finding golang.org/x/sys v0.7.0
go: finding github.com/nats-io/nuid v1.0.1
build command-line-arguments: cannot load crypto/ecdh: malformed module path "crypto/ecdh": missing dot in first path element
make[1]: *** [Makefile:2: compile-gobmp] Error 1
make[1]: Leaving directory '/home/ubuntu/Desktop/gobmp-master/cmd/gobmp'
make: *** [Makefile:16: gobmp] Error 2

currently igp router if tlv 515 gets incorrectly converted into a decimal representation, but it has to be presented in hex.

Given that flags are encoded in a variable length field, can you parse the individual flags in the following sub-TLVs?

• ISIS Flexible Algorithm Definition Flags Sub-TLV: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-14#section-6.4
• OSPF Flexible Algorithm Definition Flags Sub-TLV: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-14#section-7.4

IANA registry definition: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-14#section-18.2

Thanks!

Hello, first of all thank you for this great contribution!

I am using the latest version of the BMP collector. I have connected it with a gobgp software router for route mirroring and with a Kafka broker for BMP message publishing and everything seems to work fine for IPv4. I am monitoring both AF topics gobmp.parsed.unicast_prefix_v4|6. However, I do not see anything on v6 despite the fact that routes are properly injected in the router and reach the BMP collector.
I.e., I see Kafka messages of the form:

...  | % Message on gobmp.parsed.unicast_prefix_v4[0]@0:
...  | {"action":"add","router_hash":"a84c2cf187498ba4cff7b28bd6e928ea","router_ip":"10.152.183.12","base_attrs":{"base_attr_hash":"c06877b920b5e1b6485edf518a457fee","origin":"incomplete","as_path":[65001,65003],"as_path_count":2,"nexthop":"10.152.183.11","is_atomic_agg":false},"peer_hash":"ebbe4bfa2301281a9ef5c720528b1be6","peer_ip":"10.152.183.11","peer_asn":65001,"timestamp":"Jul  1 09:37:35.000000","prefix":"192.168.0.0","prefix_len":16,"is_ipv4":true,"origin_as":65003,"nexthop":"10.152.183.11","is_nexthop_ipv4":true,"is_prepolicy":false,"is_adj_rib_in":false}

when injecting v4 routes, but nothing on IPv6. Is there a way to debug what is happening? Can it be related to the following line https://github.com/sbezverk/gobmp/blob/master/pkg/message/route-monitor.go#L59 where the default topic is v4 only and it is not examined whether v6 should be set there? Any help/feedback is appreciated.

Btw here is my bmp-collector docker service configuration:

...
bmp-collector:
   image: sbezverk/gobmp:latest
   container_name: bmp-collector
   restart: always
   networks:
     backend
   expose:
     - 5000
     - 56767
   entrypoint: ["/gobmp", "--source-port=5000", "--intercept=false", "--split-af=true", "--kafka-server=broker:9092"]
...

Can you parse the individual flags in the SR Prefix-SID sub-TLVs?

• IS-IS: https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1
• OSPF: https://www.rfc-editor.org/rfc/rfc8665.html#section-5
• OSPFv3: https://www.rfc-editor.org/rfc/rfc8666.html#section-6

Thanks!

SR BGP-EPE SID can be generated and advertised in BGP-LS as Protocol ID 7: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

GoBMP captures most protocol IDs already:

gobmp-bgp-ls.log

I am using the latest gobmp image, and I found that when bgp withdraws the message, the bottom line of information in the picture will appear. Is this normal behavior and is it possible to turn off the display of this information?

Snippet of the json output for PeerStateChangeMsg. As you could see, the 4-byte local_asn is shown as -71967296, whereas the correct output should be unsigned int32 format with 4223000000

{
   "type":10,
   "key":"b7de6bb60d4e6fe9bec37585bce6ea30",
   "value":{
      "action":"add",
      "router_hash":"b7de6bb60d4e6fe9bec37585bce6ea30",
      "remote_bgp_id":"10.3.0.17",
      "router_ip":"10.3.0.1",
      "timestamp":"Dec 20 06:17:33.000036",
      "remote_asn":64520,
      "remote_ip":"10.3.0.17",
      "peer_rd":"0:0",
      "remote_port":59737,
      "local_asn":-71967296,
      "local_ip":"10.3.0.1",
      "local_port":179,
      "local_bgp_id":"172.16.100.8",
      "adv_cap":{

Looking forward to the fix on this. Thanks!

This is a feature request to support the following stats types:

W0519 00:32:30.775602       1 bmpstats.go:61] unprocessed stats type:0
W0519 00:32:30.775617       1 bmpstats.go:61] unprocessed stats type:14
W0519 00:32:30.775621       1 bmpstats.go:61] unprocessed stats type:15
W0519 00:32:30.775624       1 bmpstats.go:61] unprocessed stats type:16
W0519 00:32:30.775628       1 bmpstats.go:61] unprocessed stats type:17

Does goBMP support sending parsed BMP data to another process instead of Kafka via TCP Socket? This can greatly simplify network deployment costs.

I like the project and I'm just recording a feature request here for visibility to add NATS JetStream support as a publisher for an alternative to Kafka. One route would be creating a Publisher interface that the kafka and jetstream package would implement, and using that based on the provided configuration.

ensureTopic method does not have an actual timeout for topic creation, and it seems default value for this is "0", yes an actual zero. So it fails to create topics at least in our environment

adding Timeout: timeout, at line 236 in kafka-publisher.go worked for us.

The SRv6Locator attribute in the LSPrefix structure should be a direct pointer to an srv6.LocatorTLV structure (instead of a slice of pointers).

Reference: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-09#section-5.1

The function UnmarshalRoutes (https://github.com/sbezverk/gobmp/blob/master/pkg/base/route.go#L39) fails to decode non-addpath NLRIs.
Here is a test that shows the problem:

	tests := []struct {
		name   string
		input  []byte
		expect []Route
	}{
		{
			name:  "fail",
			input: []byte{0, 8, 10, 24, 10, 0, 0, 24, 20, 0, 0},
			expect: []Route{
				{
					Length: 0x0,
					Prefix: []byte{},
				},
				{
					Length: 0x08,
					Prefix: []byte{10},
				},
				{
					Length: 24,
					Prefix: []byte{10, 0, 0},
				},
				{
					Length: 24,
					Prefix: []byte{20, 0, 0},
				},
			},
		},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			got, err := UnmarshalRoutes(tt.input)
			if err != nil {
				t.Fatalf("test failed with error: %+v", err)
			}
			if !reflect.DeepEqual(tt.expect, got) {
				t.Fatalf("test failed as expected nlri %+v does not match actual nlri %+v", tt.expect, got)
			}
		})
	}
}```

Failure:
```Running tool: /home/takt/software/go/bin/go test -timeout 30s -run ^TestUnmarshalBaseNLRI$ github.com/sbezverk/gobmp/pkg/base

--- FAIL: TestUnmarshalBaseNLRI (0.00s)
    --- FAIL: TestUnmarshalBaseNLRI/fail (0.00s)
        /home/takt/git/src/github.com/taktv6/gobmp/pkg/base/route_test.go:102: test failed as expected nlri [{PathID:0 Length:0 Label:[] RD:<nil> Prefix:[]} {PathID:0 Length:8 Label:[] RD:<nil> Prefix:[10]} {PathID:0 Length:24 Label:[] RD:<nil> Prefix:[10 0 0]} {PathID:0 Length:24 Label:[] RD:<nil> Prefix:[20 0 0]}] does not match actual nlri [{PathID:526872 Length:10 Label:[] RD:<nil> Prefix:[0 0]} {PathID:0 Length:24 Label:[] RD:<nil> Prefix:[20 0 0]}]
FAIL
FAIL	github.com/sbezverk/gobmp/pkg/base	0.003s
FAIL```

The NLRI encoding can not be detected reliably by the NLRI's content.
What is needed is a calculation of the negotiated capabilities from the BGP OPEN messages from the BMP Peer Up Notifications.
With that capability information is then to be decided how the NLRI must be decoded.

The flags are currently being parsed into the entry itself, whereas other objects with parsed flags use a separate flags object.

When the prefix length received by the router is greater than 24, the prefix will become '0.0.0.0'. Is this a special setting or regulation, or is it a bug? Specific examples are as follows:

I0421 05:07:35.347038 4124 route-monitor.go:26] BMP Route Monitor Message Raw: ffffffffffffffffffffffffffffffff0096020000007b400101005002001e02070003000d0000223600000ce700000cf800000b620000e45500009c814003045bce3467c008300b62019a0b6205810b6209630b620d480ce703ee0ce703fd0ce70c050cf804100cf807da0cf8233c2236006e2236012cc020180003000d00000003000000050003000d0000000400000003189ad144
Withdrawn Routes Length: 0
Total Path Attribute Length: 28
Attribute Type: 1 (ORIGIN)
Origin: [0]
Attribute Type: 2 (AS_PATH)
AS PATH: [ 0x02, 0x06, 0x73, 0xfb, 0x32, 0xe6, 0x93, 0x1e, 0x91, 0x54, 0xdd, 0x78, 0xdd, 0x78 ]
Attribute Type: 3
[ 0x5b, 0xce, 0x34, 0x09 ]
NLRI:

I0421 05:07:35.347046 4124 bgp-update.go:358] BGPUpdate Raw: 0000007b400101005002001e02070003000d0000223600000ce700000cf800000b620000e45500009c814003045bce3467c008300b62019a0b6205810b6209630b620d480ce703ee0ce703fd0ce70c050cf804100cf807da0cf8233c2236006e2236012cc020180003000d00000003000000050003000d0000000400000003189ad144
I0421 05:07:35.347142 4124 bgp-path-attribute.go:66] BGPPathAttributes Raw: [ 0x40, 0x01, 0x01, 0x00, 0x50, 0x02, 0x00, 0x1e, 0x02, 0x07, 0x00, 0x03, 0x00, 0x0d, 0x00, 0x00, 0x22, 0x36, 0x00, 0x00, 0x0c, 0xe7, 0x00, 0x00, 0x0c, 0xf8, 0x00, 0x00, 0x0b, 0x62, 0x00, 0x00, 0xe4, 0x55, 0x00, 0x00, 0x9c, 0x81, 0x40, 0x03, 0x04, 0x5b, 0xce, 0x34, 0x67, 0xc0, 0x08, 0x30, 0x0b, 0x62, 0x01, 0x9a, 0x0b, 0x62, 0x05, 0x81, 0x0b, 0x62, 0x09, 0x63, 0x0b, 0x62, 0x0d, 0x48, 0x0c, 0xe7, 0x03, 0xee, 0x0c, 0xe7, 0x03, 0xfd, 0x0c, 0xe7, 0x0c, 0x05, 0x0c, 0xf8, 0x04, 0x10, 0x0c, 0xf8, 0x07, 0xda, 0x0c, 0xf8, 0x23, 0x3c, 0x22, 0x36, 0x00, 0x6e, 0x22, 0x36, 0x01, 0x2c, 0xc0, 0x20, 0x18, 0x00, 0x03, 0x00, 0x0d, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x05, 0x00, 0x03, 0x00, 0x0d, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x03 ]
I0421 05:07:35.347157 4124 route.go:31] Routes Raw: [ 0x18, 0x9a, 0xd1, 0x44 ]
panic: runtime error: slice bounds out of range [:26] with capacity 25

goroutine 19972 [running]:
github.com/sbezverk/gobmp/pkg/bgp.(*Update).GetAttrASPath(0xc0000d37a0, 0xc000534701, 0x0, 0x0, 0x1)
/home/sekrier/apr21/gobmp/pkg/bgp/bgp-update.go:105 +0x39a
github.com/sbezverk/gobmp/pkg/message.(*producer).nlri(0xc00001e0c0, 0x0, 0xc0000d3740, 0xc0000d37a0, 0x1500, 0x1, 0x0, 0x0, 0xc0003bbba0)
/home/sekrier/apr21/gobmp/pkg/message/base-nlri.go:43 +0x8e6
github.com/sbezverk/gobmp/pkg/message.(*producer).produceRouteMonitorMessage(0xc00001e0c0, 0xc0000d3740, 0x805340, 0xc000206070)
/home/sekrier/apr21/gobmp/pkg/message/route-monitor.go:64 +0xf1
github.com/sbezverk/gobmp/pkg/message.(*producer).producingWorker(0xc00001e0c0, 0xc0000d3740, 0x805340, 0xc000206070)
/home/sekrier/apr21/gobmp/pkg/message/producer.go:41 +0x15c
created by github.com/sbezverk/gobmp/pkg/message.(*producer).Producer
/home/sekrier/apr21/gobmp/pkg/message/producer.go:26 +0x74

On the ACP call today the team was looking at ls_link data and Peter noted that in adjacency sid tlv "prefix_sid" field should be renamed as "sid"

Ketan also asks that we change SRv6 EndXSID sub_tlv_value from byte to uint32

it is not an urgent issue

Hey!

I looking for a way to create BMP message. Rather than unmarshal them into a nice go struct, I would like to start from a go struct and marshal it into bytes.

I was wondering if I could do that via gobmp. Looking at the code, it seems that only the unmarshal direction is implemented, but maybe I'm wrong?

Best.

The IGPFlags attribute is present in LSPrefix structure but no value is set.

Function lsPrefix should call GetPrefixIGPFlags.

Reference: RFC 7752 — IGP Flags TLV

Thanks!

As BGP bmp client will publish the initialization message everytime gobmp restarted, I think gobmp internally could build a in-memory bgp peer state and route map, which could be exposed through API so that monitoring frameworks like Prometheus could collect it for monitoring and alerts. It is much scalable and flexible compared to adding SNMP monitoring for all different network devices.

Can you parse the individual flags in the Node Flag Bits TLV (1024) as defined in RFC7752?

Thanks!

Saving this output here for visibility and future reference when troubleshooting:

E0518 21:13:59.110857       1 gobmpsrv.go:95] fail to recover BMP message Common Header with error: invalid version in common header, expected 3 found 241
panic: runtime error: makeslice: len out of range

goroutine 954 [running]:
github.com/sbezverk/gobmp/pkg/gobmpsrv.(*bmpServer).bmpWorker(0xc000024600, {0x972b30?, 0xc000012030})
        /workdir/pkg/gobmpsrv/gobmpsrv.go:99 +0x62e
created by github.com/sbezverk/gobmp/pkg/gobmpsrv.(*bmpServer).server
        /workdir/pkg/gobmpsrv/gobmpsrv.go:53 +0x16a

After clearing or deleting an XR BGP session the BGP peer/node entry is not deleted from Arango and 'del' message is not seen on kafka.

gobmp log:

I0321 21:45:38.315876 1 common-header.go:25] BMP CommonHeader Raw: [ 0x03, 0x00, 0x00, 0x00, 0x46, 0x02 ]
I0321 21:45:38.315970 1 common-header.go:25] BMP CommonHeader Raw: [ 0x03, 0x00, 0x00, 0x00, 0x46, 0x02 ]
I0321 21:45:38.315993 1 per-peer-header.go:73] BMP Per Peer Header Raw: [ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC6, 0x3E, 0x9A, 0x01, 0x00, 0x00, 0xFA, 0x20, 0x0A, 0x00, 0x00, 0x20, 0x60, 0x57, 0xBE, 0xC8, 0x00, 0x04, 0x78, 0x96, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x15, 0x03, 0x06, 0x04 ]
I0321 21:45:38.316023 1 peer-down.go:19] BMP Peer Down Message Raw: [ 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x15, 0x03, 0x06, 0x04 ]
E0321 21:45:38.316059 1 peer.go:19] got invalid Payload type in bmp.Message &{Reason:1 Data:[255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 0 21 3 6 4]}
I0321 21:45:47.898576 1 common-header.go:25] BMP CommonHeader Raw: [ 0x03, 0x00, 0x00, 0x00, 0x64, 0x01 ]
I0321 21:45:47.898616 1 common-header.go:25] BMP CommonHeader Raw: [ 0x03, 0x00, 0x00, 0x00, 0x4C, 0x01 ]
I0321 21:45:47.898662 1 common-header.go:25] BMP CommonHeader Raw: [ 0x03, 0x00, 0x00, 0x00, 0x4C, 0x01 ]
I0321 21:45:47.898687 1 per-peer-header.go:73] BMP Per Peer Header Raw: [ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC6, 0x3E, 0x9A, 0x01, 0x00, 0x00, 0xFA, 0x20, 0x00, 0x00, 0x00, 0x00, 0x60, 0x57, 0xBE, 0xD1, 0x00, 0x0D, 0x77, 0xBE, 0x00, 0x00, 0x00, 0x03, 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x33, 0x00, 0x02, 0x00, 0x04, 0x00, 0x00, 0x03, 0x5B, 0x00, 0x04, 0x00, 0x04, 0x00, 0x00, 0x01, 0x55 ]
I0321 21:45:47.898707 1 stats-report.go:20] BMP Stats Report Message Raw: [ 0x00, 0x00, 0x00, 0x03, 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x33, 0x00, 0x02, 0x00, 0x04, 0x00, 0x00, 0x03, 0x5B, 0x00, 0x04, 0x00, 0x04, 0x00, 0x00, 0x01, 0x55 ]
I0321 21:45:47.898727 1 information-tlv.go:21] BMP Informational TLV Raw: [ 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x33, 0x00, 0x02, 0x00, 0x04, 0x00, 0x00, 0x03, 0x5B, 0x00, 0x04, 0x00, 0x04, 0x00, 0x00, 0x01, 0x55 ]
I0321 21:45:47.898748 1 common-header.go:25] BMP CommonHeader Raw: [ 0x03, 0x00, 0x00, 0x00, 0x64, 0x01 ]
I0321 21:45:47.898778 1 per-peer-header.go:73] BMP Per Peer Header Raw: [ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x01, 0x04, 0x20, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0xFA, 0x20, 0x0A, 0x00, 0x00, 0x20, 0x60, 0x57, 0xBE, 0xD1, 0x00, 0x0D, 0x77, 0x6B, 0x00, 0x00, 0x00, 0x05, 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x08, 0x00, 0x02, 0x00, 0x04, 0x00, 0x00, 0x00, 0x24, 0x00, 0x04, 0x00, 0x04, 0x00, 0x00, 0x00, 0x16, 0x00, 0x07, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03 ]
I0321 21:45:47.898807 1 stats-report.go:20] BMP Stats Report Message Raw: [ 0x00, 0x00, 0x00, 0x05, 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x08, 0x00, 0x02, 0x00, 0x04, 0x00, 0x00, 0x00, 0x24, 0x00, 0x04, 0x00, 0x04, 0x00, 0x00, 0x00, 0x16, 0x00, 0x07, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03 ]
I0321 21:45:47.898832 1 information-tlv.go:21] BMP Informational TLV Raw: [ 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x08, 0x00, 0x02, 0x00, 0x04, 0x00, 0x00, 0x00, 0x24, 0x00, 0x04, 0x00, 0x04, 0x00, 0x00, 0x00, 0x16, 0x00, 0x07, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03 ]
I0321 21:45:47.898848 1 common-header.go:25] BMP CommonHeader Raw: [ 0x03, 0x00, 0x00, 0x00, 0x54, 0x01 ]
I0321 21:45:47.898878 1 common-header.go:25] BMP CommonHeader Raw: [ 0x03, 0x00, 0x00, 0x00, 0x54, 0x01 ]
I0321 21:45:47.898902 1 per-peer-header.go:73] BMP Per Peer Header Raw: [ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0A, 0x01, 0x01, 0x00, 0x00, 0x00, 0xFD, 0xE8, 0x0A, 0x00, 0x00, 0x00, 0x60, 0x57, 0xBE, 0xD1, 0x00, 0x0D, 0x77, 0xC2, 0x00, 0x00, 0x00, 0x03, 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x0E, 0x00, 0x07, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07 ]
I0321 21:45:47.898919 1 stats-report.go:20] BMP Stats Report Message Raw: [ 0x00, 0x00, 0x00, 0x03, 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x0E, 0x00, 0x07, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07 ]
I0321 21:45:47.898941 1 information-tlv.go:21] BMP Informational TLV Raw: [ 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x0E, 0x00, 0x07, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07 ]

when unicast_prefix_v4 entries are removed from routing table, there are no corresponding "del" messages on Kafka

Can you parse the individual flags in the SR Adj-SID sub-TLVs?

• IS-IS: https://www.rfc-editor.org/rfc/rfc8667.html#section-2.2.1
• OSPF: https://www.rfc-editor.org/rfc/rfc8665.html#section-6.1
• OSPFv3 https://www.rfc-editor.org/rfc/rfc8666.html#section-7.1

Thanks!

In the current implementation of the streamed out message, the timestamp field is illustrated as "timestamp":"Dec 20 06:17:33.000036" It would be great to reformat this to include year into the message, and use iso format for the date representation like '2021-12-20 06:17:33.000036'. Thanks for your support in advance!

The attribute seems to have the right value for non-zero algorithms, but is missing/null for algo 0.

Statement p += 2 is missing after this line:

This causes the value parsed in the remainder of the function to start at offset 2 (beginning of the length field) instead of 4 (beginning of the value field).

Hello, I am having an add-path-based setup as follows:

other routers (BIRD) --> Route reflector (BIRD) --> router (goBGP) --> gobmp collector

I noticed that BGP updates reaching the router on the right (recorded in MRT data), properly contain the add-path Path ID (path_id) attribute, here is an example from using the mrtparse tool:

OrderedDict([('timestamp', {1671026048: '2022-12-14 13:54:08'}), ('type', {16: 'BGP4MP'}), ('subtype', {9: 'BGP4MP_MESSAGE_AS4_ADDPATH'}), ('length', 174), ('peer_as', '50414'), ('local_as', '50414'), ('ifindex', 0), ('afi', {1: 'IPv4'}), ('peer_ip', '5.161.149.178'), ('local_ip', '192.168.192.35'), ('bgp_message', OrderedDict([('marker', 'ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff'), ('length', 154), ('type', {2: 'UPDATE'}), ('withdrawn_routes_length', 0), ('withdrawn_routes', []), ('path_attributes_length', 131), ('path_attributes', [OrderedDict([('flag', 144), ('type', {14: 'MP_REACH_NLRI'}), ('length', 48), ('value', OrderedDict([('afi', {2: 'IPv6'}), ('safi', {1: 'UNICAST'}), ('next_hop_length', 32), ('next_hop', ['2a0c:9a40:1050::1', 'fe80::1ae8:29ff:fe4e:d9c5']), ('reserved', 0), ('nlri', [OrderedDict([('path_id', 40), ('length', 48), ('prefix', '2001:648:2c30::')])])]))]), OrderedDict([('flag', 64), ('type', {1: 'ORIGIN'}), ('length', 1), ('value', {0: 'IGP'})]), OrderedDict([('flag', 64), ('type', {2: 'AS_PATH'}), ('length', 22), ('value', [OrderedDict([('type', {2: 'AS_SEQUENCE'}), ('length', 5), ('value', ['34927', '3356', '21320', '5408', '8522'])])])]), OrderedDict([('flag', 128), ('type', {4: 'MULTI_EXIT_DISC'}), ('length', 4), ('value', 0)]), OrderedDict([('flag', 64), ('type', {5: 'LOCAL_PREF'}), ('length', 4), ('value', 100)]), OrderedDict([('flag', 192), ('type', {8: 'COMMUNITY'}), ('length', 8), ('value', ['34927:810', '34927:865'])]), OrderedDict([('flag', 128), ('type', {9: 'ORIGINATOR_ID'}), ('length', 4), ('value', '193.148.250.176')]), OrderedDict([('flag', 128), ('type', {10: 'CLUSTER_LIST'}), ('length', 4), ('value', ['5.161.149.178'])]), OrderedDict([('flag', 192), ('type', {16: 'EXTENDED COMMUNITIES'}), ('length', 8), ('value', [652993942782285])])]), ('nlri', [])]))])

Here we have a Path ID of 40 contain in the NLRI of the announcement. Similar for BGP withdrawals, where though the path ID is contained in the withdrawn_routes accompanying the prefix:

OrderedDict([('timestamp', {1671018180: '2022-12-14 13:43:00'}), ('type', {16: 'BGP4MP'}), ('subtype', {9: 'BGP4MP_MESSAGE_AS4_ADDPATH'}), ('length', 50), ('peer_as', '50414'), ('local_as', '50414'), ('ifindex', 0), ('afi', {1: 'IPv4'}), ('peer_ip', '192.168.55.4'), ('local_ip', '192.168.55.2'), ('bgp_message', OrderedDict([('marker', 'ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff'), ('length', 30), ('type', {2: 'UPDATE'}), ('withdrawn_routes_length', 7), ('withdrawn_routes', [OrderedDict([('path_id', 2), ('length', 16), ('prefix', '192.168.0.0')])]), ('path_attributes_length', 0), ('path_attributes', []), ('nlri', [])]))])

So everything is registered OK up to the router.

Now I have the following problem. The GoBMP collector sees the messages (incl. originator and cluster list due to the route reflection setup) but does not include the PathID attribute, as seen from the following kafka export of the related gobmp.parsed.unicast_prefix_* topic (v4 in this case, but the same happens with v6):

CreateTime:1671026561016	Partition:2	Offset:343	4b648121a337873b0d4eaa81163e4827	{"action":"add","router_hash":"4b648121a337873b0d4eaa81163e4827","router_ip":"192.168.192.35","base_attrs":{"base_attr_hash":"5570f56c18f6888a8a52b8026a12148e","origin":"igp","as_path":[64515,65534,20473,23686,7474,7473,1299,50304,12654],"as_path_count":9,"nexthop":"169.254.169.254","local_pref":100,"is_atomic_agg":false,"aggregator":"AAD8NAoRzEA=","community_list":["20473:100","20473:23686","64515:44"],"originator_id":"67.219.106.198","cluster_list":"5.161.149.178","large_community_list":["20473:100:23686"]},"peer_hash":"a2c0422e3d0c79d656df5c52b10796a6","peer_ip":"5.161.149.178","peer_type":0,"peer_asn":50414,"timestamp":"2022-12-14T14:02:41Z","prefix":"84.205.64.0","prefix_len":24,"is_ipv4":true,"origin_as":12654,"nexthop":"169.254.169.254","is_nexthop_ipv4":true,"is_adj_rib_in_post_policy":true,"is_adj_rib_out_post_policy":false,"is_loc_rib_filtered":false}

Could you please double-check that the path ID is correctly set both in IPv4 and IPv6, both for announcements and withdrawals? It is important so that paths are distinguished from one another on the application side (and gobmp collector produces very useful information in that regard, but seems to be missing some fields). Maybe this is a bug somewhere in the code?

Many thanks in advance for your help!

In your code, you get the unidirectional loss as packet percentage between two directly connected IGP link-state neighbors:

Can someone please confirm so that I can create a PR.

During restarting or stoping goBGP instance, it sends peer-down messages with reason code = 0. When I look at its code, code = 0 is its restarting value for peer down. Obviously goBGP should set a proper value during those phases. Other BGP programs may have this behaviour, bug or what ever you called because its hard match every event to a proper reason code.
It seems to me that for peer down messages should be processed and may assign a reason value of invalid reason code or e.t.c if its not already one.

peer-down.go
....
if pdw.Reason < 1 || pdw.Reason > 5 {
return nil, fmt.Errorf("invalid reason code %d in Peer Down message", pdw.Reason)
}
....

if it is ok, I will try to add this option to the code?

There is a single flag for an LSPrefix srv6_locator entry defined in RFC at this time. It would be more consistent if the d_flag were parsed, and the name of the attribute being "flags" rather than "flag".

I noticed that data specific to unresv_bw_kbps was being produced as a list that is too long for the actual TE TLV parameters. For example,

"unresv_bw_kbps":[0,0,0,0,0,0,0,0,20000000,20000000,20000000,20000000,20000000,20000000,20000000,20000000]

Notice there are 8 0 values and then 8 true values from the device. Upon investigation, I found bgpls.GetUnreservedLinkBandwidthKbps is initializing and empty slice of length 8 and then this slice is being appended with the actual TLV data producing the slice of length 16.

I have a PR that I will submit shortly that rejiggers the for loop logic to index the initial slice so that the original 0's get replaced with TLV specific data and the final slice is of length 8 as expected.
Expected result:

"unresv_bw_kbps":[20000000,20000000,20000000,20000000,20000000,20000000,20000000,20000000]

After issue_171 merge it appears we're losing adjacency-SID values.
Router BGP-LS output:

RP/0/RP0/CPU0:IE-5011-5#sho bgp link-state link-state [E][L2][I0x0][N[c30.33922][b0.0.0.0][s0000.0000.0005.00]][R[c30.33922][b0.0.0.0][s0000.0000.0002.00]][L[i172.31.101.38][n172.$
Mon Aug 23 09:04:51.766 PDT
BGP routing table entry for [E][L2][I0x0][N[c30.33922][b0.0.0.0][s0000.0000.0005.00]][R[c30.33922][b0.0.0.0][s0000.0000.0002.00]][L[i172.31.101.38][n172.31.101.39]]/696
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                257         257
Last Modified: Jul  3 15:46:47.959 for 7w1d
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    0.0.0.0 from 0.0.0.0 (172.31.101.5)
      Origin IGP, localpref 100, valid, redistributed, best, group-best
      Received Path ID 0, Local Path ID 1, version 257
      Link-state: Link ID: Local:63 Remote:63, Local TE Router-ID: 
                  172.31.101.5 Remote TE Router-ID: 172.31.101.2, admin-group: 0x00000000
                   max-link-bw (kbits/sec): 99999998, max-reserv-link-bw (kbits/sec): 0
                   max-unreserv-link-bw (kbits/sec): 0 0 0 0 0 0 0 0, 
                  TE-default-metric: 1 metric: 1, ADJ-SID: 100008(70) 
                   ADJ-SID: 100009(30) , ext-admin-group: 0x00000000.0x00000000
                  .0x00000000.0x00000000.0x00000000.0x00000000.0x00000000
                  .0x00000000
RP/0/RP0/CPU0:IE-5011-5#

corresponding arangoDB entry:

[
  {
    "_key": "2_0_0_0_0000.0000.0005_172.31.101.38_0000.0000.0002_172.31.101.39",
    "_id": "LSLink/2_0_0_0_0000.0000.0005_172.31.101.38_0000.0000.0002_172.31.101.39",
    "_rev": "_c1M2Kky--A",
    "action": "add",
    "router_hash": "215db23478f90081de227ae2480704e9",
    "router_ip": "172.31.101.1",
    "domain_id": 0,
    "peer_hash": "d99eb82ad529d6c84635579c24958245",
    "peer_ip": "172.31.101.6",
    "peer_asn": 2000002,
    "timestamp": "Aug 23 15:57:39.000585",
    "igp_router_id": "0000.0000.0005",
    "router_id": "172.31.101.5",
    "protocol": "IS-IS Level 2",
    "protocol_id": 2,
    "area_id": "0",
    "nexthop": "172.31.101.6",
    "local_link_id": 63,
    "remote_link_id": 63,
    "local_link_ip": "172.31.101.38",
    "remote_link_ip": "172.31.101.39",
    "igp_metric": 1,
    "max_link_bw": 1215750144,
    "unresv_bw": [
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0
    ],
    "te_default_metric": 1,
    "remote_node_hash": "647a519c91fa04962fd298ac42a7fb43",
    "local_node_hash": "523d2c23ccbea991337e263fd26621e7",
    "remote_igp_router_id": "0000.0000.0002",
    "remote_router_id": "172.31.101.2",
    "local_node_asn": 2000002,
    "remote_node_asn": 2000002,
    "ls_adjacency_sid": [
      {
        "flags": {
          "f_flag": false,
          "b_flag": true,
          "v_flag": true,
          "l_flag": true,
          "s_flag": false,
          "p_flag": false
        },
        "weight": 0
      },
      {
        "flags": {
          "f_flag": false,
          "b_flag": false,
          "v_flag": true,
          "l_flag": true,
          "s_flag": false,
          "p_flag": false
        },
        "weight": 0
      }
    ]
  }
]

Do you know if there is currently support in place for monitoring the Adj-RIB-Out of a router connected to gobmp via a BMP session? If not, is it in the roadmap? Relevant resource: https://datatracker.ietf.org/doc/rfc8671/
I am not sure if such monitoring is officially supported in commercial or open-source software routers yet.
Thanks in advance for the clarification!

Having yet another sub-object for flags under mt_id_tlv seems to really be an overkill. Having the names follow the convention of X_flag rather than flag_X might be worthwhile.

Various vendors support defining passive BMP connections that allow the client to initiate the connection. Support defining outbound connections in a backwards compatible way.