|
When the primary Internet 'wan1' is shut down on one of the Spoke FortiGates, both HUB and Spoke FortiGates advertise their respective tunnel IPs during IKE negotiation as shown below.
To collect and filter the IKE debugs, refer to this article: Troubleshooting Tip: IPSEC Tunnel (debugging IKE).
IKE Debugs:
ike 0:H1-BACKUP:28605: add INTERFACE-ADDR4 10.10.100.202
.
ike 0: comes X.X.X.X:500->Y.Y.Y.Y:500,ifindex=23,vrf=0....
ike 0: IKEv2 exchange=AUTH_RESPONSE id=c42f033bfebf7083/01fec251320f216d:00000001 len=240
ike 0: in C42F033BFEBF708301FEC251320F216D2E20232000000001000000F0240000D41F59D5FCACB6DB246ED8933B8C59D7E66ED687663BE8D380F75053558E242B7014C2A7D882F3C384D82C1330F1F5A491B5274FAC148F76C8E72956F2F9C186F884E2A4B1E8D95FB8BB8
785EE6E78607B2D5203A6D432267BC232C70D0A2E146DF46D5E0C7FD7424C218D7E84B968CA063DC1F8E21A9B742E463FE42627139B9131E1E2171910E377DC2ADA1716B1D2DAD6C87434A029D1F5E6141EDEFC8BFF89E5AC85FA1A7CDE6303E22FE52C52414A35D5D4F43B43744125
4DF3CBF3C9BF759F9EE0D4F186541
ike 0:H1-BACKUP:28605: dec C42F033BFEBF708301FEC251320F216D2E20232000000001000000C4240000042700000C0100000021EC222900002802000000AFA7C71DD2059C8C67AFB7B21CC9C1727E03F02BB4AAE8B33AFE0F4B2C9D4BF429000008000040242100000C0000
F0F90A0A64012C00002C0000002801030403420190990300000C0100000C800E0080030000080300000C00000008050000002D00001801000000070000100000FFFF00000000FFFFFFFF0100000FFFF00000000FFFFFFFF
ike 0:H1-BACKUP:28605: initiator received AUTH msg
ike 0:H1-BACKUP:28605: peer identifier IPV4_ADDR X.X.X.X
ike 0:H1-BACKUP:28605: auth verify done
ike 0:H1-BACKUP:28605: initiator AUTH continuation
ike 0:H1-BACKUP:28605: authentication succeeded
ike 0:H1-BACKUP:28605: processing notify type MESSAGE_ID_SYNC_SUPPORTED
ike 0:H1-BACKUP:28605: processing notify type INTERFACE_ADDR4
ike 0:H1-BACKUP:28605: INTERFACE-ADDR4 10.10.100.1
However, the BGP neighborship on the backup VPN tunnel does not get established with the Hub(10.10.100.1) using its Tunnel IP (10.10.100.202).
Instead, the existing BGP connection established over the primary VPN tunnel now uses the Backup VPN tunnel interface to keep the BGP session active.
On HUB:
HUB#get router info bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.100.102 4 65000 73903 73903 0 0 0 00:00:06 0
The route for the primary tunnel on the Spoke FortiGate remains UP in the kernel routing table even though the primary tunnel is down.
SPOKE# get router info kernel
tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->10.10.100.102/32 pref=10.10.100.102 gwy=0.0.0.0 dev=29(H1-PRIMARY)
Starting with v7.x, the kernel always maintains the tunnel interface status as 'up', even when the tunnel is down, and the IP address remains in the routing table and kernel.
As a result, existing BGP sessions consider it acceptable to use the primary tunnel IP as the source IP for establishing BGP connections over the secondary tunnel.
The recommendation is to have the HUB establish a BGP neighborship with a loopback interface IP on spoke. With this design, BGP packets from SPOKE will be transmitted over whichever tunnel interface is active at the time.
Refer to the below article which contains a sample configuration for ADVPN with BGP on the loopback interface:
Technical Tip: ADVPN with BGP on loopback
This issue has been resolved in v7.0.16, v7.2.11, 7.4.5, and v7.6.1, after which FortiGate will use the correct source IP address for subsequent BGP connections.
However, keep in mind that with the default settings, the original BGP peering will need to expire first before a new peering can be established using the IP address of the secondary tunnel.
To force the original BGP peering to go down when the primary tunnel goes down (thus speeding up the transition to the new BGP peering with the secondary tunnel address), consider enabling the BGP link-down-failover option (see: Technical Tip: Understanding the link-down-failover, fast-external-failover, and interface options f...).
|
