Archive for December, 2013

MPLS, an acronym thrown around my field, some understand it and others just say it to look smarter than they really are. Either way, very few people will ever touch the actual configuration on the service provider (SP) side and will only interface from a CE (Customer Equipment) side. I will give a very brief overview of the three most common types and their generic terms.

  • L3VPN MPLS Private IP – This is a layer 3 solution where you are given a private, RFC1918 address, to peer with SP PE (Provider Equipment). Most of the time you’ll want to peer with OSPF, if available, or more likely BGP, to exchange routes between sites
  • L3VPN MPLS Public IP – Same as above with public IP addresses provided by either the SP or if you happen to own your own block; however, the latter has considerable design attributed to it and most don’t resort to this option. You’re likely to find more L3VPN MPLS with private IP
  • L2VPN VPLS – This service, very popular with people who can manage their own infrastructure responsibly, creates a WAN solution which appears as if all your offices are on one big ole VLAN/broadcast domain. In this scenario you can connect at layer 2 and span your broadcast domain or, like most implementations you’ll see, connect using a layer 3 interface and peer with a dynamic routing protocol like OSPF.

There are lots of design considerations to be taken into account when building your MPLS cloud, each with it’s own little issues and “kinks” to iron out; however, DO NOT choose loosely. Building a fully meshed MPLS requires considerable thought about how your network works today and how you plan on running it in the future. Take it from my experience in having to migrate a global network from a L3VPN solution with 60+ static routes to a VPLS based solution using OSPF, the road to get there is painful and frustrating.


For those of you who are wondering how to bill for a COTA’s time against NC Medicaid, you will use the supervising OT NPI on the billing; however, you must be in coordination with the NCBOT supervision found here: .


All Cisco switches by default have PVST+ as their spanning-tree protocol (mode). PVST+ is Cisco proprietary and, in my humble opinion, should never be used in a production environment. The alternatives are: RPVST and MST. In a basic 1-3 VLAN network with little to no knowledge of spanning-tree you should run RPVST (802.1w) and be done with it. However, if you have a lot of VLANs and/or you need to ensure you’re not over utilizing the CPU resources, you should use MST (802.1s).

MST (802.1s) is called Multiple instances of Spanning-Tree Protocol and actually relies on RPVST to run inside each instance. MST runs in instances (think of them as groups) and in those instances you can map as many VLANs as you want; thus, you reduce the number of RPVST processes running. For example, in RPVST if you have 10 VLANs, you will have 10 instances of RPVST running, one per VLAN. However, in MST, if you have 10 VLANs grouped into only one instance, there is only one instance running, not 10.

MST is powerful because it reduces the CPU cycles used for spanning-tree operations but can also be used to create multiple paths for groups of VLANs. Configuring MST is simple and requires only a few things to be configured, which I will show here


spanning-tree mode mst

spanning-tree mst configuration
name SOMENAMEGOESHERE
revision 1
instance 1 vlan 1-4094

spanning-tree mst 0-1 priority 4096

For the breakdown:

  • spanning-tree mode mst – Turns on MST as the spanning-tree mode
  • spanning-tree mst configuration – Places you into MST subconfiguration menu
  • name – The name is case sensitive and must match on ALL switches
  • revision 1 – This sets the revision number, which must match across ALL switches, any number will do
  • instance 1 vlan 1-4094 – This maps all the VLANs to instance (group) #1, taking them out of the default IST instance 0
  • spanning-tree mst 0-1 priority 4096 – This sets the priority of both the IST (0) and instance 1 to 4096 to ensure it is always the root bridge

By default there are two instances started by default: IST (Internal Spanning-tree) and CST (Common instance Spanning-tree); however, these are commonly viewed as just one instance CIST. Basically, CIST interacts with other “modes” of spanning tree and is ALWAYS active on access and trunk ports. You can review the details here .

This brief introduction will end with the output of the command: show spanning-tree mst

Core-Switch-01#sh spanning-tree mst

##### MST0 vlans mapped: none
Bridge address 1833.9da2.5700 priority 4096 (4096 sysid 0)
Root this switch for the CIST
Operational hello time 2 , forward delay 4 , max age 6 , txholdcount 6
Configured hello time 2 , forward delay 4 , max age 6 , max hops 20

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa1/0/1 Desg FWD 200000 128.3 P2p
Fa1/0/2 Desg FWD 200000 128.4 P2p
Fa1/0/3 Desg FWD 200000 128.5 P2p
Fa1/0/4 Desg FWD 200000 128.6 P2p
Fa1/0/5 Desg FWD 200000 128.7 P2p
Fa1/0/6 Desg FWD 200000 128.8 P2p
Fa1/0/9 Desg FWD 200000 128.11 P2p
Fa1/0/12 Desg FWD 200000 128.14 P2p
Fa1/0/22 Desg FWD 200000 128.24 P2p
Fa1/0/23 Desg FWD 200000 128.25 P2p
Fa1/0/24 Desg FWD 200000 128.26 P2p

##### MST1 vlans mapped: 1-4094
Bridge address 1833.9da2.5700 priority 4097 (4096 sysid 1)
Root this switch for MST1

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa1/0/1 Desg FWD 200000 128.3 P2p
Fa1/0/2 Desg FWD 200000 128.4 P2p
Fa1/0/3 Desg FWD 200000 128.5 P2p
Fa1/0/4 Desg FWD 200000 128.6 P2p
Fa1/0/5 Desg FWD 200000 128.7 P2p
Fa1/0/6 Desg FWD 200000 128.8 P2p
Fa1/0/9 Desg FWD 200000 128.11 P2p
Fa1/0/12 Desg FWD 200000 128.14 P2p
Fa1/0/22 Desg FWD 200000 128.24 P2p
Fa1/0/23 Desg FWD 200000 128.25 P2p
Fa1/0/24 Desg FWD 200000 128.26 P2p

Notice that MST0 has no VLANs mapped but is still active on all the same ports listed in MST1. Also notice it says: Root this switch for CIST