Rare project developers

[David Schmitz <>]

Hi Frederic,

(answer is a bit longer, sorry)

On Mon, 6 Feb 2023, Frédéric LOUI wrote:

> Date: Mon, 6 Feb 2023 17:00:15 +0100
> From: Frédéric LOUI <>
> Reply-To: 
> To: 
> Subject: Re: [rare-dev] netconf
>
> Hi David,
>
> Quick question. With yang-cli you are now able to check freeRouter config in 
> Yang/xml form
Yes, now yangcli can query at least something of the config in freerouter.
Now, we have to see how this can be suitable for current FoD's netconf parser.

I am still trying to investigate how policy-map etc and BGP flow spec 
(e.g. "show ipv4 bgp 1 flowspec database") actually relate.

> I presume you plan to have « SET » operation (for policy-map / BGP flowspec ) do 
> have tested these already or you think that « exec/SET" should be added ?

1.
Just, a little summary how FoD currently uses NETFLOW 
(JUNOS-specific YANG models for FlowSpec):

FoD, currently mostly uses a "REPLACE" operation for pushing
a new BGP FlowSpec route or updating an existing BGP FlowSpec route
to a router.
Of course, also DELETE operation to remove FlowSpec route.
Along this, FoD maintains his own view of the FlowSpec routes which 
should be on the router in its local data base.

In order to discover mismatches 
between FoD view and the routers view of the FlowSpec routes,
FoD from time to time will query
the router's view of the BGP FlowSpec routes which are installed on it
with GET. 
This is done infrequently, e.g. once a day, depending on
the FoD configuration.

This is current mode and we have to see how I can adapt it
if needed to make freerouter and FoD make to cooperate.

2. Here is more detail on the currently expected JunOS-specific
NETCONF XML response from the router to a GET query by FoD,
i.e., when FoD queries the router for the router's view on
the BGP FlowSpec rules installed on it
("real" data, not from a real router,
but from a 'netconfd' in a virtual container connected to FoD
which already installed some BGP FlowSpec rules on the netconfd):

<?xml version="1.0" encoding="UTF-8"?><data 
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    <configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm";>
      <routing-options>
        <rib>
          <name>inet6.0</name>
          <flow>
            <route>
              <name>FoD_testingLiveStatus_DO53VC</name>
              <then>
                <discard/>
              </then>
              <match>
                <protocol>tcp</protocol>
                <destination-port>12</destination-port>
                <destination-port>100-200</destination-port>
                <source-port>10-20</source-port>
                <source-port>30-40</source-port>
                <source-port>89</source-port>
                <fragment>is-fragment</fragment>
                <fragment>first-fragment</fragment>
                <destination>
                  <prefix>2001:798:3::/64</prefix>
                </destination>
                <source>
                  <prefix>::/10</prefix>
                </source>
              </match>
            </route>
            <route>
              <name>FoD_testingLiveStatus_W7ILXI</name>
              <then>
                <rate-limit>1000k</rate-limit>
              </then>
              <match>
                <destination>
                  <prefix>80::/62</prefix>
                </destination>
                <source>
                  <prefix>81::/60</prefix>
                </source>
              </match>
            </route>
          </flow>
        </rib>
        <flow>
          <route>
            <name>testrule1_XDCKLA</name>
            <then>
              <rate-limit>10000k</rate-limit>
            </then>
            <match>
              <protocol>icmp</protocol>
              <fragment>dont-fragment</fragment>
              <destination>10.0.0.1/32</destination>
              <source>10.0.0.2/32</source>
            </match>
          </route>
          <route>
            <name>testrule1_OULVIZ</name>
            <then>
              <rate-limit>100k</rate-limit>
            </then>
            <match>
              <protocol>tcp</protocol>
              <protocol>udp</protocol>
              <destination-port>12</destination-port>
              <destination-port>18-30</destination-port>
              <source-port>100-200</source-port>
              <source-port>300-400</source-port>
              <fragment>is-fragment</fragment>
              <fragment>last-fragment</fragment>
              <destination>10.0.0.2/32</destination>
              <source>10.0.0.1/32</source>
            </match>
          </route>
          <route>
            <name>testrule1_FRN9GG</name>
            <then>
              <discard/>
            </then>
            <match>
              <protocol>udp</protocol>
              <destination-port>17</destination-port>
              <source-port>1000-2000</source-port>
              <fragment>last-fragment</fragment>
              <destination>10.0.0.2/32</destination>
              <source>15.1.0.0/16</source>
            </match>
          </route>
        </flow>
      </routing-options>
    </configuration>
  </data>

(compare stripped down YANG model from the JUNOS router:
https://github.com/GEANT/FOD/blob/python3/router-container/configuration.yang 
,
which is used in the container with netconfd:
"netconfd --module configuration --superuser=netconf --log-level=info")

--

This example covers both, 
IPv4 FlowSpec rules, which FoD supports since its beginnings,
and IPv6 FlowSpec rules, which are new to FoD since last year.
Both, use different YANG models unfortunately, as you can see above.

The rules above, also show you the variety of how a FlowSpec rule can look 
like
as supported by FoD:
basically "match" and "then" as defined in the FlowSpec part
+ a unique name which identifies the rule on the router.
This name is essential, currently, as it 
is used in FoD's data base to keep track of the rule,
e.g., when used in a REPLACE operation to update or in a DELETE operation
or when finding mismatches between FoD's view and the router's view
of the FlowSpec routes.
In the latter case, FoD will never "import" routes from the router
with names, which have not a counter part in his own view, i.e., its FoD data 
base.
It will only update in its own view (in its data base) the status of FlowSpec 
route
(basically ACTIVE or INACTIVE, ACTIVE meaning its is on the router).

3.
Before, we added support for IPv6 rules last year the 
NETCONF/YANG-related configuration in FoD looked like this:

# for GET:
ROUTES_FILTER = 
"<configuration><routing-options><flow/></routing-options></configuration>"

# for REPLACE/DELETE:
ROUTE_FILTER = 
"<configuration><routing-options><flow><route><name>%s</name></route></flow></routing-options></configuration>"

Since, last year, in order to support IPv6 its is more complex now:

# for GET
ROUTES_FILTER = 
"<configuration><routing-options><rib><name>inet6.0</name><flow/></rib><flow/></routing-options></configuration>"

# for REPLACE/DELETE:
ROUTE_FILTER = 
"<configuration><routing-options><rib><name>inet6.0</name><flow><route><name>%s</name></route></flow></rib><flow><route><name>%s</name></route></flow></routing-options></configuration>"

So, the XML containers elements,
where in the configuration FoD expects the specification of a BGP FlowSpec to reside in, 
are configurable, 
but the actual XML form of such a specification of match+then 
(compare the examples above)
FoD currently expects is not.

> Do you have everything at hand in order to move forward ?

Now, we have to see what is possible achieve in freerouter, e.g., with 
appropriate SENSOR configuration,
or what has to be adapted on either side, FoD or/and freerouter,
what ever has the least combined effort to make.


Best Regards
David

> All the best,
> Frederic
>
> > Le 6 févr. 2023 à 16:27, David Schmitz <> a écrit :
> >
> > Hi,
> >
> > On Sat, 4 Feb 2023, mc36 wrote:
> >
> > > Date: Sat, 4 Feb 2023 10:55:07 +0100
> > > From: mc36 <>
> > > Reply-To: 
> > > To: , David Schmitz <>
> > > Subject: Re: [rare-dev] netconf
> > > some more hacking, now it seems better indented in firefox... :)
> > > https://github.com/rare-freertr/freeRtr/commit/db7b32db4c01b76507b16f28590562ce34dbb40d
> > >
> > > sid#show running-config interface loopback0 | xml
> > > <config><interface><loopback0>
> > > </loopback0></interface>
> > > <interface><loopback0><description><management>
> > > </management></description>
> > > <vrf><forwarding><v1>
> > > </v1></forwarding></vrf>
> > > <ipv4><address><identifier-value>10.10.10.227
> > > <identifier-value>255.255.255.255
> > >
> > > </identifier-value></identifier-value></address></ipv4>
> > > <ipv6><address><identifier-value>2001:db8:1101::227:227
> > > <ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff>
> > > </ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff></identifier-value></address></ipv6>
> > > <template><template1>
> > > </template1></template>
> > > <no><shutdown>
> > > </shutdown></no>
> > > </loopback0></interface></config>
> > Great!
> >
> > Best Regards
> > David
> >
> > > sid#
> > >
> > >
> > > On 2/4/23 09:50, mc36 wrote:
> > > > hi,
> > > > to ease debugging this, 
> > > > https://github.com/rare-freertr/freeRtr/commit/4d5c20e2bad3f91c119603ae2783942b84d11830
> > > >  added a new filter to xml-ize the show outputs... :)
> > > > br,
> > > > cs
> > > > sid#show running-config interface loopback0 | xml
> > > > <config><interface><loopback0>
> > > > </loopback0></interface>
> > > > <description><management>
> > > > </management></description>
> > > > <vrf><forwarding><v1>
> > > > </v1></forwarding></vrf>
> > > > <ipv4><address><identifier-value>10.10.10.227
> > > > <identifier-value>255.255.255.255
> > > > </identifier-value></identifier-value></address></ipv4>
> > > > <ipv6><address><identifier-value>2001:db8:1101::227:227
> > > > <ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff>
> > > > </ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff></identifier-value></address></ipv6>
> > > > <template><template1>
> > > > </template1></template>
> > > > <no><shutdown>
> > > > </shutdown></no>
> > > > <identifier-value>!
> > > > </identifier-value>
> > > > </config>
> > > > sid#show running-config interface loopback0 | setdel
> > > > set interface loopback0
> > > > set interface loopback0 description management
> > > > set interface loopback0 vrf forwarding v1
> > > > set interface loopback0 ipv4 address 10.10.10.227 255.255.255.255
> > > > set interface loopback0 ipv6 address 2001:db8:1101::227:227 
> > > > ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
> > > > set interface loopback0 template template1
> > > > delete interface loopback0 shutdown
> > > > set interface loopback0 exit
> > > > set !
> > > > sid#show running-config interface loopback0
> > > > interface loopback0
> > > >   description management
> > > >   vrf forwarding v1
> > > >   ipv4 address 10.10.10.227 255.255.255.255
> > > >   ipv6 address 2001:db8:1101::227:227 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
> > > >   template template1
> > > >   no shutdown
> > > >   exit
> > > > !
> > > > sid#
> > > > On 2/4/23 08:49, mc36 wrote:
> > > > > hi,
> > > > > with 
> > > > > https://github.com/rare-freertr/freeRtr/commit/aa0bb8a11a6bc4d5bd3f2c228ae36e5f926214f2
> > > > > now yangcli accepts the config, at least partially... see attached the 
> > > > > document i sent it...
> > > > > br,
> > > > > cs
> > > > > yangcli > get-config source=running
> > > > > Warning: 'data' has no child node 'config'. Using anyxml
> > > > > Warning: 'data' has no child node 'rpc-reply'. Using anyxml
> > > > > Warning: 'rpc-reply' has no child node 'rpc-reply'. Using anyxml
> > > > > mgr_rpc: got invalid reply on session 1 (wrong node depth)
> > > > > RPC Data Reply 1 for session 399134541:
> > > > > rpc-reply {
> > > > >     data {
> > > > >         config {
> > > > >             hostname {
> > > > >                 netconf
> > > > >             }
> > > > >             buggy
> > > > >             no {
> > > > >                 password-encrypt
> > > > >             }
> > > > >             no {
> > > > >                 enable
> > > > >             }
> > > > >             banner {
> > > > >                 encoded
> > > > >             }
> > > > >             identifier-value !
> > > > >             client {
> > > > >                 label-range {
> > > > >                     identifier-value 32
> > > > >                 }
> > > > >             }
> > > > >         }
> > > > >         rpc-reply
> > > > >     }
> > > > >     rpc-reply
> > > > > }
> > > > > yangcli >
> > > > > On 2/3/23 16:56, mc36 wrote:
> > > > > > hi,
> > > > > > with this 
> > > > > > https://github.com/rare-freertr/freeRtr/commit/b604046291beb58d3f04079364f859edd2f57fec
> > > > > > i get now a different error message... maybe it's just my config, could you 
> > > > > > please give it a try?
> > > > > > yangcli > get-config source=running
> > > > > > mgr_top: get node failed (xml reader EOF); session dropped
> > > > > > yangcli>
> > > > > > the latest jar is at src.freertr.org/src/rtr.jar
> > > > > > thx,
> > > > > > cs
> > > > > > On 2/3/23 16:21, David Schmitz wrote:
> > > > > > > Hi,
> > > > > > > On Fri, 3 Feb 2023, mc36 wrote:
> > > > > > > > Date: Fri, 3 Feb 2023 16:18:45 +0100
> > > > > > > > From: mc36 <>
> > > > > > > > Reply-To: 
> > > > > > > > To: David Schmitz <>
> > > > > > > > Cc: "" <>
> > > > > > > > Subject: [rare-dev] netconf
> > > > > > > > hi,
> > > > > > > > i tried to bring up your environment but i found too many missing parts from 
> > > > > > > > freerouter netconf...
> > > > > > > > right now, only these are implemented: 
> > > > > > > > https://github.com/rare-freertr/freeRtr/blob/master/src/net/freertr/user/userNetconf.java#L29
> > > > > > > > this is all what i needed to bring up 
> > > > > > > > https://github.com/CiscoDevNet/yang-explorer in a vm and query/configure...
> > > > > > > > but when you issue sget-config / source=running in yangcli see that it tries 
> > > > > > > > to access the /?xml/rpc/get-config/source/running
> > > > > > > > which is not there yet... so the question is, how you spawn your yangcli and 
> > > > > > > > what command do you try to execute there?
> > > > > > > "get-config source=running" would be enough.
> > > > > > > "sget-config source=running" is not needed.
> > > > > > > Best Regards
> > > > > > > David
> > > > > > > > thx,
> > > > > > > > cs
> >
> > --
> >
> > David Schmitz
> >
> > Boltzmannstrasse 1, 85748 Garching
> > Telefon:   +49 89 35831-8765
> > Leibniz-Rechenzentrum, Germany
> > Mail:  

--

David Schmitz

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