On 2013-05-28 11:27, Glenn Kelley wrote:
Out of interest - why RIPv2 vs OSPF ?
Simplicity of configuration and troubleshooting. It's definitely not
the best protocol for complex environments, but there are places where
OSPF is simply overkill - I've seen two OSPF deployments in my career
where some of OSPF's advanced features were needed, and maybe another
half dozen where some of those features were helpful.
In contrast, almost every single OSPF deployment I've seen or worked on
has had issues because someone set up an overly complex system that they
then tripped over later on.
I guess if link-state, service types and load balancing is not
important it may make sense -
but figured I would ask
That's a perfect example. With modern systems, "link state" is
becoming useless - at the large ISP I worked for recently, the
overwhelming majority of routed links ran into switches or radios or
some local ethernet device that did not accurately reflect link state.
Integrating BFD into the link-state logic (à la JunOS) only works if
both ends support BFD, and not much of my gear did.
Service types were irrelevant there.
Load balancing was actually a bug, not a feature, in that network.
We wound up using IS-IS for the big microwave ring because of its
ability to respond to outages and converge extremely quickly. If I
hadn't had IS-IS-capable equipment at each hop, I would have used RIPv2
with the timers set fast. OSPF interaction with the rest of our OSPF
network would have been detrimental.
Just like I often use an Intel server running pfSense instead of buying
a Cisco CRS-1 for every client, not every network needs OSPF. The
aforementioned microwave ring, although spanning ~60 L3 sites (not sure
how many L2 sites) across just over 1000km, and supporting more than
half my customer base, was logically self-contained with a single border
router.
Configuring (and troubleshooting!) a multi-area, multi-vendor OSPF
network on 100+ devices was kind of like running a Windows 95 PC: you
*don't* want to be hand-editing the registry at 3am when customers are
screaming at you.
IS-IS (or RIPv2) on 60-odd devices is like running a Mac... if it
breaks at 3am, you just go home and buy a new one tomorrow ;-).
Facetiousness aside, I've only ever had to troubleshoot IS-IS once, and
RIP (both v1 & v2) almost never. I think that's due to the simplicity:
there's nothing to go wrong!
We have migrated for our BGP implementations to use Mikrotik at the
suggestion of a key player here - and could not be happier.
Sadly our multi-honed BGP implementation had tons of issues.
Interesting... I've had exactly the opposite experience. Mikrotik
routers are, IMHO, difficult to scale up, more difficult to configure
than they need to be, and have been surprisingly (as in,
biting-me-in-the-ass-surprisingly) feature-incomplete in surprisingly
critical places. I agree they do have a place, and they're not
inherently bad products... I've just had poor luck with them.
Internally however - I still think pfSense Rocks !
We have a large number of pfsense running virtualized in ProxMox for
clients - most who elected to use PFSense vs. vyatta after we showed
them the ease of use.
Some anecdotal evidence suggests Vyatta can scale to significantly
higher aggregate throughput than pfSense. I don't know of any
head-to-head comparisons on identical hardware, though, nor have I run
direct comparisons myself. Note that I have pfSense in production, but
not Vyatta - again, I don't need those features. (Or, rather, when I
do, I just go and buy a Cisco ASR or Juniper MX.)
-Adam
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
