< Home

Configuring Route Exchange Between PEs and CEs

To ensure that CEs can communicate, the PEs and CEs must be capable of exchanging routes.

Context

In a BGP/MPLS IP VPN, a routing protocol or static routes must be configured between a PE and a CE to allow them to communicate and allow the CE to obtain routes to other CEs. The routing protocol can be EBGP, IBGP, static route, RIP, OSPF, or IS-IS. Choose one of the following configurations as needed:
  • Configure EBGP between a PE and a CE.
  • Configure IBGP between a PE and a CE.
  • Configure static route between a PE and a CE.
  • Configure RIP between a PE and a CE.
  • Configure OSPF between a PE and a CE.
  • Configure IS-IS between a PE and a CE.
  • Configure a direct route between a PE and a CE.
The routing protocol configurations on the CE and PE are different:
  • The CE is located at the client side. It does not know the existence of a VPN. Therefore, you do not need to configure VPN parameters when configuring a routing protocol on the CE.
  • The PE is located at the edge of the carrier's network. It connects to a CE and exchanges VPN routing information with other PEs. If the CEs that access a PE belong to different VPNs, the PE must maintain different VRF tables. When configuring a routing protocol on the PE, specify the name of the VPN instance to which the routing protocol applies and configure the routing protocol and MP-BGP to import routes from each other.

Procedure

  • Configure EBGP between a PE and a CE.

    Perform the following steps on the PE:

    1. Run:

      system-view

      The system view is displayed.

    2. Run:

      bgp { as-number-plain | as-number-dot }

      The BGP view is displayed.

    3. Run:

      ipv4-family vpn-instance vpn-instance-name

      The BGP-VPN instance IPv4 address family view is displayed.

    4. (Optional) Run:

      router-id { ipv4-address | auto-select }

      A router ID is set in a BGP VPN instance IPv4 address family.

      By configuring router ID for BGP VPN instance IPv4 address family, you can differentiate the configured router ID of BGP VPN instance IPv4 address family from the BGP router ID. For example, if two VPN instances named vrf1 and vrf2 are configured on a PE, and a BGP session needs to be established between the interfaces bound to the two VPN instances, you need to configure different router IDs for the two VPN instance IPv4 address families. If no router ID is configured for the two VPN instance IPv4 address families, no BGP session can be established because the two VPN instance IPv4 address families have the same router ID, which is consistent with the BGP router ID.

    5. (Optional) Run:

      as-number { as-number-plain | as-number-dot }

      An AS number is configured for the VPN instance IPv4 address family.

      A VPN instance uses the AS number of BGP by default.

      To smoothly re-assign a device to another AS or transmit different services in different instances, run the as-number command to configure a different AS number for each VPN instance IPv4 address family.

      The AS number configured in the BGP-VPN instance IPv4 address family view must be different from the AS number configured in the BGP view.

    6. Run:

      peer ipv4-address as-number { as-number-plain | as-number-dot }

      The CE is configured as a VPN peer.

    7. (Optional) Run:

      peer { ipv4-address | group-name } ebgp-max-hop [ hop-count ]

      The maximum number of hops between the PE and its EBGP peer (the CE) is specified. This step is mandatory if the PE and the CE are not directly connected.

      By default, a direct physical link must be available between EBGP peers. If such a link does not exist, run the peer ebgp-max-hop command to allow EBGP peers to establish a TCP connection over multiple hops.

      If hop-count is not specified in the peer ebgp-max-hop command, 255 is used as the maximum number of hops in EBGP connections.

    8. (Optional) Run the following command to enable the PE to import the direct routes destined for the local CE into the VRF table and advertise the routes to the remote PE:

      • Run:

        import-route direct [ med med | route-policy route-policy-name ]*

        The direct routes destined for the local CE are imported into the VRF table of the IPv4 VPN instance.

      • Run:

        network ipv4-address [ mask | mask-length ] [ route-policy route-policy-name ]

        The direct routes destined for the local CE are advertised to the remote PE.

        The PE can automatically learn the direct routes destined for the local CE. The learned routes take precedence over the direct routes advertised from the local CE using EBGP. If this step is not performed, the PE does not use MP-BGP to advertise the direct routes destined for the local CE to the remote PE.

    9. (Optional) Run:

      peer { group-name | ipv4-address } soo site-of-origin

      The Site-of-Origin (SoO) attribute is configured for the CE that has been specified as a VPN peer of the PE.

      Several CEs at a VPN site may establish BGP connections with different PEs. The VPN routes advertised from the CEs to the PEs may be re-advertised to the same VPN site after the routes traverse the backbone network. This may cause route loops at the VPN site.

      If the SoO attribute is configured for a specified CE, the PE adds the attribute to a route sent from the CE and advertises the route to the remote PE. The remote PE checks the SoO attribute of the route before sending it to its attached CE. If the SoO attribute is the same as the local SoO attribute on the remote PE, the remote PE does not send the route to its attached CE.

    10. (Optional) Run:

      peer ipv4-address allow-as-loop [ number ] [ global-as [ vpn-as ] ]

      Route loops are allowed.

      This step is used in Hub and Spoke networking.

      The default value of number is 1. Generally, BGP uses the AS number to detect route loops. In a Hub and Spoke network, if EBGP runs between a Hub-PE and a Hub-CE at a Hub site, the route sent from the Hub-PE to the Hub-CE carries the AS number of the Hub-PE. If the Hub-CE sends a route update message to the Hub-PE, the Hub-PE will deny it because the route update message contains the AS number of the Hub-PE. To ensure proper route transmission in a Hub and Spoke network, configure all the BGP peers along the path (along which the Hub-CE advertises VPN routes to the Spoke-CE) to accept the routes which have the AS number repeated once.

    11. (Optional) Run:

      peer ipv4-address substitute-as

      BGP AS number substitution is enabled.

      In a scenario where VPN sites in the same site or those that have different private AS numbers communicate through the BGP/MPLS IP VPN backbone network, if a CE and its connected PE in a VPN site establish an EBGP connection, VPN routes from other VPN sites may carry the AS number of this VPN site. As a result, the CE discards the VPN routes, causing a failure in VPN site communication. To prevent this situation from occurring, run the peer substitute-as command on the PE to enable the AS number substitute function.

      Enabling BGP AS number substitution may cause route loops in a CE multi-homing network.

    Perform the following steps on the CE:

    1. Access the system view.

      system-view

    2. Access the BGP view.

      bgp { as-number-plain | as-number-dot }

    3. Configure the PE as a VPN peer.

      peer ipv4-address as-number { as-number-plain | as-number-dot }

    4. (Optional) Set the maximum number of hops between the CE and its EBGP peer (the PE).

      peer { ipv4-address | group-name } ebgp-max-hop [ hop-count ]

      By default, a direct physical link must be available between EBGP peers. If such a link does not exist, run the peer ebgp-max-hop command to allow EBGP peers to establish a TCP connection over multiple hops.

      If hop-count is not specified in the peer ebgp-max-hop command, 255 is used as the maximum number of hops in EBGP connections.

    5. Import routes of the local site.

      import-route { direct | static | rip process-id | ospf process-id | isis process-id } [ med med | route-policy route-policy-name ]*

      The CE advertises the routes of its own site network segment to the connected PE. The PE forwards the routes to the remote CE. The type of route imported at this step may vary with the networking mode.

  • Configure IBGP between a PE and a CE.

    Perform the following steps on the PE:

    1. Access the system view.

      system-view

    2. Access the BGP view.

      bgp { as-number-plain | as-number-dot }

    3. Access the BGP-VPN instance IPv4 address family view.

      ipv4-family vpn-instance vpn-instance-name

    4. (Optional) Set a router ID for the BGP VPN instance IPv4 address family.

      router-id { ipv4-address | auto-select }

      By configuring router ID for the BGP VPN instance IPv4 address family, you can differentiate the configured router ID of BGP VPN instance IPv4 address family from the BGP router ID. For example, if two VPN instances named vrf1 and vrf2 are configured on a PE, and a BGP session needs to be established between the interfaces bound to the two VPN instances, you need to configure different router IDs for the two VPN instance IPv4 address families. If no router ID is configured for the two VPN instance IPv4 address families, no BGP session can be established because the two VPN instance IPv4 address families have the same router ID, which is consistent with the BGP router ID.

    5. (Optional) Set an AS number for the VPN instance IPv4 address family.

      as-number { as-number-plain | as-number-dot }

      A VPN instance uses the AS number of BGP by default.

      To smoothly re-assign a device to another AS or transmit different services in different instances, a device needs to be simulated as multiple BGP devices logically. In this case, you can run the as-number command to configure an AS number for each VPN instance IPv4 address family.

      The AS number configured in the BGP-VPN instance IPv4 address family view must be different from the AS number configured in the BGP view.

    6. Configure the CE as a VPN peer.

      peer ipv4-address as-number { as-number-plain | as-number-dot }

    7. (Optional) Enable the PE to import the direct routes destined for the local CE into the VRF table and advertise the routes to the remote PE.

      • Import the direct routes destined for the local CE into the VRF table of the IPv4 VPN instance.

        import-route direct [ med med | route-policy route-policy-name ]* 
      • Advertise the direct routes destined for the local CE to the remote PE.

        network ipv4-address [ mask | mask-length ] [ route-policy route-policy-name ]

      The PE can automatically learn the direct routes destined for the local CE. The learned routes take precedence over the direct routes advertised from the local CE using IBGP. If this step is not performed, the PE does not use MP-BGP to advertise the direct routes destined for the local CE to the remote PE.

    Perform the following steps on the CE:

    1. Access the system view.

      system-view

    2. Access the BGP view.

      bgp { as-number-plain | as-number-dot }

    3. Configure the PE as a VPN peer.

      peer ipv4-address as-number { as-number-plain | as-number-dot }

    4. Import routes of the local site.

      import-route { direct | static | rip process-id | ospf process-id | isis process-id } [ med med | route-policy route-policy-name ]*

      The CE advertises the routes of its own site network segment to the connected PE. The PE forwards the routes to the remote CE. The type of route imported at this step may vary with the networking mode.

  • Configure static route between a PE and a CE.

    Perform the following steps on the PE. Configure static route on the CE, and the CE configuration details are not provided here.

    1. Access the system view.

      system-view

    2. Configure a static route for a specified VPN instance IPv4 address family.

      ip route-static vpn-instance vpn-source-name destination-address { mask | mask-length } interface-type interface-number [ nexthop-address ] [ preference preference | tag tag ] *

    3. Access the BGP view.

      bgp { as-number-plain | as-number-dot }

    4. Access the BGP-VPN instance IPv4 address family view.

      ipv4-family vpn-instance vpn-instance-name

    5. Add the configured static route to the VRF table of the BGP-VPN instance IPv4 address family.

      import-route static [ med med | route-policy route-policy-name ]*

      A VPN that receives routes outside it from a device other than the PE and advertises the routes to the PE is called a transit VPN. A VPN that receives only routes in it and routes advertised by the PE is called a stub VPN. Generally, a static route is used for route exchange between the CE and PE in a stub VPN only.

  • Configure RIP between a PE and a CE.

    Perform the following steps on the PE. Configure RIPv1 or RIPv2 on the CE, and the CE configuration details are not provided here.

    1. Access the system view.

      system-view

    2. Create a RIP process on the PE.

      rip process-id vpn-instance vpn-instance-name

      A RIP process can be bound to only one VPN instance.

    3. Enable RIP on the network segment where the interface bound to the VPN instance resides.

      network network-address

    4. Import BGP routes into the RIP routing table.

      import-route bgp [ cost { cost | transparent } | route-policy route-policy-name ]*

      After the import-route bgp command is run in the RIP view, the PE can import the VPNv4 routes learned from the remote PE into the RIP routing table and advertise them to the attached CE.

    5. Return to the system view.

      quit

    6. Access the BGP view.

      bgp { as-number-plain | as-number-dot }

    7. Access the BGP-VPN instance IPv4 address family view.

      ipv4-family vpn-instance vpn-instance-name

    8. Import RIP routes into the VRF table of the BGP-VPN instance IPv4 address family.

      import-route rip process-id [ med med | route-policy route-policy-name ]*

      After the import-route rip command is run in the BGP-VPN instance IPv4 address family view, the PE will import the VPN routes learned from the attached CE into the BGP routing table and advertise VPNv4 routes to the remote PE.

    Deleting a VPN instance or disabling a VPN instance IPv4 address family will delete all the RIP processes bound to the VPN instance or the VPN instance IPv4 address family on the PE.

  • Configure OSPF between a PE and a CE.

    Configure OSPF on the CE, and the CE configuration details are not provided here. Perform the following steps on the PE.

    1. Access the system view.

      system-view

    2. Create an OSPF process on the PE and access the OSPF view.

      ospf process-id [ router-id router-id ] vpn-instance vpn-instance-name

      An OSPF process can be bound to only one VPN instance.

      A router ID needs to be specified when an OSPF process is started after it is bound to a VPN instance. The router ID must be different from the public network router ID configured in the system view. If the router ID is not specified, OSPF selects the IP address of one of the interfaces bound to the VPN instance as the router ID based on a certain rule.

    3. (Optional) Set the domain ID.

      domain-id domain-id [ secondary ]

      The domain ID can be an integer or in dotted decimal notation.

      Each OSPF process can be configured with two domain IDs. Different processes can have the same domain IDs. There are no restrictions on the domain IDs of the OSPF processes of different VPNs on a PE. The OSPF processes of the same VPN must be configured with the same domain ID to ensure proper route advertisement.

      The domain ID of an OSPF process is contained in the routes generated by the process. When OSPF routes are imported into BGP, the domain ID is added to the BGP VPN routes and forwarded as the BGP extended community attribute.

      The default domain ID is 0.

    4. (Optional) Configure the VPN route tag.

      route-tag tag

      In a networking where a CE is dual-homed to two PEs, PE1 generates As-external-LSAs based on the imported BGP routes and sends the LSAs to the CE, then to PE2. Because OSPF routes have higher priorities over BGP routes, the former will replace the latter on PE2, causing loops. After the route-tag command is run, if the tag value of the PE and an LSA are the same, the PE will neglect the LSA and a loop is prevented. By default, OSPF allocates a VPN route tag automatically.

      • If a BGP process is not started on the local device, the default VPN route tag is 0.

      • If a BGP process is started on the local device, the default VPN route tag is 3489660928 (0xD000 in the hexadecimal format) plus the local AS number of BGP.

    5. Import BGP routes.

      import-route bgp [ cost cost | route-policy route-policy-name | tag tag | type type ] *

    6. Access the OSPF area view.

      area area-id

    7. Enable OSPF on the network segment where the interface bound to the VPN instance resides.

      network ip-address wildcard-mask

      A network segment belongs to only one area. The area to which each OSPF interface belongs must be specified.

      OSPF can run on an interface properly only when the following conditions are met:

      • The mask length of the IP address of the interface is longer than or equal to that specified by the network command.

      • The primary IP address of the interface is on the network segment specified by the network command.

      By default, OSPF advertises a route destined for the 32-bit address of the loopback interface irrespective of the mask length configured on the interface.

    8. Access the OSPF view.

      quit

    9. Return to the system view.

      quit

    10. Access the BGP view.

      bgp { as-number-plain | as-number-dot }

    11. Access the BGP-VPN instance IPv4 address family view.

      ipv4-family vpn-instance vpn-instance-name

    12. Import OSPF routes into the VRF table of the BGP-VPN instance IPv4 address family.

      import-route ospf process-id [ med med | route-policy route-policy-name ] *

    Deleting a VPN instance or disabling a VPN instance IPv4 address family will delete all the OSPF processes bound to the VPN instance or the VPN instance IPv4 address family on the PE.

  • Configure IS-IS between a PE and a CE.

    Configure IS-IS on the CE, and the CE configuration details are not provided here. Perform the following steps on the PE.

    1. Access the system view.

      system-view

    2. Create an IS-IS process on the PE and access the IS-IS view.

      isis process-id vpn-instance vpn-instance-name

      An IS-IS process can be bound to only one VPN instance.

    3. Configure the network entity title (NET).

      network-entity net

      A NET specifies the current IS-IS area address and the system ID of the router. An IS-IS process on one router can be configured with a maximum of three NETs.

    4. (Optional) Specify the IS-IS level of the router.

      is-level { level-1 | level-1-2 | level-2 }

      Configure the device level based on the network planning. If no device level is configured, IS-IS establishes separate neighbor relationships for Level-1 and Level-2 devices and maintains two identical LSDBs, consuming excessive system resources. By default, the IS-IS level of the router is Level-1-2.

    5. Import BGP routes.

      import-route bgp [ cost-type { external | internal } | cost cost | tag tag | route-policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ] *

      If the IS-IS level is not specified in the command, BGP routes will be imported into the Level-2 IS-IS routing table.

    6. Return to the system view.

      quit

    7. Access the view of the interface bound to the VPN instance.

      interface interface-type interface-number

    8. Enable IS-IS on the interface.

      isis enable [ process-id ]

    9. Return to the system view.

      quit

    10. Access the BGP view.

      bgp { as-number-plain | as-number-dot }

    11. Access the BGP-VPN instance IPv4 address family view.

      ipv4-family vpn-instance vpn-instance-name

    12. Import IS-IS routes into the VRF table of the BGP-VPN instance IPv4 address family.

      import-route isis process-id [ med med | route-policy route-policy-name ] *

    Deleting a VPN instance or disabling a VPN instance IPv4 address family will delete all the IS-IS processes bound to the VPN instance or the VPN instance IPv4 address family on the PE.

  • Configure a direct route between a PE and a CE.

    A direct route can be configured between a PE and a CE only if the CE is a host and connected to the PE using a VLANIF interface. Note that the direct route only needs to be configured on the PE.

    Perform the following steps on the PE:

    1. Access the system view.

      system-view

    2. Access the VPN instance view.

      ip vpn-instance vpn-instance-name

    3. Access the VPN instance IPv4 address family view.

      ipv4-family

    4. Advertise ARP Vlink direct routes.

      arp vlink-direct-route advertise [ route-policy route-policy-name ]

      By default, ARP Vlink direct routes cannot be advertised.

      After the parameter route-policy route-policy-name is specified in the arp vlink-direct-route advertise command, only filtered ARP Vlink direct routes are advertised.

    5. Return to the VPN instance view.

      quit

    6. Return to the system view.

      quit

    7. Access the BGP view.

      bgp { as-number-plain | as-number-dot }

    8. Access the BGP-VPN instance IPv4 address family view.

      ipv4-family vpn-instance vpn-instance-name

    9. Import the direct route to the local CE.

      import-route direct [ med med | route-policy route-policy-name ]*

      After the direct route to the local CE is imported to the VPN routing table, the local PE use MP-BGP to advertise the direct route to the remote PE. This allows the remote CE to access the local CE.

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic