iBGP problem with full meshed routers

[Martin Bosner]

Hello,

i'm a little desperate and helpless because i can't get any further with my
current problem:

My current setup (all same AS only physical):

router A   ----   router B --- router C ------- router E  --- router G
(has full                   \            |                    |
    |
 table uplink)             \          |                    |
     |
                                   \         |                    |
          |
                                        router D  ------- router F ---
router H

Router ABCD and router EFGH are each at the same location in a L2 network.
There are no additional static routing information but the one from the
interfaces and they are all connected via BGP using the same AS. All
routers can ping each other and no router has a default gw. All BGP
sessions are using the same table and are up and alive. All direct
connected routers have a "direct" connection and all non direct connected
routers use multihop.

The problem is that router G and router H only have invalid global routes
learned from router A while E and F are fine:
(using 223.230.128.0/22 is just a random pick for demonstration)


router G and H (PROBLEM):

BIRD SHOW ROUTE
birdc show route 223.230.128.0/22 all
BIRD 2.0.5 ready.
Table master4:
223.230.128.0/22     unreachable [routerG_to_routerA 03:15:02.410 from
153.92.124.4] * (100/-) [AS45609?]
Type: BGP univ
BGP.origin: Incomplete
BGP.as_path: 15943 9498 45609
BGP.next_hop: 153.92.124.4
BGP.local_pref: 100

KERNEL
route -n | grep 223.230.128.0
223.230.128.0   -               255.255.252.0   !     32     -        0 -

CONFIG
protocol bgp routerG_to_routerA{
  local as 60664;
  neighbor 153.92.124.4 as 60664;
  source address 185.27.180.133;
  enable route refresh yes;
  multihop;
  allow local as 60664;
  ipv4 {
          import all;
          export all;
          next hop self;
            };
}


router E and F (VALID):

BIRD SHOW ROUTE
birdc show route 223.230.128.0/22 all
BIRD 2.0.5 ready.
Table master4:
223.230.128.0/22     unicast [routerE_to_routerA 02:42:58.878 from
153.92.124.4] * (100/?) [AS45609?]
via 192.168.0.1 on external
Type: BGP univ
BGP.origin: Incomplete
BGP.as_path: 15943 9498 45609
BGP.next_hop: 153.92.124.4
BGP.local_pref: 100

KERNEL
route -n | grep 204.34.123.0
204.34.123.0    192.168.0.1     255.255.255.0   UG    32     0        0
external

CONFIG
protocol bgp routerE_to_routerA{
  local as 60664;
  neighbor 153.92.124.4 as 60664;
  source address 192.168.0.2;
  multihop;
  allow local as 60664;
  ipv4 {
          import all;
          export all;
          next hop self;
            };
}


router A

BIRD SHOW ROUTE
birdc show route 223.230.128.0/22 all
BIRD 2.0.5 ready.
Table master4:
223.230.128.0/22     unicast [routerA_to_external 23:01:24.661] * (100)
[AS45609?]
via 84.44.0.210 on xge1
Type: BGP univ
BGP.origin: Incomplete
BGP.as_path: 15943 9498 45609
BGP.next_hop: 84.44.0.210
BGP.local_pref: 100

KERNEL
route -n | grep 204.34.123.0
204.34.123.0    84.44.0.210    255.255.255.0   UG    32     0        0 xge1

CONFIG E (valid)
protocol bgp routerA_to_routerE{
  local as 60664;
  neighbor 153.92.124.2 as 60664;
  source address 153.92.124.4;
  direct;
  allow local as 60664;
  ipv4 {
          import all;
          export all;
          next hop self;
            };
}

CONFIG G (problem)
protocol bgp routerA_to_routerG{
  local as 60664;
  neighbor 185.27.180.133 as 60664;
  source address 153.92.124.4;
  multihop;
  allow local as 60664;
  ipv4 {
          import all;
          export all;
          gateway recursive;
          next hop self;
            };
}


I am using bird 2.0.5 and ubuntu 18.04 with 4.15.0-54-generic and already
played around with and without "next hop self"  etc. but without luck.

There seems to be a problem with my configuration or with the next hop
calculation, right? Or did i miss something else?

Thank you in advance
Martin Bosner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20190818/eaea0e3e/attachment.htm>