Spoiler alert, but I am pleased to report back that my experiment with adding an HDMI dummy plug to my Dell laptop has fixed my issues with VNC.
As I theorized in my post “VNC Cannot Currently Show the Desktop” and have since confirmed, when the laptop lid is closed, the laptop disconnects the monitor and Windows runs truly “headless”. Unfortunately VNC uses DirectX Desktop Duplication to grab a copy of what would be on the screen, and if there’s no screen there’s nothing for VNC to grab an duplicate copy of, so VNC is left doing a lot of hard work grabbing screen images using CPU rather than using the far more efficient DirectX shortcuts.
My proposed solution to this was to order an HDMI Dummy Plug, a little HDMI connector which pretends to be an HDMI monitor so that the laptop believes it has an active monitor connected. My other hope was that by having a fake external monitor for VNC to mirror, I might also be able to set it up with a higher resolution than the laptop’s own internal 1920×1080 screen, which might allow me to have a higher resolution remote session using VNC. Continue reading
I have a Dell Latitude E5440 laptop which most of the time I run headless in a 3D-printed stand next to its slightly bigger brother, a Dell E6500 or similar.
The laptops don’t take up much space on my desk in this vertical configuration (which is helpful as I have four laptops on my desk) and I use VNC to remote into them when I need to work on a Windows system. My main system is an Apple MacBook Pro, and I have that in a similar vertical dock with two 27″ monitors, a bluetooth keyboard and touchpad, and a USB-C port expander/charger. By using VNC I can keep using the peripherals I like and quickly switch between systems while sharing copy/paste buffers as well, which is pretty much perfect.
There’s one nagging little problem though, that I can’t get around. When I access the E5440 using RealVNC, it is slow to show the screen when initially connecting and every time there is a Windows UAC prompt I have to wait about five seconds or so while staring at a black screen which says “Cannot currently show the desktop”.
This is somewhat annoying and after digging around a bit I Continue reading
Digging through my office looking for some other technology which I had misplaced, I stumbled across a small box containing a Northbound Networks Zodiac-FX, a small 4-port FastEthernet OpenFlow SDN switch which I had picked up after backing a 2015 kickstarter campaign.
These were a pretty cool idea, and at the time OpenFlow (OF) was the hottest thing around, everything was being SDN-washed, and the idea that a regular user like myself could afford actual hardware with OF capabilities to toy with in the home lab was beyond belief. Of course, it was possible to virtualize OF with Mininet, but there’s something about using a real switch that goes beyond that. Even though, as you’ll in a future post, I ended up wasting that opportunity, I am still honored to have backed it, and my hat is off to Northbound Networks’ founder Paul Zanna for what he has accomplished.
With that in mind, I’m sad to note that when I went to the Northbound Networks website, I discovered that some time around August 2020 the company stopped manufacturing SDN hardware.
Since the original Zodiac FX campaign, Paul had expanded the available products to include an 802. Continue reading
In a post which now appears to have been deleted, Greg Ferro got right to the point in his article Response: Certifications Are Not A Big Deal. Stop Being a Princess About It.. The majority of this response was written while Greg’s post was still active, but I had to come back and inject more context after I spotted on June 30, 2019 that the post had become unavailable.
To save you digging in the WayBackMachine, the history to Greg’s post as I understand it is that Greg made some comments in Episode 238 of the Packet Pushers’ Network Break suggesting that vendor certifications were trivial. A listener evidently gave some strong feed back disagreeing with this, and so in Episode 239 of the Packet Pushers’ Network Break Greg responded to that feedback, and reiterated his position about certification study, specifically framed around Cisco’s CCNP. Greg made some reasonable points; that the certification programs from the vendors are not designed to teach fundamentals in the same way that, say, a computer science degree might do, and that the aim is really to make money for the vendor, and reduce their tech support costs, and as such the vendor certification education Continue reading
I’ve been developing yet more automation recently, and I’ve been hitting two major stumbling blocks that have had a negative impact on my ability to complete the tooling.
When APIs were first made available, the documentation from many vendors was simply incomplete; it seemed that the documentation team was always a release or two behind the people implementing the API. To fix that, a number of vendors have moved to a self-documenting API system along the lines of Swagger. The theory is that if you build an API endpoint, you’re automatically building the documentation for it at the same time, which is a super idea. This has improved the API’s endpoint coverage but in some cases has resulted in thorough documentation explaining what the endpoints are, but little to no documentation explaining why one would choose to use a particular endpoint.
As a result, with one API in particular I have been losing my mind trying to understand which endpoint I should use to accomplish a particular task, when no less than three of them appear to handle the same thing. I’m then left using trial and error to determine the correct path, and at the end Continue reading
The following summarizes a root privilege escalation vulnerability that I identified in A10 ACOS ADC software. This was disclosed to A10 Networks in June 2016 and mitigations have been put in place to limit exposure to the vulnerability.
SUMMARY OF VULNERABILITY
Any user assigned sufficient privilege to upload an external health monitor (i.e a script) and reference it from a health monitor can gain root shell access to ACOS.
At this point, I respectfully acknowledge Raymond Chen’s wise words about being on the other side of an airtight hatch; if the malicious user is already a system administrator or has broad permissions, then one could argue that they could already do huge damage to the ADC in other ways. However, root access could allow that user to install persistent backdoors or monitoring threats in the underlying OS where other users can neither see nor access them. It could also allow a partition-level administrator to escalate effectively to a global admin, by way of being able to see the files in every partition on the ADC.
SOFTWARE VERSIONS TESTED:
This vulnerability was originally discovered and validated initially in ACOS 2.7.2-P4-SP2 and is present in 4.x as Continue reading
I’ve been looking at security cameras recently, in part because my home owners association needs to upgrade the system which monitors some of the amenities. We want motion detection features and, obviously, remote access to view live cameras and recorded footage without having to go to the location. Unfortunately there’s a gap in the market which seems to be exactly where I’m looking. Cisco Meraki may have just stepped in and bridged that gap.
Over the last few years, a wide variety of small security cameras have become available, any of which which at first glance would appear suitable. These include products like Netgear’s Arlo, Amazon’s Blink, Google’s Nest Cam and more. After some brief testing, however, I’m a little less convinced that they are what we’re looking for. It sounds silly to say it, because it’s not like this is something they hide, but these products are all aimed at the home user market. Dashboard logins are single user, based on an email address and the web interfaces may not work well for much more than five or so cameras. The camera choices are fairly limited, and as they’ll be streaming their Continue reading
Many of us will have experienced the challenges of taking a performance alert (or user complaint) and drilling down to root cause. Performance issues can be intermittent, and it can be difficult to get visibility of what caused a problem at a particular time. Viavi Enterprise thinks it has the answer, combining analysis of packet feeds (e.g. from taps and mirror ports) and IPFix, xFlow and cloud service flow logs to monitor application performance as it would be experienced by a user. Sounds good? It looked pretty good, too.
Nothing can happen without data, and that comes from a number of potential sources.
The Observer Gigastor product is available as a virtualized solution (to capture east-west traffic in virtualized environments), a portable appliance for tactical deployment, and two hardware appliance models (in a charming shade of purple) which can provide from 96TB to 1.2PB of storage. The idea of Gigastor is to capture packets at line rate and retain the raw packet data in case it’s needed later. The packets are analyzed, and that metadata is fed to the reporting and visualization system, Observer Apex.
It’s not always possible Continue reading
The following summarizes an HTTP persistence cookie vulnerability that I identified in A10 ACOS ADC software. This was disclosed to A10 Networks in June 2016 and has now been resolved.
As noted in a previous post, ACOS uses insecure HTTP/HTTPS persistence cookies which can allow a malicious user to craft a cookie determining the server and port to which a persistent session should be sent. In addition, for vports using the default “port-based” HTTP cookie persistence, it was discovered that when using the default persistence cookie type, ACOS does not perform a check to ensure that the server/port defined in the cookie is within the configured service-group for that VIP.
The only sanity check appears to be to ensure that the server IP read from the cookie has been configured on the A10 within the same partition. If that constraint is met, packets will be forwarded by ACOS to the real server based solely on the value contained in the cookie. This is extremely serious as it allows a malicious user to connect, for example, through a public VIP and access back end servers used by other VIPs, including those only accessible via internal IPs.
SUMMARY OF VULNERABILITY
When using Continue reading
The following summarizes an HTTP persistence cookie vulnerability that I identified in A10’s ACOS ADC software. This issue was disclosed to A10 Networks in June 2016 and has since been resolved.
This vulnerability results in information disclosure about names of service-groups and IPs of real servers, as well as the ability to manipulate the content of the cookies.
SUMMARY OF VULNERABILITY
The ACOS documentation for HTTP persistence cookies notes that “For security, address information in the persistence cookies is encrypted.” However, the address information is not “encrypted”; rather, the real server IP and port information is weakly obfuscated and is easily decoded, exposing information about the internal network. The simplicity of the obfuscation also makes it trivial to manually create a cookie which ACOS would decode and honor.
Additionally, cookies configured using the service-group command option have the service-group’s full name included in the persistence cookie as plain text. This vulnerability applies to HTTP/HTTPS VIP types that have been configured to use a cookie-based persistence template.
SOFTWARE VERSIONS TESTED
This vulnerability was discovered and validated initially in ACOS 2.7.2-P4-SP2 and reconfirmed most recently in ACOS 4.1.1-P3.
VULNERABLE VERSIONS
This behavior has been core to Continue reading
The Networking Field Day Exclusive one-day event with Cisco’s Service Provider business unit definitely exceeded my expectations, and I believe showcased a different approach to technology and their customers than we might have seen from the Cisco Systems of four or five years ago.
The topic-du-jour was definitely Segment Routing, and Cisco delivered great presentations on both SR-TE (Segment Routing – Tunnel Engineering) with SR Flexible Algorithm, and SRv6 (Segment Routing for IPv6).
SR FlexAlgo effectively allows a network to calculate metric- and constraint-based primary and backup paths on demand and in a distributed fashion. For example, a policy might be that traffic to a given prefix should follow the lowest latency path using only MACSEC encrypted links, or perhaps the lowest cost path while staying within a particular geographical region. Cool stuff, and while it won’t fix every problem, conceptually I can see this as a relatively accessible way into Segment Routing, and one which could deliver tunnel engineering in a way that would be highly complex or impossible using RSVP-TE and a constraint-based IGP calculation.
I had not looked at SRv6 before, and it’s a fascinatingly different beast to regular IPv4-based Segment Continue reading
I’ve been blogging for Solarwinds recently, posting on Orange Matter, with a cross-post to the Thwack Geek Speak forum. I love automation, but it seems that dreams of a smooth customer experience can be destroyed by the persistence of engineering silos in many organizations.
This post appeared on Orange Matter as “Silo-Busting and Dream-Dashing; More Fun With Automation“, but I’m also linking to the version posted on Thwack, mainly because that format allowed me to use more images and be slightly more irreverent. Actually, quite a lot more irreverent in this particular case…
I’d love it if you were to take a moment to visit and read, and maybe even comment!
If you liked this post, please do click through to the source at Orange Matter: Silo-Busting and Dream-Dashing and give me a share/like. Thank you!
This post is part two of three in a series looking at the joint presentations made by Mellanox, Ixia and Cumulus at Networking Field Day 17, in February 2018. More specifically, this post looks at what part Ixia has to play in the deployment of an Ethernet switch fabric built using Mellanox switches and running Cumulus Linux as the Network Operating System (NOS).
What confused me most about a presentation from Mellanox, Ixia and Cumulus about Ethernet fabrics was to figure out what role Ixia would be playing in the disaggregated model. Mellanox makes the switch hardware and Cumulus makes the switch software, so Ixia fits, well, where exactly?
IxNetwork is billed as an end-to-end validation solution which in many ways undersells what it’s all about. Rather than being just more traffic-generating test equipment, IxNetwork can emulate multiple switch and server devices so that a single piece of test hardware can be connected to what it believes is a large existing infrastructure, and that hardware’s behavior and resiliency can be validated. In the demo topology, IxNetwork connects to a physical Mellanox Spectrum switch running Cumulus Linux, emulating connected servers as well as an entire leaf/switch EVPN/VXLAN fabric, attached Continue reading
When I saw that Mellanox was presenting at Networking Field Day 17, I was definitely curious. When I found out that I would in fact be watching a joint presentation by Mellanox, Cumulus Networks and Ixia, it is fair to consider my interest piqued. Why would these three companies present together?
It turns out that these three companies present quite a compelling story, both individually–as you would probably expect–but also when used in combination. This post looks at the role of Mellanox Ethernet switches in an Ethernet fabric.
To me, Mellanox has been one of those ‘behind the scenes’ companies whose hardware is all over the place but whose name, in Ethernet circles at least, is less well known. Storage and compute engineers on the other hand are likely more familiar with the Mellanox name, especially in the context of Infiniband switches and network interface cards (NICs). In 2016 Mellanox acquired EZchip, allowing the development of some very capable Ethernet switches and an expansion of the company’s portfolio; to paraphrase Amit Katz (VP, WW Ethernet Switch), Mellanox connects PCI-Express interfaces together by building NICs, cables and switches.
At the Networking Field Day event in February 2018, Continue reading
A recent post from Ivan Pepelnjak entitled Revisited: The Need For Stretched VLANs
made me smile rather bitterly as Ivan dug into the apparent continued desire for stretched layer 2 networks and the reasons
people give for the solution’s requirement and validity. I love a good bit of snark as much as the next nerd, so as you can imagine, I’m all over that post.
However, I confess I did wince slightly – in the way one might do when an old wound is poked with a sharp stick – as Ivan made a passing sarcastic reference to Microsoft’s amazing Network Load Balancing technology:
My mind was thrown back to the heady days of 2009 when I stumbled across another post from Mr Pepelnjak, this time entitled Turn a switch into a hub … the Microsoft Way
which bemoaned the unadulterated stupidity of Microsoft’s attempt to use layer 2 network flooding to accomplish clustering. I had discovered the nature of this behavior at a previous client and had my mind blown by the very stupid and non-standards-compliant way in which this had been implemented.
The reason my mind went to that post, however, is because if I recall correctly it’s Continue reading
As I write this it’s Friday afternoon in Silicon Valley, Networking Field Day 17 (NFD17) is over, and I am truly exhausted after a week of presentations covering topics like Ethernet switch hardware, testing/simulation and network operating system (Mellanox, Ixia, Cumulus), Field Area Networks (Cisco), visibility and automation (Juniper AppFormix), distributed network monitoring (Thousand Eyes) and much more.
I will be posting in the coming weeks about some of the individual presentations, but while I dry off from the information firehose I thought I’d briefly summarize some of my personal highlights from the week.
One recurring theme throughout the week was automation. Cisco for example, spoke about the capabilities for Zero Touch Provisioning (ZTP) in IOS XR. Juniper presented the OpenContrail platform which, impressively, appears to have a new and very positive sense of direction after (in my opinion) floating around somewhat aimlessly for a while. Extreme Networks spoke about Workflow Composer, and its ability to integrate with tools like Splunk to auto-remediate detected issues. VMware demonstrated the impressive capabilities of NSX to configure distributed firewalling and microsegmentation down to the container level, while VeloCloud from VMware demonstrated another facet of automation, that of the software defined WAN.
Another Continue reading
This is a quick post to say thanks to the folks at Vertitech IT for listing movingpackets.net among their Best IT Blogs for 2018 (“Must-Read Resources for CIOs, IT & Security Pros”). MP was on the Best IP Blogs of 2017 as well, and it’s an honor to be on the list for a second year.
Vertitech explain the creation of this list thus:
Information Technology. Sometimes we get so focused on the bits and bytes side of the equation we forget about the information part. When it comes right down to it, IT is all about using technology to inform, to communicate, to make the business of doing business easier and more understandable.
That’s why we compiled this list. Originally created last year with 50 top IT blogs, we’ve expanded this year’s update to include 70 leading resources for IT professionals, including blogs, discussion forums, niche industry publications, and the best resources for CIOs and CTOs. VertitechIT’s top 70 IT blogs, forums, and resources were selected because they are among the most current, frequently updated, credible, and informative sources of information related to IT on the web today. From musings of industry leaders, to the Continue reading
What’s not to love about twinax? Formerly the exclusive domain of IBM systems, twinax has seen itself reborn in the last few years in the form of the Direct Attach Cable (DAC) used to connect systems at speeds of 10Gbps and 40Gbps (by way of bundling four twinax pairs in a single cable).
Before diving into the pros and cons of DAC, it’s important to understand the different varieties that are available. A DAC is a cable which has SFP+ format connectors hard-wired on each end; plug each end into an SFP+ socket and, vendor support notwithstanding, the link should come up. A direct attach cable is frequently and erroneously referred to as a “DAC cable”, so if the words “PIN number” give you the jitters, working anywhere with DACs is likely to drive you to drink.
The most common kind of DAC is the passive DAC. The SFP+ connector on a passive DAC, give or take some electrical protection circuitry, is pretty much a direct connection from the copper in the twinax to the copper contacts which connect to the host device:
Sending a 10G signal over a single copper pair requires Continue reading
I’ve been doing some work automating A10 Networks load balancers recently, and while testing I discovered a bug which broke my scripts. As hard as I try to code my scripts to cope with both success and failure, I realized that the one thing I can’t do much with is a failure of a key protocol.
So what matters when I’m automating device configurations? Three things come to mind immediately:
I need reliable network connectivity, or my automation requests will constantly be timing out or failing. While a script should be able to cope with an occasional network failure, unreliable networks are not fun to work with.
Pick a format (XML, JSON) and use it consistently. I’m happy so long as I can send a request and read a response in a given format. If I send a request using JSON, send a response using JSON. Funnily enough I was troubleshooting WordPress xmlrpc recently and noticed that when there was an error, the XML command being issued received a 404 error followed by, well, you’d hope an XML error response, right? No, because it was an HTTP 404 error, the site Continue reading
As part of my “everything should be on a UPS” strategy, I recently replaced a regular 8-port gigabit switch with a Ubiquiti Unifi US-8 Ethernet switch because the US-8 can be powered using POE (Power Over Ethernet) provided by a UPS-protected switch in my basement, so it should stay up in the event of a power outage. This also allowed me to indirectly provide UPS protection for the Ubiquiti wireless AP in that location because the US-8 has a PoE passthrough port with which I could power the AP. Clever, right?
To clarify (because a picture is worth many thousands of my words), here’s how things were:
And here’s how things are after installing the Ubiquiti Unifi US-8:
The new setup worked well, but I noticed after a few days that the uptime for the Unifi US-8 kept on resetting; that is, it appeared to be rebooting. The Cisco 3560CX switch which is providing the POE can supply 30W per port, which is plenty enough for the US-8 and the wireless AP to be daisy-chained like this, yet when I looked at the logs on the 3560CX, I found an error:
Oct 23 18:23:12.124 UTC: %ILPOWER-3-CONTROLLER_PORT_ERR: Continue reading