Blogs

Connecting to Cloud Providers High-Level Network Architecture

More than 70 percent of Internet Traffic passes through Data Center Alley in Loudoun County. Ashburn, Virginia has the largest data center footprint in the world. It makes sense to lease or collocate your data center here. Almost all cloud providers (Azure, Amazon AWS, Google, Office 365, etc.) have presence in these data centers. Being collocated locally can take advantage of direct connect services to any of these Cloud providers. Ashburn Consulting can help you design a Hybrid Cloud On Prem Architecture for your future Infrastructure.

AzureCloudConnect

Acano and Cisco

Cisco’s purchase of Acano will be a game changer. Let’s wait for how Cisco is going to integrate Acano into their UC solutions. If it integrates into TMS……great! If it adds WebEx desktop control capabilities……great! If it replaces VCS C & E………great! Time will tell.

AcanoSelfie

 

VTC Video Conferencing Rules for Palo Alto Firewall

If you have a Cisco Telepresence VCS Expressway or a legacy Tandberg Border Controller or even an MCU behind a Palo Alto Firewall there are several Application based objects needed to be in your Outbound and Inbound Security policy.

  • rtp-base
  • rtcp
  • h.225
  • h.245
  • h.323
  • sip
  • rtp

Normally the logs will show which ports are being denied by the clean up rule. Depending on the type of Firewall, you might need to create an object with a certain udp range. There are also cases where a VTC endpoint is configured to use static ports that’s out of range from the standard protocols and applications built in. Making VTC sessions work behind a newly deployed Firewall can be challenging at first. Simple trial and error and gathering firewall connection logs is key. I’d be careful allowing a big range of ports though to Inbound Firewall rules.

Cisco TMS Telepresence Management Suite Upgrade & Install from 13.0 to 14.6

If you have an old version of TMS (13.0) running on an unsupported Windows Server 2003, here is a very extensive procedure to upgrade it to TMS version 13.2, do Database recovery, restore and conversion, and migration to a new Windows 2012 R2 system running on SQL Server Express 2012. The final step was to upgrade to the TMS version 14.6.

First big issue I ran into was the 2008 SQL Express server “SA” password provided by the previous SQL Administrator was incorrect. The numerous attempts to access the database server locked up the account and the SQL service couldn’t be started from SQL Server Configuration manager. Even if you go to Control Panel and Services, manually start the SQL service, it doesn’t start.

tms1

error code 17058 appears from the Event Logs and also look into SQL logs to get more information on the cause of the SQL service not able to start. It revealed that it went through the proper startup procedures and during the last step, there was a message that the supplied account login to the database failed.

tms2

First, you have to fix the SQL service startup issue to even be able to do anything.

You need to login as a user with admin rights on the Server. Open SQL Server Configuration Manager ==> click on SQL Server Services ==> then right click on SQL Server ==> choose Properties. A Window show below will appear:

tms3

Under the Logon tab, the SQL service was previously configured for “Network Service” which failed to start the SQL service. Under “Built-in Account”, choose “Local System”. You will need to know the local system account username and password. Provide the local user name and password. Now start the service manually and it should work fine.

SQL SA Password Reset and Recovery

Now that SQL service has started, next step is to reset the DB server SA account password. Do the following from the MS-DOS prompt (provide a Strong SA Password):

tms4

 

tms6

tms6

tms7

Make TMS Connect to the TMSNG Database

After changing the SA password, you can either use TMS Tools to reconnect TMS to the DB again or since I needed to upgrade to TMS 13.2, I went ahead and ran the install of TMS 13.2. This is the last version of TMS that supports Windows server 2003. The install will ask for your DB connection settings and this is where you enter the new SQL SA password. After the installation is complete, verify TMS functionality by pulling it up from a Web Browser.

Install TMS Provisioning Extension (TMSPE)

If you are using TMS agent legacy, we need to install TMS Provisioning Extension (TMSPE) in TMS 13.2. TMSPE is required when moving up to the 14.x versions of TMS. Without TMSPE, TMS 14.x install will fail during the install procedure. This will also require a Java Runtime Environment upgrade to at least Java 6 build 33. For more info, please go to Cisco’s Website and see the TMSPE Installation guide.

  • Download Java from Oracle site and Install.
  • Run the TMSPE Installation.
  • After Installation is complete, check the option to run the “Migration Tool” to build the database for Provisioning Extension.

Performing the installation and migration

  1. Close all open applications and disable virus scanning software.
  2. Extract the Cisco TMSPE installer from the zip archive to the Cisco TMS server.
  3. Run the Cisco TMSPE installer.
  4. Follow the setup instructions:

a.Click Next to initiate the setup.

  1. Accept the terms in the license agreement and click Next.
  2. Enter the Username and Password of the user that Cisco TMSPE will use to connect to Cisco TMS. This user must be a member of the Site Administrators group in Cisco TMS. Click Next.
  3. The installer detects where the TMS SQL database (tmsng) is installed. We recommend installing the Cisco TMSPE SQL database (tmspe) to the same location and instance.
  4. Confirm or enter the appropriate SQL Server Name and Instance Name. If deploying in a redundant setup, make sure both installations are pointing to the same database location. ii.
  5. Fill in the necessary credentials.
  6. Click Next.
  7. Click Install to begin the installation. Click Back to review or change installation settings.
  8. When the installation is complete, check Run Migration Tool and click Finish to exit the Setup window. The Migration Tool window opens.

Click Start Migration. Depending on the size of the database, the migration process may take several minutes to complete. When the migration process is complete, the Migration Tool window displays the

results of the migration and provides a migration log.

 

Enabling Cisco TMSPE

After completing the installation:

  1. In Cisco TMS, go to Administrative Tools > Configurations > General Settings, set the field Provisioning Mode to Provisioning Extension and click Save. You may need to refresh the browser window or empty the browser cache after making this selection.

 

  1. Go to Administrative Tools > Activity Status to verify that the switch is completed.

 

  1. Verify that Cisco TMSPE features are now available and functioning.
  2. Browse to the following pages in Cisco TMS: Systems > Provisioning > Users. If this page reports a problem connecting to User Repository, the database connection is not working.

Systems > Provisioning > FindMe

Systems > Provisioning > Devices

Administrative Tools > Configuration > Provisioning Extension Settings

 

Go to Administrative Tools > Provisioning Extension Diagnostics, look for any alarms raised and click Run Health Check. If any alarms are raised, click them to see details and perform the corrective actions described. See Troubleshooting the installation [p.71] for further information.

 

  1. When browsing to all of the above Cisco TMSPE pages is successful and no alarms are reported in Provisioning Extension Diagnostics

 

Perform TMS Database backup 

You will now notice that the TMS Database size has doubled. This is because of the Provisioning Extension install. It’s now time to backup this database. The easiest way is by command line:

tms8

You will now find the DB backup file in this directory: C:\Program Files\Microsoft SQL Server\MSSQL10.SQLTMS\MSSQL\Backup

 

New 2012 R1 Server Buildout

Size the server hardware by checking Cisco’s deployment guide first. Here are the software requirements to install before installing TMS 14.6:

  • .NET framework 3.5 Full (extended)
  • .NET framework 4.5.0 Full (extended)
  • Microsoft IIS for Windows Server 2012 R2: IIS 8.5
  • Apply windows updates
  • Microsoft SQL Server 2012 Express Edition (free) if installing a small deployment size of less than 200 endpoints/vtc systems. The install includes SQL Management Studio.

Once SQL server express is installed, do a database restore from the TMS backup file using SQL Management Studio. The db import will do the conversion to SQL 2012 structure.

tms9

tms10

tms11

tms12

Once Database is created, you can now run the TMS 14.6 installation.

 

Creating or upgrading the database

  • If the installer does not find an existing Cisco TMS database, but locates a local installation of SQL Server, enter the username and password to allow the installer to create a new database. Click Next.
  • If using an external SQL Server, which is required for large deployments, enter all connection details. Click Next.

 

  • If the installer finds an existing Cisco TMS database, the dialog will be pre-populated with the previously specified SQL Server. When prompted, enter the username and password and click Next.
  • Click Yes to upgrade the existing database to the current version and retain the existing information.
  • We recommend that you back up the database before it is upgraded using the appropriate tools.
  • If clicking No, you must proceed to stop the installer and manually remove the database if you wish to use the same SQL Server, before you can install a new Cisco TMS database.

tms13

Adding release keys and pre-configuring the network settings

The Release and Option Keys dialog is now displayed, and any existing keys are shown if upgrading.

tms14

  • A new release key is required if performing a new installation or upgrading to a new major release. If no release key is entered, an evaluation version of Cisco TMS will be installed. This includes support for three systems.
  • Option keys enable additional systems, extensions, or features. They may also be added post installation by going to Administrative Tools > Configuration > General Settings.
  • For questions regarding release or option keys, contact your Cisco Reseller or Cisco Support.
  • Enter the release key if necessary.
  • The release key must be entered before adding option keys.
  • Enter each option key, then click Add Option.
  • Option keys are validated as they are added.
  • When done adding keys, click Next.
  • The Network Settings screen is displayed.

You can now pre-configure default settings to allow Cisco TMS to immediately start working with a basic network configuration. The settings can be changed after installation.

If upgrading, values from the existing database are displayed.

These should be the major install steps and just follow through the wizard until the install is complete.

Make sure you enable SNMP service. It is disabled by default for new installations of TMS.

Access Cisco TMS for the first time.

Test all General Functionalities.

 

Next Generation Firewall Overview with Glimpse of Application Identification

“I am not an advocate for frequent changes in laws and constitutions, but laws and institutions must go hand in hand with the progress of the human mind. As that becomes more developed, more enlightened, as new discoveries are made, new truths discovered and manners and opinions change, with the change of circumstances, institutions must advance also to keep pace with the times. We might as well require a man to wear still the coat which fitted him when a boy as a civilized society to remain ever under the regimen of their barbarous ancestors.”

-Excerpted from a letter from Thomas Jefferson , July 12, 1816

Interestingly, Thomas Jefferson’s quote could not be more appropriate when assessing todays state in IT Network Security. When people hear IT Network Security one of the first devices that come to mind is a firewall. Early firewalls started out as not much more than an extended access list. As security requirements grew Stateful packet inspect was introduced by Check Point Software to address several security issues with most notably being certain types of man in the middle attacks (MITM). As stateful inspection began to take off many network engineers found difficulties in implementation among some issues asymmetric routing became an issue that required engineers to control network paths with a fine tooth comb to confirm forward and reverse traffic were taking the same route back and forth or it would be dropped due to stateful inspection. Part of the reason for this introduction was to reduce the capability for a man in the middle attack to be intercepting traffic and sending it back without the end user being aware their network traffic had been compromised.

Fast forward back to the present and Next Generation Firewalls (NGFW) and layer 7 inspection are introducing a new evolution in IT security whose functionality is critical to todays’ IT security landscape. With many vendors introducing their own take on layer 7 inspection the importance of this new upgrade in capabilities is more apparent than ever akin to when stateful packet inspect was originally introduced. Most firewalls previously are port based in the sense that port 80 and 443 may be open outbound to allow web and ssl traffic.

With that knowledge a malicious user could exploit this port based firewall by running any application over these ports even though they were originally designed with the intent for web browsing and ssl traffic. A malicious user could run any application they desired over open ports without any restriction including unwanted chat and bit torrent clients up to and including applications like nmap without the restriction of being blocked by a firewall without another security applicance on the network capable of application inspection.

NGFW’s enable network security engineers to not only restrict ports but also applications and ports, they do this by inspecting IP packets for what data is inside the packet header beyond the traditional source/destination and port. This visibility into traffic is critical to enabling an engineer the capability to not only restrict port but also only allow web-browsing over port 80 or only ssl traffic over 443, and disabling any traffic that does not have web-browsing requests or ssl in the IP headers and blocking a malicious users ability to run other applications like torrents or nmap over that port or even save bandwidth by stopping applications like youtube google-hangouts, facetime, minecraft and other applications that may be unwanted on the network.  In figure 1, in addition to source/destination you see a user viewing youtube over port 443 which is traditionally open, the functionality of this firewall will enable a Network Security Engineer to only allow ssl and web-browsing while blocking youtube. It is important to note that encrypted ssl traffic can be decrypted however that will be touch on in a separate article.

app-id-youtube

This new capacity requires specific configurations to implement correctly. During migrations many engineers lacking knowledge of why some traffic may stop working due to new application layer rules may cause openings in security to increase usability by removing some of the application layer configurations. This trade off is not using this new technology and functionality correctly and is effectively putting a child’s coat on an adult, it does not fit according to how the IT security landscape has evolved. Implementing this technology is critical to providing secure and trusted network traffic transactions and assist in disabling a malicious users ability to abuse legacy firewall functionality.

ICMP Security

This is a draft guide to handling ICMP securely.

Guide Analysis to Handling ICMP protocol

Summary:

This guide is an attempt to help answer common questions related to the handling of ICMP protocol in a secure and effective manner. Comments and feedback is always welcomed. This article is meant to cover the major area in which there may be questions on how to handle ICMP and what specifically should we allow in each particular condition which will also allow for effective risk mitigation. If you need specifics on ICMP codes with in each ICMP type please refer to the reference URLs below.

Major ICMP Protocol Types:

– 0: Echo Reply

– 3: Destination Unreachable

– 4: Source Quench

– 5: Redirect (change a route)

– 8: Echo Request

– 9: Router Advertisement

– 10: Router Solicitation

– 11: Time Exceeded for a Datagram

– 12: Parameter Problem on a Datagram

– 13: Timestamp Request

– 14: Timestamp Reply

– 17: Address Mask Request

– 18: Address Mask Reply

Areas of Affect:

Perimeter

Outbound: Echo Reply (0), Echo Request (8) (For Troubleshooting)

Deny Type: All except (TTL Exceed (11) & (Type 3, Code 4) From Limited External Testing Devices.

Interior (Corporate Network)

Internal Deny:  Should be handled on a case by case basis, however when permissible squelch Redirect (5), Router Advertisement (9), Router Solicitation (10), Timestamp Request (13), Timestamp Reply (14). Address Mask Request (17), and Address Mask Reply (18). The usefulness of the ICMP message types are deprecated by DHCP and NTP.

Internal Allow: Echo Reply (0), Destination Unreachable (3 Code 4), Echo Request (8), Time Exceeded (11)

Remote Access & Site to Site VPN

VPN Allow: Echo Reply (0), Destination Unreachable (3, Code 4), and Echo Request (8).

VPN Deny: Everything Else

Intranet to Intranet / Partner to Partner

Intranet to Intranet Allow:  Echo Reply (0), Destination Unreachable (3 Code 4), Echo Request (8), Time Exceeded (11)

Intranet to Intranet Deny: Everything Else

References:

PMTU

http://www.tcpipguide.com/free/t_IPDatagramSizetheMaximumTransmissionUnitMTUandFrag-4.htm

ICMP

http://www.tcpipguide.com/free/t_ICMPv4TimestampRequestandTimestampReplyMessages-3.htm

University of Syracuse ICMP Lecture Notes

Layer 2 Tracing for (6500, 7609, 4500) Cisco Switches

In a 6509, 7609 or any Chassis based Cisco switch, to determine where the switch forwards a Source and Destination pair to an actual port in a Port-channel/Etherchannel do the following commands:

Note: Doesn’t apply to Nexus switches.

First enter console for switch:

port-channel hash
Switch# remote login switch
Trying Switch ...
Entering CONSOLE for Switch

Then enter the following command:

port-channel hash
Switch-SP# test etherchannel load-balance interface port-channel 1 ip 10.1.1.1 10.1.1.2
Computed RBH: 0x6
Would select Gi2/1 of Po1

Based on the hash computation, the switch forwards traffic of the Src Dst pair to port Gi2/1.

This is a good tool to use if for some reason a particular port is dropping packets between the src and dst pairs.

Great SMTP DNS and Troubleshooting tool

mxtoolbox

Go to http://www.mxtoolbox.com

This test will list MX records for a domain in priority order. The MX lookup is done directly against the domain’s authoritative name server, so changes to MX Records should show up instantly. You can click Diagnostics , which will connect to the mail server, verify reverse DNS records, perform a simple Open Relay check and measure response time performance. You may also check each MX record (IP Address) against 147 DNS based blacklists . (Commonly called RBLs, DNSBLs)

ABOUT BLACKLIST CHECK

This test will check a mail server IP address against 147 DNS based email blacklists. (Commonly called Realtime blacklist, DNSBL or RBL).  If your mail server has been blacklisted, some email you send may not be delivered.  Email blacklists are a common way of reducing spam. If you don’t know your mail server’s address, start with a MX Lookup.   Or, just send an email to ping@mxtoolbox.com

ABOUT SMTP DIAGNOSTICS

This test will connect to a mail server via SMTP, perform a simple Open Relay Test and verify the server has a reverse DNS (PTR) record.  It will also measure the response times for the mail server.  If you don’t know your mail server’s address, start with a MX Lookup.

ABOUT EMAIL HEADERS and Analyzer

This tool will make email headers human readable by parsing them according to RFC 822.  Email headers are present on every email you receive via the Internet and can provide valuable diagnostic information like hop delays, anti-spam results and more. If you need help getting copies of your email headers, just read this tutorial.

ABOUT SPF RECORDS

Sender Policy Framework (SPF) records allow domain owners to publish a list of IP addresses or subnets that are authorized to send email on their behalf.  The goal is to reduce the amount of spam and fraud by making it much harder for malicious senders to disguise their identity.

ABOUT DNS LOOKUP

This test will list DNS records for a domain in priority order. The DNS lookup is done directly against the domain’s authoritative name server, so changes to DNS Records should show up instantly. By default, the DNS lookup tool will return an IP address if you give it a name (e.g. www.example.com) If you give it an IP address it will return a hostname based on the reverse DNS lookup.

Cisco ISR Platform feature by Ashburn Consulting

A video presentation about the Cisco ISR platform from Cisco’s Solutions Architect, Randy Benn. IPICS, Video Distribution and Management, POE switch modules, IP Camera termination are all integrated in one ISR platform. Interview conducted by Amante Bustamante.

 

MPLS L3 VPN White Paper

Enterprise Network Design White Paper
For Metropolitan and Campus Networks –
MPLS L3VPNs 
Robert Shields
Sr. Network Engineer, CCIE # 12096 
January 2012 
Enterprise Network Challenges of Today and Beyond 
Enterprise network and security managers continue to see their responsibilities increase within their respective IT organizations as applications and services continue to migrate to IP as a fundamental means of communication. These applications and services include telephony, video, wireless and mobility clients, storage area networks, etc., with the list going on and on. The reality today is that most enterprise networks are now converged IP services networks with many different and diverse customer requirements. With the network requirements changing to resemble more of a service provider model, so too should the network architecture model. 
Enterprise networks traditionally supported server-based data applications, many of which were deemed critical applications, which could be secured with a tiered firewall architecture in the data center. Today, all types of new devices and appliances are being plug into the Enterprise IP network at numerous locations and they all have their own security requirements. Compound this by the new technical challenges of the day, including server virtualization, cloud computing, business continuity, and IPv6, and there is no lack of pressure on the network and security IT groups in providing a secure, scalable, and robust network environment that can continue to meet the challenges of today and the future. 

MPLS L3VPNs – Providing a Flexible Network Architecture Solution 
This white paper focuses on how MPLS L3VPN technology can provide many benefits to Enterprise networks by enabling a flexible network architecture that can accommodate a diverse set of customer requirements across a Metropolitan Area or Campus network. These benefits stem from the ability to logically segment or virtualize the network into multiple isolated routing domains called VPNs. The following is a list of the benefits that MPLS L3VPN can provide.

  • Reduced Cost – L3VPNs allow multiple networks to be converged into a single network while still maintaining their privacy from one another. These results in less infrastructure devices, less power consumption, less vendor support contracts, and fewer personnel required to maintain multiple networks.
  • Network Virtualization – Major router manufacturers support literally thousands of virtual networks to be configured across the shared Enterprise network, thus supporting traffic isolation for specific applications, services, user groups, agencies or divisions, or any other type of isolated IP transport requirement.
  • Routable DMZs/Centralized Firewalls – By connecting the L3VPN network to a centralized firewall architecture at a physically secure data center, this essentially enables a VPN to become a boundless internal DMZs that can be extended anywhere across the Enterprise network. These DMZs will still have the ability to communicate back to a main corporate network through an approved security policy, thereby allowing access to common network services such as DNS, DHCP, SNMP, etc., while still severely restricting the vulnerability that this DMZ can pose to the internal network. Other data access or communication requirements between different DMZs/VPNs could also be granted and added to the security policy on a case by case basis. The L3VPN architecture also eliminates the need to deploy firewalls at remote sites where physical security of these devices cannot be as easily assured, since alternatively a new VPN could be created and mapped back to the centralized firewall systems.
  • VLAN to VPN/VRF Mappings – The ability to map VLANs into VPNs will be explained further throughout this document, but for now the beneficial point to make is that not all network devices need to be MPLS or VPN/VRF aware. Only the core or backbone routers will need to be evaluated to run this technology and not all the edge sites. Some edge routers may need to support VRF-Lite, which is a scaled-down version on the technology that does not require MPLS. This keeps the initial investment down and also allows a seamless and phased migration approach when transitioning to the new network architecture.
  • Additional Services Supported by an MPLS Backbone – In addition to L3VPNs, there are other services that the backbone network will be able to support as a result of having MPLS enabled. L2VPN technologies such as pseudo-wire and VPLS can also be deployed rather easily once an MPLS core is achieved.


These benefits will be illustrated and substantiated further in the MPLS L3VPN architecture example that is described later in this document. A brief and high-level overview of the MPLS L3VPN technology is described next to ensure conceptual understanding of how traffic is isolated across the shared backbone infrastructure. 


Overview of MPLS L3VPN Technology 
There are a several main concepts that network and security managers should understand with L3VPNs.

  1. Routers maintain separate routing tables for each VPN that they are connected to, called Virtual Routing and Forwarding tables (VRFs), thus VPN and VRF are used synonymously with one another when describing these isolated routing domains.
  1. Any IP packets that enter the MPLS L3VPN backbone network must enter on either a physical or logical interface that is defined to be within a specific VRF. Once a packet enters on an ingress VRF interface, it can only exit out an egress interface that is in the same VRF. This ensures that traffic is isolated between different VRFs. Examples of logical interfaces are sub-interfaces or VLANs on an 802.1Q tagged port.
  1. The ingress router for an IP packet entering the MPLS L3VPN backbone is called the Provider Edge (PE) router. As part of the intricacies of the technology, MPLS label switch paths (LSPs) are built in a full-mesh topology between all the PE routers in the backbone network. Therefore, when an IP packet enters through a VRF defined interface on the backbone network, one IP routing table lookup occurs at that PE router (within that specific VRF table), and the result is the packet gets forwarded to the appropriate LSP and is then label-switched through the MPLS network until it exits the associated egress port for its destination. These efficient techniques of a single IP lookup and label-switching packets through the network result in the technology being very secure and scalable.
  1. Routers that connect to an L3VPN network are referred to as Customer Edge (CE) routers. Although these routers are referred to as “customer” routers, they can certainly be managed by the same Enterprise network group that manages the MPLS or PE routers. CEs that need to connect to two different VPN subnets on the MPLS core will need to run VRF-Lite. VRF-Lite enables a router to function as a stand-alone virtualized router – following the same principals of L3VPNs; multiple VRFs can be configured with physical and/or logical interfaces defined within the VRFs (no MPLS). A CE can also be a L2 switch with just a trunk port to the PE.


All of these concepts are illustrated in the Figure 1. CE1 has two LANs that need to communicate using the L3VPN core using two different VPNs. VPN A is colored in blue, and VPN B is in red. Therefore, CE1 must connect to the MPLS network using either sub-interfaces or a trunked (IEEE 802.1Q – tagged) link so that the PE can define these logical connection into the appropriate VPN/VRF. Notice that PE1 is configured and has knowledge of both VRF tables, while PE2 & PE3 are only configured with the single VRF for which they have a CE connected to. When CE1 sends packets destined to both CE2 and CE3, it is PE1 that does an IP lookup for these packets using the appropriate VRF table, and then forwards the packets onto the correct LSP that will carry it straight out the egress port towards its destination.

mpls1

Figure 1. – MPLS L3VPN Concepts 
Other technologies that can also be deployed along with L3VPNs include the following:

  • Quality of Service (QoS) – For traffic classification, RFC 4594 “Configuration Guidelines for DiffServ Service Classes” is used as the basis for the recommendations for traffic classification in MPLS L3VPN environment. The 4, 8 and 12-class models can be used for traffic classification.
  • Traffic Engineering (TE) and LSP Protection – TE with LSP protection schemes can be configured to support under 50 ms failover times should a link in the network core fail. TE can also be used to move traffic from over-utilized use links to underutilized links, thus taking advantage of all resources available.
  • Encryption – MPLS does not imply encryption, however several different encryption methods exist if this is required over a L3VPN, including GRE over IPSec, Cisco’s Dynamic Multipoint VPN (DMVPN), and Cisco’s Group Encrypted Transport VPN (GET VPN).
  • Multicast in a VRF – Multicast traffic can be transported across the MPLS backbone on a per VRF basis. Next-generation multicast has recently been deployed by vendors which also contains support for point-to-multipoint LSPs which employ true label switching transport similar to the unicast implementation (previous implementations actually used GRE and the global routing table).
  • IPv6 Transport – While the enterprises slowly move their infrastructure to support IPv6, they can use their existing IPv4 MPLS infrastructure to support IPv6. MPLS L3VPN use IPv6 VPN provider edge (6VPE) approach to transport IPv6 over MPLS network. 6VPE as specified in RFC 4659, “BGP-MPLS IP VPN Extension for IPv6,” it enables the IPv6 sites to communicate with each other using MPLS LSP over MPLS IPv4 core network.


The 6VPE implementation provides scalability with no IPv6 addressing restriction. This mode enables the enterprises to deploy the IPv6 MPLS VPN service over their existing IPv4 backbone by just upgrading the PE router to the dual-stack-capable software. 
This overview was only intended to cover the major concepts of MPLS L3VPNs, for more detailed technical and protocol information, please refer to RFC 4364 “BGP/MPLS IP Virtual Private Networks”.
Legacy Enterprise Network Architectures 
Many Enterprise network today look very similar to the topology depicted in Figure 2 below. Two or more physically distinct networks were built to meet different network and security criteria such as providing services on a Corporate network (a private internal network – only for internal staff use) as well as potentially a Public network (a network open for guests access – primarily for Internet). Also on the corporate side, there are likely some access control lists (ACLs) or Policy Based Routing (PBR) that has been implemented to facilitate requests from certain groups or applications owners that required addition security or access restrictions. These workarounds can lead to increased downtime due to configuration error and extended troubleshooting timeframes. Common network services such as DNS, DHCP, and SNMP will need to be deployed and managed for each separate physical network as well. These techniques are cumbersome to manage and are simply not sophisticated technologies that were intended to support an Enterprise network architecture design. 
Finally, there could also be several firewalls deployed at remote parts of the network to accommodate partner type connections or to securely protect a remote application user group or small server farm. MPLS L3VPN technology can allow the Enterprise network to alleviate all of these unpleasant practices as will be demonstrated in the following section. 
mpls2
Figure 2. – Legacy Network Architecture 
MPLS L3VPN Enabled Enterprise Network Architectures 
Figure 3 below shows a high-level drawing of a typical Metropolitan Area Network (MAN) or Campus network design using L3VPN technology. Depending on the overall topology of the network, the MPLS L3VPN enabled backbone can include core, distribution, and even some edge site routers. This depends on which sites need the flexible capabilities of MPLS. As Figure 3 illustrates, a typical Enterprise network will have a contiguous MPLS enabled backbone encompassing core routers at the data center and distribution routers, connecting the remote sites. This enables network virtualization within the heart of the network, resulting in the ability to provide flexible solutions for any number of unique network or security related requirements that are needed in the network today or in the future. 

mpls3
Figure 3. – Example MPLS L3VPN Architecture for MAN or Campus Network 

In this example, we can see several segmented VPNs that are serving different purposes within the Enterprise design. First, there is a “Corporate VRF” (blue) that is isolating the internal staff and data centers from other entities on the network. The corporate network existed prior to the L3VPN implementation, so there are likely several sites with multiple routers that were already running an internal routing protocol such as OSPF. Therefore the “Corporate VRF” can be setup to redistribute routes with OSPF at these locations. Notice that the remote sites each have routers running VRF-Lite with 802.1Q trunked uplinks connecting to the distribution or PE routers, thereby allowing a logical path for the remote Corporate LAN segments to be mapped into the “Corporate VRF” at the distribution routers. The corporate network is also connected to centralized firewalls (dubbed, the “VRF Meet-me Point”), that allows the other VRFs to access common network services (DNS, DHCP, SNMP, etc.) that reside there. 
The second VRF to discuss is the “Public VRF” (red). This VRF shows from our previous legacy network example that a separate physical network is not needed when an additional isolated network is required. Here, a “Public VRF” is created for users who need be allowed guess-type access to the Internet. One topic that is yet to be discussed is that within a VRF itself, several different topologies are supported including full-mesh, partial-mesh, and hub-and-spoke. In this case, the “Public VRF” can be configured as a hub-and-spoke so that the only destination a user on the “Public VRF” can reach is the Internet. The two public sites within this example, Sites 1 and 2, are not able to communicate with one another as designed. A practical example for this might be a State or Local Government network providing Internet access to its constituents at library sites. A hub-and-spoke design will allow just the Internet access, without enabling library to library public access communication. 
The last VRFs to examine in the example are the “Secure-App VRF” (purple) and the “DMZ/Partner VRF” (green). The “Secure-App VRF” is representative of any type of application that has increased security requirements and therefore should be contained in an isolated network. As can be seen from Figure 3, Site 1 & 3 both have a Secure-App VLAN that will be able to communication with one another directly. Any other network services or access required from the Corporate network will need to added to the security policy enabled on the VRF Meet-Me Point firewall(s). The “DMZ/Partner VRF” is representative of a remote site where either an external partner connection or remote internal servers are located requiring additional protection. Enterprise network seem infamous for having “one-off” requests such as these. Either or these requests in a legacy Enterprise network might lead to an additional firewall being purchased and placed at the remote site, where physical security of the firewall is not ensured. With VRF technology available, these servers or partner connections can be connected to the “DMZ/Partner VRF” and transported back to the centralized VRF Meet-Me Point firewalls and again only allowed access to what is necessary on either sides of the connections. 
Just a few more technical notes to reiterate the flexibility of this new Enterprise model:

  • VRFs support overlapping IP address space between VRF – This means that two different VRFs can use the same IPv4 address space such as the 10.0.0.0/8 prefix. Thus, the Enterprise network will have the capability to transport IP traffic for other agencies or sub-division that have their own IT departments and equipment, or for a strategic partner where backhaul their traffic makes sense, or potentially even offering revenue generating service, etc.
  • Dynamic Routing Protocols between PE and CE – At the edge of the network, many different routing protocols are supported between the PE and CE routers. Depending on the router manufacturer, OSPF, EIGRP, or eBGP can be used if dynamic routing is required. For stub-site, static route injection into a VRF is available as well.
  • Enriched Enterprise Network Features – Since MPLS L3VPN technology has been used in production network for over a decade now, adopted early by Service Providers and recently into more and more Enterprise networks, many additional features have been added to support unique Enterprise network requirements. These features include support for Super-backbones and backdoor links. A Super-backbone is really a simulated OSPF backbone across a VRF; similar features are supported for EIGRP as well with Cisco. Backdoor links are remote site that may have a redundant WAN link that does not connect to the MPLS network and instead goes direct to another site via an IGP such as OSPF. Links such as these can be configured a primary, secondary, or load-sharing link for the site. These are just a few of several features specific to Enterprise network integration.



Conclusion 
MPLS L3VPNs is a very mature and scalable technology as it has had its roots in the service provider realm since the turn of the millennium. Enterprise network today share an expanding customer base similar to service providers as IP transport becomes more and more prevalent as the fundamental communication protocol within all IT fields. Ashburn Consulting believes strongly in MPLS L3VPN technology in the enterprise network space as it allows for a flexible, secure, robust and scalable network architecture that is well positioned for the foreseeable future due to its unique ability to virtualize the network. Ashburn Consulting has successfully designed and deployed this technology for both large and small customers and would be pleased to discuss our experience and possible solutions for your Enterprise network as well.