See Juniper Networks’ New SDxCentral Digs
Find the info you need to start transforming your legacy network into an open, automated, agile, and secure infrastructure that address your toughest networking challenges.
Find the info you need to start transforming your legacy network into an open, automated, agile, and secure infrastructure that address your toughest networking challenges.
We’ve had computation using slime mold and soap film, now we have computation using water droplets. Stanford bioengineers have built a “fully functioning computer that runs like clockwork - but instead of electrons, it operates using the movement of tiny magnetised water droplets.”
By changing the layout of the bars on the chip it's possible to make all the universal logic gates. And any Boolean logic circuit can be built by moving the little magnetic droplets around. Currently the chips are about half the size of a postage stamp and the droplets are smaller than poppy seeds.
What all this means I'm not sure, but pavo6503 has a comment that helps understand what's going on:
Logic gates pass high and low states. Since they plan to use drops of water as carriers and the substances in those drops to determine what the high/low state is they could hypothetically make a filter that sorts drops of water containing 1 to many chemicals. Pure water passes through unchanged. water with say, oil in it, passes to another container, water with alcohol to another. A "chip" with this setup could be used to purify water where there are many contaminants you want separated.
Knowing the members of our Ansible community is important to us, and we want you to get to know the members of our team in (and outside of!) the Ansible office. Stay tuned to the blog to learn more about the people who are helping to bring Ansible to life.
This week we're happy to introduce you to Robyn Bergeron, who recently joined Ansible as a Community Architect. Her prior role was as a Developer Advocate at Elastic, where she worked closely with the ELK stack community. And many of us at Ansible know her from her days at Red Hat, where she was the Fedora Project Leader -- a role that her illustrious boss once himself had.
What’s your role at Ansible?
Open source communities work best when contributors are empowered and enabled to make things happen; the easier it is to contribute, the more likely they’ll continue to do so, and enjoy doing it. As a community architect, it’s my job to ensure that contributors, both long-time and new, are connected with the opportunities, ideas, tools, and people to make great things happen in the Ansible community, with minimal bureaucracy.
A good deal of my focus will Continue reading

The post Worth Reading: SDN Controller Benchmarking appeared first on 'net work.

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.
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
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 ...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
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
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
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