2nd neighborship request has been rejected #15132
Replies: 2 comments 2 replies
-
Can you check with the latest version 9.1? |
Beta Was this translation helpful? Give feedback.
1 reply
-
This is not a bug. BGP interface based peering is only intended for point to point links not ethernet segments. While it is a desirable feature someone would have to develop this to make it work. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I see a strange issue, I have 3 frr instances running on 3 different machines connected via uplink switch (belong to same vlan).
FRR1 ----|
FRR2 ----| Uplink switch
FRR3 ----|
Running-config:
!
frr version 8.3.1
frr defaults traditional
hostname
log file /var/log/frr/frr.log
log timestamp precision 3
!
debug bfd peer
!
router bgp 64999
bgp router-id 9.9.9.13
bgp log-neighbor-changes
no bgp ebgp-requires-policy
no bgp suppress-duplicates
no bgp hard-administrative-reset
no bgp default ipv4-unicast
bgp graceful-shutdown
no bgp graceful-restart notification
no bgp network import-check
neighbor uplink peer-group
neighbor uplink remote-as internal
neighbor uplink bfd
neighbor uplink ttl-security hops 1
neighbor eno1 interface peer-group uplink
!
address-family ipv4 unicast
redistribute connected
neighbor uplink activate
neighbor uplink allowas-in origin
neighbor uplink prefix-list only-host-prefixes out
import vrf bgp-vrf
exit-address-family
!
address-family ipv6 unicast
redistribute connected
neighbor uplink activate
neighbor uplink allowas-in origin
neighbor uplink prefix-list only-host-prefixes out
import vrf bgp-vrf
exit-address-family
exit
!
router bgp 64999 vrf bgp-vrf
bgp router-id 9.9.9.13
no bgp ebgp-requires-policy
no bgp suppress-duplicates
no bgp hard-administrative-reset
no bgp graceful-restart notification
no bgp network import-check
!
address-family ipv4 unicast
redistribute connected
exit-address-family
!
address-family ipv6 unicast
redistribute connected
exit-address-family
exit
!
ip prefix-list only-default seq 5 permit 0.0.0.0/0
ip prefix-list only-host-prefixes seq 5 permit 0.0.0.0/0 ge 32
!
ipv6 prefix-list only-default seq 5 permit ::/0
ipv6 prefix-list only-host-prefixes seq 5 permit ::/0 ge 128
!
route-map rm-only-default permit 10
match ip address prefix-list only-default
set src 9.9.9.13
exit
!
route-map rm-only-default permit 11
match ipv6 address prefix-list only-default
set src 9.9.9.13
exit
!
ip nht resolve-via-default
!
ip protocol bgp route-map rm-only-default
!
ipv6 protocol bgp route-map rm-only-default
!
bfd
profile tripleo
exit
!
exit
!
end
All FRR instance have same running-config.
Problem here is, FRR1 can establish the bgp session either with FRR2 or FRR3, but not with both. Same behavior observed with FRR2 or FRR3 as well.
I see below in log for non connecting FRR instance.
2024/01/11 09:06:44.845 BGP: [TBYZV-W9M3D] [Event] fe80::2cb:5d26:dfc6:9a5f connection rejected(VRF default:64999:default) - not configured and not valid for dynamic
Something similar has been reported and fixed here #8644
And the version i am using should have that fix.
Can anyone help me what might be going wrong here?
Thanks
-Haresh
Beta Was this translation helpful? Give feedback.
All reactions