I have another few links to play with, but honestly, I'm probably just going to go with static neighbor definitions going forward.
I mean, I pretty much have two types of links that I need to run OSPF over, and I don't really trust either:
- Some flavor of metro-ethernet delivered over PON, which means I'm on a network that's primarily for small/medium businesses and probably has only a handful of customers running any kind of non-DIA traffic. And the last hop in that setup is some little GPON ONT that is basically disposable hardware. I would not bet any sort of money on what the ONT or the OLT boxes do to multicast traffic. I would not bet any sort of money that those managing that network care about this.
- Links over wireless gear built for the WISP industry. Sure, it's supposed to be a transparent bridge, but again, do I trust Ubiquiti has multicast handled right in their very-modified fork of DD-WRT? Do I dare inquire as to what the "multicast enhancement" checkbox on the "Network" tab of the config does? On the IgniteNet MetroLinq 60GHz gear, do I trust that their fork of DD-WRT is doing sane things with multicast? I mean, it's nice gear and where else can I get links between buildings at more than 1Gb/s for just over $1K for both ends? But are they doing the "right thing" when they tie the wireless interface(s) (there's a 5GHz backup radio) and the ethernet interface into a bridge interface WRT multicast?
I'm just not sure I want to go down either rabbit hole. Somewhere on my bookshelf I actually have some old Cisco Press book on OSPF, I had a decent understanding of it, but that was when I was running it over frame relay and ATM links and I was full-time with an ISP and spent at least 50% of my day on the network side of things. This nonsense of troubleshooting OSPF over transports with unknown properties sounds like as much fun as chasing down modem drops in the dialup days.
I mean, I pretty much have two types of links that I need to run OSPF over, and I don't really trust either:
- Some flavor of metro-ethernet delivered over PON, which means I'm on a network that's primarily for small/medium businesses and probably has only a handful of customers running any kind of non-DIA traffic. And the last hop in that setup is some little GPON ONT that is basically disposable hardware. I would not bet any sort of money on what the ONT or the OLT boxes do to multicast traffic. I would not bet any sort of money that those managing that network care about this.
- Links over wireless gear built for the WISP industry. Sure, it's supposed to be a transparent bridge, but again, do I trust Ubiquiti has multicast handled right in their very-modified fork of DD-WRT? Do I dare inquire as to what the "multicast enhancement" checkbox on the "Network" tab of the config does? On the IgniteNet MetroLinq 60GHz gear, do I trust that their fork of DD-WRT is doing sane things with multicast? I mean, it's nice gear and where else can I get links between buildings at more than 1Gb/s for just over $1K for both ends? But are they doing the "right thing" when they tie the wireless interface(s) (there's a 5GHz backup radio) and the ethernet interface into a bridge interface WRT multicast?
I'm just not sure I want to go down either rabbit hole. Somewhere on my bookshelf I actually have some old Cisco Press book on OSPF, I had a decent understanding of it, but that was when I was running it over frame relay and ATM links and I was full-time with an ISP and spent at least 50% of my day on the network side of things. This nonsense of troubleshooting OSPF over transports with unknown properties sounds like as much fun as chasing down modem drops in the dialup days.
