I have two WAN links (fiber) of 100Mbps with one customer, in my company we have two Cisco 3845 routers and in the customer there are two Cisco 2691 routers.
When we enable OSPF between the routers the adjacency isn´t established and in the routers appear EXSTART/BDR state.
The configuration and the logs were attached.
Any idea of that can be happening?
I have looked at the information that you posted. My first suggestion would be to verify connectivity between the routers. If you could post the output of show cdp neighbor detail, show ip ospf interface, and show ip ospf it might be helpful.
My second suggestion would be to look at the authentication in OSPF that is configured. If you remove the authentication, does OSPF work better?
This environment is in production with static routes, then, I can´t carry through with OSPF now. I need to open a window with antecedence.
But, I am certain that the connectivity between the routers was OK.
When I did the configurations I removed the authentication in OSPF and the issue continued.
I believe that the issue isn´t in the authentication.
It is helpful to know that you removed the authentication and that the problem remained. If the environment is now working with static routes then it will take a maintenance window to reconfigure OSPF and to do the show ospf commands that I asked about. But the show cdp neighbor detail should still work. And a traceroute on each router to the addresses of its neighbors might be helpful.
As the debug is pointing out the remote side is not responding.
Soit looks like maybe a connectivity issue where maybe the links have been swapped round and the IP's are not matching.
Issue an extended ping where the source IP address is that of the interface you are testing and make sure there is no problem here.
If that is not an issue and IP connectivity is 100% then please post a show ip ospf interface and show cdp neigbors. on both sides?
Also a good idea is to remove the all the OSPF related configuration incuding the authentication and rebuild the config without the authentication and see if its not a authentication issue.
In the environment that is working I also have crypto and ACL applied in the interface.
It follows configurations below:
crypto isakmp policy 1
crypto isakmp key
crypto ipsec transform-set itau ah-sha-hmac esp-3des
crypto map itau 1 ipsec-isakmp
set peer 10.56.4.102
set transform-set itau
match address 100
ip address 192.168.255.46 255.255.255.252
ip access-group Seguranca_Portal in
ip ospf message-digest-key 1 md5
no ip proxy-arp
no cdp enable
crypto map itau
router ospf 10
area 3 authentication message-digest
redistribute static subnets
network 192.168.255.44 0.0.0.3 area 3
ip route 10.56.4.102 255.255.255.255 192.168.255.45
ip route 10.56.133.77 255.255.255.255 192.168.255.45
ip route 10.56.133.114 255.255.255.255 192.168.255.45
ip route 192.168.30.9 255.255.255.255 192.168.255.45
ip route 192.168.30.10 255.255.255.255 192.168.255.45
ip route 192.168.30.78 255.255.255.255 192.168.255.45
ip route 192.168.30.79 255.255.255.255 192.168.255.45
ip route 192.168.30.133 255.255.255.255 192.168.255.45
ip route 192.168.30.160 255.255.255.255 192.168.255.45
ip route 192.168.30.166 255.255.255.255 192.168.255.45
ip route 192.168.30.167 255.255.255.255 192.168.255.45
ip route 192.168.30.177 255.255.255.255 192.168.255.45
ip route 192.168.30.185 255.255.255.255 192.168.255.45
ip route 192.168.30.193 255.255.255.255 192.168.255.45
ip route 192.168.30.203 255.255.255.255 192.168.255.45
ip route 192.168.30.206 255.255.255.255 192.168.255.45
ip route 192.168.30.222 255.255.255.255 192.168.255.45
ip route 192.168.30.246 255.255.255.255 192.168.255.45
access-list 100 permit ip 188.8.131.52 0.0.0.255 10.56.133.0 0.0.0.255
access-list 100 permit ip 184.108.40.206 0.0.0.255 192.168.30.0 0.0.0.255
access-list 100 permit ip 192.168.52.0 0.0.0.255 192.168.30.0 0.0.0.255
ip access-list extended Seguranca_Portal
permit udp any any eq isakmp
permit udp any eq isakmp any
permit esp any any
permit ahp any any
permit icmp any any
deny ip host 0.0.0.0 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip any host 220.127.116.11
deny ip any host 18.104.22.168
deny ip any 172.19.117.0 0.0.0.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any
This crypto and the ACL that I have configured can be causing the issue?
I have looked at the information that you posted and I do not see anything in the crypto that would impact OSPF. The access list is applied inbound and has potential to impact OSPF, but the permit ip any any at the end of the access list should let OSPF through. So I do not believe that the access list is causing the problem.
Can you provide the configuration details of the other router (interface, OSPF, any crypto or ACL)?
It might also be helpful if you post the output of show cdp neighbor detail from both routers.
I opened a new window and I observed that the OSPF neighborhood isn't being established must the extended access-list "Seguranca_Portal", because it is necessary increase the line "permit ospf any any".
After that, the routers established neighborhood and the environment functioned normally.
You're peer must by necessity be in the subnet 192.168.255.44, but you have a deny 192.168.0.0 access list statement. The OSPF traffic will never get matched to the "permit any any". Hence why the "permit ospf any any". If you are particularly security concious you might want to change that to "permit ospf host 192.168.255.x any"