I seem to be unable to get the following working.
Central ASA with 2 local networks (192.168.1.0 and 5.0) and 3 remote networks (192.168.4.0,192.168.7.0,192.168.2.0) connected via an ipSEC VPN which is all working fine. I want to deploy OSPF in this topology. The rounting (currently) is static. I can reach each and every branch from each and every branch.
The networks (remote to the ASA) are all IOS Devices (800 boxes)
All networks are classful, no subnetting in place.
Let's speak about one of the 800 boxes hanging off a VDSL line where I obiously fail on a number of points. The first one: The LSA broadcasts need to be sent thru the tunnel (which they otherwise aren't). Now, which is the interface I should be doing ip ospf network point-to-multipoint non-broadcast on ? I did this on the dialer interface (that brings up the WAN, does the NAT and a few other things ). Should I be doing this here or on the i/f that does have its local IP ( tunnel entrance) ?
Next, what is the OSPF neighbor on this box ? Is it the public WAN IP of the ASA or its internal Adress behind the tunnel exit ?
Any help for an OSPF newbie greatly appreciated.
Dear OldSchoolTechie--I'm not super familiar with WAN technologies, but the first thought that came to me was that IPSec tunnels do not support multicasting, so routing protocols like OSPF that rely on multicasting don't work over IPSec tunnels.
The issue can be solved by (1) statically configuring adjacency using neighbor. The command you referenced--ip OSPF network--would go on the tunnel interfaces, and keep in mind that P2M NBMA networks default to a hello timer of 30 seconds, so when you go to mesh the P2M NMBA section with the OSPF domain running over Ethernet, you'll need to adjust accordingly, or the static neighbors won't form adjacency with any routers running on the Ethernet default network type.
(2) is to build a GRE tunnel within your IPSec tunnel. GRE is a great protocol for flexibility. It handles unicast, multicast, and broadcast traffic. So with an IPSec/GRE combo, you could have dynamic neighbor discovery across the tunnel.
thanks for your input, much appreciated. Yes, I apparently need GRE and as we're on an ASA on one end, we cannot use GRE . and we neither can't use VTI as ASA does not support this flavor of logical interface. ( Moreover, I would have to rewrite my L2L VPN to VTI config anyway).
What I also learned is that you can try to ospf network point-to-point non-broadcast - which still doesn't give it to me while it really lures you into thinking it's the missing brick. Let me share a few pieces of code with you:
router ospf 100
network 192.168.1.0 255.255.255.0 area 0 *
network 192.168.5.0 255.255.255.0 area 1 *
network 192.168.7.0 255.255.255.0 area 1 *
neighbor 192.168.2.1 interface inside
* = this s/n mask isn't a typo, ASA does not accept wildcard masks.
ip address 192.168.1.254 255.255.255.0
policy-route route-map LTE
ospf network point-to-point non-broadcast
router ospf 100
network 192.168.2.0 0.0.0.255 area 0
ip address 192.168.2.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
ip ospf network point-to-multipoint non-broadcast
What I seem to miss is that both networks aren't in the same subnet - and how would I go about that now that there is a VPN between it ? Like I said, OSPF is new to me and I really appreciate it that you take your time and effort to look into a fellow techie's issue.
At least I've got
OSPF: Send hello to 192.168.2.1 area 0 on inside from 192.168.1.254
...but, the IOS side isn't answering.
Dear OST--Couple thoughts...
(1) There are work-arounds for GRE and ASAs assuming you have another router behind the ASA that the GRE can attach to.
(2) I think you might have your configs on the wrong interface. I would expect to see the ip OSPF network commands on int tunnel 1 (or something like that) rather than the physical interface and the VLAN interface. Each side of the tunnel would have its own IP address and be in the same subnet.
(3) Do you have IP connectivity between your ASA and the remote router? (ping 192.168.2.1 from the ASA's IP) Since you are statically configuring the adjacency, the ASA--and any intervening router--needs to know how to route data to 192.168.2.1.
(1) - I've read a few articles about that - and I seem to get to grips with that - while what I only have is (roughly) this:
R1 192.168.2.0/24 | (dialer) <-> DSL WAN<-> (gi0 outside) ASA (gi1 inside) 192.168.1.0/24
This is a hub and spoke (star) architecture with the ASA in the middle surrounded by IOS 800's.
(2) I cannot use the (GRE) "tunnel" Interfaces because ASA doesn't support them.
(3) Yes, due to the static routes I have full forward- and reverse connectivity from anywhere.
And that's the question - who is whose neighbor, seen from R1's perspective:
Candidate 1 is the ASAs WAN Interface with the public IP.
Candidate 2 is the ASA LAN Interface with area 0 set.
Either don't work.
Here's some excerpt from my literature, but I am still pretty confused about what I need to configure where in regards to the various Interfaces. Perhaps some Kind Person can elaborate on this.
OSPF Hello messages are sent over multicast by default. However, IPSec does not support multicast over a VPN tunnel. Consequently, OSPF adjacency using multicast cannot be established over IPSec VPN tunnels. Cisco ASA provides a solution to this problem by supporting the configuration of statically defined neighbors with the neighbor command. With the neighbor command, the Cisco ASA communicates with its peers using the unicast packets. This allows the OSPF messages to be successfully encrypted and sent over the VPN tunnel. This is similar to the neighbor command in Cisco IOS routers.
The OSPF neighbors can be defined only on nonbroadcast media. Because the underlying physical media is Ethernet (broadcast), the media type must be changed to nonbroadcast under the interface configuration. This would override the default physical broadcast media type. Example 6-19 demonstrates how to use the neighbor command for an IPSec peer located at 126.96.36.199.
Chicago(config)# router ospf 1 Chicago(config-router)# neighbor 188.8.131.52 interface outside INFO: Neighbor command will take effect only after OSPF is enabled and network-type is configured on the interface
Notice the warning message in Example 6-19. The command will not take effect until the network type is changed to nonbroadcast under the interface. Use the ospf network point-to-point non-broadcast interface command to accomplish this. Example 6-20 demonstrates this command.
Chicago(config-router)# interface GigabitEthernet0/0 Chicago(config-if)# ospf network point-to-point non-broadcast
Additionally, OSPF expects neighbors to belong to the same subnet. The subnet requirement is overlooked for point-to-point links. Because the IPSec site-to-site VPN tunnels are considered a point-to-point connection, the previous command provides the solution to this problem. Only one neighbor can be configured on a point-to-point link.
Once an interface is declared to be a point-to-point nonbroadcast link, it cannot form adjacencies unless neighbors are configured explicitly.
If OSPF is configured to run over a site-to-site IPSec tunnel, then that same interface cannot form an OSPF neighbor with the directly connected router.
On IPSec site-to-site and remote-access VPN configurations, you can optionally use reverse route injection (RRI). RRI is a feature on the Cisco ASA that provides a solution for topologies that require encrypted traffic to be diverted to the Cisco ASA and all other traffic to be sent to a separate router. In other words, RRI eliminates the need to manually define static routes on internal routers or hosts to be able to send traffic to remote site-to-site connections or remote-access VPN connections. RRI is not required if the Cisco ASA is used as the default gateway and all traffic passes through it to get into and out of the network.
There are several advantages to running OSPF over an IPSec VPN tunnel instead of using RRI. One of the major advantages is that when RRI is used, the routes to the remote networks or hosts are always advertised to the internal network, regardless of whether or not the VPN tunnel is operational. When using OSPF over an IPSec site-to-site tunnel, the routes to the remote networks or hosts are advertised only if the VPN tunnel is operational.
I would imagine that the IP address of the Gi1/2 would be what you would want for the neighbor command.
BTW, the ip OSPF network command on your IOS box is P2M non-broadcast, and doesn't match the network type on the ASA. That might also be flummoxing the works.