Hi,My configuration file can work normally on the wireguard tunnel, but GRE does not work. Server1 11: home_1_vpn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 5.101.92.125/32 scope global home_1_vpn valid_lft forever preferred_lft forever root@ll-ix:~# ip route get 2602:feda:ab4:5247:5247:5247:5247:5247 2602:feda:ab4:5247:5247:5247:5247:5247 from :: dev frc_ca src 2602:feda:ab2:5247:5247:5247:5247:5247 metric 1024 pre f medium root@ll-ix:~# birdc s p a FRC_CA BIRD 2.0.7 ready. Name Proto Table State Since Info FRC_CA BGP --- start 2021-07-31 Idle BGP state: Idle Neighbor address: 2602:feda:ab4:5247:5247:5247:5247:5247%frc_ca Neighbor AS: 141011 Local AS: 141011 Channel ipv6 State: DOWN Table: master6 Preference: 100 Input filter: (unnamed) Output filter: (unnamed) root@ll-ix:~# birdc s p HOME_1_ARCH BGP --- up 2021-07-31 Established The protocol home_1_arch use the same template as Server 1 and Server 2,but it do Established.The only difference is using Wireguard as tun,I don't think I have a problem with the IP configuration on Server1 and Server2. protocol bgp FRC_CA from tpl_ibgp { source address 2602:feda:ab2:5247:5247:5247:5247:5247; neighbor 2602:feda:ab4:5247:5247:5247:5247:5247 as 141011; } Server2 9: ll_ix@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1000 link/gre 104.218.61.232 peer 5.189.255.107 inet6 2602:feda:ab4:5247:5247:5247:5247:5247/128 scope global valid_lft forever preferred_lft forever inet6 fe80::200:5efe:68da:3de8/64 scope link valid_lft forever preferred_lft forever root@vpsuser:~# ip route get 2602:feda:ab4:5247:5247:5247:5247:5247 local 2602:feda:ab4:5247:5247:5247:5247:5247 from :: dev lo table local proto kernel src 2602:feda:ab4:5247:5247:524 7:5247:5247 metric 0 pref medium root@vpsuser:~# birdc s p a LL_IX BIRD 2.0.7 ready. Name Proto Table State Since Info LL_IX BGP --- start 02:48:26.395 Idle BGP state: Idle Neighbor address: 2602:feda:ab2:5247:5247:5247:5247:5247 Neighbor AS: 141011 Local AS: 141011 Channel ipv6 State: DOWN Table: master6 Preference: 100 Input filter: (unnamed) Output filter: (unnamed) protocol bgp LL_IX from tpl_ibgp { source address 2602:feda:ab4:5247:5247:5247:5247:5247; neighbor 2602:feda:ab2:5247:5247:5247:5247:5247 as 141011; } Both Server use the same template,As shown below template bgp tpl_ibgp { local as LOCAL_ASN; rr client; direct; ipv6 { next hop self; import filter { if is_bogon_asn() then { print "is bogon asn", net, " for ASN ", bgp_path.last; reject; } if is_bogon_prefix() then { print "is bogon prefix", net, " for ASN ", bgp_path.last; reject; } accept; }; export filter { if bgp_export_all() then accept; reject; }; }; } Please help me,thanks.
A "famous" saying goes if it is not DNS, then it is MTU. GRE tunnel uses MTU 1476 from your output. Does the gre tunnel work if you lower the mtu setting? Does end to end ping(6) work through the gre tunnel= (I.e. can the end points reach each other through the tunnel)
On Sun, Aug 01, 2021 at 11:32:42PM +0800, 智慧雨泽 wrote:
Hi,My configuration file can work normally on the wireguard tunnel, but GRE does not work.
Server1
11: home_1_vpn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 5.101.92.125/32 scope global home_1_vpn valid_lft forever preferred_lft forever root@ll-ix:~# ip route get 2602:feda:ab4:5247:5247:5247:5247:5247 2602:feda:ab4:5247:5247:5247:5247:5247 from :: dev frc_ca src 2602:feda:ab2:5247:5247:5247:5247:5247 metric 1024 pre f medium
Hi I guess the issue is that this GRE link does not have the prefix configured as a regular address range (is not shown in 'ip addr show'), thus BGP neighbor IP is not considered a direct neighbor and BIRD BGP is waiting for it to appear. You can either add such prefix to the GRE iface, or just use 'multihop' instead of 'direct' (as neighbor is reachable through routing table). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
Chriztoffer Hansen -
Ondrej Zajicek -
智慧雨泽