So… I’m a little embarrased to admit this but I only very recently found out that there are significant differences in how Virtual Port Channels (vPC) behave on the Nexus 5k vs the Nexus 7k when it comes to forming routing adjacencies over the vPC.
I’ve read the vPC Best Practice whitepaper and have often referred
others to it and also referred back to it myself from time to time. What I failed to realize is that I should’ve been taking the title of this paper more literally: it is 100% specific to the Nexus 7k. The behaviors the paper describes, particularly around the data plane loop prevention protections for packets crossing the vPC peer-link, are specific to the n7k and are not necessarily repeated on the n5k.
There’s a lot of information on the intertoobs about getting ssh-agent “working” in OS X and even more articles about when and how the stock behavior of ssh-agent changed (mostly with respect to how ssh-agent interacted with the Keychain).
This article doesn’t cover or care about any of that.
This article is concerned with:
Enabling ssh-agent in such a way that I can “ssh-add” in one terminal window and that same agent (and the loaded keys) is available in all of my other terminal windows.
Enabling use of ssh-agent from MacPorts and/or Homebrew and not the older ssh-agent that OS X ships with in /usr/bin.
To avoid having to put my keys in the Keychain (just a matter of preference).
At Cisco’s GSX conference at the start of FY17, the DevNet team made a programming scavenger hunt by posting daily challenges that required using things like containers, Cisco Shipped, Python, and RESTful APIs in Cisco software in order to solve puzzles. In order to submit an answer, the team created an API that contestants had to use (in effect creating another challenge that contestants had to solve).
This post contains the artifacts I created while solving some of the challenges.
I’m a big fan of Let’s Encrypt (free, widely trusted SSL certificates) but not a big fan of most of the client software available for requesting and renewing certificates. Unlike a typical certificate authority, Let’s Encrypt doesn’t have a webui for requesting/renewing certs; everything is driven via an automated process that is run between a Let’s Encrypt software client and the Let’s Encrypt web service.
Since the protocols that Let’s Encrypt uses are standards-based, there are many open source clients available. Being security conscious, I have a few concerns with most of the clients:
Complication. Many of the clients are hundreds of lines long and unnecessarily complicated. This makes the code really hard to audit and since this code is playing with my crypto key material, I do want to audit it.
Elevated privilege. At least one of the clients I saw required root permission. That’s a non starter.
I got an interesting email from Ying Lu who had read my posts on LSM:
I am curious about the Ethernet DA and codepoint used for multicast MPLS. Previously, I understand that:
– Ethernet DA is unicast MAC of nexthop of each replication leg.
– codepoint is 0x8847
However, looking at RFC5332, I am not so sure…
“Ethernet is an example of a multipoint-to-multipoint data link. Ethertype 0x8847 is used whenever a unicast ethernet frame carries an MPLS packet.
Ethertype 0x8847 is also used whenever a multicast ethernet frame carries an MPLS packet, EXCEPT for the case where the top label of the MPLS packet has been upstream-assigned.
Ethertype 0x8848, formerly known as the “MPLS multicast codepoint”, is to be used only when an MPLS packet whose top label is upstream assigned is carried in a multicast ethernet frame.
Interesting question. What is the ethernet destination address (DA) and the value of the ethernet type field (codepoint) when the MPLS packet is being sent on an LSM LSP?
Getting back into the lab, I started a ping from CE1 to a group that CE3 had joined. I then ran a sniff on the segment between P and PE3.
Examining the capture shows a unicast address in the ethernet DA field and an ethernet type of 0x8847.
I started wondering if I could trick the P router into using a multicast ethernet frame so I spun up a fourth PE and attached it to the same segment that P and PE3 are on and had it join the same multicast group.
The P router continued to send unicast ethernet frames with a type of 0x8847 and just started putting two frames on the wire, one for PE3 and one for PE4. It did not, as I had hoped, put a multicast ethernet frame on the wire that would be picked up by both PEs.
So it appears that IOS — and I tested this with a version of IOS 15.4T — sends unicast ethernet frames when sending LSM packets and therefore also uses an ethernet type code of 0x8847.
Presented by: David Prall, Communications Architect, Cisco
For reference, David is the “father of IWAN”.
This session was not what I was expecting. I was expecting design and architecture, but it was all about features in IOS and IOS-XE (eg, FHRPs, talked about routing protocol timers, PfRv3, BFD). I guess I need to pay more attention to the session code (RST == routing; ARC == architecture).
Networking. Unix. Cyber Security. Code. Protocols. System Design. My Blog.