Home > HP > Printer > HP 5500 Ei 5500 Si Switch Series Configuration Guide

HP 5500 Ei 5500 Si Switch Series Configuration Guide

Add to Favourites
    Download as PDF Print this page Share this page

    Have a look at the manual HP 5500 Ei 5500 Si Switch Series Configuration Guide online for free. It’s possible to download the document as PDF or print. UserManuals.tech offer 1114 HP manuals and user’s guides for free. Share the user manual or guide on Facebook, Twitter or Google+.

    View all the pages
    Page
    of 2513
    Add page 1081 to Favourites
    image text
    Enable zoom 
    							 392 
VPN-IPv4 address 
Traditional BGP cannot process overlapping VPN routes. If, for example, both VPN 1 and VPN 2 use 
addresses on the segment 10.110.10.0/24 and each advertise a route to the segment, BGP selects only 
one of them, which results in the loss of the other route.  
PEs use MP-BGP to advertise VPN routes and use VPN-IPv4 address family to solve the problem with 
traditional BGP. 
A VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD, followed by a four-byte 
IPv4 address prefix. 
Figure 127  VPN-IPv4 address structure 
 
 
When a PE receives an ordinary IPv4 route from a CE, it must advertise the VPN route to the peer PE. The 
uniqueness of a VPN route is implemented by adding an RD to the route. 
A service provider can independently assign RDs if the assigned RDs are unique. A PE can advertise 
d i f f e r e n t  r o u t e s  t o  V P N s  e v e n  i f  t h e  V P N s  a r e  f r o m  different service providers and are using the same IPv4 
address space. 
Configure a distinct RD for each VPN instance on a PE, so that routes to the same CE use the same RD. 
The VPN-IPv4 address with an RD of 0 is a globally unique IPv4 address. 
By prefixing a distinct RD to a specific IPv4 address prefix, you get a globally unique VPN IPv4 address 
prefix. 
An RD can be related to an autonomous system (AS) number, in which case it is the combination of the 
AS number and a discretionary number; or it can be  related to an IP address, in which case it is the 
combination of the IP address and a discretionary number. 
An RD can be in one of the following formats distinguished by the Type field: 
•   When the value of the Type field is 0, the Administrator subfield occupies two bytes, the Assigned 
number subfield occupies four bytes, and the RD format is  16 - b i t  A S  n u m b e r:32- bi t user- d efi n e d  
number . For example, 100:1. 
•   When the value of the Type field is 1, the Administrator subfield occupies four bytes, the Assigned 
number subfield occupies two bytes, and the RD format is  32-bit IPv4 address:16-bit user-defined 
number .  F o r  e x a m p l e ,  17 2 .1.1.1:1.  
•   When the value of the Type field is 2, the Administrator subfield occupies four bytes, the Assigned 
number subfield occupies two bytes, and the RD format is  32- bi t  AS  nu m b er:16-bit user-defined 
number , where the minimum value of the AS number is 65536. For example, 65536:1. 
To guarantee global uniqueness for an RD, do not  set the Administrator subfield to any private AS 
number or private IP address. 
Route target attributes 
MPLS L3VPN uses the BGP extended community attributes called route target attributes to control the 
advertisement of VPN routing information. 
A VPN instance on a PE supports the foll owing types of route target attributes:
    Add page 1082 to Favourites
    image text
    Enable zoom 
    							 393 
•  Expor t targ et at tri bute : A  l o c al  PE sets  thi s t ype  of  route  targ et at tri bute for  VP N - I P v4  routes  le arne d 
from directly connected sites before advertising them to other PEs. 
•   Import target attribute: A PE checks the export ta rget attribute of VPN -IPv4 routes advertised by 
other PEs. If the export target attribute matches the import target attribute of the VPN instance, the 
PE adds the routes to the VPN routing table. 
In other words, route target attributes define which sites can receive VPN-IPv4 routes, and from which 
sites that a PE can receive routes.  
Similar to RDs, route target attributes can be of the following formats: 
•   16 - b i t  A S  n u m b e r :32-bit user-defined number . For example, 100:1. 
•   32-bit IPv4 address :16-bit user-defined number .  F o r  e x a m p l e ,  17 2 .1.1.1:1.  
•   32- bi t  AS  nu mb er :16-bit user-defined number , where the minimum value of the AS number is 65536. 
For example, 65536:1. 
Multi-VPN-instance CE 
Using tunnels, MPLS L3VPN implements private netw ork data transmission over the public network. 
However, the traditional MPLS L3VPN architecture requires each VPN instance exclusively use a CE to 
connect with a PE, as shown in  Figure 126. 
F

or better services and higher security, a private netw ork is usually divided into multiple VPNs to isolate 
services. To meet these requirements, you can configure a CE for each VPN, which increases users’ 
device expenses and maintenance costs. Or, you can  configure multiple VPNs to use the same CE and 
the same routing table, which sacrifices data security.  
Using the Multi-VPN-Instance CE (MCE) function of the switch, you can remove the contradiction of low 
cost and high security in multi-VPN networks. Wi th MCE configured, a CE can bind each VPN in a 
network with a VLAN interface on the CE, and create  and maintain a separate routing table (multi-VRF) 
for each VPN. This separates the forwarding paths of packets of different VPNs and, in conjunction with 
the PE, can correctly advertise the routes of each VPN to the peer PE, ensuring the normal transmission 
of VPN packets over the public network.  
How MCE works 
Figure 128  shows how an MCE maintains the routing entries of multiple VPNs and how an MCE 
exchanges VPN routes with PEs.
    Add page 1083 to Favourites
    image text
    Enable zoom 
    							 394 
Figure 128 Network diagram for the MCE function 
 
 
On the left-side network, there are two VPN sites, both of which are connected to the MPLS backbone 
through the MCE device. VPN 1 and VPN 2 on the left-side network must establish a tunnel with VPN 1 
and VPN 2 on the right-side network, respectively. 
With MCE enabled, routing tables can be created for VPN 1 and VPN 2 individually, VLAN-interface 2 
can be bound to VPN 1, and VLAN-interface 3 can be bound to VPN 2. When receiving a piece of 
routing information, MCE determines the source of the routing information according to the number of 
the interface receiving the information. It then maintains the corresponding routing table accordingly.  
You  must al so  bi nd the  i nter fac es  to  the  VP Ns  on PE 1  i n the  same  way as  those  on the  MC E device. The 
MCE device is connected to PE 1 through a trunk, which permits packets of VLAN 2 and VLAN 3 with 
VLAN tags carried. In this way, PE 1 can determine the VPN a received packet belongs to according to 
the VLAN tag of the packet and passes the packet to the corresponding tunnel. 
Configuring routing on an MCE 
Interface-to-VPN-instance binding enables MCEs and  PEs to determine the sources of received packets 
and then forward the packets according to the routing information concerning the corresponding VPNs. 
MCE routing configuration includes: 
•   MCE-VPN site routing configuration 
•   MCE-PE routing configuration 
Route exchange between an MCE and a VPN site 
An MCE can adopt the following routing protoc ols to exchange VPN routes with a site:  
•   Static route 
•   RIP 
•   OSPF 
•   IS-IS 
•   IBGP 
•   EBGP 
This section briefly introduces the cooperation of routing protocols and MCE.  
PE1
PEPE2
P
P
VPN 2
Site 2
VPN 1
Site 1
MCE
VLAN-int2VLAN-int3CE
Site 1
VPN 2
CE
VPN 1 Site 2
VLAN-int7
VLAN-int8
    Add page 1084 to Favourites
    image text
    Enable zoom 
    							 395 
Static routes 
An MCE can communicate with a site through static routes. As static routes configured for traditional CEs 
take effect globally, address overlapping between mu ltiple VPNs remains a problem until the emergence 
of MCE. MCE allows static-route-to-VPN-instance bind ing, which isolates the static routes of different 
VPNs.  
RIP 
The switch can bind RIP processes to VPN instances. With these bindings on the MCE, private network 
routes of different VPNs can be exchanged betwee n MCE and sites through different RIP processes, 
isolating and securing VPN routes.  
OSPF 
The switch can bind OSPF processes to VPN instances and isolate the routes of different VPNs.  
For an OSPF process bound to a VPN instance, the rout er ID of the public network configured in system 
view is invalid. You must specify the router ID when creating an OSPF process.  
An OSPF process can be bound to only one VPN instance. However, a VPN instance can use multiple 
OSPF processes for private network route transmission. To make sure routes can be advertised properly, 
configure the same domain ID for all OSPF  processes bound to the same VPN instance.  
Routes redistributed from OSPF to BGP on the MCE have their OSPF attributes removed. To enable BGP 
to distinguish routes redist ributed from different OSPF domains, yo u must enable the redistributed routes 
to carry the OSPF domain ID by configuring the  domain-id command in OSPF view. The domain ID is 
added to BGP VPN routes as an extended community attribute. 
In cases where a VPN has multiple MCE devices attached to it and when an MCE device advertises the 
routes learned from BGP within the VPN, the routes  may be learned by other MCE devices, generating 
route loops. To prevent route loops, configure route tags for different VPN instances on each MCE. HP 
recommends that you assign the same route tag to the same VPN on all MCEs. 
IS-IS 
Similar to those in OSPF, IS-IS processes can be boun d to VPN instances for private network routes to be 
exchanged between MCE and sites. An IS-IS process can be bound to only one VPN instance.  
IBGP 
To use IBGP to exchange private routes between an MCE and a site, configure IBGP peers for VPN 
instances on the MCE and redistribute IGP routing in formation from corresponding VPNs. If the MCE is 
connected with multiple sites in the same VPN, you can configure the MCE as a route reflector (RR) and 
configure the egress routers of the sites as clients, making the MCE reflect routing information between 
the sites. This eliminates the necessity for BGP connections between sites, reducing the number of BGP 
connections and simplifying network configuration. 
EBGP 
To use EBGP for exchanging routing information between an MCE and VPN sites, you must configure a 
BGP peer for each VPN instance on the MCE, and redi stribute the IGP routes of each VPN instance on 
the VPN sites. You also can configure filtering policies to filter the received routes and the routes to be 
advertised. 
Route exchange between an MCE and a PE 
Routing information entries are bound to specific VP N instances on an MCE device, and packets of each 
VPN instance are forwarded between MCE and PE a ccording to interface. As a result, VPN routing
    Add page 1085 to Favourites
    image text
    Enable zoom 
    							 396 
information can be transmitted by performing relatively simple configurations between MCE and PE, 
such as importing the VPN routing entries on MCE devices to the routing table of the routing protocol 
running between MCE and PEs.  
The following routing protocols can be used be tween MCE and PE devices for routing formation 
exchange:  
•   Static route 
•   RIP 
•   OSPF 
•   IS-IS 
•   IBGP 
•   EBGP 
Configuring an MCE 
Configuring VPN instances 
Configuring VPN instances is required in all MCE networking schemes. 
By configuring VPN instances on a PE, you isolate no t only VPN routes from public network routes, but 
also routes of a VPN from those of another VPN.  This feature allows VPN instances to be used in 
networking scenarios besides MCE. 
Creating a VPN Instance 
A VPN instance is associated with a site. It is a collection of the VPN membership and routing rules of its 
associated site. A VPN instance does not necessarily correspond to one VPN. 
A VPN instance takes effect only after you configure an RD for it. Before configuring an RD for a VPN 
instance, you can configure no other paramet ers for the instance but a description. 
You can configure a description for a VPN instance to record its related information, such as its 
relationship with a certain VPN. 
To create and configure a VPN instance: 
 
Step Command Remarks 
1.   Enter system view. 
system-view  N/A 
2.  Create a VPN instance and 
enter VPN instance view.  ip vpn-instance
 vpn-instance-name N/A 
3.   Configure an RD for the VPN 
instance.  route-distinguisher 
route-distinguisher
  For easy management, set the 
same RD for the same VPN 
instance on the MCE and PE. 
4.
  Configure a description for 
the VPN instance.  description text
  Optional 
 
Associating a VPN instance with an interface 
In an MPLS L3VPN application, you must associate VP N instances with the interfaces connecting the PEs. 
In a tunneling application, you must associate VPN  instances with the tunnel interfaces connecting the 
peer MCE devices or CE devices.
    Add page 1086 to Favourites
    image text
    Enable zoom 
    							 397 
You can add a management Ethernet interface on the switch to a VPN so that the IP address of the 
interface only participates in the route calculation of the specified VPN. 
After creating and configuring a VPN instance, you  associate the VPN instance with the interface for 
connecting different VPN sites.  
To associate a VPN instance with an interface: 
 
Step Command Remarks 
1.   Enter system view. 
system-view  N/A 
2.  Enter interface view.  interface 
interface-type 
interface-number   N/A 
3.
  Associate the current interface 
with the VPN instance.  ip binding vpn-instance 
vpn-instance-name
  No VPN instance is associated 
with an interface by default. 
 
 
NOTE: 
The ip binding vpn-instance  command clears the IP address of the  interface on which it is configured. Be
sure to reconfigure an IP address for th e interface after configuring the command. 
 
Configuring route-related attributes of a VPN instance 
The control process of VPN route advertisement is as follows: 
•  When a VPN route learned from a si te gets redistributed into BGP, BGP associates it with a route 
target extended community attribute list, which is usually the export target attribute of the VPN 
instance associated with the site. 
•   The VPN instance determines which routes it  can accept and redistribute according to the 
import-extcommunity  in the route target. 
•   The VPN instance determines how to  change the route targets attributes for routes to be advertised 
according to the  export-extcommunity  in the route target. 
 
 IMPORTANT: 
•
  Only when BGP runs between the MCE and PE can the route target attribute be advertised to the PE 
along with the routing information. In other cases, configuring this attribute makes no sense. 
•   Before associating a routing policy with a VPN instance, you must first create the routing policy. 
Otherwise, the default routing policy is used. 
 
To configure route related at tributes of a VPN instance:  
Step Command Remarks 
1.  Enter system view. 
system-view  N/A 
2.  Enter VPN instance view. 
ip vpn-instance vpn-instance-name N/A 
3.   Enter IPv4 VPN view. 
ipv4-family  Optional. 
4.  Associate the current VPN 
instance with one or more 
route targets.  vpn-target vpn-target
& 
[ both |  export-extcommunity  | 
import-extcommunity  ]  A single 
vpn-target command can 
configure up to eight route targets. 
You can configure up to 64 route 
targets for a VPN instance.
    Add page 1087 to Favourites
    image text
    Enable zoom 
    							 398 
Step Command Remarks 
5.  Configure the maximum 
number of routes for the VPN 
instance.   routing-table
 limit  number  
{  warn-threshold  | simply-alert  }  Optional. 
Not configured by default. 
Setting the maximum number of 
routes for a VPN instance to 
support is for preventing too many 
routes from being redistributed into 
the PE. 
6.
  Apply an import routing 
policy to the current VPN 
instance.   import route-policy route-policy
 Optional. 
By default, all routes permitted by 
the import target attribute can be 
redistributed into the VPN instance.
 
7.
  Apply an export routing 
policy to the current VPN 
instance.   export route-policy 
route-policy Optional. 
By default, all VPN instance routes 
permitted by the export target 
attribute can be redistributed. 
 
 
NOTE: 
•  Only when BGP runs between the MCE and PE can the route target attribute be advertised to the PE 
together with the routing information. In other cases, configuring this attribute makes no sense. 
•   You can configure route related attributes for IPv4 VPNs in both VPN instance view and IPv4 VPN view.
Those configured in IPv4 VPN view take precedence. 
 
Configuring routing on an MCE 
MCE implements service isolation through route isolation. MCE routing configuration includes: 
•  MCE-VPN site routing configuration 
•   MCE-PE routing configuration 
On the PE in an MCE network environment, disable routing loop detection to avoid route loss during 
route calculation and disable route redistribution be tween routing protocols to save system resources. 
Configuration prerequisites 
Before you configure routing on an MCE, complete the following tasks: 
•  On the MCE, configure VPN instances, and bind  the VPN instances with the interfaces connected 
to the VPN sites and those connected to the PE. 
•   Configure the link layer and network layer protocols on related interfaces to ensure IP connectivity. 
Configuring routing between MCE and VPN site 
Configuring static routing between MCE and VPN site  
An MCE can reach a VPN site through a static route.  Static routing on a traditional CE is globally 
effective and thus does not support address overlapping among VPNs. An MCE supports binding a static 
route with a VPN instance, so that the static routes  of different VPN instances can be isolated from each 
other.
    Add page 1088 to Favourites
    image text
    Enable zoom 
    							 399 
To configure static routing between MCE and VPN site:  
Step Command Remarks 
1.  Enter system view. 
system-view  N/A 
2.  Configure a static route 
for a VPN instance. 
• ip  route-static  dest-address  { mask | mask-length  } 
{  gateway-address  | interface-type 
interface-number [ gateway-address  ] | 
vpn-instance  d-vpn-instance-name 
gateway-address  } [ preference preference-value  ] 
[ tag  tag-value  ] [ description  description-text  ] 
• ip route-static  vpn-instance  
s-vpn-instance-name&  dest-address  { mask | 
mask-length  } { gateway-address  [ public ] | 
interface-type interface-number 
[ gateway-address  ] | vpn-instance 
d-vpn-instance-name gateway-address } 
[ preference  preference-value  ] [ tag tag-value  ] 
[ description  description-text  ]  Use either command.
 
Perform this 
configuration on the 
MCE. On a VPN site, 
configure a normal 
static route. 
3.
  Configure the default 
precedence for static 
routes.  ip route-static default-preference
 
default-preference-value  Optional. 
60 by default. 
 
Configuring RIP between MCE and VPN site 
A RIP process belongs to the public network or a sing
le VPN instance. If you create a RIP process without 
binding it to a VPN instance, the process belong s to the public network. By configuring RIP 
process-to-VPN instance bindings on a IPv6 MCE, yo u allow routes of different VPNs to be exchanged 
between the MCE and the sites through different RIP pr ocesses, ensuring the separation and security of 
VPN routes.  
To configure RIP between MCE and VPN site: 
 
Step Command Remarks 
1.   Enter system view. 
system-view  N/A 
2.  Create a RIP process for a 
VPN instance and enter RIP 
view.  rip 
[ process-id  ] vpn-instance  
vpn-instance-name   Perform this configuration on the 
MCE. On a VPN site, create a 
normal RIP process. 
3.
  Enable RIP on the interface 
attached to the specified 
network.  network 
network-address  By default, RIP is disabled on an 
interface. 
4.
  Redistribute remote site routes 
advertised by the PE.  import-route 
protocol [  process-id  ] 
[  allow-ibgp  ] [ cost cost | 
route-policy route-policy-name  | 
tag  tag ] *   By default, no route is redistributed 
into RIP. 
5.
  Configure the default cost 
value for the redistributed 
routes.  default cost 
value  Optional. 
0 by default. 
 
Configuring OSPF between MCE and VPN site  
An OSPF process belongs to the public network or a 
single VPN instance. If you create an OSPF process 
without binding it to a VPN instance, the  process belongs to the public network.
    Add page 1089 to Favourites
    image text
    Enable zoom 
    							 400 
By configuring OSPF process-to-VPN instance bindings on a MCE, you allow routes of different VPNs to 
be exchanged between the MCE and the sites through different OSPF processes, ensuring the separation 
and security of VPN routes. 
An OSPF process can belong to only one VPN instance, but one VPN instance can use multiple OSPF 
processes to advertise the VPN routes. 
An OSPF process that is bound with a VPN instance do es not use the public network router ID configured 
in system view. Therefore, you must configure a router ID when starting the OSPF process. All OSPF 
processes for the same VPN must be configured with the same OSPF domain ID to ensure correct route 
advertisement. 
To configure OSPF between MCE and VPN site: 
 
Step Command Remarks 
1.   Enter system view. 
system-view  N/A 
2.  Create an OSPF process for a 
VPN instance and enter OSPF 
view.  ospf
 [ process-id  | router-id 
router-id  | vpn-instance 
vpn-instance-name  ] *  Perform this configuration on the 
MCE. On a VPN site, create a 
normal OSPF process. 
3.
  Configure the OSPF domain 
ID.  domain-id 
domain-id [ secondary ] 
Optional. 
0 by default. 
Perform this configuration on the 
MCE. On a VPN site, perform the 
common OSPF configuration. 
4.   Redistribute remote site routes 
advertised by the PE.  import-route 
protocol [ process-id 
|  allow-ibgp  ] [ cost cost  | type  
type  | tag  tag | route-policy 
route-policy-name  ] *
  By default, no route of any other 
routing protocol is redistributed 
into OSPF.
 
5.  Create an OSPF area and 
enter OSPF area view.  area
 area-id   By default, no OSPF area is 
created. 
6.
  Enable OSPF on the interface 
attached to the specified 
network in the area.  network 
ip-address wildcard-mask By default, an interface neither 
belongs to any area nor runs 
OSPF.
 
 
Configuring IS-IS between MCE and VPN site 
An IS-IS process belongs to the public network or a  single VPN instance. If you create an IS-IS process 
without binding it to a VPN instance, the  process belongs to the public network. 
By configuring IS-IS process-to-VPN instance bindings  on a MCE, you allow routes of different VPNs to 
be exchanged between the MCE and the sites through different IS-IS processes, ensuring the separation 
and security of VPN routes. 
To configure IS-IS between MCE and VPN site: 
 
Step Command Remarks 
1.   Enter system view. 
system-view  N/A 
2.  Create an IS-IS process for a 
VPN instance and enter IS-IS 
view.  isis
 [ process-id  ] vpn-instance  
vpn-instance-name   Perform this configuration on the 
MCE. On a VPN site, configure a 
normal IS-IS process. 
3.
  Configure a network entity 
title.  network-entity 
net  Not configured by default.
    Add page 1090 to Favourites
    image text
    Enable zoom 
    							 401 
Step Command Remarks 
4.  Redistribute remote site routes 
advertised by the PE.  import-route { isis
 [ process-id ] |  
ospf  [ process-id  ] | rip  
[  process-id  ] |  bgp  [ allow-ibgp  ] | 
direct |  static } [ cost  cost  | 
cost-type  { external |  internal } | 
[ level-1  | level-1-2  | level-2  ] | 
route-policy  route-policy-name  | 
tag  tag  ] *  Optional. 
By default, IS-IS does not 
redistribute routes of any other 
routing protocol. 
If you do not specify the route level 
in the command, the command will 
redistribute routes to the level-2 
routing table by default. 
5.
  Return to system view. 
quit  N/A 
6.  Enter interface view.  interface 
interface-type 
interface-number   N/A 
7.
  Enable the IS-IS process on 
the interface.  isis enable
 [ process-id  ]  Disabled by default. 
 
Configuring EBGP between MCE and VPN site 
To use EBGP for exchanging routing information between an MCE and VPN sites, you must configure a 
BGP peer for each VPN instance on the MCE, and redi stribute the IGP routes of each VPN instance on 
the VPN sites. 
If EBGP is used for route exchange, you also can configure filtering policies to filter the received routes 
and the routes to be advertised. 
1.  Configure the MCE:  
Step Command Remarks 
1.  Enter system view. 
system-view  N/A 
2.  Enter BGP view. 
bgp as-number  N/A 
3.  Enter BGP-VPN instance view.  ipv4-family vpn-instance
 
vpn-instance-name   N/A 
4.
  Configure an EBGP peer.  peer 
{ group-name |  ip-address } 
as-number  as-number  N/A 
5.
  Allow the local AS number to 
appear in the AS_PATH 
attribute of a received route, 
and set the maximum number 
of times that such case is 
allowed to appear.  peer { group-name |
 ip-address } 
allow-as-loop  [ number ]  Optional. 
6.
  Redistribute remote site routes 
advertised by the PE.  import-route 
protocol [ process-id  
|  all-processes  ] [ med  med-value  | 
route-policy route-policy-name ] *  By default, no route redistribution 
is configured. 
7.
  Configure a filtering policy to 
filter the routes to be 
advertised.  filter-policy {
 acl-number | 
ip-prefix  ip-prefix-name  } export 
[ direct | isis  process-id  | ospf  
process-id  | rip process-id  | static ]
 
Optional. 
By default, BGP does not filter the 
routes to be advertised. 
8.  Configure a filtering policy to 
filter the received routes.  filter-policy 
{ acl-number  | 
ip-prefix ip-prefix-name  } import Optional. 
By default, BGP does not filter the 
received routes.
    All HP manuals Comments (0)

    Related Manuals for HP 5500 Ei 5500 Si Switch Series Configuration Guide