Operation Manual MCE H3C S3610&S5510 Series Ethernet Switches. Table of Contents

Transcription

1 Table of Contents Table of Contents Chapter 1 MCE Overview MCE Overview Introduction to BGP/MPLS VPN BGP/MPLS VPN Concepts Introduction to MCE How MCE Works Routing Information Exchange for MCE Route Exchange between a CE and the Private Network Route Exchange between CE and PE Configuring a VPN Instance VPN Instance Configuration Tasks Setting the Operation Mode of the Switch to MCE Creating a VPN Instance Associating an VPN Instance with an Interface Configuring the Route-related Attributes for a VPN Instance Configuring Route Exchange between a MCE and a Site Configuring Route Exchange between a MCE and a Site Configuring to Use Static Routes between a MCE and a Site Configuring to Use RIP between a MCE and a Site Configuring to Use OSPF between a MCE and a Site Configuring to Use IS-IS between a MCE and a Site Configuring to Use EBGP between a MCE and a Site Configuring Route Exchange between a MCE and a PE Configuring Route Exchange between a MCE and a PE Configuring to Use Static Routes between a MCE and a PE Configuring to Use RIP between a MCE and a PE Configuring to Use OSPF between a MCE and a PE Configure to Use IS-IS between a MCE and a PE Configure to Use EBGP between a MCE and a PE Displaying and Maintaining MCE MCE Configuration Example MCE Configuration Example (A) MCE Configuration Example (B) i

2 Chapter 1 MCE Overview Chapter 1 MCE Overview Note: The term router in this document refers to a router in a generic sense or a Layer 3 switch running routing protocols. 1.1 MCE Overview Multi-CE (MCE) enables a switch to function as the CEs of multiple VPN instances in a BGP/MPLS VPN network, thus reducing the investment on network equipment Introduction to BGP/MPLS VPN BGP/MPLS VPN is a kind of PE-based L3VPN technology for service provider VPN solutions. It uses BGP to advertise VPN routes and uses MPLS to forward VPN packets on the service provider backbone. BGP/MPLS VPN provides flexible networking modes, excellent scalability, and convenient support for MPLS QoS and MPLS TE. Hence, it is widely used. The BGP/MPLS VPN model consists of three kinds of devices: Customer edge device (CE): A CE resides on a customer network and has one or more interfaces directly connected with service provider networks. It can be a router, a switch, or a host. It neither can "sense" the existence of any VPN nor needs to support MPLS. Provider edge router (PE): A PE resides on a service provider network and connects one or more CEs to the network. On an MPLS network, all VPN processing occurs on the PEs. Provider (P) router: A P router is a backbone router on a service provider network. It is not directly connected with any CE. It only needs to be equipped with basic MPLS forwarding capability. Figure 1-1 illustrates a BGP/MPLS VPN implementation. 1-1

3 Chapter 1 MCE Overview Figure 1-1 A BGP/MPLS VPN implementation CEs and PEs mark the boundary between the service providers and the customers. A CE is usually a router. After a CE establishes adjacency with a directly connected PE, it redistributes its VPN routes to the PE and learns remote VPN routes from the PE. A CE and a PE use BGP/IGP to exchange routing information. You can also configure static routes between them. After a PE learns the VPN routing information of a CE, it uses BGP to exchange VPN routing information with other PEs. A PE maintains routing information about only VPNs that are directly connected, rather than all VPN routing information on the provider network. A P router maintains only routes to PEs. It does not need to know anything about VPN routing information. When VPN traffic travels over the MPLS backbone, the ingress PE functions as the ingress LSR, the egress PE functions as the egress LSR, while P routers function as the transit LSRs. You can use H3C S3610&S5510 series switches as the CEs in a BGP/MPLS VPN implementation BGP/MPLS VPN Concepts I. Site Site is often mentioned in the VPN, whose meanings are described as follows: A site is a group of IP systems with IP connectivity that does not rely on any service provider network to implement. The classification of a site depends on the topology relationship of the devices, rather than the geographical positions, though the devices at a site are adjacent to each other geographically in most cases. 1-2

4 Chapter 1 MCE Overview The devices at a site can belong to multiple VPNs, namely, a site can belong to multiple VPNs. A site is connected to a provider network through one or more CEs. A site can contain many CEs, but a CE can belong to only one site. Sites connected to the same provider network can be classified into different sets by policies. Only the sites in the same set can access each other through the provider network. Such a set is called a VPN. II. Address space overlapping Each VPN independently manages the addresses that it uses. The assembly of such addresses for a VPN is called an address space. The address spaces of VPNs may overlap. For example, if both VPN 1 and VPN 2 use the addresses in network segment /24, address space overlapping occurs. III. VPN instance In MPLS VPN, route separation between VPNs is implemented by VPN instance. A PE creates and maintains a separate VPN instance for each directly connected site. Each VPN instance contains the VPN membership and routing rules of the corresponding site. If a user at a site belongs to multiple VPNs at the same time, the VPN instance of the site contains information about all the VPNs. For independency and security of VPN data, each VPN instance on a PE maintains a relatively independent routing table and a separate label forwarding information base (LFIB). VPN instance information contains these items: the LFIB, IP routing table, interfaces bound to the VPN instance, and administration information of the VPN instance. The administration information of the VPN instance includes the route distinguisher (RD), route filtering policy, and member interface list. Note: LFIBs of VPN instances exist on only PEs supporting MPLS. No LFIBs of VPN instances exist on MCE-capable devices. IV. VPN-IPv4 address Traditional BGP cannot process VPN routes which have overlapping address spaces. If, for example, both VPN 1 and VPN 2 use addresses in the segment /24 and advertise a route to the segment, BGP selects only one of them, which results in 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. 1-3

5 Chapter 1 MCE Overview A VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD, followed by a 4-byte IPv4 address prefix, as shown in. Route Distinguisher ( 8-Byte ) Type Field ( 2-Byte ) Administrator Subfield Assigned Number Subfield IPv4 Address Prefix ( 4-Byte ) Figure 1-2 Structure of a VPN-IPv4 address When a PE receives an ordinary IPv4 route from a CE, it must redistribute 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 provided the assigned RDs are unique. In this way, a PE can advertise different routes to VPNs even if the VPNs are from different service providers and are using the same IPv4 address space. You are recommended to configure a distinct RD for each VPN instance on a PE, guaranteeing that routes to the same CE use the same RD. The VPN-IPv4 address with an RD of 0 is in fact a globally unique IPv4 address. By prefixing a distinct RD to a specific IPv4 address prefix, you make it 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 an AS number and a discretionary number; or be related to an IP address, in which case it is the combination of an IP address and a discretionary number. An RD can be in either of the following two 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-bit AS number:32-bit user-defined 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. For example, :1. For the global uniqueness of an RD, you are not recommended to set the Administrator subfield to any private AS number or private IP address. V. VPN target attributes BGP/MPLS VPN uses the BGP extended community attributes called VPN target attributes, or route target attributes, to control the advertisement of VPN routing information. A VPN instance on a PE supports two types of VPN target attributes: 1-4

6 Chapter 1 MCE Overview Export target attribute: A local PE sets this type of VPN target attribute for VPN-IPv4 routes learnt from directly connected sites before advertising them to other PEs. Import target attribute: A PE checks the export target 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, VPN target attributes define which sites can receive a VPN-IPv4 route, and from which sites a PE can receive routes. Like RDs, VPN target attributes can be of two types of formats: 16-bit AS number:32-bit user-defined number. For example, 100:1. 32-bit IPv4 address:16-bit user-defined number. For example, : Introduction to MCE With BGP/MPLS VPN, data of private networks can be transmitted in the public network securely through tunnels. However, in a typical BGP/MPLS VPN network, each VPN is connected to the PE through a CE, as shown in Figure 1-1. With the users increasing demand for service segmentation and security, a private network may be divided into multiple VPNs, and the users of different VPN are usually isolated from each other. In a private network containing multiple VPNs, users may be in such a dilemma: equipment investment and the maintenance cost increment caused by assigning a CE for each of the VPNs; and potential data security risks introduced by sharing one CE among multiple VPNs (because the same routing entry may be used in multiple VPNs in this case). An S3610&S5510 switch with MCE enabled can solve this problem. By binding the VLAN interfaces to the VPNs in a network on an S3610&S5510 switch of this kind, you can create and maintain a routing table for each of the VPNs. In this way, packets of different VPNs in the private network can be isolated. Moreover, with the cooperation of the PE, the routes of each VPN can be advertised to the corresponding remote PE properly, so that packets of each VPN in the private network can be transmitted securely through the public network How MCE Works Figure 1-3 illustrates how MCE creates and maintains routing entries of multiple VPNs and how the MCE exchanges VPN routes with PEs. 1-5

7 Chapter 1 MCE Overview Figure 1-3 How MCE works In Figure 1-3, the two VPN sites on the left side (Site 1 and Site 2) are connected to the backbone network through an MCE device. Two VPN tunnels are expected between them and the remote VPNs at Site 2 and Site 1. 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 and then maintains the corresponding routing table accordingly. You need to also to bind the interfaces/sub-interfaces to the VPNs on PE 1 in the same way as those on the MCE 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. 1.2 Routing Information Exchange for MCE Interface-to-VPN-instance binding enables CEs and PEs to determine the sources of received packets and then forward the packets according to the routing information concerning the corresponding VPNs. The following sections describe the way how MCE transmits the private routing information of multiple VPNs to PEs properly Route Exchange between a CE and the Private Network A CE can adopt the following routing protocols to exchange VPN routes with a site: Static route RIP OSPF IS-IS 1-6

8 Chapter 1 MCE Overview EBGP Note: This introduces the cooperation of routing protocols and MCE in brief. For details on routing protocols, see the IPv4 Routing module of this manual. I. Static routes A CE can communicate with a site through static routes. As static routes configure for traditional CEs take effect globally, address overlapping between multiple VPNs remains a problem till the emergence of MCE. MCE allows static-route-to-vpn-instance binding, which isolates the static routes of different VPNs. II. RIP A S3610&S5510 switch can bind RIP processes to VPN instances. With the same binding configured on CE and site, private network routes of different VPNs can be exchanged between CEs and sites through different RIP processes, thus isolating and securing VPN routes. III. OSPF A S3610&S5510 switch can bind OSPF processes to VPN instances and isolate the routes of different VPNs. Note that: For an OSPF process bound to a VPN instance, the router ID of the public network configured in system view is invalid. So you need to 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, you need to configure the same domain ID for all the OSPF processes bound to a VPN instance. 1-7

9 Chapter 1 MCE Overview Note: Normally, when an OSPF route is imported to the BGP routing table as a BGP route on a PE, some attributes of the OSPF route get lost. When the BGP route is imported to the OSPF routing table on the remote CE, not all the attributes of the original OSPF routes can be restored. As a result, the route cannot be distinguished from the routes imported from other domains. In order to distinguish OSPF routes imported from different OSPF domains, the OSPF routes to be imported to the BGP routing tables on PEs must carry an attribute (the OSPF domain ID) used to identify the OSPF domains. The domain ID of an OSPF process is contained in the routes generated by the process. When an OSPF route is imported to BGP, the domain ID is added to BGP VPN routes as the extended BGP community. In cases where a VPN have multiple MCE devices attached to it, when a MCE device advertises the routes learned from BGP within the VPN, the routes may be learned by other MCE devices, thus generating route loops. To prevent route loops, you can configure route tags for different VPN instances on each MCE. It is recommended that a VPN be assigned the same route tag on multiple MCEs. IV. IS-IS Similar to those in OSPF, IS-IS processes can be bound to VPN instances for private network routes to be exchanged between CEs and sites. An IS-IS process can be bound to only one VPN instance. V. EBGP To use EBGP to exchange private routes between a CE and a site, you need to configure BGP peers for VPN instances on CEs and import IGP routing information from corresponding VPNs. Normally, sites reside in different ASs, so EBGP is used for route exchange. In this case, the following configurations are needed. 1) Configuring to use EBGP to import IGP routes from each site To advertise private network routes to PEs properly, IGP routes in the sites directly connected to an MCE device need to be first imported to the BGP routing table of the MCE device. 2) Configuring a peer group for each VPN instance For proper route exchange between a CE and a site, you need to configure a peer group for each VPN instance and assign AS numbers for these peer groups in BGP IPv4 address family view. 3) Applying filtering policies for route filtering To make sure that routing information is exchanged between sites and PE devices properly, filtering policies are applied to filter routes received or to be advertised. 1-8

10 Chapter 1 MCE Overview Route Exchange between CE and PE Routing information entries are bound to specific VPN instances on a MCE device, and packets of each VPN instance are forwarded between CE and PE according to interface. As a result, VPN routing information can be transmitted by performing relatively simple configurations between CE and PE, such as importing the VPN routing entries on MCE devices to the routing table of the routing protocol running between CEs and PEs. The following routing protocols can be used between CE and PE for routing formation exchange: Static route RIP OSPF IS-IS EBGP For information on how to configure the routing protocols and how to import routes, refer to the IPv4 Routing module of this manual. 1-9

11 Note: For detailed information on the routing protocol configuration mentioned in this chapter, see the IPv4 Routing module of this manual. 2.1 Configuring a VPN Instance VPN Instance Configuration Tasks Table 2-1 Configure a VPN instance Operation Description Related section Configuring the operation mode to MCE Create a VPN instance Associate the VPN instance with an interface Configure the route-related attributes for the VPN instance See Setting the Operation Mode of the Switch to MCE See Creating a VPN Instance See Associating an VPN Instance with an Interface See Configuring the Route-related Attributes for a VPN Instance Setting the Operation Mode of the Switch to MCE The switch must work in the operation mode of MCE to support MCE. Table 2-2 Set the operation mode of the switch to MCE Enter system view system-view Set the operation mode of the switch to MCE switch-mode mce By default, the device works in the default mode and does not support MCE. 2-1

12 2.1.3 Creating a VPN Instance A VPN instance needs to be associated with a site. A VPN instance does not correspond to a VPN directly. Instead, a VPN instance is an integration of the VPN membership and routing rules of its corresponding site. A VPN instance takes effect only after a route distinguisher (RD) is configured for it. For a VPN instance with the RD not configured, all the other settings (except the description information) are inaccessible. The description information of a VPN instance can be used to record the relationship between the VPN instance and a VPN. Table 2-3 Create a VPN instance Enter system view system-view Create a VPN instance and enter VPN instance view Configure an RD for the VPN instance Set the description information for the VPN instance ip vpn-instance vpn-instance-name route-distinguisher route-distinguisher description text By default, no VPN instance is present. By default, a VPN instance has no RD configured. Optional By default, a VPN instance has no description configured. Caution: The RD configured for a VPN instance on the MCE device must be same as that configured for the VPN instance on the PE device Associating an VPN Instance with an Interface After creating a VPN instance, you need to associate it with the interface connecting a site to a PE. 2-2

13 Table 2-4 Associate an VPN instance with an interface Enter system view system-view Enter interface view of the interface to be associated Associate the current interface with the VPN instance interface interface-type interface-number ip binding vpn-instance vpn-instance-name By default, no interface is associated with a VPN instance. Note: Executing the ip binding vpn-instance command invalidates the IP address configured for the current interface, so you need to configure an IP address for an interface again after associating the interface with a VPN instance Configuring the Route-related Attributes for a VPN Instance The process of advertising VPN routes is as follows: When the switch learns a VPN route from a site and injects it into BGP, BGP associates the route with a VPN target extended community attribute list, which is normally the export route attribute list of the VPN instance. A VPN instance determines whether to accept a received route according to the VPN target import extended community attribute list associated with the route and the setting specified by the vpn-target command. A VPN instance modifies the export VPN target attribute according to the setting specified by the vpn-target command. Table 2-5 Configure the route-related attributes for a VPN instance Enter system view system-view Enter VPN instance view Associate the current VPN instance with one or multiple VPN targets ip vpn-instance vpn-instance-name vpn-target vpn-target&<1-8> [ both export-extcommunity import-extcommunity ] By default, a VPN instance has no VPN target associated with it. 2-3

14 Configure the maximum number of routes a VPN instance can accommodate Apply a route policy for the routes received Apply a route policy for the routes to be advertised routing-table limit number { warn-threshold simply-alert } import route-policy route-policy export route-policy route-policy Optional Not configured by default Optional By default, all routes matching the VPN target attribute are permitted. Optional By default, all routes matching the VPN target attribute are permitted. Note: This attribute can be advertised with a route only when BGP runs between the MCE and the PE. Otherwise, this attribute is of no sense. The VPN target specified for a VPN instance on the MCE device must be same as that specified for the VPN instance on the PE device. 2.2 Configuring Route Exchange between a MCE and a Site Configuring Route Exchange between a MCE and a Site Table 2-6 Configure route exchange between a MCE and a site Operation Description Related section Configure to use static routes between a MCE and a site Configure to use RIP between a MCE and a site Configure to use OSPF between a MCE and a site Configure to use IS-IS between a MCE and a site Configure to use EBGP between a MCE and a site You can choose one or multiple configurations as required. See Configuring to Use Static Routes between a MCE and a Site See Configuring to Use Static Routes between a MCE and a Site See Configuring to Use OSPF between a MCE and a Site See Configuring to Use IS-IS between a MCE and a Site See Configuring to Use EBGP between a MCE and a Site 2-4

15 2.2.2 Configuring to Use Static Routes between a MCE and a Site Table 2-7 Configure to use static routes between a MCE and a site Enter system view system-view Define a static route for a VPN instance ip route-static vpn-instance s-vpn-instance-name&<1-5> 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 ] This operation is performed on the MCE device. The corresponding configuration on the site is the same as configuring a normal static route Configuring to Use RIP between a MCE and a Site A RIP process can be bound to only one VPN instance. RIP processes not bound to any VPN instances belong to the public network. Table 2-8 Configure to use RIP between a MCE and a site Enter system view system-view Enable RIP for a VPN instance (This operation also leads you to RIP view) rip [ process-id ] vpn-instance vpn-instance-name This operation is performed on the MCE device. As for the corresponding configuration on the site, you can just enable RIP as usual. Note: After enabling RIP for a VPN instance, you need also to configure to use RIP for routing information exchange, which is described in the IPv4 Routing module of this manual Configuring to Use OSPF between a MCE and a Site An OSPF process can be bound to only one VPN instance. OSPF processes not bound to any VPN instances belong to the public network. 2-5

16 Table 2-9 Configure to use OSPF between a MCE and a site Enter system view system-view Enable OSPF for a VPN instance (this operation also leads you to OSPF view) Enable multi-vpn-instance CE for the OSPF process Configure the OSPF domain ID ospf [ process-id router-id router-id vpn-instance vpn-instance-name ] * vpn-instance-capabi lity simple domain-id domain-id [ secondary ] This operation is performed on the MCE device. As for the corresponding configuration on the site, you can just enable OSPF as usual. Disabled by default Optional By default, the OSPF domain ID is 0. This operation is performed on the MCE device. As for the corresponding configuration on the site, you can just enable OSPF as usual. Note: Router IDs of the public network configured in system view do not applies to OSPF processes bound to VPN instances. So you need to configure the Router ID after enabling OSPF for a VPN instance. To make sure routes can be advertised properly, you need to configure the same domain ID for all the OSPF processes bound to a VPN. After enabling OSPF for a VPN instance, you need also to configure to use OSPF for routing information exchange, which is described in the IPv4 Routing module of this manual Configuring to Use IS-IS between a MCE and a Site An IS-IS process can be bound to only one VPN instance. IS-IS processes not bound to any VPN instances belong to the public network. 2-6

17 Table 2-10 Configure to use IS-IS between a MCE and a site Enter system view system-view Enable IS-IS for a VPN instance and enter IS-IS view isis [ process-id ] vpn-instance vpn-instance-name This operation is performed on the MCE device. As for the corresponding configuration on the site, you can just enable IS-IS as usual. Note: After enabling IS-IS for a VPN instance, you need also to configure to use IS-IS for routing information exchange, which is described in the IPv4 Routing module of this manual Configuring to Use EBGP between a MCE and a Site 1) Configuration on the MCE device Table 2-11 Configure an MCE device Enter system view system-view Enter BGP view bgp as-number Enter BGP-VPN instance view Configure a CE as a VPN peer Import routes of the local CE Apply a filter policy to the routes to be advertised ipv4-family vpn-instance vpn-instance-name peer { group-name ip-address } [ as-number as-number ] import-route protocol [ process-id ] [ med med-value route-policy route-policy-name ] * filter-policy { acl-number ip-prefix ip-prefix-name } export [ direct isis process-id ospf process-id rip process-id static ] The PE device must import routes of the local CE to the VPN routing table in order to advertise these routes to the remote PE device. Optional By default, routes to be advertised are not filtered. 2-7

18 Apply a filter policy to routes received Configure to permit the routes with their AS numbers contained in their AS_PATH attributes being the local AS number (this operation can also specify the number of the AS number occurrences allowed) filter-policy { acl-number ip-prefix ip-prefix-name } import peer { group-name ip-address } allow-as-loop [ number ] Optional By default, received routes are not filtered. Optional By default, routes with their AS numbers contained in their AS_PATH attributes being the local AS number are denied. Note: AS number contained in the AS_PATH attribute can be used for route loop detect. With EBGP running between a MCE and a site, the routes advertised by an MCE device to the site carry the local AS number. So do the routes advertised by the site. In this case, you need to configure to permit the routes with their AS numbers contained in their AS_PATH attributes being the local AS number on MCE devices for the routes advertised by the site to be received and processed by the MCE device. 2) Configuration on the site Note: The site configuration procedures vary with device model. The following takes an S3610&S5510 Ethernet switch as an example. As for switches from other vendors, refer to the corresponding user manuals. Table 2-12 Configure the site Enter system view system-view Enter BGP view bgp as-number Configure the PE as a peer peer { group-name ip-address } as-number as-number 2-8

19 Configure to import routes import-route protocol [ process-id ] [ med med-value route-policy route-policy-name ] * Optional The site must advertise the addresses of the reachable VPN segments to the MCE connected to the site. Note: In a VPN instance with BGP enabled, the BGP route exchange is processed in the same way as those in a normal BGP-enabled network. 2.3 Configuring Route Exchange between a MCE and a PE Configuring Route Exchange between a MCE and a PE Table 2-13 Configure route exchange between a MCE and a PE Operation Description Related section Define a static route for a VPN instance Configure to use RIP between a MCE and a PE Configure to use OSPF between a MCE and a PE Configure to use IS-IS between a MCE and a PE Configure to use EBGP between a MCE and a PE You can choose one or multiple configurations as required. See Configuring to Use Static Routes between a MCE and a PE See Configuring to Use RIP between a MCE and a PE See Configuring to Use OSPF between a MCE and a PE See Configure to Use IS-IS between a MCE and a PE See Configure to Use EBGP between a MCE and a PE 2-9

20 2.3.2 Configuring to Use Static Routes between a MCE and a PE Table 2-14 Define a static route for a VPN instance Enter system view system-view Define a static route for a VPN instance Set the default preference value of static routes 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&<1-6> 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 ] ip route-static default-preference default-preference-value By default, for a static route, the preference value is 60, the tag value is 0, and no description information is configured. Optional By default, the preference value of a static route is 60. Note: A static route configured for a VPN instance does not take effect if you configure the next hop address of the route as the IP address of a local interface (such as Ethernet interface, VLAN interface). If the default static route preference is not configured, the preference of a newly defined static route adopts the system default preference value, which is 60. A customized default static route preference has no effect on existing static routes. Static routes can be controlled selectively by using routing policies according to the tag values set for static routes. The ip route-static command defines a default route if both the destination address and the mask are set to

21 2.3.3 Configuring to Use RIP between a MCE and a PE When configuring to use RIP between a MCE and a PE, you need to configure the RIP processes to be bound to the VPN instances and manually import the VPN routes in the site maintained by the MCE device to the routing table of the PE. Table 2-15 Enable RIP for a VPN instance Enter system view system-view Enable RIP for a VPN instance and enter RIP view Set the default cost for imported routes Import the VPN routes of the site rip [ process-id ] [ vpn-instance vpn-instance-name ] default cost value import-route protocol [ process-id ] [ allow-ibgp ] [ cost cost route-policy route-policy-name tag tag ] * Optional By default, the cost for an imported route is 0. By default, RIP does not import routes from other protocols Configuring to Use OSPF between a MCE and a PE When configuring to use OSPF between a MCE and a PE, you need to configure the OSPF processes to be bound to VPN instances and router IDs; you also need to manually import the VPN routes in the site maintained by the MCE device to the routing table of the PE. Table 2-16 Configure to use OSPF between a MCE and a PE Enter system view system-view Enable OSPF for a VPN instance and enter OSPF view Enable OSPF to import routes of other protocols Apply a filter policy for imported routes ospf [ process-id router-id router-id vpn-instance instance-name ] * import-route protocol [ process-id allow-ibgp ] [ cost cost type type tag tag route-policy route-policy-name ] * filter-policy { acl-number ip-prefix ip-prefix-name } export [ protocol [ process-id ] ] By default, OSPF does not import the routes of other protocols. Optional By default, no filter policy is applied. 2-11

22 Configure the default values of the route attributes (including cost, limit, tag, and type) for the routes imported default { cost cost limit limit tag tag type type } * Optional The default route attributes are as follows: the cost value is 1, the upper limit on the maximum number of imported external routes is 1,000, the tag value is 1, and the type is type Configure to Use IS-IS between a MCE and a PE When configuring to use IS-IS between a MCE and a PE, you need to configure the IS-IS processes to be bound to VPN instances and manually import the VPN routes in the site maintained by the MCE device to the routing table of the PE. In IS-IS, routes discovered by other routing protocols are external routes. While importing routes of other protocols, you can specify the default cost value for the imported routes as well. You can also apply filter policies for imported routes. Table 2-17 Configure IS-IS to import external routes Enter system view system-view Enable IS-IS for a VPN instance and enter IS-IS view Import routes of other protocols Apply a filter policy for imported routes isis [ process-id ] [ vpn-instance vpn-instance-name ] 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 ] * filter-policy { acl-number ip-prefix ip-prefix-name route-policy route-policy-name } export [ isis process-id ospf process-id rip process-id bgp direct static ] By default, IS-IS does not import routes of other protocols. If none of the level-1, level-2, and level-3 keywords is specified, the external routes are imported to level-2 routing table. Optional By default, no filter policy is applied. 2-12

23 2.3.6 Configure to Use EBGP between a MCE and a PE To use EBGP to exchange routing information between a MCE and a PE, you need to configure the peer end as a peer in the BGP-VPNs on both ends, import VPN routes in the site to the MCE, and then advertise these routes to the PE. Table 2-18 Configure to use EBGP between a MCE and a PE Enter system view system-view Enter BGP view bgp as-number Enter BGP-VPN instance view Configure the PE as a VPN peer Import routes of the local site Apply a filter policy for routes to be advertised Apply a filter policy for received routes ipv4-family vpn-instance vpn-instance-name peer { group-name ip-address } as-number as-number import-route protocol [ process-id ] [ med med-value route-policy route-policy-name ] * filter-policy { acl-number ip-prefix ip-prefix-name } export [ direct isis process-id ospf process-id rip process-id static ] filter-policy { acl-number ip-prefix ip-prefix-name } import The MCE device must import routes of the local site to the VPN routing table in order to advertise these routes to the PE device. Optional By default, no filter policy is applied. Optional By default, no filter policy is applied. 2.4 Displaying and Maintaining MCE After the about-mentioned configuration, you can use the display command in any view to view the MCE information, so as to verify the configuration. You can also use the refresh commands to soft reset the BGP VPN connections of a VPN instance, or use the reset commands to reset the BGP connections of a VPN instance or clear the BGP information of a VPN instance. 2-13

24 Table 2-19 Display and maintain MCE Operation Display the IP routing tables associated with a VPN instance Display the information about a VPN instance Display information about a specified BGP VPNv4 peer group Display information about BGP VPNv4 routes injected into a specified VPN instance Display BGP VPNv4 AS path information Display information about BGP VPNv4 peers Display the BGP VPNv4 routing information of a specified VPN instance Perform a soft reset of the BGP connections in a specified VPN instance Reset the BGP connections of a VPN instance Clear the route flap dampening information of a VPN instance Command display ip routing-table vpn-instance vpn-instance-name [ verbose ] display ip vpn-instance [ instance-name vpn-instance-name ] display bgp vpnv4 vpn-instance vpn-instance-name group [ group-name ] display bgp vpnv4 vpn-instance vpn-instance-name network display bgp vpnv4 vpn-instance vpn-instance-name paths [as-regular-expression ] display bgp vpnv4 vpn-instance vpn-instance-name peer [ group-name log-info ip-address { log-info verbose } verbose ] display bgp vpnv4 vpn-instance vpn-instance-name routing-table [ network-address [ { mask mask-length } [ longer-prefixes ] ] as-path-acl as-path-acl-number cidr community [ aa:nn ]&<1-13>[ no-export-subconfed no-advertise no-export ]* [ whole-match ] community-list { basic-community-list-number [ whole-match ] adv-community-list-number }&<1-16> dampened dampening parameter different-origin-as flap-info [ as-path-acl as-path-acl-number network-address [ mask [ longer-match ] mask-length [ longer-match ] ] regular-expression as-regular-expression ] peer ip-address { advertised-routes received-routes } regular-expression as-regular-expression statistic ] refresh bgp vpn-instance vpn-instance-name { ip-address all external group group-name } { export import } reset bgp vpn-instance vpn-instance-name { as-number ip-address all external group group-name } reset bgp vpn-instance vpn-instance-name dampening [ network-address [ mask mask-length ] ] 2-14

25 Operation Clear route flap history information about a BGP peer of a VPN instance Command reset bgp vpn-instance vpn-instance-name ip-address flap-info reset bgp vpn-instance vpn-instance-name flap-info [ ip-address [ mask mask-length ] as-path-acl as-path-acl-number regexp as-path-regexp ] Note: The above table lists only the commands used to display VPN instance-related information is displayed. For information about the commands used to display routing protocol configuration, see relevant chapters in the IPv4 Routing module of this manual. 2.5 MCE Configuration Example MCE Configuration Example (A) I. Network requirements An MCE device connects to VPN1 (with the address range being /16) through VLAN-interface 10 (with the IP address being ) and connects to VPN2 (with the address range being /24) through VLAN-interface 20 (with the IP address being ). VPN2 has RIP enabled. It is required that the MCE device isolate routes of VPN1 from those of VPN2 and advertise all the VPN routes to the PE device using OSPF. 2-15

26 II. Network diagram Figure 2-1 Network diagram for MCE configuration (A) III. Configuration procedure For distinguish devices, assume the system name of the MCE device is MCE, the names of the egress router of VPN1 and VPN2 are VR1 and VR2, and the system name of the PE device is PE. Configure VPN instances # Configure two instances VPN1 and VPN2 on the MCE device, with the RD values of the two VPN instances being 10:1 and 20:1. Configure the VPN target values of the two VPN instances as 10:1 and 20:1 for both the import and export extended community attribute list. <MCE> system-view [MCE] ip vpn-instance vpn1 [MCE-vpn-instance-vpn1] route-distinguisher 10:1 [MCE-vpn-instance-vpn1] vpn-target 10:1 both [MCE-vpn-instance-vpn1] quit [MCE] ip vpn-instance vpn2 [MCE-vpn-instance-vpn2] route-distinguisher 20:1 [MCE-vpn-instance-vpn2] vpn-target 20:1 both # Create VLAN 10, add Ethernet 1/0/10 to VLAN 10, and create VLAN-interface 10. [MCE-vpn-instance-vpn2] quit [MCE] vlan 10 [MCE-vlan10] port Ethernet 1/0/

27 [MCE-vlan10] quit [MCE] interface Vlan-interface 10 # Bind VLAN-interface 10 to VPN1, and configure IP address /24 for VLAN-interface 10. [MCE-Vlan-interface10] ip binding vpn-instance vpn1 [MCE-Vlan-interface10] ip address # Create VLAN 20, add Ethernet 1/0/20 to VLAN 20, create VLAN-interface 20, bind VLAN-interface 20 to VPN2, and configure IP address /24 for VLAN-interface 20. [MCE-Vlan-interface10] quit [MCE] vlan 20 [MCE-vlan20] port Ethernet 1/0/20 [MCE-vlan20] quit [MCE] interface Vlan-interface 20 [MCE-Vlan-interface20] ip binding vpn-instance vpn2 [MCE-Vlan-interface20] ip address Configure the routing protocol running between MCE and a site MCE is directly connected to VPN1, which has no routing protocol enabled. You can configure to use static routes between MCE and a site. Configuration on VR1: Assume VR1 is an S3610 switch, configure IP address /24 for the interface connecting to MCE and IP address /24 for the interface connecting to VPN1. The operation of adding a port to a VLAN and configuring IP address for a VLAN-interface is omitted here. # Configure a default route on VR1, specifying the next hop address to <VR1> system-view [VR1] ip route-static # Define a static route on MCE, specify the next hop address for packets destined for the network segment , and bind this route to VPN1. [MCE-Vlan-interface10] quit [MCE] ip route-static vpn-instance vpn # Display the information about the routes of VPN1 maintained on MCE. [MCE] display ip routing-table vpn-instance vpn1 Routing Tables: vpn1 Destinations : 5 Routes : 5 Destination/Mask Proto Pre Cost NextHop Interface /8 Direct InLoop /32 Direct InLoop0 2-17

28 /24 Direct Vlan /32 Direct InLoop /16 Static Vlan10 As shown in the displayed information above, a static route has been specified for VPN1. # RIP is running within VPN2, so you can configure RIP on MCE and involve the RIP on MCE in the routing computation in the site to update the routing information automatically. Create RIP process 20 and bind it VPN2. [MCE] rip 20 vpn-instance vpn2 # Advertise the network segment [MCE-rip-20] network # On VR2, configure IP address /24 for the interface connecting to MCE (configuration procedures omitted), enable RIP and advertise the network segments and <VR2> system-view [VR2] rip 20 [VR2-rip-20] network [VR2-rip-20] network # Display the information about the routes of VPN2 on MCE. [MCE-rip-20] display ip routing-table vpn-instance vpn2 Routing Tables: vpn2 Destinations : 5 Routes : 5 Destination/Mask Proto Pre Cost NextHop Interface /8 Direct InLoop /32 Direct InLoop /24 Direct Vlan /32 Direct InLoop /24 RIP Vlan20 As shown in the displayed information above, MCE has obtained the routes of VPN2 through RIP, and maintains these routes in a routing table different from the routing table for routing information of VPN1 to the network segment , thus isolating the routes of VPN1 from the routes of VPN2. Configure the routing protocol running between the MCE and a PE # MCE uses Ethernet 1/0/3 to connect to Ethernet 1/0/18 of PE. Configure the two ports to be trunk ports and permit tagged packets of VLAN 10 and VLAN 20. [MCE-rip-20] quit [MCE] interface Ethernet 1/0/3 2-18

29 [MCE-Ethernet1/0/3] port link-type trunk [MCE-Ethernet1/0/3] port trunk permit vlan # Configure Ethernet 1/0/18 of PE. <PE> system-view [PE] interface Ethernet 1/0/18 [PE-Ethernet1/0/18] port link-type trunk [PE-Ethernet1/0/18] port trunk permit vlan # Configure IP addresses and for VLAN-interface 10 and VLAN-interface 20 of PE respectively. The configuration procedures are omitted here. # Configure Loopback0 of MCE and CE to specify the router ID for MCE and PE respectively. The IP addresses for Loopback0 of MCE and CE are and respectively. Configuration procedures are omitted here. # Create OSPF process 10 on MCE, bind the process to VPN1, and set the OSPF domain ID to 10. [MCE-Ethernet1/0/3] quit [MCE] ospf 10 router-id vpn-instance vpn1 [MCE-ospf-10] domain 10 # Advertise the network segment within Area0, and import static routes of VPN1. [MCE-ospf-10] area 0 [MCE-ospf-10-area ] network [MCE-ospf-10-area ] quit [MCE-ospf-10] import-route static # Create OSPF process 10 on PE, bind the process to VPN1, set the OSPF domain ID to 10, and advertise the network segment within Area0. [PE-Ethernet1/0/18] quit [PE] ospf 10 router-id vpn-instance vpn1 [PE-ospf-10] domain-id 10 [PE-ospf-10] area 0 [PE-ospf-10-area ] network # Display the information about the routes of VPN1 on PE. [PE-ospf-10-area ] display ip routing-table vpn-instance vpn1 Routing Tables: vpn1 Destinations : 6 Routes : 6 Destination/Mask Proto Pre Cost NextHop Interface /8 Direct InLoop /32 Direct InLoop0 2-19

30 /24 Direct Vlan /32 Direct InLoop /32 Direct InLoop /16 O_ASE Vlan10 As shown in the displayed information above, the static routes of VPN1 have been imported to the OSPF routing table between MCE and PE. Create OSPF process 20 and import the routing information of VPN2, which is similar to the above procedure. The only difference lies in that RIP routes rather than static routes are imported to the OSPF routing table of MCE. The detailed configuration procedures are omitted here. The information displayed below verifies the configuration. <PE> display ip routing-table vpn-instance vpn2 display ip routing-table vpn-instance vpn2 Routing Tables: vpn2 Destinations : 6 Routes : 6 Destination/Mask Proto Pre Cost NextHop Interface /8 Direct InLoop /32 Direct InLoop /24 Direct Vlan /32 Direct InLoop /32 Direct InLoop /24 O_ASE Vlan20 After the above configurations, the routing information of VPN1 and VPN2 can be advertised to PE properly MCE Configuration Example (B) I. Network requirements An S3610 switch functions as MCE. It is required that VPN routes of site 1 and site 2 be advertised to the PE for the purpose that VPNs at both ends of the MPLS backbone network can communicate with each other properly. OSPF runs within both site 1 and site 2, and EBGP runs between MCE and PE. 2-20

31 II. Network diagram Figure 2-2 Network diagram for MCE configuration (B) III. Configuration procedure Configure VPN instances # The procedure of creating VPN instances on MCE and binding interfaces to VPN instances is similar to that in MCE Configuration Example (A) and is omitted here. Configure the routing protocol running between MCE and a site # The procedure of enabling OSPF in the two VPN instances and advertising the network segments is the same as that in normal OSPF and is omitted. # Create OSPF process 10 for MCE, and bind OSPF process 10 to VPN instance 1 so that MCE can learn the routes of VPN1. <MCE> system-view [MCE] ospf router-id vpn-instance vpn1 [MCE-ospf-10] area 0 [MCE-ospf-10-area ] network # Display the information about the routes of VPN1. [MCE-ospf-10-area ] display ip routing-table vpn-instance vpn1 Routing Tables: vpn1 Destinations : 5 Routes : 5 Destination/Mask Proto Pre Cost NextHop Interface /8 Direct InLoop0 2-21

32 /32 Direct InLoop /24 Direct Vlan /32 Direct InLoop /24 OSPF Vlan2 As shown in the displayed information above, MCE has obtained the routing information of VPN1 through OSPF process 10. # Create OSPF process 20 and bind OSPF process 20 to VPN instance 2 so that MCE can learn the routes of VPN2. The procedure of configuring OSPF process 20 is similar to that of configuring OSPF process 10. Followed is the result of the above configuration. [MCE] display ip routing-table vpn-instance vpn2 Routing Tables: vpn2 Destinations : 5 Routes : 5 Destination/Mask Proto Pre Cost NextHop Interface /8 Direct InLoop /32 Direct InLoop /24 Direct Vlan /32 Direct InLoop /24 OSPF Vlan3 Configure the routing protocol running between MCE and PE # The procedure of connecting MCE to PE through trunk ports is similar to that in MCE Configuration Example (A) and is omitted here. # Create BGP process 10 for MCE. [MCE] bgp 100 [MCE-bgp] # Enter IPv4 address family view in VPN1. [MCE-bgp] ipv4-family vpn-instance vpn1 [MCE-bgp-vpn1] # Configure PE as an EBGP peer and import the routing information of OSPF process 10 (assuming that the address of the interface bound to VPN1 is and the ID of the BGP process is 200). [MCE-bgp-vpn1] peer as-number 200 [MCE-BGP-vpn1] import-route ospf 10 # Create BGP process 200 on the PE, and configure MCE as an EBGP peer. <PE> system-view [PE] bgp 200 [PE-bgp] ipv4-family vpn-instance vpn1 2-22