ViewsLetter(SM) on Provisioning

Site Map



 Flanagan Consulting                 Network Analysts and Consultants
                                         "We Have the Experience"
ViewsLetter on Provisioning       7 July 2003        #24
A fortnightly look at provisioning automation--chips to business software.

-- Back On-Line with a New List Server
-- Virtual Circuits and IP Routing

/============ + ======= + ======= + ======= + ============
|      We're back after a hiatus to set up a new list server. 
|  As a preferred subscriber, you have been put on the new list and
|  will receive future issues by email.  You may unsubscribe or
|  renew a subscription at any time:

|  If you received this message from a friend, you can
|  pick up each issue from our archive or through
|, but it's easier to subscribe--and
|  you'll get your copy earlier, too. 
|      Registered users can subscribe with "2 clicks" at
| If these text URLs are not 'clickable,' cut and paste into a browser.
| NOTE:  subscriptions are confirmed by email (double opt-in).
\============ + ======= + ======= + ======= + ============


--By William A. Flanagan, Editor and Publisher

Welcome back.  Last issue (#23, available on the web site) described various forms of virtual circuits that can isolate users of a network from each other, ensuring the "privacy" of a VPN.  This issue we continue our description of Virtual Private Netowrks by looking at where in a network each VC type operates and how a VPN does IP routing.

BPNs based on Virtual LANs provide the least physical separation because they add relatively little to normal IP routing.  vLAN packets carry a standard IP header, with source and destination IP addresses, so a vLAN router forwards them in the normal way--but only on the vLAN.  Unfortunately, if the packet reaches a router that is not configured for that vLAN, the router may still forward the packet normally.  This is not usually what you want--you want to limit the movement of packets so they don't stray from the vLAN. 

Virtual Circuits (VCs) provide tighter control.  While on the MPLS, frame relay, or ATM portion of the path, an IP packet (encapsulated in a "frame" or "cells") moves forward based only on its VC address, not its IP address.  A frame doesn't go astray easily because the paths on the switches are configured only by the service provider (SP).  Once a connection is working, it remains essentially static.

Routing IP, on the other hand, often must be dynamic.  Flexibility for IP requires IP routers in the network of VCs.  Good examples are the mixed services known as IP-enabled frame relay, frame-aware IP, or similar names. 

When positioned as VPNs, these services dedicate routers to each customer.  VCs on a shared packet/cell network interconnect the routers.  Usually routers are "virtual" or software instances--hundreds can run on one large, shared hardware platform.  Thus each customer has a set of routers and circuits (all of them virtual) dedicated to his VPN and thus "private" within the carrier's network   Privacy may extend to the customer premises in the form of VCs or dedicated leased local loops (private lines for access).   

Isolation on a VPN has implications for routing protocls and IP addresses.  If there is no connection to the public Internet, a VPN can use any IP address range, for example the private network space 10.x.x.x, or any arbitrary range.  Connecting those users to the Internet would require a Network Address Translation (or Network and Port Address Translation), where the 10.x.x.x is changed to a valid public ("routable") address before the packet leaves the VPN, and back to the private range as the VPN delivers packets to the customer sites.

When a VPN service provider wants to offer secure access to people on the Internet, it often considers encryption.  However, when combined with private IP addresses and NAT, encryption can be awkward.  Some modes of IPsec and other tunneling protocols will encrypt the original IP address (10.x.x.x or 192.168.x.x for example) and keep it in the payload.  Going through NAT does not change this address.  When the packet reaches the far end, the public (NAT'ed) address is removed, the payload is decrypted, and the original address emerges--but it may not be recognized by the recipient or may conflict with local IP addresses there. 

Conflicts are avoidable.  If one end of a connection (usually the server) has a public IP address, the other end (a remote PC) can have a private IP address.  A direct encrypted session between two hosts with private IP addresses (both of which use NAT) is the most difficult situation.

The other consideration is a routing protocol. VPN customers who provide their own routers can choose to peer with the VPN service using any interior routing protocol supported by the SP on the virtual routers:  OSPF, IS-IS, iBGP, eIGP, etc.  However, many users prefer static routes from small sites that have a single access link, as a routing protocol offers little benefit when there is no alternate path.  They leave the "route finding" up to the SP within its core network.

VPN networks based on MPLS in the core are generally transparent from the user's demarcation point to the far side of the SP's network--the entire network appears as one hop to the customer's router.  This condition allows the customer to run any routing protocol among its own routers.

============ + ===== + ===== + ===== + ============
>>Next Time
-- The Key to Encryption VPNs Is Key Management

    To ensure timely receipt of future issues,
subscribe now.  See information at the top.
============ + ===== + ===== + ===== + ============

This Issue's Sponsor:
============ + ===== + ===== + ===== + ============


Can't bill? Why bother!
Primal understands carriers' needs to generate revenue
as well as provide a service. The family of Primal Service Node
products not only supports multiple applications, it
generates Call Detail Records for your existing billing system.
Flexible conferencing has dial in and out, prepaid, toll free access--
all under real-time control of each conference chairman.
All PSN models give each customer a unique conference bridge number,
And a choice of many other applications, including voice mail, Prepaid,
IVR, unified messaging, and voice over IP.
Get details at

============ + ===== + ===== + ===== + ============

-- Visit when you need independent review,
validation, or verification of network architecture, product positioning,
or your marketing message.
-- The archive of past ViewsLetters is available from the web site.
-- Special thanks for supporting ViewsLetter to, your best source for communications tutorials and white papers.

"Flanagan Consulting" and "ViewsLetter" are Service Marks of W. A. Flanagan, Inc.
 Updated:  7 July  2003

Flanagan ConsultingSM
W. A. Flanagan, Inc.
45472 Holiday Drive, Dulles, VA 20166
Ph:  +1.703.242.8381
Fx:  +1.703.242.8391