HP 5500 Ei 5500 Si Switch Series Configuration Guide
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+.
![Page 1076
387
system-view
[SwitchB] ip route-static 10.110.0.0 24 1.1.2.1
# Configure the IP address of VLAN-interface 10.
[SwitchB] interface vlan-interface 10
[SwitchB-Vlan-interface10] ip address 1.1.2.2 255.255.255.0
[SwitchB-Vlan-interface10] quit
3. Configure Switch C:
# Configure a static route to subnet 10.110.0.0/24.
system-view
[SwitchC] ip route-static 10.110.0.0 24 1.1.3.1
# Configure the IP address of VLAN-interface 20.
[SwitchC] interface vlan-interface 20
[SwitchC-Vlan-interface20]...](http://img.usermanuals.tech/thumb/36/58909/w64_hp-5500-ei-5500-si-switch-series-configuration-guide-1075.png "Page 1076
387
system-view
[SwitchB] ip route-static 10.110.0.0 24 1.1.2.1
# Configure the IP address of VLAN-interface 10.
[SwitchB] interface vlan-interface 10
[SwitchB-Vlan-interface10] ip address 1.1.2.2 255.255.255.0
[SwitchB-Vlan-interface10] quit
3. Configure Switch C:
# Configure a static route to subnet 10.110.0.0/24.
system-view
[SwitchC] ip route-static 10.110.0.0 24 1.1.3.1
# Configure the IP address of VLAN-interface 20.
[SwitchC] interface vlan-interface 20
[SwitchC-Vlan-interface20]...")
![Page 1077
388
[SwitchA-acl-basic-2000] rule 0 permit source any
[SwitchA-acl-basic-2000] quit
# Define a match criterion for class a to match ACL 2000.
[SwitchA] traffic classifier a
[SwitchA-classifier-a] if-match acl 2000
[SwitchA-classifier-a] quit
# Configure the action of redirecting traffic to the next hop 202.1.1.2 for behavior a.
[SwitchA] traffic behavior a
[SwitchA-behavior-a] redirect next-hop 202.1.1.2
[SwitchA-behavior-a] quit
# Associate class a with behavior a in QoS policy a....](http://img.usermanuals.tech/thumb/36/58909/w64_hp-5500-ei-5500-si-switch-series-configuration-guide-1076.png "Page 1077
388
[SwitchA-acl-basic-2000] rule 0 permit source any
[SwitchA-acl-basic-2000] quit
# Define a match criterion for class a to match ACL 2000.
[SwitchA] traffic classifier a
[SwitchA-classifier-a] if-match acl 2000
[SwitchA-classifier-a] quit
# Configure the action of redirecting traffic to the next hop 202.1.1.2 for behavior a.
[SwitchA] traffic behavior a
[SwitchA-behavior-a] redirect next-hop 202.1.1.2
[SwitchA-behavior-a] quit
# Associate class a with behavior a in QoS policy a....")
![Page 1078
389
[SwitchA] traffic classifier a
[SwitchA-classifier-a] if-match acl ipv6 2000
[SwitchA-classifier-a] quit
# Configure the action of redirecting traffic to the next hop 202::2 for behavior a.
[SwitchA] traffic behavior a
[SwitchA-behavior-a] redirect next-hop 202::2
[SwitchA-behavior-a] quit
# Associate class a with behavior a in QoS policy a.
[SwitchA] qos policy a
[SwitchA-qospolicy-a] classifier a behavior a
[SwitchA-qospolicy-a] quit
# Apply QoS policy a to the incoming traffic of...](http://img.usermanuals.tech/thumb/36/58909/w64_hp-5500-ei-5500-si-switch-series-configuration-guide-1077.png "Page 1078
389
[SwitchA] traffic classifier a
[SwitchA-classifier-a] if-match acl ipv6 2000
[SwitchA-classifier-a] quit
# Configure the action of redirecting traffic to the next hop 202::2 for behavior a.
[SwitchA] traffic behavior a
[SwitchA-behavior-a] redirect next-hop 202::2
[SwitchA-behavior-a] quit
# Associate class a with behavior a in QoS policy a.
[SwitchA] qos policy a
[SwitchA-qospolicy-a] classifier a behavior a
[SwitchA-qospolicy-a] quit
# Apply QoS policy a to the incoming traffic of...")
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:
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.
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
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
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.
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.
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.
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.
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.
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.