|
It's about using as many resources as possible for a solution that can be solved with 'yum install rsyslog' and grep.
|
# ? Nov 29, 2015 00:29 |
|
|
# ? Apr 25, 2024 18:42 |
|
Can someone write some words about why you would ever want to use a software router/firewall like BIRD or vyOS instead of a hardware Cisco or Juniper product? I'd imagine upfront cost, expected load and need of manufacturer support are the main motivators.
|
# ? Nov 29, 2015 01:47 |
|
Methanar posted:Can someone write some words about why you would ever want to use a software router/firewall like BIRD or vyOS instead of a hardware Cisco or Juniper product?
|
# ? Nov 29, 2015 07:14 |
|
I wouldn't have an issue using a firewall virtual appliance as long as it was being deployed into a stable environment. You can back them up with whatever you currently back VMs up with, easily deploy a fresh image and move configuration across for larger software updates, and take an exact clone for diagnostic purposes without having to work in a maintenance window or risk causing service interruptions. On your manufacturer support point, loads of the large vendors are doing virtual appliances now - Juniper have vSRX, F5 do virtual appliances, Palo Alto do etc. It's not a choice between big vendor hardware with support contract or virtual appliance with community support. Thanks Ants fucked around with this message at 12:35 on Nov 29, 2015 |
# ? Nov 29, 2015 12:32 |
|
Software routers can also have a better price/performance ratio for certain tasks that require a lot of control plane resources, such as a route server with many full views or complex filters.
|
# ? Nov 29, 2015 20:27 |
|
Methanar posted:Can someone write some words about why you would ever want to use a software router/firewall like BIRD or vyOS instead of a hardware Cisco or Juniper product? I usually come across software firewalls and routers at customers who were too cheap to spring for even a Ubiquiti or Mikrotik and have suffered for it. It's far more common in organizations that have no network engineering team and dump the task on sysadmins. That's not to say there aren't other use cases, but that's probably by far and away the most common one. The other major one is when you're setting up a jump box or SSH proxy to a secured enclave and are running IPTables for an added layer of security on the proxy itself.
|
# ? Nov 30, 2015 02:21 |
|
It would depend on the throughput that you're looking for through the firewall, and the featureset. A lot of our customers seem to want to just paste a firewall in as their router, which does little, but then ram 1, 2,+ GBps through it using it as an ACL. Depending on your appliance provisioning costs it may be easier to get them to barf up for the hardware and license and let that do its thing instead of letting it chew up your VM cluster resources.
|
# ? Nov 30, 2015 06:29 |
|
Methanar posted:Can someone write some words about why you would ever want to use a software router/firewall like BIRD or vyOS instead of a hardware Cisco or Juniper product? I do a lot of QoS by IP source/destination since I can't really control layer-2 100% of the time. The cost of fully redundant Cisco or Juniper core could be as high as 10x more than a comparable cluster of (effectively disposable) soft routers.
|
# ? Nov 30, 2015 08:45 |
|
Methanar posted:Can someone write some words about why you would ever want to use a software router/firewall like BIRD or vyOS instead of a hardware Cisco or Juniper product? There are some interesting notes by Google or about Google or Facebook somewhere. Basically Cisco are completely unable to solve their network issues for any amount of money, and you know if they could it would be not even remotely financially viable.
|
# ? Nov 30, 2015 17:32 |
|
Google and Facebook design their own network hardware for their data centers.
|
# ? Nov 30, 2015 17:49 |
|
psydude posted:Google and Facebook design their own network hardware for their data centers. That's not -entirely- true. They're still buying normal (huge) switches etc, but they don't bother with much of the processing/routing capabilities of those units since they're writing their own routing engines and farming it off to much cheaper x86 commodity processing.
|
# ? Nov 30, 2015 19:56 |
|
Don't forget about modifying routing tables by external programs. Think of anti-ddos applications and related apps that need to inject routes into bgp and the like.
|
# ? Nov 30, 2015 20:24 |
|
Like anything else it's usually way easier to just scale way over your application requirements when you can. Unfortunately, not everything in the field of data networking scales well, adapts in a timely manner, or is readily distributable. Unfortunately for legacy designs, the "throw a bigger pipe at it" idea no longer always works.
|
# ? Dec 1, 2015 01:56 |
|
CrazyLittle posted:That's not -entirely- true. They're still buying normal (huge) switches etc, but they don't bother with much of the processing/routing capabilities of those units since they're writing their own routing engines and farming it off to much cheaper x86 commodity processing. Yeah. They still use a lot of Cisco and Juniper at the edge and at their PoPs (and I'd imagine for their corporate networks). Their internal DC stuff is a lot of home baked stuff running crazy rear end SDN poo poo.
|
# ? Dec 1, 2015 02:42 |
|
psydude posted:Yeah. They still use a lot of Cisco and Juniper at the edge and at their PoPs (and I'd imagine for their corporate networks). Their internal DC stuff is a lot of home baked stuff running crazy rear end SDN poo poo. https://gigaom.com/2014/11/14/facebook-shows-the-promise-of-sdn-with-new-networking-tech/ Yeah this clears things right up.
|
# ? Dec 1, 2015 05:02 |
|
I've been out of the networking game for a while but that might make more sense if you look up "spine leaf topology". Usually you hear it alongside TRILL or any of the other new attempts at making STP obsolete -- the 'short version' I got from some quick reading was that you basically take IS-IS and tone it way down and run it at layer 2 and you keep all of a logically significant section of layer 2 at full mesh. I think cisco's implementation of this is called FabricPath or similar, and people generally refer to full mesh layer 2 as "fabric" because it's a lot of links, sort of like fabric. My old boss was pretty excited about it as a storage engineer because apparently layer 2 hops are pretty expensive when you're running really dense VM clusters, and especially moving VMs around and poo poo. The idea with spine leaf was to minimize layer 2 hops between virtualization resources and storage to increase performance. I think. It's not really my job anymore and even when it was it's gated behind hardware purchases, so it was never worth considering. Maybe someone else can elaborate or correct me here.
|
# ? Dec 1, 2015 05:38 |
|
You're close, but TRILL/FabricPath are being phased out in favor of VXLAN. Full mesh is out though, spine/leaf is supposed to provide the ability to scale east/west traffic without needing a full mesh. At this point "fabric" usually refers to spine/leaf with VXLAN/FabricPath/TRILL running. What is means for most of us is that Cisco will roll in and try to sell 6 switches instead of the 2 you actually need.
|
# ? Dec 1, 2015 14:30 |
|
Reiz posted:I've been out of the networking game for a while but that might make more sense if you look up "spine leaf topology". Usually you hear it alongside TRILL or any of the other new attempts at making STP obsolete -- the 'short version' I got from some quick reading was that you basically take IS-IS and tone it way down and run it at layer 2 and you keep all of a logically significant section of layer 2 at full mesh. I think cisco's implementation of this is called FabricPath or similar, and people generally refer to full mesh layer 2 as "fabric" because it's a lot of links, sort of like fabric. Actually a lot of the newer stuff ends up running BGP with VXLAN. Here's a paper on a Cisco implementation: http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/guide-c07-734107.html Fabricpath/QFabric/TRILL/Whatever Brocade's fabric is called have basically been obsoleted by encapsulating L2 into L3. The Cisco 9k line is a perfect example of this and I think even the 7k supports VXLAN these days. I like to think of Fabricpath as the Sony Minidisk in an era of MP3 (VXLAN, NV-GRE, and STT). Sure, minidisc is more convenient than LPs and tape but now I can carry a billion songs on a mobile phone so who gives a poo poo. FabricPath itself actually uses a custom frame which basically stuffs a standard ethernet frame into a FabricPath frame with it's own loop prevention/forwarding behavior.
|
# ? Dec 2, 2015 09:50 |
|
Methanar posted:
Eh. It's not absurdly complex, but it is non intuitive. I'm at a large ad-tech company and we have a similar topology (that I designed) 2x40g tor uplinks, with the ability to scale to 4. If we exceeded 100 Hadoop pods of 120 servers each we'd redesign to run bgp, currently at 40. Look up clos fabrics and its mathematically the best way to do a datacenter made up of hundred of thousands of nodes.
|
# ? Dec 3, 2015 01:50 |
|
I'm dealing with an old-rear end Cisco ASA 5520 (not the -X series, the originals). My boss wants me to update it to the latest software, but it's so drat old it has the original 64MB flash card which only has room for one OS image and one ASDM image. Is it safe to delete the images from a running system, copy over the new ones, update the config, and reload? I'd assume they're already loaded into RAM, but don't really want to test this in production. Either way I'm going to recommend that we just buy a larger flash card, since YOLOing with no rollback possible sounds awful. But I want to present him with all of the options. Docjowles fucked around with this message at 19:50 on Dec 3, 2015 |
# ? Dec 3, 2015 19:47 |
|
Docjowles posted:I'm dealing with an old-rear end Cisco ASA 5520 (not the -X series, the originals). My boss wants me to update it to the latest software, but it's so drat old it has the original 64MB flash card which only has room for one OS image and one ASDM image. Is it safe to delete the images from a running system, copy over the new ones, update the config, and reload? I'd assume they're already loaded into RAM, but don't really want to test this in production. 9.1(6) has some specific RAM and flash requirements. You'll probably have to upgrade both. http://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/product_bulletin_c25-586414.html
|
# ? Dec 3, 2015 20:06 |
|
Powercrazy posted:Eh. It's not absurdly complex, but it is non intuitive. I'm at a large ad-tech company and we have a similar topology (that I designed) 2x40g tor uplinks, with the ability to scale to 4. If we exceeded 100 Hadoop pods of 120 servers each we'd redesign to run bgp, currently at 40. Yeah, at that point the most complex part just seems to be "how do I display this on paper?"
|
# ? Dec 3, 2015 20:10 |
|
psydude posted:9.1(6) has some specific RAM and flash requirements. You'll probably have to upgrade both. Somehow the box already has 2GB of RAM. And is already on 9.1(1). It just has this tiny-rear end CF card so I can't upgrade further. I'm guessing whatever VAR we bought it from years ago flashed it up for us using an external card and then pulled it after delivery or something. code:
|
# ? Dec 3, 2015 20:24 |
|
You could buy a bigger CF card for about $12 and throw both images and the configs on there. I've done that for customers before.
|
# ? Dec 3, 2015 20:45 |
|
Docjowles posted:I'm dealing with an old-rear end Cisco ASA 5520 (not the -X series, the originals). My boss wants me to update it to the latest software, but it's so drat old it has the original 64MB flash card which only has room for one OS image and one ASDM image. Is it safe to delete the images from a running system, copy over the new ones, update the config, and reload? I'd assume they're already loaded into RAM, but don't really want to test this in production. You could go with replacing the image on the card, and use ROMMON recovery if something goes awry.
|
# ? Dec 3, 2015 21:14 |
|
psydude posted:You could buy a bigger CF card for about $12 and throw both images and the configs on there. I've done that for customers before. This is the plan. You can just use any rando CF card, it doesn't have to be a ~~~CISCO CERTIFIED~~~ $500 256MB one, right?
|
# ? Dec 3, 2015 21:26 |
|
Docjowles posted:This is the plan. You can just use any rando CF card, it doesn't have to be a ~~~CISCO CERTIFIED~~~ $500 256MB one, right? I bought a handful of them off ebay to cover the few Cisco routers we have running. Had one of the old 64mb ones poo poo the bed on me.
|
# ? Dec 3, 2015 21:30 |
|
Docjowles posted:This is the plan. You can just use any rando CF card, it doesn't have to be a ~~~CISCO CERTIFIED~~~ $500 256MB one, right? Yep, basically.
|
# ? Dec 3, 2015 21:42 |
|
CrazyLittle posted:Yeah, at that point the most complex part just seems to be "how do I display this on paper?" Or more germane, how do I display link utilization for our NOC...
|
# ? Dec 3, 2015 22:20 |
|
Docjowles posted:Somehow the box already has 2GB of RAM. And is already on 9.1(1). It just has this tiny-rear end CF card so I can't upgrade further. I'm guessing whatever VAR we bought it from years ago flashed it up for us using an external card and then pulled it after delivery or something. If the hardware meets the requirements for the image, you can delete the old one while its running and load the new one on. Highly recommended to be console cabled. Make triple sure your hardware is strong enough or woe be unto you. Does it have a second cf card slot? If so you can load another image to that card and boot to it. Oh andif it needed to be said, you have to reload the ASA to use the new image. Plan downtime of five minutes minimum. Bigass Moth fucked around with this message at 22:43 on Dec 3, 2015 |
# ? Dec 3, 2015 22:22 |
|
I don't know that this fits here, but I just configured (in GNS3) a super basic, statically-routed network with 3 routers and VCPCs as the end-points. 10.0.0.0/30 for "WAN" links, 192.168.x.x as the various endpoint networks. Seeing those pings gradually start working regardless of their destination as I configured routes on all the individual routers was so rewarding. I saved my project in GNS3 planning to go back into it, which requires you to shut down all devices. Went back into it later, and none of my interfaces are working. Forgot to do copy running-config startup-config. Oops. Rite of passage? Oh well, get to do it all over again and maybe this time I'll use OSPF. My biggest mistake in studying for CCNA was not getting lab'ing stuff sooner.
|
# ? Dec 3, 2015 23:51 |
|
Japanese Dating Sim posted:I don't know that this fits here, but I just configured (in GNS3) a super basic, statically-routed network with 3 routers and VCPCs as the end-points. 10.0.0.0/30 for "WAN" links, 192.168.x.x as the various endpoint networks. There are many rites of passage. Just typing "copy run start" and closing your Putty window when your particular box actually wants "write mem" is a personal favorite (show cli history caught this one!). Also "switchport trunk allowed vlan x add".
|
# ? Dec 4, 2015 01:11 |
|
I'm guilty of switchport trunk allowed vlan add x. Best part is I was working from home and my internet service went down right afterward, so I spent the next 5 minutes furiously racking my brain and trying to figure out how dropping the other vlans would sever my connection and pondering just how bad of an outage I had just caused. Then my boss calls me and tells me we've lost connectivity on every VM on whatever host that port was attached to, probably the least appropriate "oh, good!" I've ever said. I had just finished doing the exact same thing to 11 other ports because I wasn't allowed to use rancid for that job and was just flying through with tab autocomplete. Don't be like me.
|
# ? Dec 4, 2015 01:59 |
|
Reiz posted:I'm guilty of switchport trunk allowed vlan add x. I really need to get around to implementing do_auth on our tacacs servers, to force the use of add/remove through command authorization.
|
# ? Dec 4, 2015 02:10 |
|
madsushi posted:Also "switchport trunk allowed vlan x add". Reiz posted:I'm guilty of switchport trunk allowed vlan add x. wait, what platform/version is that? Looking through my config repo I'm seeing nothing but the latter syntax. "trunk allowed vlan add ###"
|
# ? Dec 4, 2015 08:16 |
|
You haven't lived until you've rommon confreged and forgotten the 0x...
|
# ? Dec 4, 2015 09:56 |
|
Methanar posted:Can someone write some words about why you would ever want to use a software router/firewall like BIRD or vyOS instead of a hardware Cisco or Juniper product? There's actually at least one virtual router that Cisco makes itself: http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/datasheet-c78-734034.html I saw a presentation about this that I probably should have paid more attention to but I recall one of the use cases being "we want all the same features and CLI, but don't need the same scale/performance numbers that a physical box would provide."
|
# ? Dec 4, 2015 22:19 |
|
Virtual routing within a virtual host actually increases throughput to the speed of the host's backplane. Try doing iperf between adjacent VMs for a good laugh.
|
# ? Dec 5, 2015 00:05 |
|
CrazyLittle posted:wait, what platform/version is that? Looking through my config repo I'm seeing nothing but the latter syntax. "trunk allowed vlan add ###" NX-OS / Nexus. I think it is "trunk allowed vlan add x"!
|
# ? Dec 5, 2015 00:50 |
|
|
# ? Apr 25, 2024 18:42 |
|
Reiz posted:I'm guilty of switchport trunk allowed vlan add x. Best part is I was working from home and my internet service went down right afterward, so I spent the next 5 minutes furiously racking my brain and trying to figure out how dropping the other vlans would sever my connection and pondering just how bad of an outage I had just caused. In my last job I worked with Fortigates a lot and built up a significant amount of FortiOS muscle memory. This is hazardous because you get used to typing sh whilst in config mode which on FortiOS shows the running configuration within your current context. Of course doing the same thing on IOS in interface config mode leads to hilarious results.
|
# ? Dec 5, 2015 08:29 |