Implementations of SDN Networking

spirit said:
ok telnet confirm that connection can be established.

looking at yor logs, I found 2 suspicious line:


Code: 
Apr 22 09:06:55 parker zebra[1597466]: [WVJCK-PPMGD][EC 4043309093] netlink-cmd (NS 0) error: Device or resource busy, type=RTM_GETROUTE(26), seq=5, pid=2594392672


Apr 22 11:01:49 parker bgpd[1632074]: [VX6SM-8YE5W][EC 33554460] 10.0.10.4: nexthop_set failed, resetting connection - intf 0x0

seem that frr is breaking on a spefic local network devices (could be physical , but also a tap|veth vm|ct interface)

Maybe this frr bug is related:
https://github.com/FRRouting/frr/issues/10404

can you send result of "vtysh -c "sh ip route" ?

on you proxmox host, do you use other vm|ct with nic on vlanaware bridge ? (in parallel to evpn vms)

I'll try to see if I can backport the frr patch.
Click to expand...
with
no bgp controllers setup except the one thats setup for evpn.
vtysh -c "sh ip route"
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure

B>* 10.0.201.0/24 [20/0] is directly connected, TestNet (vrf vrf_CLextern), weight 1, 00:02:34

summary
Evpn controller between 3 hosts.
evpn Zone
Vnet with subnet 10.0.201.0/24 with a gateway.
 
spirit said:
I have build a frr 8.2.2 version + 3 patches from
https://github.com/FRRouting/frr/pull/10482

can you try it ?:

Code: 
wget https://mutulin1.odiso.net/frr_8.2.2-1+pve1_amd64.deb
wget https://mutulin1.odiso.net/frr_8.2.2-1+pve1_amd64.deb
dpkg -i frr_8.2.2-1+pve1_amd64.deb frr_8.2.2-1+pve1_amd64.deb
systemctl restart frr
Click to expand...
Same config as before

and with your patch

vtysh -c "sh ip route"
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure

B>* 0.0.0.0/0 [20/0] via 10.0.10.197, vrfbr_CLextern (vrf vrf_CLextern) onlink, weight 1, 00:00:20
C>* 10.0.10.0/24 is directly connected, vlan10, 00:00:26
C>* 10.0.12.0/24 is directly connected, vlan12, 00:00:26
C>* 10.0.13.0/24 is directly connected, vlan13, 00:00:26
B>* 10.0.201.0/24 [20/0] is directly connected, TestNet (vrf vrf_CLextern), weight 1, 00:00:25
B>* 10.0.201.10/32 [20/0] via 10.0.10.197, vrfbr_CLextern (vrf vrf_CLextern) onlink, weight 1, 00:00:20
C>* 192.168.89.0/24 is directly connected, vmbr0.1, 00:00:26


nice work!
thats the spirit... :D


i will do additional testing and try add the setup with external bgp routers
 
ic3cool said:
Same config as before

and with your patch

vtysh -c "sh ip route"
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure

B>* 0.0.0.0/0 [20/0] via 10.0.10.197, vrfbr_CLextern (vrf vrf_CLextern) onlink, weight 1, 00:00:20
C>* 10.0.10.0/24 is directly connected, vlan10, 00:00:26
C>* 10.0.12.0/24 is directly connected, vlan12, 00:00:26
C>* 10.0.13.0/24 is directly connected, vlan13, 00:00:26
B>* 10.0.201.0/24 [20/0] is directly connected, TestNet (vrf vrf_CLextern), weight 1, 00:00:25
B>* 10.0.201.10/32 [20/0] via 10.0.10.197, vrfbr_CLextern (vrf vrf_CLextern) onlink, weight 1, 00:00:20
C>* 192.168.89.0/24 is directly connected, vmbr0.1, 00:00:26


nice work!
thats the spirit... :D


i will do additional testing and try add the setup with external bgp routers
Click to expand...

yes, it could be great if you can test it on your side. I'm currently testing it since 24h, I don't have seen evpn regression. (I had a lot of frr bugs when updating to recent version in the past, so I really need to be carefull before pushing it for all users)

BTW, does multiple exit-nodes working now ?
 
spirit said:
yes, it could be great if you can test it on your side. I'm currently testing it since 24h, I don't have seen evpn regression. (I had a lot of frr bugs when updating to recent version in the past, so I really need to be carefull before pushing it for all users)

BTW, does multiple exit-nodes working now ?
Click to expand...
i have not been able to test fail-over for multiple exit-nodes.

ive not enable debug mode and looked in to it in depth but i would say that its working now.

evpn-c - zone - vnet - subnet
multiple exit nodes and one prefered(forced in gui :) )
BGP from all 3 nodes to route reflector. Routes from outside is propagated as expected. both host and frr shows the active routes.
as well as the routes from the test subnet is propagated to outside cluster.

can ping between two test machines on two different nodes, as well as default gw on subnet.
i can also ping outside where its allowed to do so, and reach internet.

so once again nice!

do i dare to build something upon this? will your awesome work get in to next patch?
 
Last edited:
ic3cool said:
i have not been able to test fail-over for multiple exit-nodes.

ive not enable debug mode and looked in to it in depth but i would say that its working now.

evpn-c - zone - vnet - subnet
multiple exit nodes and one prefered(forced in gui :) )
BGP from all 3 nodes to route reflector. Routes from outside is propagated as expected. both host and frr shows the active routes.
as well as the routes from the test subnet is propagated to outside cluster.

can ping between two test machines on two different nodes, as well as default gw on subnet.
i can also ping outside where its allowed to do so, and reach internet.

so once again nice!

do i dare to build something upon this? will your awesome work get in to next patch?
Click to expand...
I have already send patch for exit-nodes to pve-devel mailing, so I hope it'll be include soon. (you can keep my .deb for now if you want).
Here the patch : https://lists.proxmox.com/pipermail/pve-devel/2022-April/052633.html

(I also need to fix the forced exit-node, this is a bug in the gui, it should be optionnal ;)


For frr 8.2,I'll do more tests this week, if it's work fine, I'll send patch next week. (you can also keep my .deb, it'll not be replaced on proxmox upgrade)
 
spirit said:
I have already send patch for exit-nodes to pve-devel mailing, so I hope it'll be include soon. (you can keep my .deb for now if you want).
Here the patch : https://lists.proxmox.com/pipermail/pve-devel/2022-April/052633.html

(I also need to fix the forced exit-node, this is a bug in the gui, it should be optionnal ;)


For frr 8.2,I'll do more tests this week, if it's work fine, I'll send patch next week. (you can also keep my .deb, it'll not be replaced on proxmox upgrade)
Click to expand...
Hi,
I have not had the time for more tests from my end sorry about that.

How did it go from your side?
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom