Help!?, IP CEF (Dual Wan with OER) Breaks IPSEC VTI Tunnels and EIGRP.
I have a very weird but also very frustrating issue going on right now.
My current home WAN Setup involves a single 1921 with 2x HWIC1-ADSL Cards installed running OER for Wan Balancing. The OER and WAN balancing side of things works very well and doesn't give us the issue that GLBP on 2 Routers that i was running before did, which was breaking sessions by changing the default route without being session aware. (Old Setup was 1921 + 1941 running GLBP with 1x HWIC1-ADSL Each).
This new setup however, has brought along its own problems which are just as much if not more infuriating than what GLBP was doing.
So, as part of a Group Project for my Network Security degree with 3 other friends, we have multiple IPSEC VTI Tunnels between our routers, and we use EIGRP for dynamic routing, each person has 2 tunnels from their wan router to 2x other people for redundancy, and over this our Labs and servers are able to communicate.
My Setup however is a bit different because i have 2x WAN Connections, so i have 2x tunnels per WAN Connection and here is where the trouble starts.
When i cold start the router i will typically only get 2 out of 4 tunnels to come up, either one to each Peer (HUB A, and HUB B) each on 1 WAN line, or 2 tunnels out one line and none out the other, and its totally random, sometimes 3 will come up. Now here comes the interesting bit...... If i turn off IP CEF, they ALL COME UP and Form EIGRP Adjacency normally, and if i turn IP CEF back on, then over 5 - 10 minutes a couple will fail and drop.
It should be noted that when a tunnel refuses to come up, the Peer router CAN NOT be Pinged from the respective wan interface (but often can on the other wan interface).
Tunnel 9004 goes to HUB A, from WAN A (Dialer 0) Tunnel 9006 goes to HUB B, from WAN A (Dialer 0) Tunnel 92004 goes to HUB A, from WAN B (Dialer 1) Tunnel 92006 goes to HUB B, from WAN B (Dialer 1)
on a Cold boot, tunnels 9004 and 92006 Come up but 92004 and 9006 do not.
With the above being the case:
HUB A CAN be Pinged from WAN A, But NOT from WAN B HUB B CAN Be Pinged from WAN B, But NOT from WAN A
Sometimes as is the case right as im typing this, two tunnels come up, but only one will form EIGRP Adjacency and pass traffic both ways, with the other in a constant New Adjacency / timeout loop leaving me on just 1 working tunnel.
Turning off IP CEF results in Either HUB being Pingable from Either WAN Interface and all tunnels coming up.
I cant however leave IP CEF Disabled because its Required by the OER Load Balancing running on the router, and turning CEF off results in MASSIVE (often 50% or more) Packet drops.
Does anyone know why turning CEF OFF causes ALL the tunnels to come up, and turning it back on (or booting up with it enabled) means that half the tunnels just dont work?
I have attached a sanitised router config as an attachment. IOS Version is:
はじめに確認方法Version による Application name の変更について備考参考情報 はじめに本ドキュメントでは Cisco SD-WAN における Policy 上で設定可能な Application を確認する方法について記載しています。 確認方法サポートされている Application name についてはご使用されている vManage へ API を呼び出して確認することが可能です。https://<IP or FQDN>/...
DMVPN (Dynamic Multipoint VPN) Introduced by Cisco in late 2000 is a routing technology you can use to build a VPN network with multiple sites (spokes) without having to statically configure all devices. It’s a “hub and spoke” network, where the spok...
On 24th August 2021, Cisco announced the latest IOS XE release - Cisco IOS XE Bengaluru 17.6.1a
IOS XE 17.6.1a unlocks various routing features and enhancements comprehensively covering different technology segments such as voice, security,...
DMVPN (Dynamic Multipoint VPN) Introduced by Cisco in late 2000 is a routing technology you can use to build a VPN network with multiple sites (spokes) without having to statically configure all devices. It’s a “hub and spoke” network, where th...
SummaryRequirementsConfiguration StepsVerificationFAQTroubleshootingReferences & Tools
In the past when IOS 12.x was hot stuff we used MD5 to authenticate OSPF neighbors. This worked great on ethernet networks because OSPF is a m...