-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Traffic seems to break when it has to go between FRRs #17651
Comments
can we get the output of show zebra? |
Please see below from FRR1. _OS Linux(6.1.0-27-amd64)
VRF Installs Removals Updates Installs Removals |
and a show ip route |
Is there anything in particular you want to see from there? I only ask as there are thousands of routes |
Is anyone able to assist here, please? |
Description
Current setup overview:
I am hoping that I am asking this in the right place.
The current problem I am having is that when traffic has to route via one FRR to the next FRR to get to its destination it seems to break. For example if I attempt to SSH into FRR1 and the route it takes is via FRR2, I can't connect to FRR1. I can see the messages on a TCPDump on both FRRs but it never negotiates. I can also never SSH into FRR2 as the route it takes always ends up going via FRR1 first. If I disable one of the FRRs I can get to the other one perfectly fine.
Each FRR has 3 interfaces:
FRR config is below. Both FRRs are the same except with different router IDs and hostnames:
frr version 8.4.4
frr defaults traditional
hostname FRR1
service integrated-vtysh-config
log file /var/log/frr/ospfd.log debugging
!
interface ens18
ip ospf message-digest-key 1 md5 *****
ip ospf area 0.0.0.0
ipv6 ospf6 area 0.0.0.0
exit
!
interface ens20
ip ospf area 0.0.0.0
ip ospf passive
ipv6 ospf6 area 0.0.0.0
ipv6 ospf6 passive
exit
!
router ospf
ospf router-id 195.a.a.a
area 0.0.0.0 authentication message-digest
exit
!
router ospf6
ospf6 router-id 195.a.a.a
exit
!
The VMs are hosted on Proxmox and I am using their built-in SDN VXLAN facility for the 10.a.a.a and 149.a.a.a subnets.
I have checked the routing table and both FRRs use their connected route to the 149.a.a.a subnet.
Version
How to reproduce
Attempt to get to a destination that has to route via two FRRs to get there.
Expected behavior
I can reach any VM regardless of what route is being taken.
Actual behavior
See above.
Additional context
No response
Checklist
The text was updated successfully, but these errors were encountered: