Onsite "side arm" laptops? Networking |
- Onsite "side arm" laptops?
- LACP + SRIOV
- Moving external DNS from on-prem to hosted
- SVTI's Supporting Routing Protocols
- Adding packets to speed up failure
- Should Cisco licenses be pre-installed?
| Posted: 27 Jun 2020 12:15 PM PDT I've always carried a second laptop on me for onsites. There's multiple reasons for this and I'm sure a lot of your do the same. Traditionally I've used a MBA since battery life is great, it runs the apps I need (Wireshark and bash/homebrew) and is easy to have in hand when I squeeze behind racks. What are you using as your "side arm" laptop? Really curious if anyone is using a Chromebook using ChromeOS + Linux app support because that seems like a perfect low cost solution here, I just can't find any information on people using Wireshark and serial adapters with one. [link] [comments]  |
| Posted: 27 Jun 2020 03:45 AM PDT |
| Moving external DNS from on-prem to hosted Posted: 26 Jun 2020 07:52 PM PDT Hey all, I have never setup a DNS before and our current on-prems are running on Webmin/BIND DNS. register.com hosts our domain name and they offer a free DNS service. This whole thing has sort of fallen into my lap since the person who originally set it up is gone. We are K-12 so not a whole lot of money (hence the free route). On our BIND DNS server we have several DNS zones. These consist of a handful of subdomains. I'm overall confused about where the translate to the register.com web console. Any advice would be appreciated. I realize this is a long shot and I'm probably missing important information. [link] [comments]  |
| SVTI's Supporting Routing Protocols Posted: 27 Jun 2020 06:06 AM PDT I would like to understand the reason why SVTI's can support routing protocols and multicast. In the old-school way that I'm used to, we use to use crypto maps for IPSec traffic. IPsec doesn't natively support multicast and broadcast traffic (it supported only unicast), which is why a tunnelling-protocol was invented (GRE) to carry another IP payload that did support multicasting (thus hiding the multicast routing-protocol hello's behind a GRE header, allowing you to tunnel multicast traffic over an IPSec tunnel via a 3rd IP header). But digging into a packet capture of an SVTI, which I know does support multicast traffic, I find that no additional headers are added at all. So how is it then, that IPSec only supports unicast traffic, but if you shove it down a virtual tunnel interface, multicast works (thus routing protocols work)? What has changed to allow the use of multicast down this IPSec tunnel with an SVTI? [link] [comments]  |
| Adding packets to speed up failure Posted: 27 Jun 2020 10:01 AM PDT Hi all – If you've got a small payload situation where the payloads always fit into a single 1400-ish byte UDP/IPv6 packet, there's no explicit way to know about packet loss. It seems like timeout is the only way you know, by default. In fact, AFAIK this is how DNS is – a one-packet request that simply times out. What if we want to know about packet loss sooner than a multi-second timeout? Would it be smart to string out the send into a couple of packets, and get a fast notification when one is missing? How would the math work on that solution? I mean if a packet has a 99% chance of arrival, the chance that one of two gets through should be higher than 99%, but I don't remember the formula. That's assuming independent probabilities, but two packets that are sent together are unlikely to be independent in that sense – the failure of one is probably going to correlate at least slightly with the other's chance of failure, but I don't know if there's a general rule here. The chance of some kind of failure (like one of the two packets lost) goes up if you string out a one-packet send to two or more packets. Worst case is .99 * .99 = .98, assuming independent probabilities, but it should be better than .98 since these aren't fully independent. But maybe the slightly greater chance of some level of failure is worth the hit to us if it helps us detect a failure sooner than a timeout would. What do you think? Would breaking one packet into several smaller ones make sense? (We could get fast notification by switching to TCP instead of UDP, or maybe something out of band.) Relatedly, does TCP have any solution for the one-packet use case in terms of notification of a lost packet? Do you just have to do something out of band in that case? ICMP? Thanks. Edit: According to DNSPerf, the fastest resolvers are in the low double-digit milliseconds, and the slowest are around 100 ms. That's my baseline for fast failure of a single-packet use case. [link] [comments]  |
| Should Cisco licenses be pre-installed? Posted: 26 Jun 2020 06:08 PM PDT Been a while since I've been involved in the purchase and setup of new kit, so this could be a dumb question. My department at work (generally non-technical) bought an ISR 4331 and performance license for an internal project, purchased from a Cisco distributor in Japan. The router arrived with an EVAL license installed, then we got a separate email from the distributor about adding/activating the real license in our Cisco smart account (which we don't have). Does this seem normal for a router to ship with an EVAL license, then require the customer to screw around seting up the proper licence later? Seems strange to me, but I must admit I've never purchased an IOS XE device before. [link] [comments]  |
| You are subscribed to email updates from Enterprise Networking news, blogs and discussion.. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
No comments:
Post a Comment