Ordering of flow spec elements conflicts with standard

[pavel-odintsov]

Hello!

I've found some issues with sequence of flow spec elements inside BGP Flow SPEC NLRI.

I've announced this announce with up to date GoBGP:

gobgp global rib -a ipv4-flowspec add match protocol tcp destination 10.0.0.0/24 source 20.0.0.0/24 then redirect 10:10

And it correctly received from other side with same GoBGPD's version:

gobgp global rib -a ipv4-flowspec
    Network                                                     Next Hop             AS_PATH              Age        Attrs
*>  [protocol: tcp][destination:10.0.0.0/24][source:20.0.0.0/24]fictitious                                00:00:54   [{LocalPref: 100} {Origin: ?} {Extcomms: [redirect: 10:10]}]

Wireshark also correctly parses this announce:

But please take a look at sequence of types. We have following order: protocol (type 3), destination prefix (type 1) and source prefix (type 2).

But in RFC we have strict requirements about order of types (https://tools.ietf.org/html/rfc5575):

Flow specification components must follow strict type ordering. A
given component type may or may not be present in the specification,
but if present, it MUST precede any component of higher numeric type
value.

So we need to order they from lowest type to highest type. I.e.: destination prefix, source prefix and protocol.

Wireshark could parse this but other devices from Cisco or Juniper could just reject it because we are conflicting with reference.

So I could like to ask you to change type's ordering in this place.

I've reproduced this tests with my custom flow spec announce and got same results.

Example announce "match destination 10.0.0.0/24 protocol tcp source 20.0.0.0/24 then redirect 10:10" encoded with function serialize_path into following Flow Spec NLRI:

0x01 (<--destination prefix type) 0x18 0x0a 0x00 0x00 0x03 (<-- protocol type) 0x81 0x06 0x02 (<-- source prefix) 0x18 0x14 0x00 0x00 

As you can see they haven't any ordering at all: 1 => 3 => 2. But they should be 1 => 2 => 3.

Finally, thank you for your work on Open Source BGP. :)

[pavel-odintsov]

Looks like ExaBGP could handle this but will send notification about broken order: https://github.com/Exa-Networks/exabgp/blob/master/lib/exabgp/bgp/message/update/nlri/flow.py#L636

Will be perfect to read flow spec NLRI's with broken order but we should generate they in proper order.

Will try to check with real hardware but it's complicated ... :(

[pavel-odintsov]

I've checked it with exabgp and it failed to parse announce with broken order.

ExaBGP's author Thomas Mangin confirmed this behavior according to standard.

sbin/exabgp qa/conf/flow.conf --decode "0000 0024 4002 0040 0504 0000 0064 4001 0102 800E 1300 0185 0000 0D03 8111 0118 0A00 0002 1814 0000" 2>&1|tail -n 5
Tue, 23 Feb 2016 21:32:18 | INFO     | 1358   | parser        |     return cls.registered_nlri[key].unpack_nlri(afi,safi,data,action,addpath)
Tue, 23 Feb 2016 21:32:18 | INFO     | 1358   | parser        |   File "/usr/src/exabgp/lib/exabgp/bgp/message/update/nlri/flow.py", line 637, in unpack_nlri
Tue, 23 Feb 2016 21:32:18 | INFO     | 1358   | parser        |     raise Notify(3,10,'components are not sent in the right order %s' % seen)
Tue, 23 Feb 2016 21:32:18 | INFO     | 1358   | parser        | Notify: UPDATE message error / Invalid Network Field / components are not sent in the right order [3, 1]
Tue, 23 Feb 2016 21:32:18 | INFO     | 1358   | parser        | 

[pavel-odintsov]

I've tested it with Juniper MX and it could handle it perfectly.

I've checked it with following announce:

./gobgp global rib -a ipv4-flowspec add match protocol tcp destination 10.0.0.0/24 source 20.0.0.0/24 then redirect 10:10

It received perfectly:

lab_user@MX-1> show route receive-protocol bgp 10.30.50.1 table inetflow.0 

inetflow.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Restart Complete
  Prefix                  Nexthop              MED     Lclpref    AS path
  ,,proto=6,10.0.0/24,20.0.0/24/term:2                
*                         Self                         100        ?

Here I could offer debug log of Juniper:

Feb 23 20:52:40.434422 BGP RECV 10.30.50.1+179 -> 10.30.80.1+54430
Feb 23 20:52:40.434484 BGP RECV message type 2 (Update) length 70
Feb 23 20:52:40.434500 BGP RECV Update PDU length 70
Feb 23 20:52:40.434522 BGP RECV flags 0x40 code ASPath(2) length 0: <null>
Feb 23 20:52:40.434538 BGP RECV flags 0x40 code LocalPref(5): 100
Feb 23 20:52:40.434554 BGP RECV flags 0x40 code Origin(1): Incomplete
Feb 23 20:52:40.434573 BGP RECV flags 0x80 code MP_reach(14): AFI/SAFI 1/133
Feb 23 20:52:40.434624 BGP RECV     *,*,proto=6,10.0.0/24,20.0.0/24/104
Feb 23 20:52:40.434646 BGP RECV flags 0xc0 code Extended Communities(16): 8008:10:10
Feb 23 20:52:40.434808 bgp_rcv_nlri: *,*,proto=6,10.0.0/24,20.0.0/24/104
Feb 23 20:52:40.435148 CHANGE   *,*,proto=6,10.0.0/24,20.0.0/24/104  nhid 0  BGP      pref 170/-101 metric  <Active Int Ext>  as 65001
Feb 23 20:52:40.435214 ADD      *,*,proto=6,10.0.0/24,20.0.0/24/104  nhid 0  BGP      pref 170/-101 metric  <Active Int Ext>  as 65001
Feb 23 20:52:40.435250 bgp_multipath_check: rth *,*,proto=6,10.0.0/24,20.0.0/24/104 { nentries 1 ac 0x9e80550 } Skip calc. multipath, was_mp_active=0, act_is_mp=0 
Feb 23 20:52:40.435286 bgp_rt_add: rt *,*,proto=6,10.0.0/24,20.0.0/24/104 { nhid 0x0 <Active Int Ext> <Accepted> from 10.30.50.1 (Internal AS 65001) } Done rt add
Feb 23 20:52:40.435365 rt_close: 1 route proto BGP_65001_65001.10.30.50.1+179

They have pretty smart BGP implementation but other vendors could follow standard in strict order.

[fujita]

Thanks for the report, I pushed a fix:
00a592e

Can you try the latest?

[pavel-odintsov]

Awesome! Thanks!

But I could not build project because of this:
#710

Could you look at this bug too?

On Wednesday, 24 February 2016, FUJITA Tomonori notifications@github.com
wrote:

Thanks for the report, I pushed a fix:
00a592e
00a592e

Can you try the latest?

—
Reply to this email directly or view it on GitHub
#708 (comment).

Sincerely yours, Pavel Odintsov

[pavel-odintsov]

Perfect! Perfect! Perfect! It's alive (and working correctly)!

I've received announce by ExaBGP:

exabgp: 8821   wire          session 1 outgoing 10.0.3.9 / 10.0.3.115            RECEIVED  ( 127) 0000 002F 4002 0040 0504 0000 0064 4001 0102 800E 1300 0185 0000 0D01 180A 0000 0218 1400 0003 8106 C010 0880 0800 0A00 0000 0A

And could decode it without any issues:

sbin/exabgp qa/conf/flow.conf --decode "0000 002F 4002 0040 0504 0000 0064 4001 0102 800E 1300 0185 0000 0D01 180A 0000 0218 1400 0003 8106 C010 0880 0800 0A00 0000 0A" 2>&1|tail -n 1
Wed, 24 Feb 2016 09:36:43 | INFO     | 8884   | parser        | update json { "exabgp": "3.5.0", "time": 1456295803, "host" : "netflow.fv.ee", "pid" : 8884, "ppid" : 8791, "counter": 1, "type": "update", "neighbor": { "address": { "local": "127.0.0.1", "peer": "127.0.0.1" }, "asn": { "local": "1", "peer": "1" }, "direction": "in", "message": { "update": { "attribute": { "origin": "incomplete", "local-preference": 100, "extended-community": [ 9225623879618134026 ] }, "announce": { "ipv4 flow": { "no-nexthop": { "flow-11": { "destination-ipv4": [ "10.0.0.0/24" ], "source-ipv4": [ "20.0.0.0/24" ], "protocol": [ "=tcp" ], "string": "flow destination-ipv4 10.0.0.0/24 source-ipv4 20.0.0.0/24 protocol =tcp" } } } } } } } }

Great job! Fujita thanks a lot!

[pavel-odintsov]

Hello again!

Looks like you haven't corrected code for function serialize_path. It still produces flow spec elements it wrong order.

Could you check it?

[fujita]

What do you mean? Flowspec components are sorted before they are inserted into a table, avoid to sort them every time sending them to peers.

[pavel-odintsov]

I'm using serialize_path() for preparing flow spec BGP attributes from my C++ code and right now it prepares flow spec attribute with broken order.

I could offer some code:

path* gobgp_lib_path = serialize_path(ipv4_flow_spec_route_family, (char*)"match destination 10.0.0.0/24 protocol tcp source 20.0.0.0/24 then redirect 10:10");

This code produces following output:

Whole MP reach NLRI in hex: 80 0e 13 00 01 85 00 00 0d /01/ 18 0a 00 00 /03/ 81 06 /02/ 18 14 00 00 

As you can see we have wrong order 01/03/02 here. But if I do same announce from GoBGP CLI tool everything working OK.

[fujita]

Should be fixed by:
b387a7b

[pavel-odintsov]

Perfectly! It's working!

[pavel-odintsov]

I've implemented some sort of self-tests for GoBGP with exabgp. You could try this code:

Will run command /opt/dps/libraries/exabgp_git/sbin/exabgp /opt/dps/libraries/exabgp_git/qa/conf/flow.conf --decode "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 3c 02 00 00 00 25 80 0e 13 00 01 85 00 00 0d 01 18 0a 00 00 02 18 14 00 00 03 81 06 40 01 01 02 c0 10 08 80 08 00 0a 00 00 00 0a " >/tmp/exabgp_output_decoder.txt 2>&1 for test

It will return 1 in case of error or return correctly parsed json code:

tail -1 /tmp/exabgp_output_decoder.txt
Wed, 24 Feb 2016 16:43:33 | INFO     | 19105  | parser        | update json { "exabgp": "3.5.0", "time": 1456321413, "host" : "Ubuntu-1404-trusty-64-minimal", "pid" : 19105, "ppid" : 19104, "counter": 1, "type": "update", "neighbor": { "address": { "local": "127.0.0.1", "peer": "127.0.0.1" }, "asn": { "local": "1", "peer": "1" }, "direction": "in", "message": { "update": { "attribute": { "origin": "incomplete", "extended-community": [ 9225623879618134026 ] }, "announce": { "ipv4 flow": { "no-nexthop": { "flow-11": { "destination-ipv4": [ "10.0.0.0/24" ], "source-ipv4": [ "20.0.0.0/24" ], "protocol": [ "=tcp" ], "string": "flow destination-ipv4 10.0.0.0/24 source-ipv4 20.0.0.0/24 protocol =tcp" } } } } } } } }