Giters

facebook / openr

Distributed platform for building autonomic network functions.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

multi-area route redistribution sets incorrect routes on one area

martynas-gryb opened this issue · comments

commented

Topology:


+------------------------+                      +---------------------------+
|                        |      Area "1" link   |                           |
| Node: First_00abcdef   |                      |  Node: Second_1234567890  |
| Namespace: n1          |Veth0          Veth0  +  Namespace: n2            |
| areas: "1"             +----------------------+  areas: "1", "2"          |
|                        |                      |                           |
|                        |                      |                           |
+------------------------+                      +-----------+---------------+
                                                            | veth1
                                             Area "2" link  |
                                                            |
                                                            |Veth0
                                                +-------------------------+
                                                |                         |
                                                | Node: Third_ab1234fefe  |
                                                | Namespace: n3           |
                                                | areas: "2"              |
                                                |                         |
                                                +-------------------------+

tested with:
ubuntu 20.04 with linux namespaces (kernel 5.4)
OpenR 2021-01-16 (d76157f)

#to recreate issue:
openr-multi-area.zip
to setup unzip files and :
sudo ./multi-area-openr.sh
will create 3 namespaces with OpenR instance each.

#to destroy setup
sudo ./multi-area-openr.sh stop

What's the actual result?

First node on n1 receives routes from Third node on n3 namespace. Which are in different areas.
fdfd:2:3:1::/64 via fe80::b801:49ff:fe41:5b7f dev veth0 proto 99 metric 10 pref medium
First node doesn't receive route from Second node on n2.
First node cant ping node n2 but can ping n3 via n2:

# ping fdfd:2:2::1
ping: connect: Network is unreachable
# ping fdfd:2:3::1
PING fdfd:2:3::1(fdfd:2:3::1) 56 data bytes
64 bytes from fdfd:2:3::1: icmp_seq=1 ttl=63 time=0.125 ms

Adjacencies and peers seem to be formed correctly, but the n1 received route from n3 and it is advertised as area 1 route

> Prefix: fdfd:2:3:1::/64
  via fe80::b801:49ff:fe41:5b7f dev veth0 weight 0 metric 1 area 1

Second node on n2 receives routes from both areas correctly:

# ip -6 r | grep /56
fdfd:1:1::/56 via fe80::e48e:64ff:fe4a:6205 dev veth0 proto 99 metric 10 pref medium
fdfd:2:3::/56 via fe80::c0f9:c0ff:feca:d7e7 dev veth1 proto 99 metric 10 pref medium

Third node on n3 can ping both n1 and n2

notes:

  • when changing the order of areas in n2.conf we can switch the the effect from n1 to n3 so that implies that the first area in area list is the main one, other is semi-working.
commented

Thanks for reporting. Internal SWEs are digging into this one and reproducing with our internal unit tests + Emulation CI.

commented

Thanks for bringing this to attention. We've identified the root-cause and addressed the fix. Once fix goes through internal code review, it'll be on Github for you to pull.

commented

This issue should be resolved by commit ad0e936.

Please try and let us know! Thanks for reporting.

commented

Thanks for the quick fix. Seem to work on my setup also.