Visitor III

Solved

Redistribute OSPF over BGP Between to FotiGates (wrong next hop ip)

Forum|Forum|2 years ago
June 14, 2023
7 replies
12011 views

Hi,

I'm trying to redistribute OSPF over BGP. The Neighbors are getting the routes but the routes are using wrong recursive next hop IP on one of the sides... 2023-06-18 13_51_33-Visio Professional.png

When you look at the routing table on the right side it is using the WAN IP instead of the tunnel IP

DEFLE-FW01 $ get router info routing-table bgp
Routing table for VRF=0
B 10.1.2.0/24 [200/20] via 172.21.1.6 (recursive via ADVPN tunnel "WAN IP"), 01:06:38
B 10.1.3.0/24 [200/20] via 172.21.1.6 (recursive via ADVPN tunnel "WAN IP"), 01:06:38
B 10.1.4.0/24 [200/20] via 172.21.1.6 (recursive via ADVPN tunnel "WAN IP"), 01:06:38
B 10.1.5.0/24 [200/20] via 172.21.1.6 (recursive via ADVPN tunnel "WAN IP"), 01:06:38
B 10.1.6.0/24 [200/20] via 172.21.1.6 (recursive via ADVPN tunnel "WAN IP"), 01:06:38
B 10.1.90.0/24 [200/20] via 172.21.1.6 (recursive via ADVPN tunnel "WAN IP"), 01:06:38
B 10.1.91.0/24 [200/20] via 172.21.1.6 (recursive via ADVPN tunnel "WAN IP"), 01:06:38
B 10.1.91.100/32 [200/0] via 172.30.0.254 (recursive via ADVPN tunnel "WAN IP"), 02:32:12
B 10.1.100.0/24 [200/20] via 172.21.1.6 (recursive via ADVPN tunnel "WAN IP"), 01:06:38
B 172.21.1.0/30 [200/0] via 172.30.0.1 (recursive via ADVPN tunnel "WAN IP"), 02:32:12
B 172.21.1.4/30 [200/0] via 172.30.0.1 (recursive via ADVPN tunnel "WAN IP"), 02:32:12
B 192.168.4.0/24 [200/0] via 172.30.0.1 (recursive via ADVPN tunnel "WAN IP"), 02:27:33

But when you look on the left side everything seems fine

DKAAR-FW01 $ get router info routing-table bgp
Routing table for VRF=0
B 10.2.2.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN tunnel 172.30.0.2), 01:48:55
B 10.2.3.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN tunnel 172.30.0.2), 01:48:55
B 10.2.4.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN tunnel 172.30.0.2), 01:48:55
B 10.2.5.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN tunnel 172.30.0.2), 01:48:55
B 10.2.6.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN tunnel 172.30.0.2), 01:48:55
B 10.2.90.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN tunnel 172.30.0.2), 01:48:55
B 10.2.91.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN tunnel 172.30.0.2), 01:48:55
B 10.2.91.100/32 [200/0] via 172.30.0.1 (recursive is directly connected, ADVPN), 03:21:57
B 10.2.100.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN tunnel 172.30.0.254), 01:48:55
B 172.21.2.0/30 [200/0] via 172.30.0.1 (recursive is directly connected, ADVPN), 03:21:57

If you have idea on how to fix this please let me know.

Both Fortigates are running version 7.0.11

FortiGate

Best answer by Sowie

Hi all,

I would like to express my gratitude for your assistance in resolving my issue. Your time and support have been greatly appreciated.

Upon reflection, I realized that I neglected to perform a simple ping test between the sites after resetting both Fortigates. Consequently, I am uncertain about the exact cause of the problem. However, I attempted to rectify the situation by implementing static routes instead of relying on OSPF. Surprisingly, everything appears to be functioning correctly, albeit with an incorrect tunnel IP on the recursive route. To my surprise, I successfully executed a ping test. Subsequently, I decided to remove the static routes, and to my amazement, the connection still remains functional. This turn of events has left me perplexed as to why the ADVPN tunnel now exhibits the WAN IP of the HUB instead of the tunnel IP and why it is working. Perhaps it is related to setting the remote Gateway to that address...

Thank you once again for your assistance and understanding.

RaniGome

New Member

Hi,

I think you can using the "set next-hop-self-rr enable " inside config neighbor to redistribute the routes from BGP neighbors make them the gateway for this routes. As the routers of BGP peers are directly connected, there is no need to static routes for overlays.

Here follows some information from fortinet:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-modify-BGP-next-hop-for-route-reflector/ta-p/190639

SowieAuthor

Visitor III

Hi,

Thanks for the quick reply. Sorry I missed this command in the picture. This I've already configured.

DKAAR-FW01

config neighbor
edit "172.30.0.2"
set next-hop-self-rr enable
set remote-as 65400
set update-source "ADVPN"
set password XXX
set route-reflector-client enable

DEFLE-FW02

config neighbor
edit "172.30.0.1"
set next-hop-self-rr enable
set remote-as 65400
set update-source "ADVPN"
set password XXX
set route-reflector-client enable

Demir21

Staff

On the faulty site can you please check if next -hop is in the routing table and if yes, is it pointing to the VPN?

SowieAuthor

Visitor III

Hi Demir

Here is the routing-table on the faulty site marked in red is the IP I assume should be the next-hop.

S* 0.0.0.0/0 [5/0] via 10.192.22.1, wan1, [1/0]
B 10.1.2.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.3.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.4.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.5.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.6.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.90.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.91.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.91.100/32 [200/0] via 172.30.0.254 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:49:59
B 10.1.92.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.100.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
O E2 10.2.2.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.3.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.4.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.5.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.6.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.90.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.91.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
C 10.2.91.100/32 is directly connected, NETMGMT
O E2 10.2.100.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
C 10.192.22.0/24 is directly connected, wan1
B 172.21.1.0/30 [200/0] via 172.30.0.254 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:49:59
B 172.21.1.4/30 [200/0] via 172.30.0.254 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:49:59
C 172.21.2.0/30 is directly connected, LACP DEFLE-CSW1
S 172.30.0.0/24 [5/0] via ADVPN-SPOKE tunnel ###WANIP###, [1/0]
C 172.30.0.1/32 is directly connected, ADVPN-SPOKE
S 172.30.0.254/32 [15/0] via ADVPN-SPOKE tunnel ###WANIP###, [1/0]
O E2 192.168.0.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
C 192.168.1.0/24 is directly connected, lan

Demir21

Staff

Hi,

Thank you. Please to also include the configuration of tunnel interface ADVPN-SPOKE.

Command as follows: show system interface ADVPN-SPOKE

akristof

Staff

Hello,

I am not sure if the on right firewall the "WAN IP" means that gateway is resolved incorrectly. I would need to see whole routing-table including output from #diag vpn ike gateway list and from #diag vpn tunnel list. Ideally unredacted. I am not sure if this BGP is between spoke to spoke or between spoke to HUB.

SowieAuthor

Visitor III

Hi Adrian,

I reset the firewalls and got the VPN working again, but I still have the issue with BGP next-hop. Here you have the requested outputs.

Routing table
S* 0.0.0.0/0 [5/0] via 10.192.22.1, wan1, [1/0]
B 10.1.2.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.3.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.4.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.5.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.6.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.90.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.91.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.91.100/32 [200/0] via 172.30.0.254 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:49:59
B 10.1.92.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
B 10.1.100.0/24 [200/20] via 172.21.1.2 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:43:43
O E2 10.2.2.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.3.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.4.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.5.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.6.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.90.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
O E2 10.2.91.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
C 10.2.91.100/32 is directly connected, NETMGMT
O E2 10.2.100.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
C 10.192.22.0/24 is directly connected, wan1
B 172.21.1.0/30 [200/0] via 172.30.0.254 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:49:59
B 172.21.1.4/30 [200/0] via 172.30.0.254 (recursive via ADVPN-SPOKE tunnel ###WANIP###), 01:49:59
C 172.21.2.0/30 is directly connected, LACP DEFLE-CSW1
S 172.30.0.0/24 [5/0] via ADVPN-SPOKE tunnel ###WANIP###, [1/0]
C 172.30.0.1/32 is directly connected, ADVPN-SPOKE
S 172.30.0.254/32 [15/0] via ADVPN-SPOKE tunnel ###WANIP###, [1/0]
O E2 192.168.0.0/24 [110/20] via 172.21.2.2, LACP DEFLE-CSW1, 03:17:07
C 192.168.1.0/24 is directly connected, lan

diag vpn ike gateway list

name: ADVPN-SPOKE
version: 1
interface: wan1 5
addr: 10.192.22.17:4500 -> ###WANIP###:4500
tun_id: ###WANIP###/::###WANIP###
remote_location: 0.0.0.0
network-id: 0
virtual-interface-addr: 172.30.0.1 -> 172.30.0.254
created: 9958s ago
nat: me
auto-discovery: 2 receiver
IKE SA: created 1/1 established 1/1 time 20/20/20 ms
IPsec SA: created 1/1 established 1/1 time 40/40/40 ms

id/spi: 1 630310eb9f49d396/faa1622092f94387
direction: initiator
status: established 9958-9958s ago = 20ms
proposal: aes128-sha256
key: d67ffbc3d7874fb3-47d28846402d395b
lifetime/rekey: 86400/76141
DPD sent/recv: 00000402/00000239

diag vpn tunnel list

list all ipsec tunnel in vd 0
------------------------------------------------------

name=ADVPN-SPOKE ver=1 serial=1 10.192.22.17:4500->###WANIP###:4500 tun_id=###WANIP### tun_id6=::###WANIP### dst_mtu=1500 dpd-link=on weight=1
bound_if=5 lgwy=static/1 tun=intf mode=auto/1 encap=none/568 options[0238]=npu create_dev frag-rfc role=primary accept_traffic=1 overlay_id=0

proxyid_num=1 child_num=0 refcnt=5 ilast=0 olast=1 ad=r/2
stat: rxp=2689 txp=5077 rxb=540576 txb=3796897
dpd: mode=on-idle on=1 idle=5000ms retry=3 count=0 seqno=1026
natt: mode=keepalive draft=32 interval=10 remote_port=4500
proxyid=ADVPN-SPOKE proto=0 sa=1 ref=6 serial=1 auto-negotiate adr
src: 0:0.0.0.0-255.255.255.255:0
dst: 0:0.0.0.0-255.255.255.255:0
SA: ref=6 options=1a227 type=00 soft=0 mtu=1422 expire=32827/0B replaywin=1024
seqno=13d4 esn=0 replaywin_lastseq=00000a80 qat=0 rekey=0 hash_search_len=1
life: type=01 bytes=0/0 timeout=42901/43200
dec: spi=f1b700f7 esp=aes key=16 581dc979cff130a025311f22d633870a
ah=sha1 key=20 7eef9344de69b0fe184a07a3487db50f7f642f4e
enc: spi=09053b75 esp=aes key=16 59c85a2e11093fb873a501cd3cc9798d
ah=sha1 key=20 a6f270b938efb506b3ae387a4729d381120accb1
dec:pkts/bytes=2690/540636, enc:pkts/bytes=10139/7882174
npu_flag=03 npu_rgwy=###WANIP### npu_lgwy=10.192.22.17 npu_selid=0 dec_npuid=1 enc_npuid=1

Sorry but I have to mask the WAN IP. This is HUB-SPOKE the right side is the SPOKE.

Thanks again for taking a look at this.

akristof

Staff

Hi,

Can you please add me the following from the HUB:
show vpn ipsec phase1-setting ADVPN-SPOKE

show system interface ADVPN-SPOKE

Please?

SowieAuthor

Visitor III

Hi @akristof @Demir21

Thanks for the response! I managed to delete the Spoke VPN (and spill Ice Tea into my laptop...)by mistake. I've have been unable to recreate it. So I'll have get that working again before I can check.

Thinking of just factory resetting both firewalls...

RaniGome

New Member

When you can, try to create static routes to the network of your IP addresses of the tunnels that are exchanging route, in your case ADVPN. that will solve your problem of wrong interfaces on bgp routes.

SowieAuthor

Visitor III

Hi Rani

This already has a static route As you can see in the picture
2023-06-18 13_24_22-FortiGate - DEFLE-FW01.png

Faiza_Emam_Delhi

Visitor III

Hello,

From the output you have provided, it appears that the issue is with the recursive next-hop IP address on the right side. It is using the WAN IP instead of the ADVPN tunnel IP address.

To fix this issue, you may need to check the BGP configuration on the right side FortiGate to ensure that the correct next-hop IP address is being advertised to the BGP peers. You may also need to check the routing settings on the right side FortiGate to ensure that the ADVPN tunnel IP address is being used as the next-hop IP address for the redistributed routes.

Here are some steps you can try:

1. Check the BGP configuration on the right side FortiGate to ensure that the correct next-hop IP address is being advertised to the BGP peers. You can use the "get router info bgp summary" command to check the BGP peer status and the advertised next-hop IP address.

2. Check the OSPF configuration on the left side FortiGate to ensure that the redistributed routes are using the correct next-hop IP address. You may need to configure a static route or modify the OSPF configuration to ensure that the ADVPN tunnel IP address is being used as the next-hop IP address for the redistributed routes.

3. Verify the routing table on both FortiGate devices to ensure that the correct next-hop IP address is being used for the redistributed routes.

4. If the issue persists, you may need to provide more information about the network topology and the configuration settings on both FortiGate devices to help diagnose the issue.

I hope this helps! Let me know if you have any further questions.

Faiza_Emam_Delhi

Visitor III

Hi,

Based on the routing table output you provided, it appears that the issue is with the recursive next hop IP address on the right side FortiGate device. The BGP routes are using the WAN IP instead of the tunnel IP as the recursive next hop.

To fix this issue, you can try the following steps:

1. Check BGP configuration on the right side FortiGate device: Verify that the BGP configuration on the right side FortiGate device is correct and that the tunnel interface is specified as the next hop for the redistributed OSPF routes.

2. Check IPsec configuration on the right side FortiGate device: Verify that the IPsec configuration on the right side FortiGate device is correct and that the tunnel interface is reachable via the IPsec tunnel.

3. Check BGP configuration on the left side FortiGate device: Verify that the BGP configuration on the left side FortiGate device is correct and that the tunnel interface is configured as the next hop for the redistributed OSPF routes.

4. Check IPsec configuration on the left side FortiGate device: Verify that the IPsec configuration on the left side FortiGate device is correct

SowieAuthor

Visitor III

Hi Faiza,

Thanks for the response!

1. Check BGP configuration on the right side FortiGate device: Verify that the BGP configuration on the right side FortiGate device is correct and that the tunnel interface is specified as the next hop for the redistributed OSPF routes.
How would I do this? I have tried to set the "next-hop-self-rr" and "next-hop-self".

2. Check IPsec configuration on the right side FortiGate device: Verify that the IPsec configuration on the right side FortiGate device is correct and that the tunnel interface is reachable via the IPsec tunnel.

I have check and the VPN is working as it should. The only thing that is different is that on the right side I've had to set a remote gateway. I don't know if that is what is causing the issue here.

3. Check BGP configuration on the left side FortiGate device: Verify that the BGP configuration on the left side FortiGate device is correct and that the tunnel interface is configured as the next hop for the redistributed OSPF routes.

When looking at the routing table this side dosn't seem to have an issue with the recursive route.

Routing table for VRF=0
B 10.2.2.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN-HUB tunnel 172.30.0.1), 00:00:02
B 10.2.3.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN-HUB tunnel 172.30.0.1), 00:00:02
B 10.2.4.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN-HUB tunnel 172.30.0.1), 00:00:02
B 10.2.5.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN-HUB tunnel 172.30.0.1), 00:00:02
B 10.2.6.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN-HUB tunnel 172.30.0.1), 00:00:02
B 10.2.90.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN-HUB tunnel 172.30.0.1), 00:00:02
B 10.2.91.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN-HUB tunnel 172.30.0.1), 00:00:02
B 10.2.91.100/32 [200/0] via 172.30.0.1 (recursive is directly connected, ADVPN-HUB), 00:38:22
B 10.2.100.0/24 [200/20] via 172.21.2.2 (recursive via ADVPN-HUB tunnel 172.30.0.1), 00:00:02
B 172.21.2.0/30 [200/0] via 172.30.0.1 (recursive is directly connected, ADVPN-HUB), 00:38:22

4. Check IPsec configuration on the left side FortiGate device: Verify that the IPsec configuration on the left side FortiGate device is correct
Also correct

SowieAuthorAnswer

Visitor III

Hi all,

I would like to express my gratitude for your assistance in resolving my issue. Your time and support have been greatly appreciated.

Upon reflection, I realized that I neglected to perform a simple ping test between the sites after resetting both Fortigates. Consequently, I am uncertain about the exact cause of the problem. However, I attempted to rectify the situation by implementing static routes instead of relying on OSPF. Surprisingly, everything appears to be functioning correctly, albeit with an incorrect tunnel IP on the recursive route. To my surprise, I successfully executed a ping test. Subsequently, I decided to remove the static routes, and to my amazement, the connection still remains functional. This turn of events has left me perplexed as to why the ADVPN tunnel now exhibits the WAN IP of the HUB instead of the tunnel IP and why it is working. Perhaps it is related to setting the remote Gateway to that address...

Thank you once again for your assistance and understanding.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded