Cisco Systems OL-4344-01 North Bound Interface (NBI)

1-28

Cisco IP Solution Center, 3.0: MPLS VPN Management User Guide, 3.0

OL-4344-01

Chapter1 About Cisco IP Solution Center

Security Requirements for MPLS VPNs

The forwarding table for a PE contains only address entries for members of the same VPN. The PE

rejects requests for addresses not listed in its forwarding table. By implementing a logically separate

forwarding table for each VPN, each VPN itself becomes a private, connectionless network built on a

shared infrastructure.

IP limits the size of an address to 32 bits in the packet header. The VPN IP address adds 64 bits in front

of the header, creating an extended address in routing tables that classical IP cannot forward. MPLS

solves this problem by forwarding traffic based on labels, so one can use MPLS to bind VPN IP routes

to label-switched paths. PEs are concerned with reading labels, not packet headers. MPLS manages

forwarding through the provider’s MPLS core. Since labels only exist for valid destinations, this is how

MPLS delivers both security and scalability.

When a virtual circuit is provided using the overlay model, the egress interface for any particular data

packet is a function solely of the packet’s ingress interface; the IP destination address of the packet does

not determine its path in the backbone network. Thus, unauthorized communication into or out of a VPN

is prevented.

In MPLS VPNs, a packet received by the backbone is first associated with a particular VPN by

stipulating that all packets received on a certain interface (or subinterface) belong to a certain VPN. Then

its IP address is looked up in the forwarding table associated with that VPN. The routes in that

forwarding table are specific to the VPN of the received packet.

In this way, the ingress interface determines a set of possible egress interfaces, and the packet’s IP

destination address is used to choose from among that set. This prevents unauthorized communication

into and out of a VPN.

To maintain proper isolation of one VPN from another, it is important that the provider routers not accept

a labeled packet from any adjacent PE unless the following conditions are met:

•The label at the top of the label stack was actually distributed by the provider router to the PE device.

•The provider router can determine that use of that label will cause the packet to exit the backbone

before any labels lower in the stack and the IP header will be inspected.

These restrictions are necessary to prevent packets from entering a VPN where they do not belong.

The VRF tables in a PE are used only for packets arriving from a CE that is directly attached to the PE

device. They are not used for routing packets arriving from other routers that belong to the service

provider backbone. As a result, there may be multiple different routes to the same system, where the

route followed by a given packet is determined by the site from which the packet enters the backbone.

So one may have one route to a given IP network for packets from the extranet (where the route leads to

a firewall), and a different route to the same network for packets from the intranet.

North Bound Interface (NBI)

The user’s Web browsers communicate with IP Solution Center Web server through HTTP, and the client

applications communicate with ISC’s CORBA server (backward compatible API) or through the Web

server via XML/SOAP.

API support is provided for the following services:

•QoS Service