Using Intel vPro AMT ME as a poor man's iLO for KVM

Monday, 21 Jan 2019

Got Intel vPro AMT ME, bruv?

Recently I've been trying and failing to get Nutanix Community Edition (CE) to cluster-up, with one ESXi-nested virtualised AHV/CVM and another physical AHV/CVM, running on an old HP Elite 8200 Small Form Factor Desktop PC. If you've played around with Nutanix, you'll know there's a lot of tinkering with the Host (Acropolis Hypervisor, AHV) Node to install the Controller Virtual Machine (CVM), and a bit of rebootery required; if you've been following this blog long, you'll realise that I'm not favoured with the Technology Gods - and my mileage often varies into many more reboots than the average bear.

When you're working with a frankenmachine (ProTip - Buy a 13-pin male Mini-SATA to 22-pin female SATA Converter to use the proprietary MicroSATA/Power Cable going into the CD Drive for an SSD), which you've put in your upstairs LAN Room, then the frequent trips up and down, and lugging a keyboard, video and mouse can get, well, annoying. Unless, that is, you've got Intel vPro, Active Management Technology (AMT) or Management Engine (ME) onboard your lovely business-class Laptop or PC - and then you can use Intel's AMT VNC Server.

BIOS Time - Setting it up

Note - Most of the first part of this is the same as the How-to Geek article on How to Remotely Control Your PC with some added time-saving, hair-tearing-out tips to follow later.

As with all good things in life (with PC hardware), the fun stuff happens in the BIOS. As per the links above, this is fairly simple:

  1. Take your old school keyboard, video and mouse (or USB Crash Cart KVM Adapter, if Christmas time has just been) and plug them into your vPro/AMT/ME-enabled Desktop or Laptop (well, not Laptop, obviously because it's got a keyb... never mind)
  2. Reboot
  3. Furiously tap Ctrl + P to get into the Intel ME Settings BIOS
  4. When asked for a password, unless you set it, it will be "admin" (without the speech marks)
  5. Enter "ME General Settings", and
    1. Change the password to something more secure (it'll need to be at least one capital letter, one number and one special character)
    2. Setup the Network IP for AMT - think of this the same as an iLO/iDRAC/BMC, you can either "Share" the Host OS's one (but why, as you're tied into that), or set a seperate, dedicated IP for just AMT Keyboard Video Mouse (KVM) access
    3. Hit Enter and OK on "Active Network Access" (or this was all for nought)
    4. Configure the DNS-related Hostname, DNS Server and related settings (maybe something like amt-<PC_Hostname>, so you can distinguish the two in your DNS later on)
  6. Enter "AMT Configuration", and
    1. Enable the "Manageability Feature Selection"
    2. Enable "SOL" (Serial-over-LAN)
    3. Enable "IDER" (ISO/Image Remote Booting)
    4. Enable "Legacy Redirection Mode" (By Legacy they mean "Using something sensible like VNC Viewer, rather than crappy Intel-proprietary KVM Viewers)
    5. Enable "KVM Feature Selection"
    6. Disable "User Opt-in"
      1. If you leave it enabled, the non-existent person in front of the real keyboard/video/mouse that you plugged in will have to type a challenge/response string to allow you in, which defeats the point
    7. Enable "Opt-in configurable from Remote IT"
      1. For when you sit back at your desk, and realise you didn't do the step above
    8. Escape/Escape/Escape/Yes/Save/OK

Now we've setup most of it, what can we do?

Stage 1 - The ME Web GUI

Now you've done all that BIOS work, here comes the first payoff - a lovely Web User Interface you can access via http://<AMT_IP_ADDRESS>:16992, as per example below (my AMT IP is


The kind of information you get to see here includes:

  • System Information
    • Model, BIOS, Firmware etc.
    • undefined
  • Memory Information
    • Type, Number of DIMMs, Size etc.
    • undefined
  • Disk Information
    • Type, Size, Manufacturer etc.
    • undefined
  • Event Logs
    • Last Power, Last Crash, Case Opened etc.
    • undefined

Then there's the juicy ones that you literally don't want (or have) to leave your chair for any more:

  • Remote Power On/Off/Reboot
    • Including "Next Boot" actions (i.e. Boot to USB, Boot to BIOS etc)
    • undefined

Stage 2 - But Ma, where's my KVM?

If you've read this far, you're probably thinking you've been short-changed here; I promised you a KVM and I've delivered you a fancy Web GUI. So here's the fun part; you'll need one of the following to actually enable the VNC-based KVM functionality to work:

  1. (Windows App) MeshCommander
  2. (Windows App) Intel Manageability Commander
  3. (Windows SDK) Download Intel SDK, extract it some place and execute "KVMControlApplication.exe" (hiding away under the "Windows", and then "bin" directories (ProTip - You'll need to install Microsoft dotNET for this, so get a brew break ready), and you can then "Edit Machine Settings", login with "admin" and the <AMT_PASSWORD> you set earlier, and click "Machine Settings", then "Enabled - all ports" - as described in this lovely blog post

Regardless of which you chose, here's a big tip - the "RFB Password" has to be exactly 8 characters, and include at least one each of the following:

  • A capital letter
  • A number
  • A special character (i.e. @,'| etc.)

That tip right there saved you two hours of Googling "Error 400" and "XML invalid", and - my personal favourite - "KVM no respond" errors.

You can also do this from within MeshCommander, you click on the following sections, and then you'll get a prompt to chose the KVM "Enabled - all ports" and "RFB Password" (Intel-speak for "VNC Login Password")


Stage 3 - Look Ma, no hands(-eyes engineer lugging his ass upstairs)!

Once done, you can now use a standard VNC Client* to connect via <AMT_IP_ADDRESS>:5900 the same you would with any other standard VNC Server:

* = On Windows, only RealVNC seemed to work. On Mac OS X, only VNC Viewer seemed to work. On Linux (Debian), only Remmina seemed to work.


You'll then be prompted for the VNC Password (this is the pesky 8-character RFB Password):


And finally given a lovely KVM VNC session into your vPro-enabled PC or Laptop:


Et voila - the poor man's iDRAC/iLO/CIMC/<BMC acronym of choice here> is complete!

Note, if you have a Windows PC and don't want to enable the VNC (TCP/5900) part, then both MeshCommander and Intel Manageability Commander have a built-in, non-VNC KVM Client, which seems to speak some magical SOL/IDER "backdoor" protocol into the AMT chip, so they always work, regardless of you turning on/off the "Legacy ports" settings.

When BGP AS-Override goes the wrong way

Sunday, 13 Jan 2019

BGP AS-Override

Much like my post on when BGP SoO goes the wrong way, I seem to have a problem with directionality of commands on Cisco IOS - this time, with BGP AS-Override. I came across this in an Enterprise Network (the same kind where we say "MPLS" but actually mean "IP VPN we buy from someone else"), where the ISP we used had an offering they called "Shared Access" - which basically means they'll let you hook an Access Circuit into someone else's IP VPN/VRF with them, as long as you, the ISP and the "VRF Owning Company" co-sign an agreement saying it's allowed.

Why might you want to do this? Think along the lines of Extranets, and furthering the idea that "Everything is just a Line Card" across Company boundaries; particularly useful if you work in the Large Enterprise and Public Sector space, as here there are often strange agreements where multiple Managed Service Providers (MSPs), Systems Integrators (SIs) and sometimes even Service Providers (SPs) (reluctantly) come together to offer a common "Service" back to either the General Public, or perhaps some large Industry Sector. Regardless of the why, the problem is normally the same old BGP-over-VRF limitation - if you use the same ISP for multiple IP VPNs/VRFs, and have end-to-end BGP reachability, BGP doesn't know to turn off it's split-horizon-based-on-ASN functionality; because it just sees the same ASN twice in the AS_PATH, rather than "knowing" that the AS_PATH consists of two differing VRFs/Routing Domains.

The Scenario Topology


This is the Scenario Network Topology, showing:

  • 2x My Network MPLS CE Network Customer Edge (CE) Router
  • 4x MPLS SP Network Provider Edge (PE) Routers
    • 2x Connected to My Company Network IP VPN/VRF VPNN123456
    • 2x Connected to Other Company Network IP VPN/VRF VPNN654321
  • 2x eBGP Peering from My Company Network < -> SP MPLS PE Router, connected to My Company IP VPN/VRF VPNN123456
  • 2x eBGP Peering from Other Company Network <-> SP MPLS PE Router, connected to Other Company IP VPN/VRF VPNN654321
    • 1x "Foreign Network" CE Router @ My Company Data Centre
  • AS-Override applied on My Network MPLS CE Network (CE) Router (towards My Company IP VPN/VRF VPNN123456)
    • Note that I am "piggy-in-the-middle"

Some notes on SP Terminology

As some of this is specific to using a Third Party SP's MPLS Network, through a "wires-only" IP VPN offering - here's a quick primer on some terminology I'm using, as this will differ between varying SP's:

  • "wires-only" - Means the SP drops a NTE/NTU in My Company's Premises, to which I attach my self-managed CE Router
    • The SP does not manage any of CE Router; I eBGP Peer direct from a Private ASN to the SP's Public ASN (or whatever they use)
    • I'm told this model is more popular in the USA than Europe (but I'm in the UK, so there are exceptions to the rule...)
  • VPNNxxxxxx - The SP-allocated IP VPN/VRF Identifier, so that they can differentiate between their various Customers (they could name their VRF instances by Company Name, but what happens when the Company changes name, or two different Companies have the same/similar names...)
  • ASN Numbers - Those on the left-hand side are My Network ones; those on the right-hand side are "Foreign" (Other Company Network) ones
    • Just like between IPsec Encryption Domains, it's a good idea to make sure these don't conflict (tricky when everyone is using the same Private BGP ASN Range)
    • It is the same Core ASN/PE-CE Peering ASN that the SP uses for all Customers
  • CE Devices - I am the Customer (or one of two), and not the SP here; I have no visibility or access to any of the PE's in this topology
    • This is a very different slant to most write-ups and blog posts I've read on the matter; everyone seems to work for an SP bar me!
  • AS-Override - This is applied at My Company end only; the "Foreign" Company are not performing AS-Override
    • So the AS_PATH they "advertise" to me contains the raw SP ASN for their own CE-PE Peering,Their CE1 <->  PE2 and Their CE15 <-> PE66

What I thought would happen

Caveat - apparently, Cisco IOS doesn't let you use AS-Override in the Global Routing Table (GRT, y'know, the one that's not in an "address-family" command); but it sometimes does (worked on my ASR1K's), and that's not the point of this post.

Focussing on My Company Data Centre - and ignoring the "Southbound" eBGP Peering from this DC into MPLS IP VPN/VRF VPNN123456 - here's an example of the Prefix I'm looking at, received from "Foreign" Company:

CE1# via <DC-Router1>, AS_PATH: 65007 1234 64999

Now, if we look at the "Southbound" eBGP Peering towards My Company IP VPN/VRF VPNN123456, I want to re-advertise "Foreign" Company Prefix onward, via VPNN123456, into My Company Other Campus DEF (bottom-right). Given the "as-override" command is applied towards the SP's PE Router, I expected the "find-and-replace" operation to work in a similar (outbound) manner. That is, for this configuration on my CE1 Router @ My Company Network, Data Centre ABC:

router bgp 65432
 neighbor remote-as 1234
 neighbor as-override

I thought my CE1 Router would therefore rewrite it's own AS65432 (Local ASN, CE1 Router) with the SP's AS1234 (Foreign ASN, CE1 Router perspective) - so an AS_PATH that actually looks like this, to the downstream PE1 (and any other Routers) on VPNN123456:

PE1(VRF "VPNN123456") or CE99# via, AS_PATH: 65432 65439 65007 1234 64999

 ...but that's not how AS-Override works here.

What actually happens

It transpires the "find-and-replace" behaviour isn't working with the "find" parameter I think it is. If I use some colouring here, this will be easier to see. If we show the entire AS_PATH (including the Routers at either end, which you normally wouldn't see in BGP outputs), here's what you've got for Prefix going all the way to CE1 @ My Company Data Centre ABC:

  • 64999 1234 65007 65439 65432 1234 65430

I appreciate this runs inverse/reverse to the AS_PATH that CE1 actually sees; but bear with my incorrect directional thinking here. So the part I'm focusing in on is between CE1 <-> PE1, or this part:

  • ...65432 1234...

At this point, in my head, I'm thinking "The neighbour command is applied outbound to the SP PE1 peering, so it must use this relationship in the find-replace activity", so I'm thinking, after the AS-Override rewrite, it looks like this:

  • 64999 1234 65007 65439 65432 65432 65430

Here's the kicker

The reality is that AS-Override doesn't care about eBGP Peering relationships; it acts as a dumb "find-replace" algorithm, but it uses the eBGP Peering configuration to get it's "find" parameter, by looking at the ASN value after the "remote-as" command, so here for CE1:

  • router bgp 65432
    neighbor remote-as 1234

What it then "dumbly" does is looks at the entire AS_PATH it already has, and simply replaces the <REMOTE_AS> value with it's <LOCAL_AS>, before "advertising" this out, so for CE1 it would do this instead:

  • 64999 65432 65007 65439 65432 65432 65430

Which completely broke my thinking, as I hadn't appreciated that a downstream Router could overwrite an AS_PATH entry that happened much earlier-on in the formation of the AS_PATH (i.e. for a Peering Association it wasn't involved in, so how could it dare overwrite anything to do with that?).

So what next

For the example given, we actually ended up moving all this entirely, such that we had a PE-like Router where we could control ingress/egress into both IP VPNs (and AS-Override in both directions, between both IP VPNs) - but this isn't always possible. Technologically, it's easy to look dismissively at the Scenario Topology; but if you step back a bit, you appreciate our hand was forced. As I described earlier, this is a politically complex setup, with various MSPs and SIs - and as you can see, although CE15 sits in "our" DC (actually an MSP, but anyway...), it's actually a CE Router of our "Foreign" (think Extranet) Company's IP VPN (VPNN654321); which they just so happen to have with the same SP that we have Our Company IP VPN (VPNN123456) with.

Sure, this isn't a great place to be - but (in that time-honoured phrase), "It is, what it is"; looking longingly at CCNP and CCIE Greenfield Exam Topologies isn't making this self-rectify. We were fortunate because we had the capability to entirely redesign this (something for another blog post), but if we hadn't, there's a whole manner of constraints here causing pain, such as:

  • SP won't let us reconfigure their PEs on either IP VPN/VRF (so no quick-win "Bang AS-Override on PE66 and PE1" for you)
  • Commercials mean we can't collapse-out the CE15 <-> PE66 arrangement
  • CE1 / Data Centre ABC doesn't just exist for this flow (so no quick-win "Bang the VPNN123456 eBGP Peering into a VRF Lite instance, instead of the GRT"

What's the point then?

Ignoring the goal of getting this working, this was a useful real-world exercise, as it taught me:

  1. BGP AS-Override is dumb, and will quite happily assume the <REMOTE_AS> to <LOCAL_AS> Peering is the only one that contains the <REMOTE_AS>, which couldn't possibly already be in the AS_PATH
  2. BGP is not VRF-aware; it's rules of split-horizon are there to annoy me and rob me of sleep
  3. Stop reading "neighbor" commands and assuming they imply the directionality of the thing they are doing
  4. Googling for issues like this throws up limited results, because everyone else seems to be able to access the SP PE Routers
  5. I need to flip-round the way I think about AS_PATH as "Destination-to-Source" rather than "Source-to-Destination"

Making BlueCoat ASG use one Forwarding VIP for multiple TCP Services

Friday, 07 Sep 2018

BlueCoat Advanced Secure Gateway

The BlueCoat ASG are a series of Proxy Appliances, sold by Symantec and commonly used for a combination of Proxy Types, such as:

  • Forward Proxy
    • HTTP/S Web Proxy to Internet
    • SOCKS Proxy to Internet
  • Reverse Proxy
    • ActiveSync Proxy to Microsoft Exchange
    • Oracle OAM Proxy to Oracle Authentication

Once you get past the fact that the Admin Panel runs Java (eww), they aren't bad boxes to configure and use; but if you're coming at these from a Networking background, be warned - everything is split-out into a different section, and not much is where you'd expect it to be.

The Scenario

My Scenario was using the Virtual IP (VIP) functionality, to offload some Reverse Proxy functionality to a downstream Appliance; which sits behind the BlueCoat to allow it to (in future) perform some DPI and other bits and pieces. I needed to create one VIP Address, but have it forward three TCP Ports/Services:

  • SOCKS (Running on TCP/80)
  • SSH (TCP/22)
  • RDP (TCP/3389)

The Proxy VIP (BlueCoat VIP) is

The Downstream Proxy Real IP (BlueCoat Forwards/NATs to) is

Coming from a Networking background, my mind went to NAT, VIPs and Load Balancer Groups; but BlueCoat doesn't play ball that way.

Elements to Configure

The following sections of the Admin Panel/BlueCoat Configuration need to be modified to achieve this:

  • Proxy Services
  • Forwarding Hosts
  • Forwarding Host Groups
  • Visual Policy Manager (Forwarding Layer)

So let's crack on.

Proxy Services

  1. From BlueCoat Admin Panel, navigate to Proxy -> Configuration -> Services -> Proxy Services
  2. Add your "Custom Service Groups" (mine is called "CustomGroup")
  3. Add your SOCKS/SSH/RDP Service Group elements, under the "Custom Service Groups" section
  4. Set these to "Intercept", and Source to "All" (or specific Downstream User Subnets, which should be able to access the VIP)
  5. Click "Apply" (bottom-right) when done


Forwarding Hosts

  1. From BlueCoat Admin Panel, navigate to Proxy -> Configuration -> Forwarding-> Forwarding Hosts
  2. Add your "Forwarding Hosts", one per TCP Service you want to listen to (I have three)
  3. Within each Forwarding Host, set the "Type" to "Server", and specify the relevant "TCP:" port you want to use
  4. Click "Apply" (bottom-right) when done


Forwarding Hosts Groups

  1. From BlueCoat Admin Panel, navigate to Proxy -> Configuration -> Forwarding-> Forwarding Hosts -> Forwarding Groups
  2. Define a custom Group Alias (mine is "Custom-Group") to use as the Group container for the three Forwarding Hosts you input
    1. undefined
  3. Add your Custom Hosts to the Custom Group:
    1. undefined

Visual Policy Manager (Forwarding Layer)

  1. From BlueCoat Admin Panel, navigate to Proxy -> Configuration -> Policy -> Visual Policy Manager -> Launch
  2. Within "Forwarding Layer", add an entry using your VIP Address (, with a colon (:) after, and "Any" Service
    1. undefined
  3. Tie this to a new Action called "Action-CustomGroup"
    1. undefined
  4. Edit "Action-CustomGroup" to relate to the Forwarding Host Group you specified earlier (Custom-Group), and "Deny the request" if the Forwarding Host (i.e. all TCP Ports within that Group) aren't available
    1. undefined
  5. Within VPM, apply the policy to the BlueCoat ASG - navigate to File -> Install Policy on SG Appliance
  6. Party on down, we're done!

Wrapping it up

BlueCoat ASG will quite happily let you specify a collection of individual Forwarding Hosts, each with an individual TCP Port; and the VPM will then let you specify these multiple individual Forwarding Hosts - but it won't actually VIP Forward the traffic, and will fail miserably.

The above seems to be the "BlueCoat Way" of doing this, and definitely works.

When BGP SoO Site of Origin goes the wrong way

Sunday, 12 Aug 2018

BGP Site of Origin (SoO)

I have a scenario where an "internal" Service Provider (SP) MPLS Network interfaces with a Third Party's MPLS Network, as an IPVPN - rather than a true MP-BGP Handoff; or in other words, "I happen to know it's underpinned by MPLS so I'll call it that, even though technically it's not MPLS Presentation to me" (the same way most Enterprise Network shops refer to their WAN as "MPLS").

Unlike the base assumption of most Cisco articles on SoO, I don't actually control the Provider Edge (PE) Routers on this Third Party (let's say, "BT") MPLS Network; and nor am I the Third Party themselves. What I'd like to do is identify Prefixes I have on my IPVPN "Overlay" MPLS Network, from CE Routers on said IPVPN Overlay Network that I do control, and block them from coming back into my own SP MPLS Network. I thought BGP Site of Origin (SoO) might be my friend here...

The Scenario Topology


This is the Scenario Network Topology, showing:

  • 2x My MPLS SP Network Provider Edge (PE) Routers
  • 1x My MPLS SP Network Route Reflector (RR) Router
  • 2x BT MPLS PE Routers (Location Unknown)
  • 2x eBGP Peerings from My <-> BT MPLS PE Routers
  • 2x Repeated BGP SoO Communities (65432:999), applied to VRF (IPVPN) "BLAH"

What I thought would happen

Given the BGP SoO Attribute is applied towards the BT (Third Party MPLS Network) PE Router, I thought I'd be able to jump on one of my MPLS Enterprise Network CE Routers, and see the SoO Attribute 65432:999 applied, as it made sense to me that this configuration would "advertise" the BGP SoO Extended Community from Me -> BT:

router bgp 65432
 address-family ipv4 vrf BLAH
  neighbor remote-as 2856
  neighbor send-community both
  neighbor soo 65432:999

Where I then duly hop onto my CE1 Router and issue the following, expecting to see the SoO Tag for my VRF "BLAH" Network:


But, no dice - it's just a normal IPv4 BGP Prefix with no Extended Communities. What gives?

What actually happens

At this point, confused, I start to wonder if I'm misunderstanding what SoO does and is, and getting confused between the simplistic Cisco and Internet examples of SoO (which are aimed at Service Providers, from their perspective, towards a singular Customer Edge/Customer) - so I poke around. The first point I poke around on is a "non-SoO Tagging PE Router', PE99 - which has an attachment to VRF "BLAH" (an ingress/attachment point into My MPLS Network, for VRF "BLAH"; but performs no SoO tagging) - and see what I see:

PE99#sh ip bgp vpnv4 vrf VLAH
  ...Extended Community: SoO:65432:999 RT...

Which starts to make it click - the SoO must be applied "the wrong-way-around" from what I thought, and be an "ingress only" behaviour, as otherwise I wouldn't see it this side of the MPLS CE-PE Network Handoff fence. Or more succinctly, this is the direction/Routing Domain the SoO Tag is applied into:


Even though I first looked at this part of the SoO command as an "advertise-out"/egress behaviour; it's actually a "Match Packets from this BT Peer, mark them with this when advertised deeper back to us" behaviour. Because I looked at this part of the config as an "advertise SoO to neighbour" behaviour:

  neighbor soo 65432:999

Which is different to what I first expected ("advertise-out" behaviour), which would have been this:


What have I learned?

In effect, then, depending on your "directional thinking", based on the Cisco IOS syntax, you might be unpleasantly surprised by how this works - to my mind, it's working the wrong-way-around from what the config syntax would suggest. What actually happens, as a result of just one line of config, is:

  1. On PE1# (My<->BT Network 1st CE-PE Handoff)
    1. Apply SoO Tag 65432:999 inbound/ingress (BT->Me) for all BT-side Prefixes
    2. Advertise this SoO Tag 65432:999 deeper back to My SP Network (not BT's at all)
  2. On PE99# (Any other CE-like Router on My Network; Attachment Point into VRF "BLAH")
    1. See SoO Tag 65432:999 on BT-native Prefixes
    2. Do nothing about it; "advertise on" SoO Prefix (don't strip it out on re-advertise to another PE/Router)
  3. On PE2# (My<->BT Network 2nd CE-PE Handoff)
    1. See SoO Tag 65432:999 pre-egress/outbound (just before Me->BT) for the BT-side Prefix
    2. Because the Me<->BT eBGP Peer has the same SoO Tag set, don't allow it out to BT Router ("reverse behaviour")

The same would then happen for BT->PE2->My MPLS->PE1, performing an overlapping-behaviour for the secondary/dual-homed path between My Network<->BT's Network.

So these bits are wrong then

Which means, given SoO is an "inbound behaviour", not an "outbound" behaviour, the whole concept of tagging these with 65432:999 as the SoO Tag doesn't make sense; it probably should be 2856:999, to show these are BT-native, not My Network-native.

It also means I should re-think why I'm using SoO here, as a Tag+Block/Route Map technique, using bog-standard BGP Communities, might be a better fit for the behaviour I wanted.

I've been here before

Sadly, I've fallen victim to this presumed "outbound behaviour of the config" before with my friend BGP AS-Override, which also has a strange "not the way you might expect" behaviour, but that's one for another blog post. Key points here are:

  • Trust nothing
  • Lab everything
  • Assume that Cisco Support Forums write-up that looked exactly like your scenario was too good to be true

The difference between BGP RD and RT

Friday, 10 Aug 2018

BGP Route Descriptor and Route Target

Let me caveat this post by saying I'm not a Service Provider (SP) kid by trade; I spend my life doing Enterprise, Data Centre and Wireless - so all this MPLSery is new territory for me, and my imaginary sidekick-dog friend ("Hi Jake!") - which means this might be technically incorrect, but this is how the concepts of RD and RT finally "clicked" for me.

How it was explained to me


When I first starting Googling for Dear Life (TM) about this (because I needed to spin up a new VRF/IPVPN/L3VPN on our MPLS Network), and looked at a few existing config excerpts, I thought they were both the same thing, which seems valid:

vrf definition ADVENTURE-TIME-VRF
 route-target export 65432:999
 route-target import 65432:999

I didn't really question the fact that the Export/Import Route Target (RT) was the same (and didn't know about "Full Mesh VRF" vs "Hub-and-Spoke VRF"), but it did strike me as odd that the RD wasn't the same as the RT, given all the explanation I'd read said things like:

The RD is used to keep all prefixes in the BGP table unique between Customers or VRFs...

Which I read thinking:

"Hmm, that makes sense; BGP will just append the RD in-front of the Prefix, to identify the VRF it belongs to. But wouldn't that mean the RD should be the same for each PE Router, the same for each instantiation of that VRF/Customer across the network?"

So then why the differing RD from the RTs?

Why bother with the extra admin work of creating a different value each time, between the RD and RT?

How I now understand it


When I started exploring Full Mesh VRF vs Hub-and-Spoke VRF, it started to click into place - the RT and RD aren't really related, and I think there's some missing text from the common definition of how RD's are enacted:

  • RD = Route(r) Descriptor
  • RT = Rout(ing Table) Target

When I looked around the configs we had elsewhere, the pattern become clear; it decomposed like this:

vrf definition <VRF Human-friendly Name>
 rd <Router Loopback0>:<VRF RT No>
 route-target export <Router ASN>:<VRF RT No>
 route-target import <Router ASN>:<VRF RT No>

It's starting to click

Then you step back a bit more, and realise the VRF Name and RT/RD have pretty much no association (and then it suddenly clicks what they mean when they say "Locally Significant"...), and we - as humans - use the same VRF Name everywhere because it's easier for us, like a sort of "Poor Man's DNS for VRF RTs". So there's no reason this config wouldn't just stitch VRF "Bob" to VRF "Jane" between two Routers in the same MPLS Domain - but it'd be a pain in the arse to troubleshoot when it scaled to more than a few Routers:

Router_PE1#vrf definition Bob
 route-target export 65432:999
 route-target import 65432:999

Router_PE2#vrf definition Jane
 route-target export 65432:999
 route-target import 65432:999

Great Scott! He's got it!

Which is when it clicks - when you look at two Router's configurations and realise the RT is the same, but the RD changed; within what we've established is the same VRF "Container" (even though we renamed it across Routers, to cause pain to that guy in Ops that looked at our wife wrong during that Christmas Do, yeah - "Bob"...). So roughly then:

  • An RD can be thought of as the "Router Descriptor"
    • i.e. "Who injected that Prefix into my VRF?"
    • Probably makes sense to use a Loopback, or unique attribute of a Router; then you can jump on your Route Reflector (RR) and have a quick "Whodunnit?"
      • Router_RR1#sh ip bgp vpnv4 all | sec <Router Loopback0>:<VRF RT No>
  • An RT can be thought of as the "Routing Table Target"
    • i.e. "So that's just a VLAN-equivalent Tag for a VRF Container on the MPLS Domain then..."
    • If it's the same RT you're import/exporting everywhere, we're rocking Full Mesh; if it's not (or I'm suddenly doing loads of import statements/one export statement, or vice versa), we're looking at a pesky Hub-and-Spoke
      • Got multiple RT Import statements and one Export? You're probably on a Hub Router (for that VRF)
      • Got one RT Import statement and multiple Exports? You're probably on a Spoke Router (for that VRF)

Am I right here?

That's how I understand all this MPLS VRFery anyway; if I'm wrong, why not:

  • Tweet me @notworkd and tell me "U iz well wrong, Bruv..."
  • Write a comment below and tell me "Dude, do you even MPLS, Bro?"


I'm not Technical, but...

Sunday, 22 Jul 2018

A day in the life of

There you are, describing the latest solution/thesis you have to a problem, Project or task, and then someone comes along and says:

I'm not technical, but...

And just like that, you're thrown sideways. Disparaged. Condescended. Belittled. Siderailed.

My problem here isn't the content that's about to follow - it could well be valid (it could well not, too), and could change the direction of the idea to the right direction. My problem is the derision and disdainful manner this is normally delivered to me in. I mean, why even include the prelude and the "but"; if you've got something to contribute, jump in - it's what you'd do in a normal business conversation

You wouldn't say that to a Doctor

Would you say the same to another field or vocation that you were more familiar with - maybe a Doctor or Healthcare Professional? What about another field you popularly know to exist, but probably don't have exposure to - maybe a Nuclear Physicist?

It's not that your opinion is invalid; you have the right to opine about anything, in the same way I would. It's that your presentation of said opinion is disrespectful - not just of me, but also of:

  • My chosen career profession
  • The financial and personal background
  • The context of your and my employment
  • Our respective positions to our employer

But for some reason, you think that the inclusion of this prelude with a little "but" counteracts all these.

Respect that I'm here for a reason

  • I'm not a Project Manager; I'm not paid to manage time and cost of delivery (but I can cost-up and cook a three-course meal)
  • I'm not a Business Analyst; I'm not paid to analyse business requirements against our employer's strategy (but I can work out the difference to my family of buying a shiny new MacBook vs getting that larger house we could all do with)
  • I'm not a Commercial Analyst; I'm not paid to understand common costings or understanding market economics (but I do recognise that buying artisanal gluten-free bread should cost more than a standard white loaf)
  • I'm not a Legal Consultant; I'm not paid to understand the laws my employer is subject to, or loopholes within them (but I do recognise that torrenting Adobe Photoshop is a lesser crime than killing a man)

We all know how to do things we're not paid to do; that's why opinions can be valid. We're not paid to know all the things we can do; that's why you need to respect that I exist here for a reason, the same way I respect you exist.

If you don't understand or accept something, feel free to question and interject; but don't add an insulting prelude before you do, and recognise that the person you're talking to was not only employed to do the very thing you're about to question, but has also legitimately built a career upon it.

I'm not business; but...

Butt out.

Home ← Older posts