Hello,
I will try to answer all your questions in this post.
so i want r2 and r3 to advertise that peer ip address to r1, so r1 knows how to reach it via either r2 or r3.. therefore r2 and r3 need no connectivity between them
I see... Hmmm... Well, the configuration I have suggested will not prevent r2 and r3 from mutually learning about their networks, because r2 will tell r1 and r1 in turn will tell r3 - and vice versa. Are you OK with this?
are the neighbor statements necessary in this configuration?
Yes, they are. With non-broadcast network type, OSPF does not sent multicast Hello packets to dynamically discover neighbors. The only way for a router to know who its neighbors are on a non-broadcast network type is to define them using the neighbor statement. Without it, the adjacencies would not go up at all.
also can i use a 0.0.0.0 wildcard on the network statement to make it more specific?
Yes, of course.
would the ipsec configuration on the outside interface of r1 interfere somehow with this config?
I do not think so - but to be completely sure, I would need to see the configuration.
does it matter if i set the type to non broadcast even though it's ethernet thus broadcast?
On any real network type, you can force the OSPF to treat it as a different network type. Doing that allows you to achieve a non-standard behavior of OSPF to attain specific goals, like yours in this case. Of course, you cannot just redefine a network type arbitrarily without paying attention how the underlying network infrastructure works - the OSPF may need to be specifically tweaked to work well. For example, the NBMA network type is not really suitable for Frame Relay hub-and-spoke scenarios although it is the default network type. You often have to modify the priorities to prevent spoke routers from becoming DR/BDR, manually take care about the reachability of the spokes to each other, etc.
am i simply disabling unicast messaging within ospf if i configure it manually like this?
There is more behind it than just disabling multicast OSPF messaging. However, many things that change with the PtMP-NB network type are relevant to the internal OSPF processing and database contents, and you do not have to worry about that. What you should take into consideration is that the OSPF communication will be fully in your hands by virtue of the neighbor statements, and that routers that are not manually peered together will not be able to route packets via each other directly. This means that even if r1, r2 and r3 are on the common segment, with the configuration as I suggested, packets from r3 destined to r2 will be sent via r1.
could i also create two point to point links from r1 instead of the point to multipoint so that r1 knows everything, or this a stupid thought?
That's not a bad idea at all - but what it does is merely doing on physical level what we are able to do on logical OSPF level.
can i configure the interface on r1 as point to multipoint
and r2 and r3 as point to point, since they don't need to talk to each other?
or does it have to match on all routers, i.e. point to multipoint?
Man, this is like CCIE R&S Lab Exam assignment from OSPF You would at least need to tweak the timers because PtP network OSPF timers are 10/40 (Hello/Dead) while PtMP uses 30/120. After that, the combination of PtP and PtMP should work. However, this can be considered an excessive optimization with no significant advantages so I would personally discourage doing it.
Best regards,
Peter
