Docker and the container world are growing up fast.
APIs are increasingly becoming the backbone of the modern internet - whether you're ordering food from an app on your phone or browsing a blog using a modern JavaScript framework, chances are those requests are flowing through an API. Given the need for APIs to evolve through refactoring and extension, having great automated tests allows you to develop fast without needing to slow down to run manual tests to work out what’s broken. Additionally, by having tests in place you’re able to firmly identify the requirements that your API should meet, your API tests effectively form a tangible and executable specification. API Testing offers an end-to-end mechanism of testing the behaviour of your API which has advantages in both reliability and also development productivity.
In this post I'll be demonstrating how you can test RESTful APIs in an automated fashion using PHP, by building a testing framework through creative use of two packages - Guzzle and PHPUnit. The resulting tests will be something you can run outside of your API as part of your deployment or CI (Continuous Integration) process.
Guzzle acts as a powerful HTTP client which we can use to simulate HTTP Requests against our API. Though PHPUnit Continue reading
An overview of how new protocols impact storage performance.
Here’s a trick question:
To implement this request you use the following configuration commands (plenty of other commands removed because they don’t impact the results):
router bgp 64500
address-family ipv4
maximum-paths ibgp 32
maximum-paths 32
neighbor 192.168.0.4 next-hop-self
neighbor 192.168.0.1 next-hop-self
address-family vpnv4
maximum-paths ibgp 32
maximum-paths 32
no neighbor 192.168.0.4 next-hop-self
no neighbor 192.168.0.1 next-hop-self
Try to figure out what the end-result will be without connecting to a router or reading the rest of this blog post.
Ok, here’s what totally threw me off (and wasted an hour of my life): next-hop-self is removed from neighbors in the IPv4 address family. Here’s why:
No wonder David Barroso named his library NAPALM (you’ll find the full story in this or this podcast).
Many networks leverage what is known as a VRF. These are used for traffic isolation and create separate routing instances within a router. It is important that vrf awareness is confirmed for any service (DHCP, Voice GW, etc) being locally provided for a given point in the network. One use case for such a configuration might be for voice isolation with or without MPLS. In the case that a router is providing voice gateway functionality (i.e. FXO/FXS to VOIP), the voice functions must understand the VRF construct in order to properly fulfill the role.
TL;DR–This configuration sometimes does not behave as expected and, in my experience, may require a reboot after following the documented procedure.
The configuration for VRF-Aware H.323 and SIP for Voice Gateways can be found at the URL below.
http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/stork.html
Notice that it makes reference to the fact that the services need to be restarted–
To configure a voice VRF, you must shut down voice services on the gateway, assign a previously defined VPN VRF to the VoIP SPI, and then restart voice services.
As one researches this particular configuration, the concept of voice “multi-vrf” will likely come up. Based on my Continue reading