Rare project developers

[mc36 <>]

hi,
forgot to attach the single-pc version of your topology...
(the rtr-hw.txt was created to mimick your physical topology)
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

Attachment: zzz.zip
Description: Zip archive