gre over ipsec tunnel not established and ospf mtu mss issue
We have a customer who has 8 branches. 6 branches gre over ipsec tunnel is established with their headoffice without having any problem because they are connected through VLAN directly from PE router. Only problem is happening at 2 branches. recently we have implemented MPLS in our network and that customer all the branches are connected through MPLS vrf. 6 branches are connected through VLAN point to point ip with us and those branches are coming through layer2 switches upto PE router. rest 2 branches is connected through L2TPV3 router in between then through VLAN upto PE. the scenerio is
branch office ---->L2TPV3 Router fa0/1 xconnect------>L2TPV3 router Fa0/0 pseduowire-----> PE Router1 VLAN 333----> PE Router2 VRF with same VLAN
everyday clearing ip ospf neighbour process at branch office router tunnel gets up and remain up whole day but when they shutdown the router everyday evening and open it at nextday morning tunnel doesnt up automatically ospf neighbour show down
pseudowire-class ethernet encapsulation l2tpv3 ip local interface Loopback0 ip pmtu
nterface FastEthernet0/1 no ip address ip route-cache flow duplex auto speed auto no cdp enable xconnect 220.127.116.11 110 pw-class ethernet ==========================================
Customer branch office router
interface Tunnel1 description "branch office" bandwidth 1024 ip address 18.104.22.168 255.255.255.252 ip mtu 1452 no ip route-cache cef no ip route-cache ip tcp adjust-mss 1360 no ip mroute-cache tunnel source GigabitEthernet0/0 tunnel destination 10.9.9.1 tunnel path-mtu-discovery
customer headoffice office router
interface Tunnel21 description "branch office router" ip address 22.214.171.124 255.255.255.252 ip mtu 1452 ip tcp adjust-mss 1360 ip ospf cost 10 tunnel source 10.9.9.1 tunnel destination 10.9.9.17 tunnel path-mtu-discovery
problem is ospf neighbour is not getting up automatically if the router gets down. after clearing the ospf process tunnel is getting up. sometimes tunnel is getting down by giving the ospf too many retransmission error. before applying the MTU size we saw the debug ip ospf adjacency which was showing
*Mar 14 17:03:00.493 BDT: OSPF: Send DBD to 172.24.24.1 on Tunnel1 seq 0x1605 opt 0x52 flag 0x3 len 1452 *Mar 14 17:03:00.493 BDT: OSPF: Retransmitting DBD to 172.24.24.1 on Tunnel1  *Mar 14 17:03:05.502 BDT: OSPF: Killing nbr 172.24.24.1 on Tunnel1 due to excessive (25) retransmissions *Mar 14 17:03:05.502 BDT: OSPF: 172.24.24.1 address 126.96.36.199 on Tunnel1 is dead, state DOWN *Mar 14 17:03:05.502 BDT: %OSPF-5-ADJCHG: Process 100, Nbr 172.24.24.1 on Tunnel1 from EXCHANGE to DOWN, Neighbor Down: Too many retransmissions *Mar 14 17:04:13.666 BDT: OSPF: Rcv DBD from 172.24.24.1 on Tunnel1 seq 0x1EA0 opt 0x52 flag 0x7 len 32 mtu 1476 state EXSTART *Mar 14 17:04:13.670 BDT: OSPF: First DBD and we are not SLAVE *Mar 14 17:04:13.698 BDT: OSPF: Rcv DBD from 172.24.24.1 on Tunnel1 seq 0xF5D opt 0x52 flag 0x2 len 1452 mtu 1476 state EXSTART
so we set ip MTU 1452 at branch office and headoffice tunnel. can someone help us what would be the correct MTU and MSS setting at tunnel interface which will help to gets the ospf neighbour and tunnel up and running without clearing ip ospf neighbour process manually everyday.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...