SDN and the Trough Of Understanding
An article published this week referenced a recent Hype Cycle diagram (pictured above) from the oracle of IT – Gartner. While the lede talked a lot about the apparent “death” of Fibre Channel over Ethernet (FCoE), there was also a lot of time devoted to discussing SDN’s arrival at the Trough of Disillusionment. Quoting directly from the oracle:
Interest wanes as experiments and implementations fail to deliver. Producers of the technology shake out or fail. Investments continue only if the surviving providers improve their products to the satisfaction of early adopters.
As SDN approaches this dip in the Hype Cycle it would seem that the steam is finally being let out of the Software Defined Bubble. The Register article mentions how people are going to leave SDN by the wayside and jump on the next hype-filled networking idea, likely SD-WAN given the amount of discussion it has been getting recently. Do you know what this means for SDN? Nothing but good things.
Software Defined Hammers
Engineers have a chronic case of Software Defined Overload. SD-anything ranks right up there with Fat Free and New And Improved as the Most Overused Marketing Terms. Every solution release in the last two years Continue reading
Introducing Docker Content Trust
written by Diogo Mónica, Security Lead at Docker, Inc. Image Signing and Verification using The Update Framework (TUF) A common request that we’ve heard from the Docker community is the need to have strong cryptographic guarantees over what code … ContinuedAnnouncing Docker 1.8: Content Trust, Toolbox, and Updates to Registry and Orchestration
written by Ben Firshman, Director of Product Management at Docker Inc. We’re thrilled to announce Docker 1.8 with support for image signing, a new installer, as well as incremental improvements to Engine, Compose, Swarm, Machine and Registry. You’ve been telling … ContinuedComware 7 autodeploy supports Python scripts
I recently discovered that the Comware auto-configuration feature also supports Python scripts. In the traditional auto configuration setup, a TFTP server and TFTP boot filename are used to deploy a (basic initial) configuration to the network devices. This configuration boot … Continue reading
Automation And Orchestration: Speed Vs. Efficiency
We need to go beyond automating network tasks via SDN into the realm of orchestration and DevOps to eliminate inefficiency.Simware 7.1.59 download available for all users
HP has released an updated version of the Comware simulator Simware, no license or registration is required to use this tool. The updated version includes a simple to use GUI and drag-and-drop connections between the devices. A limitation of the … Continue reading
SDN Will Not Solve Real-Life Enterprise Problems
It’s hard to visit an IT journal web site without stumbling upon an SDN fairy tale. Here’s another one:
The idea is to cut away the manual process of setting up new firewalls, load balancers and other network appliances, and instead open the door to provisioning a new network infrastructure within a few minutes.
And why exactly is it that you can’t do that today?
Read more ...Another useful SRX command for looking at IPSec tunnels
This is a new one on me – obviously I’ve not been paying much attention since it has been around since 10.2!
On 12.1X45-D15.5 the counters for packets/bytes all show zero, but at least you can see that your tunnel is up and what the various parameters in use are… See below:
imtech@srx650-1-POD1> show security flow session tunnel extensive Session ID: 38046, Status: Normal Flag: 0x10000 Policy name: N/A Source NAT pool: Null Dynamic application: junos:UNKNOWN, Maximum timeout: N/A, Current timeout: N/A Session State: Valid Start time: 105905, Duration: 52592 In: 10.1.0.9/49698 --> 10.1.0.1/27622;esp, Interface: ge-2/0/13.0, Session token: 0xa, Flag: 0x100621 Route: 0x110010, Gateway: 10.1.0.2, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 0, Bytes: 0 Session ID: 38047, Status: Normal Flag: 0x10000 Policy name: N/A Source NAT pool: Null Dynamic application: junos:UNKNOWN, Maximum timeout: N/A, Current timeout: N/A Session State: Valid Start time: 105905, Duration: 52592 In: 10.1.0.9/0 --> 10.1.0.1/0;esp, Interface: ge-2/0/13.0, Session token: 0xa, Flag: 0x621 Route: 0x110010, Gateway: 10.1.0.2, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 0, Bytes: 0 Total sessions: 2
Another useful SRX command for looking at IPSec tunnels
This is a new one on me – obviously I’ve not been paying much attention since it has been around since 10.2!
On 12.1X45-D15.5 the counters for packets/bytes all show zero, but at least you can see that your tunnel is up and what the various parameters in use are… See below:
imtech@srx650-1-POD1> show security flow session tunnel extensive Session ID: 38046, Status: Normal Flag: 0x10000 Policy name: N/A Source NAT pool: Null Dynamic application: junos:UNKNOWN, Maximum timeout: N/A, Current timeout: N/A Session State: Valid Start time: 105905, Duration: 52592 In: 10.1.0.9/49698 --> 10.1.0.1/27622;esp, Interface: ge-2/0/13.0, Session token: 0xa, Flag: 0x100621 Route: 0x110010, Gateway: 10.1.0.2, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 0, Bytes: 0 Session ID: 38047, Status: Normal Flag: 0x10000 Policy name: N/A Source NAT pool: Null Dynamic application: junos:UNKNOWN, Maximum timeout: N/A, Current timeout: N/A Session State: Valid Start time: 105905, Duration: 52592 In: 10.1.0.9/0 --> 10.1.0.1/0;esp, Interface: ge-2/0/13.0, Session token: 0xa, Flag: 0x621 Route: 0x110010, Gateway: 10.1.0.2, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 0, Bytes: 0 Total sessions: 2
Useful SRX debugging blog
Just came across a useful debugging guide for site-to-site IPSec VPNs on Juniper SRX. It is a bit confusing because in steps 2 and 3, where it says [LOCAL PEER IP] it should actually say [REMOTE PEER IP]. But otherwise, this is a very useful set of instructions.
It doesn’t mention that you should observe the lifetime of the IKE and IPSec security associations, and also keep an eye on the SA index or ID. If the index number keeps changing, it means your tunnel is going down and coming back up all the time. If the lifetime regularly starts again at the maximum value and does not count down to zero steadily, this indicates the same thing.
Particularly interesting is the way the author splits out the sections on troubleshooting the packet flow within the VPN, versus the packet flow of the VPN crypto itself. I’ve not used packet-filters in flow debug before, so will definitely be trying that out.
Link to SRX debug article at fir3net.com
Useful SRX debugging blog
Just came across a useful debugging guide for site-to-site IPSec VPNs on Juniper SRX. It is a bit confusing because in steps 2 and 3, where it says [LOCAL PEER IP] it should actually say [REMOTE PEER IP]. But otherwise, this is a very useful set of instructions.
It doesn’t mention that you should observe the lifetime of the IKE and IPSec security associations, and also keep an eye on the SA index or ID. If the index number keeps changing, it means your tunnel is going down and coming back up all the time. If the lifetime regularly starts again at the maximum value and does not count down to zero steadily, this indicates the same thing.
Particularly interesting is the way the author splits out the sections on troubleshooting the packet flow within the VPN, versus the packet flow of the VPN crypto itself. I’ve not used packet-filters in flow debug before, so will definitely be trying that out.
Link to SRX debug article at fir3net.com
How to achieve Alcatel-Lucent’s Network Routing Certification
Almost every networks-oriented vendor has its own certification program. Some of them are familiar to every network engineer (like Cisco orA Second Look at APNIC and IPv4 Address Exhaustion
It has been said often enough that its easy to make predictions; the tough part is getting them right! And in trying to predict the manner that APNIC will exhaust its remaining supply of IPv4 addresses I’m pretty sure that I did not get it right in the most recent article on this topic. So I’ll try and correct that in a more detailed look at the situation.More PIM-BiDir Considerations
Introduction
From my last post on PIM BiDir I got some great comments from my friend Peter Palúch. I still had some concepts that weren’t totally clear to me and I don’t like to leave unfinished business. There is also a lack of resources properly explaining the behavior of PIM BiDir. For that reason I would like to clarify some concepts and write some more about the potential gains of PIM BiDir is. First we must be clear on the terminology used in PIM BiDir.
Terminology
Rendezvous Point Address (RPA) – The RPA is an address that is used as the root of the distribution tree for a range of multicast groups. This address must be routable in the PIM domain but does not have to reside on a physical interface or device.
Rendezvous Point Link (RPL) – It is the physical link to which the RPA belongs. The RPL is the only link where DF election does not take place. The RFC also says “In BIDIR-PIM, all multicast traffic to groups mapping to a specific RPA is forwarded on the RPL of that RPA.” In some scenarios where the RPA is virtual, there may not be an RPL though.