I am not sure what happened here but we have enough bad press without this.
A common and reasonable requirement would be to secure communications of the control plane for BGP between two neighbors to provide data authentication, confidentiality and anti-replay. Since BGP does not possess any inherent security mechanism other than MD5 authentication (and some session based protections for eBGP) the only option is to use some other feature to provide this. The most common protocol for IP based security is IPsec.
One approach to this is to use a tunneling method, such as GRE or VTI, to establish the BGP session between the two peers. The problem with this is that a tunnel may have an undesirable effect on the data plane for various reasons including issues of fragmentation, reduced MTU, and performance. Moreover path MTU discovery does not always work correctly when IPsec is involved. (It can work if you configure IPsec to copy the df-bit from the IP headers and the transit path is not blocking ICMP. )
This problem of data following control plan can be overcome with a route-map applied inbound to all updates from the eBGP on the far end of the tunnel to point to the physical interface next-hop. The end result is that the eBGP session is established across the VTI yet the BGP table has the next hop of the physical interface of the peer, not the tunnel IP.
Sample config from R1:
!First we need to define phase 1 policy:
crypto isakmp policy 1
crypto isakmp key CISCO address 22.214.171.124
!We then create our transform set & IPsec profile:
crypto ipsec transform-set XSET esp-aes esp-md5-hmac
crypto ipsec profile PROFILE1
set transform-set XSET
!A VTI is created using the directly connected subnet between R1 and R2:
ip address 126.96.36.199 255.255.255.0
tunnel source Ethernet0/0
tunnel mode ipsec ipv4
tunnel destination 188.8.131.52
tunnel protection ipsec profile PROFILE1
!The BGP session is establish to R2 using the tunnel IP:
router bgp 100
network 10.0.0.0 mask 255.255.255.0
neighbor 184.108.40.206 remote-as 200
neighbor 220.127.116.11 route-map SET-NEXT-HOP in
!Our route-map modifies all updates from R2 to point to its physical interface.
!This must be applied INBOUND:
route-map SET-NEXT-HOP permit 10
set ip next-hop 18.104.22.168
The end result is that the networks advertised from R2 have the next hop PA of the physical interface of R2, not the tunnel. Therefore the data plane traffic will use the directly connect subnet for transit rather than the VTI:
Notice that the eBGP session is established over the VTI:
However we can send the full sized packet to the eBGP peer. No MTU issues here:
We cannot say the same for the VTI which will not support the standard 1500 byte MTU:
Mission completed. The BGP control plane has been secured using an IPSec VTI and the data plane follows the directly connected interface rather than the tunnel. Please note that while the IPsec settings used here are suitable for lab purpose, consider using stronger cipher suites and hashing for a production network. (And never used the shared key of “CISCO” except in lab!)
I took and failed the CCIE R&S v5 lab last Friday. It was my first attempt at the version 5 and third overall. I wanted to throw some random tidbits out there about my impression of the lab while withholding anything that would be a violation of the NDA or exam integrity.
For study I used the Cisco blueprint, IOS configuration guides, Cisco 360 (now called Cisco “Expert Level Training”) and INE v5 workbook. I completed the INE workbook except for the Services and Security section which are incomplete. I am already well versed in these topics so for exam purposes I was not too concerned.
I used the Cisco 360 graded labs for assessments and my scores ranged from 60 – 100%. Overall I did quite well on the Cisco graded labs. Unfortunately, I can say now that they do not resemble the real lab at all. They are way too brief with disproportionate amounts of configuration spent on certain technologies/features that were nothing like the real lab. (Excuse the vagueness but I want to avoid violating the NDA! )
The INE v5 workbook was great for a basic understanding of the technologies and I believe it should be a mandatory part of study. I completed the workbook and made flash cards with all of the configs I had trouble with. I practiced each technology on a weekly basis and I had no problems understanding any task on the lab.
This was just as difficult as v4. Very similar format updated with v5 topics. The questions seemed to be either really easy or very difficult. Nothing lukewarm. I used the full 2.5 hours and scored fairly high. I assume my score was just below passing threshold.
I was concerned about this one
since none of the practice labs I used (INE or Cisco) have included this. EDIT 9-10-2015: all major vendors now have a diagnostic section in their material. It is relatively close to how Cisco has publicly described it. It you understand the blueprint of the exam you should have no issues with this. I passed it and I believe that I got just 2 out of 3 correct.
This thing was a surprise! For me there were no curve balls except the sheer volume of tasks necessary to be completed and the size of the topology.
It is very different, topology wise, than v4! I do not feel than any vendor that I used (including Cisco, IPexpert, or INE) has practice labs that are even close to what the real thing has. EDIT 9-10-2015: all major vendors now have updated their materials. In my opinion the changes reflect what a “real” world network would be like rather than something baked up for a certification lab like they were in version 4. Think “global” and highly interconnected.
My biggest gripe is that the user interface stinks. It was very unresponsive and very hard to manage all of the topology documents. This is further hurt by the fact that the terminal emulator does not have tabs and you are stuck with a single monitor. I left feedback to this effect. My understanding is that they are in the process of getting dual monitors.
I plan to make my next attempt in 90 days. My wish list is for practice labs that actually have a topology that is more comparable to the real thing in terms of task and size. I think Cisco did a great job of making the exam much more real world, topology wise, but if you are used to the v4 format you need to radically change your thinking.
The industry is abuzz about the ongoing transformation of the data center! With technologies like SDN, OpenStack and so called “white box” switching, insiders have voiced their opinion that these changes spell certain trouble for status quo players like Cisco. Cisco has enjoyed an almost monopoly like status in enterprise switching, hovering in the 61% range leaving competitors to fight over single digit table scraps.
Not be outdone, Cisco spawned and assimilated its own brand of SDN, now called Application Centric Infrastructure (ACI), that has proven to be formidable in the market place. As it turns out, ACI was just a red herring for a product Cisco calls “Network Defined Software” or NDS.
NDS is Cisco’s way of bringing the network back to where it belongs: in the hands of highly paid and over qualified Network Engineers. While a full architectural model is beyond the scope of the article (and the authors time budget) here is a brief overview of how it works.
“We realized that our customers were using our products incorrectly”, said one Cisco employee on the condition that his name not be revealed. According to Joey, we can pretty much support any-to-any connectivity and can programmatically deploy an entire network with minimal effort since around 2004. He continued, “Developers just don’t understand networking beyond a basic hub and a few nodes. If they had read a book or two, they could have placed a nice wrapper around any commodity scripting environment, like Expect and gotten similar results. But hey, we’ll take their money. ” Joey continued stating how existing technologies like VLAN tunneling (QinQ), coupled with MPLS VPLS/EoMPLS could support ten of thousands of nodes in a multi-tenant environment with minimal effort.
The internal code name for Cisco’s NDS is named “Closed Stack”, presumably a bit of snark directed at another hot technology. It will be interesting to see how many customers sign on to NDS. Only time will tell. Read more here.
I am now in the final phase of lab prep for my CCIE R&S v5 exam. I am disconnecting from as much media as possible to focus all minutes of the day possible on the exam. Hopefully in 90 days I will have those digits.
I was looking for an external USB enclosure to house a spare 256 GB SDD that I have laying here on my desk. While looking around I noticed a housing for about $20 on Amazon that boasts support of “UASP.” Curious, I wanted to find out if this is something I care about.
In short, it is.
USB storage uses something known as USB Bulk Only Transfer (BOT). This is essentially a subset (read: stripped down) of the SCSI command set that was built specifically for USB attached storage. While it is fine for things like thumbdrives and even desktop external disk drives, the BOT scheme has severe performance limitations when it comes to random read/writes and out of order commands as you would get when running VMs from an external USB drive. (Come on now. I am not the only one.)
This is where the USB attached SCSI protocol (UASP) comes in. UASP addresses a number of the problems with BOT including more robust command set and command queueing to allow out of order commands. It also eliminates much of the CPU overhead. So you get the full SCSI command set over USB with no out of order penalty.
Keep in mind since most desktop drive use the ATA commands set (aka SATA drive) there is always some level of SCSI to ATA translation happening in the external housing regardless if you are using BOT or UASP.
Alternate title: Monday morning musing on the RSTP backup port role.
Arguably the most misunderstood role in RSTP is the so called “backup” port role. The mantra of this role is typically that this type of port should not been seen on a modern network where full-duplex is prolific. The reasoning here is that this role is found when our RSTP bridge is connected to a half-duplex, shared media aka hub like so:
Indeed this topology will cause Fa0/2 to move into the backup port role since we are connected to a hub. However, to be clear here, the reason we are moving into backup is not merely due to the fact that it is a hub but rather due the propagation of BPDU’s.
The second reason we would see this is when there is a self-looped port:
Observe. Notice that this is not half-duplex media. The point is that we have the backup port role and we are talking full-duplex which proves disproves the notion that backup port is found only on half-duplex media.
The third time we see this backup port role is when we are connected to a switch that does not support STP and the BPDU’s are flooded as unknown multicast. (MAC: 0180-c200-00xx)
Again, notice here we are not half-duplex or self-looped and the interface Fa0/24 is in backup port role:
EDIT: My port numbering in the IOS output does not match my last topology diagram, but you get the idea…