Community discussions

 
aaronbla
just joined
Topic Author
Posts: 5
Joined: Sat Jun 04, 2016 12:00 am

OSPF Multicast over EoIP

Tue Mar 21, 2017 6:57 pm

is anyone aware of multicast issues over EoIP tunnels? That or is there a better way to design this?

We have 16 locations all with CCR 1036s running either v6.34.6 or 6.36.4. All CCRs have EoIP tunnels to all other CCRs creating a broadcast domain. We attach the tunnels to a bridge interface and assign it a private address of 100.64.255.x/24. We then run OSPF on the 100.64.255.x/24 range but that's where our issues start. All CCRs can ping each other via the 100.64.255.x and our tunnels are up but not all of them are OSPF neighbors. Each CCR should have 15 neighbors and some do both then others only have 7-10 with many of the neighbors that they have constantly changing states.

When I log into one of the CCRs having this issue and run a pcap it only sees multicasts from the handful of neighbors it already has. However I know that the neighbors it doesn't have are sending hellos into the same broadcast domain because other routers are seeing those hellos and establishing relationships.

We have disabled spanning tree on the bridge and we run Split Horizon to prevent loops. We have also manually set the MAC addresses of all tunnels and bridges to make sure there wasn't a duplicate.

Here is an example OSPF config. We are running all of this inside a VRF.

/routing ospf instance
set [ find default=yes ] redistribute-connected=as-type-1 router-id=\
100.64.255.13 routing-table=MPLS use-dn=no
/routing ospf network
add area=backbone network=100.64.255.0/24

EoIP Tunnel

0 R name="From_x.x.x.x_To_x.x.x.x" mtu=auto actual-mtu=1458
l2mtu=65535 mac-address=00:00:5E:80:08:00 arp=enabled arp-timeout=auto
local-address=x.x.x.x remote-address=x.x.x.x tunnel-id=77
dscp=inherit clamp-tcp-mss=yes dont-fragment=no allow-fast-path=no

Bridge interface

0 R name="Mesh" mtu=1500 actual-mtu=1500 l2mtu=65535 arp=enabled
arp-timeout=auto mac-address=00:00:5E:80:08:0C protocol-mode=none
priority=0x8000 auto-mac=yes admin-mac=00:00:5E:80:08:0C
max-message-age=20s forward-delay=15s transmit-hold-count=6
ageing-time=5m

Note that all the CCRs are on the same ISP and are able to ping each other via the public connections as well.
You do not have the required permissions to view the files attached to this post.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: OSPF Multicast over EoIP

Tue Mar 21, 2017 8:43 pm

If you plan to use OSPF like this, bridging them all together is a bad idea.

For starters, you're probably running STP to prevent bridge loops. Whichever site is the bridge will carry all traffic between the sites, regardless of what OSPF thinks.

(EDIT: I see you're using split horizon, which is going to cause even more headaches for something like this.)

So if You have HUB site, and remote sites A, B, and C - if something at Site A talks to something at site B, it will go to HUB site first and then from HUB to B.
OSPF won't know this is the case because it can only see that they're all "directly" connected on a "LAN"

Since you have a full mesh of tunnels already, and you're looking to make all of the sites speak OSPF, you're much much better off just un-bridging the tunnels from each other, and putting /30 IP addressing onto each individual link and letting OSPF form adjacencies directly with each other. It will be the most efficient use of your bandwidth.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
User avatar
petrb
Frequent Visitor
Frequent Visitor
Posts: 96
Joined: Thu Jan 26, 2017 4:17 pm

Re: OSPF Multicast over EoIP

Tue Mar 21, 2017 10:24 pm

idea: agree with zerobyte ... you use split horizon and multicast - it's not good combination. Best way is use /30 or you can try configure ospf as nbma network and define neighbors.
Did you read manual? .... What? .... Read the manual.
 
w0lt
Member
Member
Posts: 484
Joined: Wed Apr 02, 2008 2:12 pm
Location: Minnesota USA

Re: OSPF Multicast over EoIP

Tue Mar 21, 2017 10:45 pm

I use EoIP (IPSec) to connect my sites.
Each site has it's own subnet.
I use a separate /30 to assign to the EoIP interfaces on each end link.
Once established, I use PIM-SM to connect multicast through them.
Works perfectly.
Been working for years.
(That said, it did take a little work to get the configuration right though :D )

-tp
MTCNA - 2011

" The Bitterness of Poor Quality Remains Long After the Sweetness of Low Price is Forgotten "

Image
 
aaronbla
just joined
Topic Author
Posts: 5
Joined: Sat Jun 04, 2016 12:00 am

Re: OSPF Multicast over EoIP

Wed Mar 22, 2017 9:42 pm

Thanks to everyone who responded. We had played with the idea of doing /30s on all the tunnels and setting up OSPF that way. We may still go that direction but there is some debate as to if its just going to be easier to mange static routing at that point.

We did flip OSPF over to NBMA and set all the static neighbors on every router. With this setup I'm learning all of the correct routes and my routing table has been stable. The one thing I'm not sure about is a dr other router will only establish a neighbor with the DR and BDR. I've never ran OSPF this way but from what I'm reading so far that seems to be the correct operation for NBMA? If that's the case then on a remote router I'd only need to build static neighbors for the DR and BDR?
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: OSPF Multicast over EoIP

Fri Mar 24, 2017 4:26 pm

The one thing I'm not sure about is a dr other router will only establish a neighbor with the DR and BDR. I've never ran OSPF this way but from what I'm reading so far that seems to be the correct operation for NBMA?
That's how any multi-access OSPF inerface works. the routers only communicate with the DR and BDR. This cuts down the number of LSAs that must be sent and reduces the CPU load on the routers by minimizing the number of conversations they have to maintain with other routers.

The big difference with NBMA is that it requires manualy-configured static neigbors and the routes propagated will actually point to the DR in the routing table, whereas normal broadcast area routes will point directly at the actual next-hop neighbor. NBMA also uses unicast hellos where broadcast networks use the 224.0.0.2 multicast group to send hellos.

NBMA was designed for things like X.25 / Frame Relay / ATM where you don't necessarily provision direct paths between all nodes. On these types of connections, the spokes may not be able to directly send and receive data to each other, but must communicate via a hub site. This mode of OSPF takes that into account.
We may still go that direction but there is some debate as to if its just going to be easier to mange static routing at that point.
My $0.02's worth is to say that the NBMA is a bad way to go. It adds extra work for you to maintain it (you must also provision the neighbors in OSPF manually) and it could lead to sub-optimal routing (if I'm right in remembering how NBMA tweaks routes). You already maintain a full mesh of tunnel configs, so you can make the OSPF side "just magically figure it out." Suppose that all of your /30s come from the same supernet (e.g. all of them are subnets of 172.16.0.0/16) then you can just make one network statement : 172.16.0.0/16 area=backbone : in each router. This way, all tunnel interfaces will automatically be added to OSPF as you add/remove them. Plus I think (I could be wrong) that the NBMA behavior will route your traffic via whichever site is the DR, even if sites X and Y have a direct tunnel between them.
When given a spoon,
you should not cling to your fork.
The soup will get cold.

Who is online

Users browsing this forum: No registered users and 9 guests