migrating from quagga: frr bgp & pmacct --> Can not configure the local system as neighbor

[acoul]

FRR VERSION: 8.1.0 OPERATING SYSTEM VERSION: Gentoo rolling latest default/linux/x86/17.0 (stable) KERNEL VERSION: 5.15.5-gentoo

Greetings,

this is NOT a bug, rather than an issue

I am in the process of migrating the quagga bgpd to the frr bgpd.

I am locally using pmacct as a BGP collector (import only) on the same server running bgpd

with quagga bgpd, this process was working fine

on frr, after loading bgpd, I get the following error: Can not configure the local system as neighbor

        if (peer_address_self_check(bgp, &su)) {
            vty_out(vty,
                "%% Can not configure the local system as neighbor\n");
            return CMD_WARNING_CONFIG_FAILED;
        }

here is the relative information on pmacct: BGP neighbor over localhost via Quagga

if configuring a BGP neighbor over localhost via Quagga CLI the following
message is returned: "% Can not configure the local system as neighbor". This
is not returned when configuring the neighborship directly in the bgpd config
file.

the configuration:

Current configuration:
!
frr version 8.1-gentoo
frr defaults traditional
hostname orion
log file /tmp/bgpd.log
no ipv6 forwarding
hostname quagga-orion
service integrated-vtysh-config
!
router bgp 3298
 bgp router-id 10.2.19.1
 bgp cluster-id 10.2.19.0
 bgp deterministic-med
 bgp bestpath as-path multipath-relax
 bgp bestpath compare-routerid
 neighbor reflect peer-group
 neighbor reflect remote-as 3298
 neighbor reflect timers 10 30
 neighbor reflect capability dynamic
 neighbor 10.2.19.6 peer-group reflect
 neighbor 10.2.19.7 peer-group reflect
 neighbor 10.2.19.8 peer-group reflect
 neighbor 10.2.19.9 peer-group reflect
 neighbor 10.2.19.11 peer-group reflect
 neighbor 10.2.19.12 peer-group reflect
 neighbor 10.2.19.14 peer-group reflect
 neighbor 10.2.19.15 peer-group reflect
 neighbor 10.2.19.3 remote-as 3298
 neighbor 10.2.19.3 capability dynamic
 neighbor 10.2.146.10 remote-as 22128
 neighbor 10.2.146.10 ebgp-multihop 255
 neighbor 192.168.1.69 remote-as 3298
 neighbor 192.168.1.69 port 17917
 !
 address-family ipv4 unicast
  network 10.1.100.0/24
  network 10.2.10.0/24
  network 10.2.19.0/24
  aggregate-address 10.2.10.0/24 summary-only
  aggregate-address 10.2.19.0/24 summary-only
  redistribute connected
  redistribute static
  neighbor reflect capability orf prefix-list both
  neighbor reflect route-reflector-client
  neighbor reflect soft-reconfiguration inbound
  neighbor reflect prefix-list awmn-bgp in
  neighbor reflect prefix-list awmn-bgp out
  neighbor reflect filter-list maxaslength out
  neighbor 10.2.19.3 capability orf prefix-list both
  neighbor 10.2.19.3 route-reflector-client
  neighbor 10.2.19.3 prefix-list awmn-null in
  neighbor 10.2.146.10 prefix-list awmn-null in
  neighbor 10.2.146.10 prefix-list awmn-bgp out
  neighbor 192.168.1.69 route-reflector-client
  neighbor 192.168.1.69 prefix-list awmn-null in
 exit-address-family
exit

and the error when loading frr:

 * Starting FRR ...
line 253: Failure to communicate[13] to bgpd, line: neighbor 192.168.1.66 remote-as 3298

line 254: Failure to communicate[13] to bgpd, line: neighbor 192.168.1.66 port 17917

line 255: Failure to communicate[13] to bgpd, line: neighbor 192.168.1.66 update-source 192.168.1.66

line 256: Failure to communicate[13] to bgpd, line: neighbor 192.168.1.66 route-reflector-client

line 257: Failure to communicate[13] to bgpd, line: neighbor 192.168.1.66 prefix-list awmn-null in

Configuration file[/etc/frr/frr.conf] processing failure: 13  

is there a possible workaround for this ?

Edit: FWIW I was able to overcome this issue using redir on a different server on the same lan.

redir 192.168.1.10:17917 192.168.1.66:17917

[riw777]

We don't allow bgp to peer with itself on the same device because we only allow one bgp process on the device, and a bgp speaker peering with itself produces some odd semantics, including the possibility of routing loops. What pmacct appears to be doing is acting as a second bgp speaker on the same device--something we normally wouldn't see.

The problem with allowing peering to the same device for pmacct is that we would then be allowing a standard bgp speaker to peer to itself ... which isn't a good idea. So ... two options.

Someone could code up an "exception" for pmacct in the FRR code. I think this would require a test of some kind so the local bgp speaker can "know" a potential peer on the same device isn't really a peer, but rather just a passive receiver. Adding some kind of local capability might work here--but it would make the peering code a bit more complex.

Another solution might be for pmacct to always run in its own namespace, container, or something similar? I'm not quite certain how this can be configured, etc., but it might be an option.

[mjstapp]

@frrbot autoclose in 5 days

[frrbot[bot]]

This issue will be automatically closed in the specified period unless there is further activity.

[acoul]

thank you Russ for your feedback on this issue.

IMHO this feels more like a feature restriction rather than a protection mechanism, assuming one knows what he is doing/configuring.

another fine tool that comes to mind that may well be running on the same server/router as FRR is ExaBGP

Edit: FWIW using the attached patch I was able to regain the lost quagga functionality I was having before the migration to FRR nuke_local_check-patch.txt .

[frrbot[bot]]

This issue will no longer be automatically closed.