flowspec redirect ip implemention

[pubyun]

some vendor like Huawei only implement new draft:

https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-02

and exabgp only implement old draft:

https://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02

so the huawei and exabgp is not compatible

[thomas-mangin]

Hello @pubyun

Some other vendors also implement the old draft - so I am stuck and doomed to displease someone until the document reach RFC status ! :-(

Thomas

[pubyun]

can ExaBGP support two draft and have a option for it?

[thomas-mangin]

everything is possible but the realistic answer is not easily and I have no time to be able to start this work atm.

[Johnny0326]

@thomas-mangin Could you tell us where we can get the value of redirect ip of the config file in the code ? I want to try to make some changes to test the new draft https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-02 for example flow { route test { match { destination 100.0.80.2/32;

destination-port >8080&<8088 =3128;

        source-port >1024; 
        protocol tcp; 
        } 
        then {          
            **redirect 192.168.20.2;**
        } 
          }
    }

[thomas-mangin]

@Johnny0326 happy to help but .. I do not understand the question ..

[Johnny0326]

@thomas-mangin I want to know where can I get value of the parameter of redirect ip, then I can assign it into the BGP Extended Communities. In the draft https://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 the redirect IP is writed in the BGP Extended Communities.

[thomas-mangin]

@Johnny0326 I still do not understand. The parser create a Change object which contains the NLRI and attribute the value will be within that object. You will need to read the code and understand the class structure if you want to perform changes.

The difference between the draft and the implementation change is very small, but as I said, as long as no RFC is out, I do not intend to change the code, unless all large vendors have already updated their implementation to the latest version.

[sonixyznitesh]

@thomas-mangin (and others):

I know this thread is a year old but wanted to update with my observations as well:

We have run into similar issues with Juniper (vSRX) where it does not like the extended community type (0x0800) for redirect-to-ip flow spec too whereas Cisco seems to be happy :) and seems to support only the new community type

Looks like following clarifies the formatting of BGP FlowSpec Redirect Extended community:

https://tools.ietf.org/html/rfc7674

Would be good to know if ExaBGP would be able to support both in future versions.

Thanks

[sonixyznitesh]

@thomas-mangin

Any update on this one?

We are using ExaBGP v3.4.20 and it uses 'extended community type = 0x0800' for flow spec redirect-to-ip - this is causing juniper to reject the route with following error message:

"Extended Communities(16): Unsupported IANA community format:800:0:0:0:0:0:0"

Looks like Juniper expects community type 0x8108 which uses: 'Generic Transitive Experimental Use Extended Community Part 2 Sub-Types' 9 (sub type = 0x08)

To confuse the matter further, when I look at IANA assignments, I found following as well for FlowSpec IPv4/Ipv6 redirect to IP

• Transitive IPv4-Address-Specific Extended Community Sub-Types : 0x0c
• Transitive IPv6-Address-Specific Extended Community Types: 0x000c

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-ipv6

[thomas-mangin]

No RFC - no change in code in 3.4. to follow the principle of least surprise. However things may have changed enough to justify a change of code in 4.0

[elindsey]

Unfortunately I need to send flowspec redirect routes to Juniper gear, so I'll have to patch my exa to support the ietf draft.

Given the RFC (still ☹️) hasn't been finalized and there's now a vendor split between simpson, ietf, and both - is there interest in upstreaming that patchset behind a config flag, or do you want to hold off?

[thomas-mangin]

Yes, i would gratefully take this on.