Barracuda vs Meraki - firewalls
-
@storageninja said in Barracuda vs Meraki - firewalls:
@dustinb3403 said in Barracuda vs Meraki - firewalls:
ou can include your wireless equipment and optical GPON devices as well
My understanding is it manages their WISP targeted (AirMax) and EdgeSwitch and not their Commercial/enterprise focused UniFI. The edge line of firewall/routers also lack any layer 7 content etc filtering.
Correct for UniFi devices, it will simply link you to the UniFi controller, while supplying minimal status information.
-
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
-
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
SDWAN is a hell of a lot more than VPN tunnels...
- Link bonding. Mix MPLS/Cable/T1/4G etc.
- Per packet routing. Have the same session use multiple links depending on requirements...
- Jitter management for the above. Can strategically use buffer bloat to make 2 similar segments match on one way latency (Inflate the lower link to match the higher one). This reduces the need for packet re-odrering (expensive from a compute basis).
- Per segment monitoring. Latency isn't symmetric. Using things like 2 party clock synchronization and packet tagging you can measure with packet stamps in real time the one way latency of a link (Critical to keep jitter under control).
- Automated rules engines with multiple factors that can even handle encrypted. Massive centrally collected rules engines based on destination IP, Ports, CNAME on SSL Cert for encrypted, packet headers if not encrypted etc.
- Packet loss mitigation. For bulk media store and re-forward to avoid TCP retransmits keep throughput up. More sensitive real time protocols that are narrower can benefit from duel transmit (send packet down both links) as well as parity injected into packet streams.
Reason why you would pay a 3rd party....
-
Management of hardware for disparate links. Someone to deal with all the 4G cards, Cable Modems etc.
-
Management of billing. Having to sort and verify through billing for 5 different carriers
-
Awareness of options and scale. WAN resellers who do this for a living tend to aggregate a lot more demand and can get better pricing, as well as already have the fiber maps and quote tooling backend hooks for the tier 1 players so they can quickly identify the best options for each site.
Here's the dirty secret about not wanting to deal with someone else reselling someone else's links.... You always are. Thats how the internet (and wireless Networks) work. Everyone is leasing lines and transit from everyone.
-
@storageninja said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
SDWAN is a hell of a lot more than VPN tunnels...
- Link bonding. Mix MPLS/Cable/T1/4G etc.
- Per packet routing. Have the same session use multiple links depending on requirements...
- Jitter management for the above. Can strategically use buffer bloat to make 2 similar segments match on one way latency (Inflate the lower link to match the higher one). This reduces the need for packet re-odrering (expensive from a compute basis).
- Per segment monitoring. Latency isn't symmetric. Using things like 2 party clock synchronization and packet tagging you can measure with packet stamps in real time the one way latency of a link (Critical to keep jitter under control).
- Automated rules engines with multiple factors that can even handle encrypted. Massive centrally collected rules engines based on destination IP, Ports, CNAME on SSL Cert for encrypted, packet headers if not encrypted etc.
- Packet loss mitigation. For bulk media store and re-forward to avoid TCP retransmits keep throughput up. More sensitive real time protocols that are narrower can benefit from duel transmit (send packet down both links) as well as parity injected into packet streams.
None of those things are SD-WAN. Those things CAN be, but they CAN be part of non-SD-WAN too. A VPN can be required to do all of that. These kinds of assumptions are bad, because people get expectations of a technology that does not imply them.
-
@storageninja said in Barracuda vs Meraki - firewalls:
Reason why you would pay a 3rd party....
-
Management of hardware for disparate links. Someone to deal with all the 4G cards, Cable Modems etc. Solution looking for a problem, what management is needed here?
-
Management of billing. Having to sort and verify through billing for 5 different carriers Not a real thing, SD-WAN doesn't address this, you still have to pay all those people PLUS the sixth company, the one with the WAN.
-
Awareness of options and scale. WAN resellers who do this for a living tend to aggregate a lot more demand and can get better pricing, as well as already have the fiber maps and quote tooling backend hooks for the tier 1 players so they can quickly identify the best options for each site. This can be done without the SD-WAN, this is not really a benefit of the service offering but of going through a broker in general.
Here's the dirty secret about not wanting to deal with someone else reselling someone else's links.... You always are. Thats how the internet (and wireless Networks) work. Everyone is leasing lines and transit from everyone. Sure, but not really related to SD-WAN.
-
-
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@storageninja said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
SDWAN is a hell of a lot more than VPN tunnels...
- Link bonding. Mix MPLS/Cable/T1/4G etc.
- Per packet routing. Have the same session use multiple links depending on requirements...
- Jitter management for the above. Can strategically use buffer bloat to make 2 similar segments match on one way latency (Inflate the lower link to match the higher one). This reduces the need for packet re-odrering (expensive from a compute basis).
- Per segment monitoring. Latency isn't symmetric. Using things like 2 party clock synchronization and packet tagging you can measure with packet stamps in real time the one way latency of a link (Critical to keep jitter under control).
- Automated rules engines with multiple factors that can even handle encrypted. Massive centrally collected rules engines based on destination IP, Ports, CNAME on SSL Cert for encrypted, packet headers if not encrypted etc.
- Packet loss mitigation. For bulk media store and re-forward to avoid TCP retransmits keep throughput up. More sensitive real time protocols that are narrower can benefit from duel transmit (send packet down both links) as well as parity injected into packet streams.
None of those things are SD-WAN. Those things CAN be, but they CAN be part of non-SD-WAN too. A VPN can be required to do all of that. These kinds of assumptions are bad, because people get expectations of a technology that does not imply them.
Bullshit. Those things all together are what makes it SD-WAN instead of some random guy trying to say all of his Ubiquiti ERLs with IPSEC tunnels are SD-WAN, because they are not.
@StorageNinja is exactly right on this.
-
@jaredbusch said in Barracuda vs Meraki - firewalls:
Bullshit. Those things all together are what makes it SD-WAN instead of some random guy trying to say all of his Ubiquiti ERLs with IPSEC tunnels are SD-WAN, because they are not.
@StorageNinja is exactly right on this.SD-WAN in general simplifies management at large scale (and nore than just the devices, but also the links), optimizies performance in ways BGP, Shaping DSCP alone can't (and with a 1000x less work, no need for bespoke optimizations), enables unlimited choice on the WAN links without unlimited management hell as you try to deal with 10 different CLEC providers, and brings costs down for CPE gear (Virtualized, x86 rather than proprietary ASICs).
-
@jaredbusch said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@storageninja said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
@jt1001001 said in Barracuda vs Meraki - firewalls:
I won't do manage sd wan from the carrier ever again! Ask around here how much I love carriers!
OH yeah, such a bad idea. Just a VPN that you don't control and pay a fortune for.
SDWAN is a hell of a lot more than VPN tunnels...
- Link bonding. Mix MPLS/Cable/T1/4G etc.
- Per packet routing. Have the same session use multiple links depending on requirements...
- Jitter management for the above. Can strategically use buffer bloat to make 2 similar segments match on one way latency (Inflate the lower link to match the higher one). This reduces the need for packet re-odrering (expensive from a compute basis).
- Per segment monitoring. Latency isn't symmetric. Using things like 2 party clock synchronization and packet tagging you can measure with packet stamps in real time the one way latency of a link (Critical to keep jitter under control).
- Automated rules engines with multiple factors that can even handle encrypted. Massive centrally collected rules engines based on destination IP, Ports, CNAME on SSL Cert for encrypted, packet headers if not encrypted etc.
- Packet loss mitigation. For bulk media store and re-forward to avoid TCP retransmits keep throughput up. More sensitive real time protocols that are narrower can benefit from duel transmit (send packet down both links) as well as parity injected into packet streams.
None of those things are SD-WAN. Those things CAN be, but they CAN be part of non-SD-WAN too. A VPN can be required to do all of that. These kinds of assumptions are bad, because people get expectations of a technology that does not imply them.
Bullshit. Those things all together are what makes it SD-WAN instead of some random guy trying to say all of his Ubiquiti ERLs with IPSEC tunnels are SD-WAN, because they are not.
@StorageNinja is exactly right on this.
Nope. SD-WAN exists without any of those. And I never said that they were. But SD-WAN existed and was standard before anyone associated these things with them. This is like claiming you need all of the things in a UTM to be a firewall.
Lots of SD-WAN products don't offer these features.
-
@storageninja said in Barracuda vs Meraki - firewalls:
@jaredbusch said in Barracuda vs Meraki - firewalls:
Bullshit. Those things all together are what makes it SD-WAN instead of some random guy trying to say all of his Ubiquiti ERLs with IPSEC tunnels are SD-WAN, because they are not.
@StorageNinja is exactly right on this.SD-WAN in general simplifies management at large scale (and nore than just the devices, but also the links), optimizies performance in ways BGP, Shaping DSCP alone can't (and with a 1000x less work, no need for bespoke optimizations), enables unlimited choice on the WAN links without unlimited management hell as you try to deal with 10 different CLEC providers, and brings costs down for CPE gear (Virtualized, x86 rather than proprietary ASICs).
These might be common features of a certain type of SD-WAN, but come from things outside of the SD-WAN itself. It's like confusing an implementation with the concept. If you look at Windows, you might think that an OS means a GUI because a few major implementations tie the two together, but that woudl be wrong because DOS didn't have a GUI but was an OS.
-
From Wikipedia: "SD-WAN is an acronym for software-defined networking in a wide area network (WAN). An SD-WAN simplifies the management and operation of a WAN by decoupling (separating) the networking hardware from its control mechanism. This concept is similar to how software-defined networking implements virtualization technology to improve data center management and operation."
Notice that what it IS does not guarantee or even suggest any of those things. You are working form revisionist marketing material and not what an SD-WAN actually is. Very dangerous because it makes it trivial for salesman to sell you an SD-WAN with you thinking that they sold you all this stuff, and get nothing. And they did nothing wrong, because they were being honest.
-
@scottalanmiller said in Barracuda vs Meraki - firewalls:
From Wikipedia: "SD-WAN is an acronym for software-defined networking in a wide area network (WAN). An SD-WAN simplifies the management and operation of a WAN by decoupling (separating) the networking hardware from its control mechanism. This concept is similar to how software-defined networking implements virtualization technology to improve data center management and operation."
Notice that what it IS does not guarantee or even suggest any of those things. You are working form revisionist marketing material and not what an SD-WAN actually is. Very dangerous because it makes it trivial for salesman to sell you an SD-WAN with you thinking that they sold you all this stuff, and get nothing. And they did nothing wrong, because they were being honest.
Or keep reading the wikipedia article and see that I was largely describing the feature section....
I'll argue it's pedantic to try to separate SD-WAN from Hybrid-WAN at this point as (the majority) of deployments of SD-WAN will be Hybrid-WAN. Wayyyyy to much of IT spend in companies is telco's, and the combined technologies are going to do what virutaliation in x86 did to compute, and what HCI and cloud is doing to storage.
-
To get the topic somewhat back on the rails, @bbigford I have enjoyed working with Juniper. They have at least feature equivalence with Cisco and a significantly better engineered OS (based on FreeBSD). Their pricing is significantly better than Cisco (although not in the same range as Ubiquiti).
-
@storageninja said in Barracuda vs Meraki - firewalls:
@scottalanmiller said in Barracuda vs Meraki - firewalls:
From Wikipedia: "SD-WAN is an acronym for software-defined networking in a wide area network (WAN). An SD-WAN simplifies the management and operation of a WAN by decoupling (separating) the networking hardware from its control mechanism. This concept is similar to how software-defined networking implements virtualization technology to improve data center management and operation."
Notice that what it IS does not guarantee or even suggest any of those things. You are working form revisionist marketing material and not what an SD-WAN actually is. Very dangerous because it makes it trivial for salesman to sell you an SD-WAN with you thinking that they sold you all this stuff, and get nothing. And they did nothing wrong, because they were being honest.
Or keep reading the wikipedia article and see that I was largely describing the feature section....
Yes, but you were describing possible features as defining characteristics which are wholly different things. That's how sales people trick customers all the time. Customer things X means Y, sales people know this is a common misconception, they promise X knowing the customers wants Y, customer is at fault for buying the wrong thing.
UTM and SAN are famously sold this way.
-
EVIL SALES GUY TRICK #403. DESCRIBE WHAT THE BENEFIT OF A PRODUCT RATHER THAN SIMPLY USE A VAGUE BUZZWORD
If you Limit SD-WAN to just being "a separate control mechanism" then some Cisco stuff from the 90's falls under than and it's a meaningless term.
-
@storageninja said in Barracuda vs Meraki - firewalls:
EVIL SALES GUY TRICK #403. DESCRIBE WHAT THE BENEFIT OF A PRODUCT RATHER THAN SIMPLY USE A VAGUE BUZZWORD
If you Limit SD-WAN to just being "a separate control mechanism" then some Cisco stuff from the 90's falls under than and it's a meaningless term.
It still has to be software defined, though. It's a broad term without a lot of purpose, but it is what it is. Just like software defined anything, is very broad. But being software defined is an extremely logical concept to name something, and having something that is software defined not be included because it doesn't do an arbitrary set of features doesn't make sense.
-
Most "hot new things" apply to existing technology. It's extremely rare that a new industry term arises before (or with) the invention of something. It's normally more a recognition of something that's been created. SaaS for example arose as a term decades after the idea was pioneered and at least five years after it was mainstream. But it doesn't make the things that predate the name not SaaS, it's just a super broad term.
