From time to time you may want to debug TLS, Now this is not as easy as you might think, Because of the nature of TLS, you don’t really want to have anyone (even if they technically may have the key on the se
Coffee, doughnuts and networking. A perfect combination.
The post Network Break 27 appeared first on Packet Pushers Podcast and was written by Greg Ferro.
The IEEE actually moved faster than a dead turtle and has a PAR for 25GbE. Except now they are inventing problems that don't need solving and demonstrating how much stupid they can achieve.
The post Response: IEEE 802.3by – Inventing Their Own Problems to Solve Them appeared first on EtherealMind.
During a great conversation I had with Terry Slattery during Interop New York, he said “well, I don’t think anyone should be configuring VLANs and asking ÔÇśHow to configure a VLAN on a switch’ – we should be focused on providing end-to-end connectivity”, and there’s absolutely nothing in that statement that one could disagree with.
Read more ...
Troubleshooting Lab 3 and Full Scale Lab 3 have now been added to the CCIE RSv5 Workbook!
The new Troubleshooting Lab 3 uses the Full Scale Lab 1 logical topology, but breaks all of the protocols you’ve previously built. I suggest you take your time with each ticket so that you can fully digest why each fault occurs. Practice your time and knowledge skills by taking the Troubleshooting Lab 3 challenge!
Full Scale Lab 3 is built on a brand new logical topology, and has a strong focus in MPLS and BGP technologies. The solution guide features detailed breakdowns of each topic domain to give you a better understanding of the solutions used to solve each task. Keep in mind that there are multiple ways to solve most problems.
For discussion on these new labs visit our online community, IEOC.
Enjoy!
Last week, a very small number of our users who are using IP tunnels (primarily tunneling IPv6 over IPv4) were unable to access our services because a networking change broke "path MTU discovery" on our servers. In this article, I'll explain what path MTU discovery is, how we broke it, how we fixed it and the open source code we used.
When a host on the Internet wants to send some data, it must know how to divide the data into packets. And in particular it needs to know the maximum size of packet. The maximum size of a packet a host can send is called Maximum Transmission Unit: MTU.
The longer the MTU, the better for performance, but the worse for reliability, because a lost packet means more data to be retransmitted and because many routers on the Internet can't deliver very long packets.
The fathers of the Internet assumed that this problem would be solved at the IP layer with IP fragmentation. Unfortunately IP fragmentation has serious disadvantages and it's avoided in practice.
To work around fragmentation problems the IP layer contains a "Don't Fragment" bit on every IP packet. Continue reading
As is our annual tradition, this blog provides a year-end review of how the Internet providers at the top of our IP Transit Intelligence global rankings (formerly, Renesys’ Market Intelligence) fared over the previous year. The structure and performance of the Internet remains a huge blind spot for most enterprises, even those critically dependent on it for business operations. Whether it’s the next 3 billion people coming online, poor performance due to suboptimal routing, or security breaches of a trust-based Internet infrastructure, Dyn provides critical insight into the structure and performance of the Internet, both real-time and historical, via its Internet Intelligence products. More importantly, our services help our customers make the changes necessary to optimize Internet availability, reliability, and reach. This blog reviews a single very small slice of our data related to the sizes of the top global players as it pertains to the markets and customers they serve.
Back in 2008, we chose to look at the 13 providers that spent at least some time in the Top Ten that year, hence the name “Baker’s Dozen“. We repeated that exercise in 2009, 2010, 2011, Continue reading
This post is a Zombie that I'm resurrecting from my drafts. I"m not doing any Java these days, but hopefully this post might be useful to somebody
In my quest to get better code coverage for the OVSDB project in OpenDaylight I started to look at increasing coverage for the REST API. It's pretty difficult to test this in an efficient way (lines of code) and frameworks like Robot would have been easier to use. The disadvantage with using an external test framework is that code coverage (using a plugin like JaCoCo) would not be logged. Therefore I harnessed my Junit-Jitsu and found a solution that lives in the JVM
This post is a Zombie that I'm resurrecting from my drafts. I"m not doing any Java these days, but hopefully this post might be useful to somebody
In my quest to get better code coverage for the OVSDB project in OpenDaylight I started to look at increasing coverage for the REST API. It's pretty difficult to test this in an efficient way (lines of code) and frameworks like Robot would have been easier to use. The disadvantage with using an external test framework is that code coverage (using a plugin like JaCoCo) would not be logged. Therefore I harnessed my Junit-Jitsu and found a solution that lives in the JVM
Lets take a very simple example REST API
GET, PUT: /v2/foo
The solution uses the following components
The parameterized runner will run run a test multiple times given a bunch of parameters. This way we can write one test, specifiy our parameters in YAML and let JUnit do the hard work!
Here's a sample YAML file:
---
- name: testGetAllFoo
operation: GET
uri Continue readingIn the final part of our MPLS-focused discussion, Seamus wanted to know how one could combine MPLS/VPN, MPLS-TE and QoS (for example, sending VoIP traffic for one customer over a different path).
Short answer: don’t even think about doing that. The added complexity is not worth whatever extra money you’ll be charging the customer (or not).
