RARE user and assistance email list

["David Schmitz" <>]

Hi Csaba,

On Tue, 6 Jun 2023, mc36 wrote:

> Date: Tue, 6 Jun 2023 16:34:08 +0200
> From: mc36 <>
> Reply-To: , 
> To: David Schmitz <>, 
> Subject: Re: [freertr] Issues with actual FlowSpec filtering,
>     especially for rules announced via exabgp (fwd)
>
> a raw guess, have u tried cle ipv4 bgp 1 recompute instead of adding exabgp?
That was indeed missing.
That fixes the issues of local rules (via conf policy-map/access-list)
not to be installed.

Thanks for that.


It has the little disadvantage that it resets the counters of all rules,
but that is something we can address later on the long-term.

> at the moment acls are not directly binded/linked/etc to the bgp just to the 
> icmp cores,
Ok.

> so this or wait an bgp update interval is my guesss...
Waiting did not help, as far as I have experienced.

> seeking 4 your results,

Best Regards
David

> thx,
>
> cs
>
> On 6/6/23 16:28, David Schmitz wrote:
> > Hi,
> >
> > I still have some issues with the actual mitigation via Flowspec rules in 
> > freertr.
> >
> > Probably I am missing something.
> >
> >
> > To explain the issues and to allow to reproduce them,
> > find attached a simple test case to demonstrate and reproduce the issues.
> > (java -Xmx1024m -jar /rtr/rtr.jar   test tester rtr-ddos1 path ./ temp ./ 
> > wait)
> >
> > It consists of 3 routers: rtr1, host1, and host2.
> > rtr1 is supposed to perform the FlowSpec filtering of traffic between host1 
> > and host2.
> >
> > rtr1#show version freeRouter-rare v23.6.6-cur, done by .
> >
> >
> > interesting part of the config for rtr1 is:
> >
> > router bgp4 1
> > ...
> >    address-family unicast flowspec
> >    flowspec-install
> >    flowspec-advert flowspec-pmap"
> >
> > policy-map flowspec-pmap
> >    sequence 10 action drop
> >    sequence 10 match access-group flowspec-rules
> >    !
> >    exit
> >
> > access-list flowspec-rules
> >    sequence 50 permit 1 10.1.10.1 255.255.255.255 all 10.2.10.2 
> > 255.255.255.255 all
> >    exit
> >
> > -
> >
> > The different issues I am experiencing based on this test case are 
> > demonstrated in 3 steps:
> >
> > step 1)
> >
> > As can be seen above,
> > the access-list "flowspec-rules" for policy-map "flowspec-pmap" defined by 
> > local config on rtr1 contains an initial rule: to block icmp traffic from 
> > 10.1.10.1 (host1) to 10.2.10.2 (host2).
> >
> > So, when the freertr test case rtr-ddos1.tst starts up, the filter rule
> > is installed as expected and actually also filterting the traffic 
> > correctly.
> > It is also nicely shown with "show policy-map flowspec":
> >
> > host2# ping 10.1.10.1 vrf CORE
> > ...
> >
> > rtr1# show policy-map flowspec CORE ipv4
> > seq   chld   queue   intrvl   byt/int   rxb     rxp   trnsmt ace
> > 1       0         0/128   100         0               192     3 
> > tx=0(0) rx=0(0) drp=192(3) 1-1 10.1.10.1 
> > ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all 10.2.10.2 
> > ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all
> > 2       0         0/128   100         0               5863   118 
> > tx=5863(118) rx=0(0) drp=0(0)
> >
> >
> > But, if now the filter rule is removed by changing the config, this has no 
> > immediate effect on the "policy-map flowspec"
> > and the icmp traffic from host2 to host1 continues to being filtered:
> >
> > rtr1# conf t
> > rtr1# access-list flowspec-rules
> > rtr1# no sequence 50 permit 1 10.1.10.1 255.255.255.255 all 10.2.10.2 
> > 255.255.255.255 all
> > rtr1# do wr
> >
> > rtr1# show policy-map flowspec CORE ipv4
> > seq   chld   queue   intrvl   byt/int   rxb     rxp   trnsmt ace
> > 1       0         0/128   100         0               448     7 
> > tx=0(0) rx=0(0) drp=448(7) 1-1 10.1.10.1 
> > ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all 10.2.10.2 
> > ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff all
> > 2       0         0/128   100         0               6357   127 
> > tx=6357(127) rx=0(0) drp=0(0)
> >
> > Am I maybe missing something here?
> >
> >
> > step 2) add exabgp peering
> >
> > Now, the test case can be extended by using exabgp:
> >
> > In addition to starting the freertr test case (java -Xmx1024m -jar 
> > /rtr/rtr.jar test tester rtr-ddos1 path ./ temp ./ wait),
> > some manual additional commands are executed to start exabgp:
> >
> > # start process for tap1 interface manually   (connected to interface 
> > ethernet3 of rtr1)
> > /rtr/tapInt.bin tap1 38200 127.0.0.1 38100 127.0.0.1 # running in 
> > foreground
> >
> > # on another terminal:
> > ifconfig tap1 10.3.10.3/24
> >
> > # to install exabgp: e.g. : apt-get install exabgp
> > # start exabgp: will BGP connect to rtr1 (10.3.10.10 on eth3) as 10.3.10.3 
> > (on tap1)
> > exabgp --debug ./rtr-ddos1-exabgp1.conf
> >
> > Interestingly, as soon as the peering between exabgp and rtr1 is working, 
> > the rule "sequence 50 permit 1 10.1.10.1 255.255.255.255 all 10.2.10.2 
> > 255.255.255.255 all"
> > already above having been deleted from the "flowspec-rules"
> > without formerly having an effect on "policy-map flowspec" listing,
> > is now immediately gone from "policy-map flowspec":
> >
> > rtr1# show policy-map flowspec CORE ipv4
> > seq   chld   queue   intrvl   byt/int   rxb     rxp   trnsmt ace
> > 1       0         0/128   100         0               6357   127 
> > tx=6357(127) rx=0(0) drp=0(0)
> >
> > So, the change in the BGP connection status seems to cause an update of the 
> > "policy-map flowspec".
> >
> >
> > step 3) announce rule via exabgp
> >
> > Going on, let's dispatch a FlowSpec rule from exabgp to rtr1 via BGP:
> >
> > # example to announce a rule (same as in step 1) by local exabgp, exabgpcli 
> > announce flow route source-ipv4 10.1.10.1/32 destination-ipv4 10.2.10.2/32 
> > protocol =icmp
> >
> > # for verification: show rules currently announced by local exabgp
> > exabgpcli show adj-rib out
> >
> > The new rule announced is spread to rtr1, as shown in "show policy-map 
> > flowspec".
> > But the icmp traffic from host1 (10.1.10.1) to host2 (10.2.10.2) is not 
> > blocked at all,
> > which is also reflected in the drop counter staying at zero.
> >
> >
> > I also tried to further extend the scenario by adding another tap2 
> > interface for rtr1 router and attaching an extra instance of exabgp peering 
> > with rtr1.
> > But with no success. Basically same issue, rules announced by exabgp are 
> > immediately listed under dynamic policy-map flowspec, but do not drop the 
> > traffic as expected. And unfortunately restarting the second exabgp 
> > instance in order to cause a bgp connection status within rtr1 do not help 
> > to remedy the situation unlike it helped at step 2 for locally emitted 
> > rules via policy-map/access-list defined by local config.
> >
> > --
> >
> > To sum it up:
> > - locally deleted rules (via policy-map/access-list defined in config) do 
> > not show up immediately after config change,
> > but only after a change of connection status of some BGP peering
> > (same seems to be happening with adding rules added via local 
> > policy-map/access-list)
> >
> > - FlowSpec rules added via a peering of exabgp show up immediately in the 
> > dynamic "policy-map flowspec", but do not actually drop the traffic as 
> > expected.
> >
> >
> > What am I missing in the BGP config or somewhere else?
> >
> >
> > Thanks in Advance.
> >
> >
> > Best Regards
> > David

--

David Schmitz

Boltzmannstrasse 1, 85748 Garching
Telefon:   +49 89 35831-8765
Leibniz-Rechenzentrum, Germany
Mail:  




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#1379): https://groups.io/g/freertr/message/1379
Mute This Topic: https://groups.io/mt/99364239/6413194
Group Owner: 
Unsubscribe: https://groups.io/g/freertr/unsub []
-=-=-=-=-=-=-=-=-=-=-=-