It's the Network Break! This week we examine the latest round in the Cisco/Arista legal battle, applaud Cisco's IoT acquisition, review the latest cloud infrastructure numbers, parse a warning of armed revolt if governments weaken crypto systems, and more.
The post Network Break 73: Cisco Buys Into IoT; Crypto Violence appeared first on Packet Pushers.
A while ago I answered a few questions that Dan Novak from University of Maryland sent me, and as they might be relevant to someone out there decided to publish the answers.
Dan started with a soft one:
What circumstances led you to choosing network engineering for a career?
It was pure coincidence.
Read more ...In this video, Tony Fortunato discusses his initial analysis of a network redesign project.
With the rise of disaggregation, the networking industry needs more than the IETF in order to thrive.
Do you sometimes feel as insignificant as a packet? Maybe technology does have its roots in philosophy.
Plexxi had a really big year in 2015; growing year-over-year revenue by 10X and dramatically increasing our list of customers, signing an exclusive distribution relationship with Arrow Electronics and expanding our value added reseller network by 6X. We achieved all this through a relentless focus on providing transformational data center networking products and tools. Our solutions are purpose-built to support the people responsible for designing, architecting and supporting public and private clouds deployments. As I discussed in my last blog, we call these people Cloud Builders.
Cloud Builders are tasked with finding new ways to meet today’s dynamic business requirements. Traditionally, public cloud has been associated with speed, agility, elasticity and cost savings, whereas private cloud has been associated with control around application performance, latency and security. To support modern day business requirements Cloud Builders need to leverage both public and private cloud; it’s no longer an either/or scenario. Public and private clouds need to offer control over application performance, latency and security AND offer speed, agility, elasticity and cost savings.
We continue, as a company, to learn and adapt to market conditions by listening intently to customers, prospects and partners. Lately our conversations with Cloud Builders have revolved Continue reading
I've been developing an IPAM/DCIM tool for work over the past several months (more on that soon), and recently my focus has been on expanding it to store confidential data associated with network devices. Backup login credentials, TACACS+/RADIUS secrets, SNMP communities, and so on: Short strings that need to be stored securely.
Storing a password or other small piece of sensitive data is different from merely authenticating against it. Most password storage mechanisms never actually store a user's actual password, but rather an irreversible hash of it. (That is if you're doing it correctly, at least.)
For example, the Django Python framework (which powers packetlife.net) by default employs salted SHA256 hashes to authenticate user passwords. When a password is saved, a random salt is generated and concatenated with the plaintext password. (A salt is used to prevent two identical passwords from producing the same hash.) The SHA256 algorithm is then run against the whole thing to produce a fixed-length hash. Here's an example in Python using Django's built-in make_password() function:
>>> from django.contrib.auth.hashers import make_password
>>> make_password("MyP@ssw0rd!")
u'pbkdf2_sha256$12000$x5E0yB2dh13m$ablUOER8qn4CxjmHZlJrUUA1Cb9MeLXvfggTnG56QpM='
I've been developing an IPAM/DCIM tool for work over the past several months (more on that soon), and recently my focus has been on expanding it to store confidential data associated with network devices. Backup login credentials, TACACS+/RADIUS secrets, SNMP communities, and so on: Short strings that need to be stored securely.
Storing a password or other small piece of sensitive data is different from merely authenticating against it. Most password storage mechanisms never actually store a user's actual password, but rather an irreversible hash of it. (That is if you're doing it correctly, at least.)
For example, the Django Python framework (which powers packetlife.net) by default employs salted SHA256 hashes to authenticate user passwords. When a password is saved, a random salt is generated and concatenated with the plaintext password. (A salt is used to prevent two identical passwords from producing the same hash.) The SHA256 algorithm is then run against the whole thing to produce a fixed-length hash. Here's an example in Python using Django's built-in make_password() function:
>>> from django.contrib.auth.hashers import make_password
>>> make_password("MyP@ssw0rd!")
u'pbkdf2_sha256$12000$x5E0yB2dh13m$ablUOER8qn4CxjmHZlJrUUA1Cb9MeLXvfggTnG56QpM='
I've been developing an IPAM/DCIM tool for work over the past several months (more on that soon), and recently my focus has been on expanding it to store confidential data associated with network devices. Backup login credentials, TACACS+/RADIUS secrets, SNMP communities, and so on: Short strings that need to be stored securely.
Storing a password or other small piece of sensitive data is different from merely authenticating against it. Most password storage mechanisms never actually store a user's actual password, but rather an irreversible hash of it. (That is if you're doing it correctly, at least.)
For example, the Django Python framework (which powers packetlife.net) by default employs salted SHA256 hashes to authenticate user passwords. When a password is saved, a random salt is generated and concatenated with the plaintext password. (A salt is used to prevent two identical passwords from producing the same hash.) The SHA256 algorithm is then run against the whole thing to produce a fixed-length hash. Here's an example in Python using Django's built-in make_password() function:
>>> from django.contrib.auth.hashers import make_password
>>> make_password("MyP@ssw0rd!")
u'pbkdf2_sha256$12000$x5E0yB2dh13m$ablUOER8qn4CxjmHZlJrUUA1Cb9MeLXvfggTnG56QpM='
Continue reading · No comments
More on BGP Table Version – the most unknown and unexplained, BGP concept/value that I rarely ever troubleshoot without This is part 3 and final post in the 3 part series of “Understanding the BGP Table Version”. If you haven’t... Read More ›
The post Understanding the BGP Table Version – Part 3: Troubleshooting appeared first on Networking with FISH.
I’m preparing for the CCDE practical and I was doing a practice scenario by Jeremy Filliben and I realized that I’m not comfortable with all of the WAN speeds so I might as well write a blog post on it. I was familiar with some of them like T1, E1, DS3, OC-192 etc but there are still some I could not remember. This post will describe some of the most commonly used WAN rates.
Some of the CCDE scenarios are based on that we are upgrading a network or migrating from an old network. In real life it’s likely that most service providers will already have moved to Ethernet but it makes a more interesting scenario to build a network mimicing the FRR capabilities of SDH for example.
Digital Signal 0 (DS0) is a rate that was introduced to carry a digitized single call at 64 kbits/s. A DS1 can transport 24 DS0 and runs at 1544 kbit/s. Note that 24 * 64 is 1536 but the extra 8 kbit/s is used for frame synchronization. A DS3 runs at 44736 kbit/s and can transport 28 DS1 or 672 DS0. A T3 also runs at the same rate as a DS3. Continue reading