|
Docjowles posted:I used to work for a regional ISP (coincidentally also in Colorado). One time our marketing team sent a mailing with this sweet stealth bomber on it advertising our speeds in miles per hour Lol badass
|
#
?
Nov 15, 2023 16:42
|
|
The lead network engineer almost quit over that lol
|
|
| # ? Apr 29, 2024 02:07 |
|
|
MrMoo posted:Facebook and others use IPv6 because the headers are smaller and less processing needed in routing, something like 10% faster? The headers aren't smaller, if you're just talking about raw IP traffic. IPv4 headers are 20 bytes and IPv6 headers are 40 bytes. It's kind of hard to avoid since the source and destination addresses for v6 take up 32 bytes by themselves. That said, if you are doing some kind of extra processing or tunneling with IPv4 like NAT that you don't need with IPv6, then that could very well end up making more of a difference to the performance of whatever you're doing than the header length. I should have said "your addressing system doesn't inherently have much to do with how fast you're going, but modern networks are complicated". Eletriarnation fucked around with this message at 16:59 on Nov 15, 2023 |
|
#
?
Nov 15, 2023 16:54
|
|
|
Docjowles posted:I used to work for a regional ISP (coincidentally also in Colorado). One time our marketing team sent a mailing with this sweet stealth bomber on it advertising our speeds in miles per hour Hello? Tech support? My internet is going 55 mph and I'm concerned the data bus will explode on the information superhighway if it slows down any more
|
|
#
?
Nov 15, 2023 17:01
|
|
|
ipv6 is slower because it takes the computer longer to type the address in (it has more characters)
|
|
#
?
Nov 15, 2023 17:05
|
|
|
Eletriarnation posted:The headers aren't smaller, if you're just talking about raw IP traffic. IPv4 headers are 20 bytes and IPv6 headers are 40 bytes. Technically IPv4 headers can be up to 60 bytes, but the real issue is the number of fields that network devices need to process. IPv6 reduces that from 6 to 4. Copying bytes is "free" in an ASIC, evaluating the content is not, hence why network switches are cheaper than network routers. https://www.microsoftpressstore.com/articles/article.aspx?p=2225063&seqNum=3 uhhhhahhhhohahhh posted:ipv6 is slower because it takes the computer longer to type the address in (it has more characters) I like that devices end up with multiple addresses and some with short term lifetimes, idk how the designers of IPv6 expected the typical IT technician or network engineer to cope with that. Like most apps record a device with a single IPv4 address, now you have multiple with different lifetimes, and each one very terse to read, awesome. Because mDNS is going to actually reliably work everywhere, any day now. MrMoo fucked around with this message at 17:14 on Nov 15, 2023 |
|
#
?
Nov 15, 2023 17:10
|
|
|
MrMoo posted:Technically IPv4 headers can be up to 60 bytes. Yes, I saw that too when I went to double check myself before posting but options aren't commonly used. MrMoo posted:, but the real issue is the number of fields that network devices need to process. IPv6 reduces that from 6 to 4. Copying bytes is "free" in an ASIC, evaluating the content is not, hence why network switches are cheaper than network routers. I mean yeah that's totally valid but, and hopefully I'm not splitting hairs too finely here, I wouldn't say that "we can use a simpler forwarding architecture" is usually what people mean when they say that a network is faster. They're usually talking either about latency or bandwidth. I can understand why the article that spurred the discussion wouldn't get into this kind of detail but it was funny to me because being "faster" isn't the point of IPv6 in the first place, and outside of edge cases like "we are Actually Facebook" it indeed doesn't matter.
|
|
#
?
Nov 15, 2023 17:47
|
|
|
The real motivation for moving to IPv6 was a combination of exhaustion of addresses in the network fabric itself and the desire to do prefix delegation to tupperware hosts.
|
|
#
?
Nov 15, 2023 23:37
|
|
|
I'll be long dead before ipv6 is forced upon us all.
|
|
#
?
Nov 15, 2023 23:46
|
|
|
Also the original spec for NAT in 1994 had no concept of dynamically translating ports and just assumed that you would be able to have as many globally routable IPs on hand as your best guess was for how many internal hosts would simultaneously need to talk out to the internet. Because that scales reasonably. Then we solved that for another 20 years with port translation and then solved the unexpected explosion of always-on mobile internet access on smartphones with CGNAT.
|
|
#
?
Nov 15, 2023 23:48
|
|
|
GreenNight posted:I'll be long dead before ipv6 is forced upon us all. Buried under a pile of NAT’s. Everytime I see CG-NAT I just hear chief Wiggum in my head going “No, NAT up stupid!”
|
|
#
?
Nov 17, 2023 03:49
|
|
|
MrMoo posted:I like that devices end up with multiple addresses and some with short term lifetimes, idk how the designers of IPv6 expected the typical IT technician or network engineer to cope with that. Don't use the ephemeral addresses for anything not ephemeral? Every IPv6 device will have a link local address, those are in the fe80::/64 network and should never be used for anything long term. They're the equivalent of a 169.254 address in IPv4, just there to allow devices to communicate without any network-assigned address. In a network using SLAAC the router advertises the prefix and the host assigns itself one or two addresses depending on the OS and configuration. On older systems you'll usually get one address which is based directly on the MAC address of the interface. This address should always be the same as long as the network and NIC remain the same. At some point people realized that making the MAC address part of the global address makes it possible to uniquely identify a machine on the internet and track it across networks, so some new mechanisms were developed to choose host addresses. There's one method that generates a repeatable address based on the interface, a network identifier, and a private key unique to the host. Again the address should never change unless the network or hardware changes. These are your reliable identifiers. There's another method to generate temporary addresses that are effectively random, which are intended to be used to increase privacy for outgoing connections from devices or applications that don't care. For those who really care about assigning specific addresses to specific devices, DHCPv6 is also a thing and works more or less the same as DHCP in IPv4, your DHCP server assigns whatever address it wants to the clients and those addresses will remain the same as long as the DHCP server wants them to. Android for whatever reason explicitly does not support it, every other major platform does. tl;dr: You have more addresses to choose from on most IPv6 enabled devices, but there's still always a reliable long-lived address unless the system has gone out of its way to only use temporary addresses (technically allowed in the spec but intended for IoT type stuff not normal computers). It's not hard to keep track of IPv6 devices if you don't just assume that every address is going to be around forever. Also in the end if you're regularly entering in IP addresses of any kind something is wrong. If the thing needs to be accessed by humans it should have a DNS name (not mDNS, real DNS). Rudager posted:Everytime I see CG-NAT I just hear chief Wiggum in my head going “No, NAT up stupid!”
|
|
#
?
Nov 17, 2023 05:07
|
|
|
Docjowles posted:That was goofy but I thought it was a reasonable article overall for a random local newspaper that’s not a trade journal or anything. Unless you were breaking 700 million mph, I'm also not impressed. I scared you out of Colorado, correct? I thought you relocated but now don't remember.
|
|
#
?
Nov 19, 2023 09:56
|
|
|
Moey posted:Unless you were breaking 700 million mph, I'm also not impressed. Oh drat hey Moey, been a while. Yeah I moved to Boston in like 2015 but I actually moved back to CO last summer. Apparently the east coast doesn’t suit me anymore. You still up in the mountains?
|
|
#
?
Nov 19, 2023 10:15
|
|
|
Docjowles posted:Oh drat hey Moey, been a while. Yeah I moved to Boston in like 2015 but I actually moved back to CO last summer. Apparently the east coast doesn’t suit me anymore. You still up in the mountains? Welcome back! Yup, still in the same town. You finally cave and decide to start sliding down the mountain like a good Colorado resident?
|
|
#
?
Nov 19, 2023 15:04
|
|
|
Tetramin posted:
How'd your upgrades go? I'm in the middle of doing 6 VMs from 2.7 to 3.2 in situ.  It's semi nerve wracking and I didn't have a choice to do it any other way.
|
|
#
?
Nov 29, 2023 04:00
|
|
|
Rudager posted:Buried under a pile of NAT’s. It is still no NAT november... CGNAT loving sucks and I hated keeping it running.
|
|
#
?
Nov 29, 2023 04:17
|
|
|
Prescription Combs posted:How'd your upgrades go? I'm in the middle of doing 6 VMs from 2.7 to 3.2 in situ. It got pushed until 12/8. Luckily, because my boss mentioned to me like two days before the original time that I can hit up our partner company for some help planning it, getting my ducks in a row, and figuring out licensing. I also was able to get a fresh VM for our secondary admin node, so it looks like I’ll only need to do an upgrade to the Primary and then join all of my new VMs to the deployment. Still feeling a bit nervous about it, but after discussing the plan with our partner and now that I only will need to upgrade one server, I’m feeling way better. But yeah good luck with yours fellow goon. I would be sweating a bit in your shoes honestly, are y’all using ISE for dot1x etc? I’m curious if you’ve ran the URT and what it told you. I ran it on my 6 server deployment and it said it would be like 70 minutes per node, and were only really doing TACACs+RADIUS for our network gear. Anyway once I actually complete it next week, I’ll try to make a post about what I ran into and stuff like that. In both of our situations, I’d really say to check if you can leverage a partner relationship, get an hour with a delivery engineer to see if you can hammer out your process and ask any questions. It really made me feel a lot better.
|
|
#
?
Nov 29, 2023 05:56
|
|
|
3 of 6 are done. The last 2 were a pair and had some hangups but making them standalone I was able to get them to successfully upgrade and rejoin each other. So far, the licensing has been a piece of cake. A TAC case with serials and had them convert everything over to the Smart Virtual Account for me so I could do the specific license reservation afterwards since they're not internet connected. All these ISE servers do is TACACS and RADIUS. Whole lotta money for a buncha ISE licenses but it's what the customer wanted so it is what it is. E: between ISE and doing 4 pairs of FMCs with a swath of FTD's I'll be glad when this week is over. Prescription Combs fucked around with this message at 06:24 on Nov 29, 2023 |
|
#
?
Nov 29, 2023 06:22
|
|
|
hey guys, it's been a while. i've got a random question. last year we migrated our core switching infrastructure in our on-prem colo from a pair of 5548s and a bunch of ancient 2ks to a bunch of 9ks all throughout. at the time i wanted us to examine whether or not it made since to re-architecture everything and move to vxlan / spine&leaf since basically everything is hosted on several ucs domains anyways. i was shot down in the interest of getting poo poo down quickly as possible, and one of the network guys on the architecture team told me our environment really didn't make sense as a candidate for deploying underlay/overlay stuff. i'm not super convinced, are there huge downsides to that kind of architecture for an on-prem colo with like 30-40 racks and ~12 n9ks? we're definitely taking advantage of the end-to-end l2 stuff with vpc as it is, and everything i've read about vxlan evpn feels like a straight upgrade in terms of robustness, scalability, etc.
|
|
#
?
Jan 3, 2024 07:22
|
|
|
I think VXLAN EVPN can be a good fit if your environment is 1 or more of the following: -Very dynamic (groups of servers are constantly being deployed or torn down) -Expected to grow aggressively -Needs a high degree of segmentation between different applications and their components -Applications need very consistent latency between their components Another point of consideration is what's the labor pool look like for network people at your company, do they hire all highly-skilled people with lots of prior experience? Or are most of the new hires more on the junior side, and the expectation is that they're develop internally and promote from within? If it's the latter, a complex environment will naturally have a higher learning curve for them. If you don't have a technical or business use case for a certain technology or design, you may want to consider that it's often easier to change a network design than it is to change your company's hiring practices. One of my little personal soapboxes when it comes to technologies that provide an increasingly high level of abstraction (often through some level of automation) from what's happening underneath, it makes your distribution of failure outcomes more leptokurtic. You very tightly control and eliminate a lot of simple errors (typed the wrong VLAN tag type of stuff), but, when you do have some kind of serious fault, it ends up being a very complex, Byzantine kind of failure. It typically ends up requiring a much higher level of technical expertise to resolve, and that troubleshooting process can take much longer. It's a little bit like the thing of "would you rather fight 50 duck-sized horses, or 1 horse-sized duck?"
|
|
#
?
Jan 3, 2024 16:38
|
|
|
single-mode fiber posted:One of my little personal soapboxes when it comes to technologies that provide an increasingly high level of abstraction (often through some level of automation) from what's happening underneath, it makes your distribution of failure outcomes more leptokurtic. You very tightly control and eliminate a lot of simple errors (typed the wrong VLAN tag type of stuff), but, when you do have some kind of serious fault, it ends up being a very complex, Byzantine kind of failure. It typically ends up requiring a much higher level of technical expertise to resolve, and that troubleshooting process can take much longer. It's a little bit like the thing of "would you rather fight 50 duck-sized horses, or 1 horse-sized duck?" This is wisdom. That said, VXLAN is worth it if you have 1) at least a few people who are capable of learning it, understanding it, and maintaining it 2) control the configuration via automation and 3) enforce the use of that automation to limit config drift. It is complex, and you will have everything fall over if it isn't aggressively standardized and kept simple as you can get.
|
|
#
?
Jan 3, 2024 21:09
|
|
|
If you're getting the performance with respect to bandwidth across the current fabric with traditional ethernet (STP) and their kludges (VPC/MC-LAG), then it may not be worth the re-wiring effort to move to a leaf/spine topology.
|
|
#
?
Jan 3, 2024 22:28
|
|
|
HPE dropped a cool 14 billion and bought Juniper. RIP to the best CLI out there.
|
|
#
?
Jan 10, 2024 05:41
|
|
|
Did it for the AI junk, too. Ironic, considering as solid of a product as Mist is, the AI bits of it have been barely functional from the get-go.
|
|
#
?
Jan 10, 2024 05:57
|
|
|
Kazinsal posted:Did it for the AI junk, too. Ironic, considering as solid of a product as Mist is, the AI bits of it have been barely functional from the get-go. Seriously. We got apparently "free" Marvis licensing when migrating over for wireless/wired access switching. I've tried using it maybe a dozen times over the past 2.5 years, it's been entirely unhelpful.
|
|
#
?
Jan 10, 2024 06:02
|
|
|
We just dumped Cisco in November and standardized on EX4400's across 350 sites, 8 campus networks. This is 6 months after finally convincing the server team to move from Hyper-V to ESXi for our large database clusters. Then Broadcom happened. We just can't win. (From a purely technical standpoint, it's still a win, but drat.
|
|
#
?
Jan 10, 2024 07:20
|
|
|
I just got a job offer from a place that's full Juniper stack top to bottom. I'm still looking forward to the job, partially on account of not being one of the network guys, but wow that timing.
|
|
#
?
Jan 10, 2024 07:25
|
|
|
the spyder posted:We just dumped Cisco in November and standardized on EX4400's across 350 sites, 8 campus networks. My environment is a lot smaller, but I'm the only dork here that does anything infrastructure related. All servers virtualized within vSphere (sold). 400 seat VDI environment with Horizon (being sold off). Carbon Black for EDR/NGAV (being sold off). Workspace One for MDM (being sold off). Previously was using Nimble for block iSCSI, then HPE bought em and I jumped ship. Previously was using Meraki for WiFi and access layer switching, then Cisco bought em so I jumped ship. Currently using Juniper Mist for WiFi/access layer switching, then non-Mist EX/SRX virtual chassis for routin' n firewallin'. Unsure what's next, or if I just call it quits since I'm the kiss of death. Have a project coming up replacing a bunch of EX4550 VCs, was planning on going EX4650. Ugh.
|
|
#
?
Jan 10, 2024 10:41
|
|
|
How awful was it to use Meraki switching before the Cisco acquisition? Because it's not great now.
|
|
#
?
Jan 10, 2024 11:48
|
|
|
Thanks Ants posted:How awful was it to use Meraki switching before the Cisco acquisition? Because it's not great now. It was worse. At least now basic switching functionality works.
|
|
#
?
Jan 10, 2024 13:10
|
|
|
Once implemented, I had zero issues with em. I was only doing layer 2 access with the switches, all routing handled upstream. What issues did I miss out on?
|
|
#
?
Jan 10, 2024 19:51
|
|
|
Moey posted:Once implemented, I had zero issues with em. I was only doing layer 2 access with the switches, all routing handled upstream. My favourite was that, despite having fairly standard switchport style configuration that uses switching terminology, the LAN ports on MX devices will happily flood BPDUs between distinct network segments and cause STP to absolutely poo poo the bed.
|
|
#
?
Jan 10, 2024 23:22
|
|
|
My favourite meraki shitness was their routers didn't support vlan subinterfaces for WAN interfaces, dunno if they ever added that but ended up having to add switches in front of them to get it working a long time ago.
|
|
#
?
Jan 11, 2024 00:14
|
|
|
My favorite was when we had a stack of 8 switches and if the management plane crashed on one switch you had to reboot the entire stack.
|
|
#
?
Jan 11, 2024 04:04
|
|
|
Moey posted:Currently using Juniper Mist for WiFi/access layer switching, then non-Mist EX/SRX virtual chassis for routin' n firewallin'. Unsure what's next, or if I just call it quits since I'm the kiss of death. Juniper just got bought by HPE lol
|
|
#
?
Jan 11, 2024 04:23
|
|
|
I wonder who's gonna buy Extreme in the next couple years.
|
|
#
?
Jan 11, 2024 04:27
|
|
|
Broadcom, again.
|
|
#
?
Jan 11, 2024 04:27
|
|
|
Some Chinese company will license the Nortel name and start making acquisitions
|
|
#
?
Jan 11, 2024 09:30
|
|
|
After all kinds of delays, my 2.7-3.1 ISE upgrade is going down Friday night. At this point I think I feel like I know what needs to be done pretty well, but still a little stressed. Will be glad to get this done
|
|
#
?
Jan 18, 2024 05:06
|
|
|
|
| # ? Apr 29, 2024 02:07 |
|
|
Tetramin posted:After all kinds of delays, my 2.7-3.1 ISE upgrade is going down Friday night. At this point I think I feel like I know what needs to be done pretty well, but still a little stressed. Will be glad to get this done Good luck. My recent 2.7 to 3.2 upgrade generally went ok. I've just been having residual issues with RADIUS live logs. I've done the post upgrade steps and MnT DB reset but no luck. Guess it's TAC case time.
|
|
#
?
Jan 18, 2024 17:27
|
|