Everything else is getting opened up — how about rack management?
I’ll continue to update this throughout the next two days. Feel free to issue a pull request if you’re also here at the conference and want to add to this post.
Location: Open Networking User Group (ONUG) at Columbia University
ONUG currently has 6 working groups:
It is interesting and awesome to see that half of the working groups are all about Day 2 operations and management of networks. This is exactly what’s needed in the industry.
Speaker: Adrian Cockcroft
Ansible is about simple, yet powerful automation. We want to make automation easy for everyone to learn, use, and deploy, for developers, system administrators, and operators of every skill level.
Every day we hear the success stories of people who have been able to take Ansible’s powerful automation and use it to cut their IT costs, stabilize their deployments, and allow them to get back to their focus of their job rather than continually grinding through manual tasks.
On top of that, we’ve built Ansible Tower, a web interface and API that brings those same simple principles to applying command, control, and delegation to an Ansible deployment. Customers like Nike, Splunk, Grainger, and others use Tower to centralize their Ansible deployment, delegate credentials and tasks to users in a controlled manner, and allow easy self-service access to users without them knowing the specifics of those automation.
We’re always interested in making things simpler for our users, and this extends to deploying and trying Tower as well. That’s why we’ve decided to make Tower available for use with Vagrant - what’s simpler than that?
You can try out Ansible Tower in Vagrant with just a few commands.
I have been having issues using the F5 APM client behind a Juniper SRX-110 using hide NAT. I believe I’ve tracked it down to the default timeout settings used for UDP services. Here’s what I did to resolve it.
The laptop client was behind the SRX-110, using hide NAT. The initial client connection would work, and things would look good for a while. The the client would stop receiving packets. Traffic graphs would show a little bit of outbound traffic, and nothing inbound. Eventually, the client might decide it needed to reconnect. But usually, it would sit there for a few minutes doing nothing. Then I would force a disconnect, which would take a while, and then reconnect. Exceedingly frustrating.
Connecting the client to a different network – e.g. using a phone hotspot – worked fine. No dropouts. Using a wired connection behind the SRX had the same issue. So clearly the problem was related to the SRX.
I dug into the traffic flows to better understand what was going on. This SSL VPN solution makes an initial TLS connection using TCP 443. It then switches over to DTLS using UDP 4433 for ongoing encrypted Continue reading
Original content from Roger's CCIE Blog Tracking the journey towards getting the ultimate Cisco Certification. The Routing & Switching Lab Exam
BGP Dynamic Neighbors are a way to bring up BGP neighbors without specifically defining the neighbors remote IP address. Using the BGP Listen Range command you specify a range of IP addresses typically on your Hub site (maybe in a DMVPN environment) that you trust to become BGP neigbors with you. When a TCP request... [Read More]
Post taken from CCIE Blog
Original post BGP Listen Range Command