Rare project developers

[mc36 <>]

hi,

with the following changes, it seems to be not flooding, however, the mpolka 
path representation is still far from good...:(
https://github.com/rare-freertr/freeRtr/commit/62dfd075dd8a68e4a2800807cf15551185c5bc1e
i still could imagine paths that cannot be expressed right now, but at least, 
they will not flood.... :)

so for now, at least, it encodes a valid path (that have the bit0 set in 
somewhere) for both interfaces:

R1#show mpolka routeid tunnel1
iface      hop      routeid
ethernet3  1.1.1.2  00 00 00 00 00 00 00 00 00 00 00 00 80 02 80 01
ethernet2  4.4.4.2  00 00 00 00 00 00 00 00 00 00 00 00 40 03 40 0b

index  coeff     poly   crc    equal
0      00010000  32769  32769  true
1      00010001  3      3      true
2      00010003  4      4      true
3      00010005  1      1      true
4      00010009  55     55     true
5      0001000f  50     50     true
6      00010011  171    171    true
7      0001001b  152    152    true
8      0001001d  157    157    true
9      0001002b  608    608    true
0      00010000  16395  16395  true
1      00010001  8      8      true
2      00010003  32782  32782  true
3      00010005  1      1      true
4      00010009  2      2      true
5      0001000f  32779  32779  true
6      00010011  124    124    true
7      0001001b  32892  32892  true
8      0001001d  127    127    true
9      0001002b  33144  33144  true


and finally it pings

R1#ping 30.30.30.2 vrf v1
pinging 30.30.30.2, src=null, vrf=v1, cnt=5, len=64, tim=1000, gap=0, 
ttl=255, tos=0, sgt=0, flow=0, fill=0, sweep=false, multi=false
!!!!!
result=100%, recv/sent/lost/err=5/5/0/0, rtt min/avg/max/sum=0/0/1/3, ttl 
min/avg/max=252/252/252, tos min/avg/max=0/0/0
R1#ping 30.30.30.2 vrf v1 multi
pinging 30.30.30.2, src=null, vrf=v1, cnt=5, len=64, tim=111, gap=0, ttl=255, 
tos=0, sgt=0, flow=0, fill=0, sweep=false, multi=true
!!!!!!!!!!
result=200%, recv/sent/lost/err=10/5/0/0, rtt min/avg/max/sum=1/1/2/557, ttl 
min/avg/max=252/253/255, tos min/avg/max=0/0/0

and does not flood during doing so:

R1#clear counters
R1#ping 30.30.30.2 vrf v1 size 1111
pinging 30.30.30.2, src=null, vrf=v1, cnt=5, len=1111, tim=1000, gap=0, 
ttl=255, tos=0, sgt=0, flow=0, fill=0, sweep=false, multi=false
!!!!!
result=100%, recv/sent/lost/err=5/5/0/0, rtt min/avg/max/sum=0/1/2/5, ttl 
min/avg/max=252/252/255, tos min/avg/max=0/0/0
R1#show interfaces summary
interface  state  tx    rx     drop
template1  admin  0     0      0
loopback0  up     0     0      0
ethernet2  up     5665  11629  0
ethernet3  up     5665  5717   0
tunnel1    up     5565  0      0
tunnel10   down   0     0      29036
tunnel2    down   0     0      0
tunnel5    up     0     0      0

R1#

br,
cs




On 6/5/22 18:29, mc36 wrote:
> hi,
> so the reason is that the path on eth2 is badly encoded:
>
> R1#show mpolka routeid tunnel1
> iface           hop           routeid
> ethernet3   1.1.1.2   00 00 00 00 00 00 00 00 00 00 00 00 80 02 80 01
> ethernet2   4.4.4.2   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04   
> <------------
>
> index   coeff         poly     crc       equal
> 0           00010000   32769   32769   true
> 1           00010001   3           3           true
> 2           00010003   4           4           true
> 3           00010005   1           1           true
> 4           00010009   55         55         true
> 5           0001000f   50         50         true
> 6           00010011   171       171       true
> 7           0001001b   152       152       true
> 8           0001001d   157       157       true
> 9           0001002b   608       608       true
> 0           00010000   4           4           true   <------------
> 1           00010001   4           4           true   <------------
> 2           00010003   4           4           true   <------------
> 3           00010005   4           4           true   <------------
> 4           00010009   4           4           true   <------------
> 5           0001000f   4           4           true   <------------
> 6           00010011   4           4           true   <------------
> 7           0001001b   4           4           true   <------------
> 8           0001001d   4           4           true   <------------
> 9           0001002b   4           4           true   <------------
>
> R1#
>
> here for the first path over eth3, the path for index 3 the bit0 indicating 
> the end of processing,
> whereas on the path over eth2, the end marker is not encoded, and that's what 
> causes the infinite loop...
> in other words, that every node in the topology results in a computation of 
> 4, which is bit3, that is,
> the 2nd entry in the srindex table to forward the given packet:
>
> R1#show ipv4 srindex v1
> index   conn     prefix                 peers   bytes
> 1           false   ::/0                                   0
> 2           true     20.20.20.2/32   1 3       0
> 3           false   20.20.20.3/32   2 4       0
> 4           true     20.20.20.4/32   1 3       0
>
> R1#
>
> so r1 will send out to r2 who will get the packet and forward to r3, who will 
> forward to r4, who to r3 and so on...
>
> so for now, it clearly shows that the current routeid encoding plus the 
> calculation is cannot express the
> situation correctly because it does not consider r3 over eth2 because it's 
> through the other interface...
> i've no better idea for now is that once the calculation spots that no 
> endpoint was encoded, then i'll
> add the tunnel destination as an implicit endpoint (setting bit0 for that 
> node if nobody else got it)
>
> br,
> cs
>
>
>
> -------- Forwarded Message --------
> Subject:   Doubt mpolka tun
> Date:   Sun, 5 Jun 2022 12:04:32 -0300
> From:   Everson Borges <>
> To:   cs <>
>
>
>
> Hi Csaba
>
> Doubt about mpolka tunnel.
>
> Screen Shot 2022-06-05 at 11.45.59.png