| Oracle® Communications IP Service Activator Juniper M-series Device Support Guide Release 7.2 E47718-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Juniper M-series Device Support Guide Release 7.2 E47718-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how Oracle Communications IP Service Activator configures MPLS VPNs on Juniper M-series devices.
The Juniper M-series Device Driver configures the PE routers that define the membership of a VPN. The information set up on each PE router defines the VPNs to which connected sites belong and the routes to and from these sites that are to be distributed throughout the VPN.
IP Service Activator does not configure the CE routers or the provider core routers.
Before setting up VPNs you should ensure that:
All routers are appropriately configured. See "Preconfiguring Routers".
Domain-level parameters are appropriately set. See "Setting Domain-level Parameters".
All routers and their interfaces within the VPN are correctly assigned roles. See "Assigning Roles".
Some preconfiguration of PE and P routers is required. For example, MPLS must be enabled. For full details of the preconfiguration required, see "Manual Preconfiguration".
A number of BGP parameters may be set up at domain level on the VPN BGP, ASN and VPN MPLS property pages of the Domain dialog box:
Specify whether you want IP Service Activator to set up iBGP peering on the PE devices. See "Co-existence with Previously Configured iBGP".
The default is for IP Service Activator not to configure iBGP peering. If you leave this setting off, iBGP peering must already be configured correctly on your devices.
If Route Reflectors are used, iBGP peering must be deselected.
If IP Service Activator is to manage multi-AS VPNs, iBGP and eBGP peering must be configured on devices and IP Service Activator's configure iBGP peering capability must remain deselected. See "Manually Preconfigured BGP Peering".
On the ASN property page of the Domain dialog box, set the ASN for the domain.
If there is no ASN already configured on the device, IP Service Activator configures the device with the ASN specified in the client. If an ASN is already configured on the device, IP Service Activator ignores the ASN specified in the client and uses the one found in the configuration instead. This enables IP Service Activator to support multi-AS VPNs.
Choose whether you will enable Allow AS in which allows PE devices to re-advertise route prefixes containing one or more instances of the same ASN in the AS_PATH attribute. Specify the maximum number of instances allowed for an incoming prefix to be permitted by the PE device. The PE device denies incoming prefixes having more than the number of instances specified. See "Allow AS In".
Specify whether a global ASN applies to sites within VPNs, or whether the ASN is set at site. If a global ASN applies, you can also enable AS Override which allows PE devices receiving route prefixes from the core, whose AS_PATH attributes have ASNs matching the ASN of their neighboring CEs, to substitute those ASN instances with the ASN of the service provider network. Prefixes with the substituted ASNs are then re-advertised to neighboring CEs. This is enabled by default. For more information, see "AS Override".
Choose whether you will enable load-balancing between eBGP peers by setting a value for Maximum Paths. This controls the number of alternative routes to a given prefix that are maintained in a device's routing table. By default, this option is disabled and no alternatives are held. To enable load-balancing, you specify the number of routes that are maintained. The global setting can be overridden by a site-specific value on the Site dialog box. For more information, see "eBGP Load Sharing".
Choose whether the identity of iBGP peers and the integrity of data exchanged during iBGP sessions will be verified using MD5 Authentication. See "Configuring MD5 Authentication".
Note:
The Send Communities and the Loopback ID options (selected on the VPN BGP property page of the Domain dialog box) are not valid on Juniper M-series devices. If any of these values are set, they are ignored.For more information, see IP Service Activator VPN User's Guide.
In an MPLS domain, the core provider network is assumed to use public addresses. All CE routers are assumed to use private addresses. An IP address or DNS name must be specified in order to discover all devices in the domain.
All devices within the network must be assigned the correct system-defined roles (that is, PE routers must be classified as Gateway devices, P routers as Core devices and CE routers as Access devices). Interfaces to be configured must also be assigned the correct roles. You can assign user-defined roles as well as the system-defined roles.
Do not use role assignment rules. You must assign a role manually for each device. For more information, see the discussions of roles of routers and policy roles in IP Service Activator User's Guide.
Note:
Role assignment rules do not function correctly for gigabitEthernet interfaces on Juniper devices. These interfaces are discovered with the media type ethernet-csmacd(6) rather than gigabitEthernet(117).To work around this problem, use the media type ethernet-csmacd(6) when creating role assignment rules for gigabitEthernet interfaces. Note that this impacts the media type granularity of the role assignment rules.
Juniper devices maintain the following routing tables that relate to VPN configuration:
bgp.l3vpn.0 stores VPN-IPv4 unicast routes received from other PE routers through iBGP. This is where a route received from another PE router is initially placed and resolved using the inet.3 routing table.
routing-instance.inet.0 is the VRF table. It holds routing information for one or more access interfaces associated with a VPN. See "About VRF Tables".
inet.3 stores MPLS routes learned from LDP and RSVP signaling for VPN traffic. It is used by the PE device to resolve routes received from PE peers in VPN-IPv4 format. For VPN routes to be resolved properly, this table must contain routes to all the PE routers in the VPN.
inet.0 is the global routing table. It stores IPv4 routes learned by BGP sessions between peer devices.
mpls.0 is the MPLS path routing table, maintained by MPLS. It contains a list of the next label-switched router in each LSP and is used on transit routers to switch packets to the next router along an LSP.
For each interface that participates in a VPN, the PE device stores associated VPN routing information in a VRF table. The table stores:
All unicast IPv4 routes received from directly-connected CE devices.
All explicitly configured static routes.
Routes learned from PE peers that match the VRF table's import policy.
Every VRF table has an import and an export policy associated with it that specifies which routes are imported into and exported from the table as follows:
Routes learned through iBGP from other PE peers are imported into the VRF table (from the bgp.l3vpn.0 table) if the route matches the VRF import policy.
Routes learned from directly-connected CE devices are stored in the VRF table and exported into BGP for distribution to other PE devices if they pass the VRF export policy. On export, the PE device tags a route with one or more route targets. For information on route targets, see "VPN Topology and Route Targets".
You also have the option of applying a user-defined export map to the export policy configured by IP Service Activator. See "About Previously Defined Export Maps".
The VRF table is defined at the edit routing-instances level as follows:
vrf-table-name { instance-type vrf; interface logical-interface-name; route-distinguisher RD-number; vrf-import import-policy; vrf-export export-policy; protocols { protocol-configuration } }
where vrf-table-name is an identifier for the VRF table, logical-interface-name is the name of the logical interface, RD-number is the route distinguisher, import-policy is the name of the import policy to be applied to routes received from PE peers through iBGP, export-policy is the name of the export policy to be applied to routes exported into BGP, and protocol-configuration is the protocol configuration details (RIP, OSPF, or eBGP).
Note:
If static routes are selected for PE-CE connectivity or if IP Service Activator has configured rib groups, an additional routing-options clause is included within the VRF definition. For more information, see "PE-CE Communication Using Static Routes" and "Exporting Routes Between Routing Instances in Overlapping VPNs".By default, IP Service Activator generates VRF table names of the form Orch_RD-number. However, you can define specific names for VRF tables on selected interfaces if you do not want to use the system-calculated ones. You must ensure that the name you enter does not match any user-defined VRF tables that may exist on the device if you want those VRF tables to be preserved. (See "Co-existence with Previously Configured iBGP").
If a user-defined VRF table name begins with a digit, IP Service Activator prepends a _ character to the name.
By default, IP Service Activator automatically generates a specific VRF table name for each interface that participates in a VPN. However, if you wish to apply the same RD number to all interfaces that participate in the VPN, the same VRF name will also apply (auto-generated or user-defined). See "Setting RD Number per VPN".
Note:
Do not modify VRF parameters of an unmanaged device. This is not supported by IP Service Activator.IP Service Activator may get out of sync with a device if VRF parameters are changed while a device is unmanaged, and the device is then managed. In this case, the device may not have correct VRF configuration.
If this happens, manually remove the incorrect VRF configuration from the device.
IP Service Activator supports the vrf-table-label configuration keyword on Juniper equipment. On an MPLS VPN, this feature causes the inner (VPN) label of a packet to be popped off as the packet arrives at a VRF so that it can be processed based on the contents of its IP header. Without this feature, incoming packets are mapped directly onto an outgoing (CE-facing) interface based on the inner VPN label.
Support for the Juniper vrf-table-label setting is configured in two places: for the VPN itself (on the VPN dialog box, VRF property page) and for the site (on the Site dialog box, on the VRF property page).
On the VPN dialog, VRF property page:
To enable vrf-table-label support, check the VRF label option.
To clear vrf-table-label support, clear the VRF label option.
On the Site dialog box, VRF property page:
To enable vrf-table-label support, check the VRF label option.
To clear vrf-table-label support, clear the VRF label option.
Customer networks typically use private addresses. Overlap between customer addresses may occur when they connect to the public Internet or to the provider's NOC. To avoid this problem, iBGP prefixes a site identifier, known as a route distinguisher or RD number, to each route associated with a particular site. This ensures that VPN routes are unique within the Internet.
The new route is part of the VPN-IPv4 address family: a BGP address family added as an extension to the BGP protocol.
The RD number consists of two integers separated by a colon. It can be in either of the following formats:
32-bit IP address:16-bit number
16-bit ASN number:32-bit number
IP Service Activator normally generates RD numbers automatically, using the ASN for the high-order number and the unique system ID of the Site object for the low-order number. For example, 1:3125
However, you can override these defaults and specify your own RD numbers if you wish.
To specify your own RD numbers:
At the [edit routing-instances vrf-table-name] level, enter the following command:
route-distinguisher high-order;low-order
Note:
IP Service Activator checks that system-generated RD numbers are unique but no check for uniqueness is made on user-defined RD numbers.The interface description of a VPN Site, entered in the Site Properties - Addressing dialog, is enabled as the interface description only if the -OverwriteInterfaceDescription parameter is present on the JDD command line. For more information on this parameter see "Command-line Parameters".
By default, IP Service Activator automatically generates a site-specific VRF table name and RD number for each site that participates in a VPN.
However, you can override the IP Service Activator default by specifying at the VPN level that the same VRF table name and RD number is applied to all sites that participate in the VPN. You can choose whether to use IP Service Activator-generated values or specify your own VRF table name and RD number.
On the IP Service Activator client, these settings are is specified on the VRF page of the VPN property dialog box.
In addition, you can override the name generation rules so that if a site is part of only one VPN, the VRF table name and RD are derived from the VPN. If a site is part of multiple VPNs, the VRF table name and RD are derived from the site.
If a single RD number or VRF table name is set per VPN, the settings for VRF re-use and reduction must also be set at VPN level. See "About VRF Re-use and Reduction".
Note:
Using a single RD number for all sites in a VPN is suitable only where a site belongs to one intranet VPN. If the site may become a member of an extranet VPN in the future, Oracle does not recommend this method.The connectivity of the VPN can be one of the following:
Mesh: all sites have connectivity to all other sites
Hub and Spoke: one or more hub sites has access to all other sites; spoke sites can access the hub only
Management: works in the same way as hub and spoke, but is used when setting up QoS to ensure connectivity to CE devices
When setting up a VPN, you have to set its connectivity, and for a hub and spoke or management VPN, select the hub site(s).
To create a fully-meshed VPN, each site's VRF table imports and exports the same routes. In a hub and spoke or management VPN the VRF table at the hub site imports routes from all other hub sites and all spoke sites, and exports routes to other hub sites and to the spoke sites. VRF tables at spoke sites export routes only to the hub site and import routes only from the hub site.
A route target (RT) identifies a set of sites within a VPN to which a PE device distributes routes.
Route targets are used to create the VPN topology. Each VPN must have a unique route target number. The RT is implemented as a BGP extended community. A BGP community groups a set of destinations that share a common property. In this case the property is a set of routes that are to be distributed to a set of CE sites. The RT is added to the route by the ingress PE device and used by the egress PE device to determine whether a received route is destined for a VPN that the PE services.
IP Service Activator creates one or more BGP communities per VPN, depending on the VPN topology:
If the VPN is fully-meshed, IP Service Activator creates one community. Every site receives routing information from all other sites.
If the VPN is a hub and spoke or management VPN, IP Service Activator creates two communities. There are effectively two sets of devices: one set of hub site(s) and one set of spoke sites. By default, routes from the spoke sites are only distributed to the hub site(s), routes from the hub site(s) are distributed to all spoke sites and any other hub sites.
The RT number consists of two integers separated by a colon. It can be in one of two alternative formats:
32-bit IP address:16-bit number
16-bit ASN number:32-bit number
IP Service Activator normally generates RT numbers automatically, using the ASN for the high order number and the unique system ID of the VPN for the low order number. For example, 20:4926.
In a hub and spoke VPN topology, IP Service Activator generates two RT numbers: one for the hub site(s), generated as indicated above, and one for all spoke sites, generated by incrementing the hub low order number by one.
If you wish, you can specify your own RT numbers for hub, spoke, or fully-meshed sites within a VPN if you do not want to use the system-generated default values. You can easily reassign RT numbers to sites within a VPN, if for example, it has been imported from a different system or it is to be exported to a different system.
You can specify any number of RT values per VPN and specify whether a value is used for VRF import, VRF export, or neither, for hub, spoke and fully-meshed behaviors. On the client, these settings are on the MPLS property page of the VPN dialog box.
Note:
IP Service Activator checks that system-generated RT numbers are unique but no check for uniqueness is made on user-defined RT numbers.The community is configured at the [edit groups orchestream policy-options] level as follows:
community community-name members target:route-target-value;
where community-name is an identifier for the community and route-target-value identifies the route target in the format AS-no or IPAddress:ID. AS-no is the domain AS number and ID is an identifier based on the site's object ID number within IP Service Activator.
By default, in a hub and spoke VPN, hub sites are members of community _0 and _1, and spoke sites are members of community _1, as follows:
community VPN-name_0 members target:route-target-value community VPN-name_1 members target:route-target-value
For each new user-defined route target, IP Service Activator allocates a community value that is incremented by one, for example, if another route target is added to a VPN with the above route targets, it will be allocated to community _2.
A community is referenced within the policy statement for each VRF table's import and export policy.
The VRF import and export policies define which routes are imported into and exported from the VRF table.
For information on the PE-CE export policy, see "Route Redistribution".
The VRF export policy specifies whether a route received from a directly-connected CE device is advertised by the PE device to other peer PE devices. There is one export policy per VRF table.
Routes received by the PE device from a directly-connected CE device are placed in the VRF table. The device checks the received route against the VRF export policy for that interface. The policy consists of three terms:
The first term specifies the community to be added to the route on export.
The second term specifies from which protocol routes must be received for the policy to be applied.
If the VRF table belongs to an interface whose VPN membership overlaps with that of another interface on the PE device, an extra interface clause is defined in the term. For more information, see "Exporting Routes Between Routing Instances in Overlapping VPNs".
The final term rejects any routes that do not meet the protocol criteria.
If a route passes the VRF export policy criteria:
A route target is added to the route – several route targets may be added if an interface is associated with multiple VPNs.
The route is converted to VPN-IPv4 format.
The route is advertised through iBGP to peer PE devices within the VPN.
By default, the VRF export policy for hub sites specifies community_0, and for spoke sites, community_1.
IP Service Activator names the VRF export policy in the following format:
Orch_RD-number-export-to-PEs
where RD-number is the route distinguisher associated with a site.
If users have specified metrics for route redistribution from the PE to CE protocol into BGP, a policy statement is configured and referenced in the VRF export policy. For more information, see "Exporting Routes Between Routing Instances in Overlapping VPNs". It is also possible to manually pre-configure a policy statement to apply to redistributed routes. For more information, see "About Predefined Filtering Policies for Route Redistribution".
The VRF export policy is applied to a VRF by the vrf-export statement. For information, see "About VRF Tables".
The VRF export policy is configured at the [edit groups orchestream policy-options] level as follows:
policy-statement vrf-export-policy-name { term add_communities { then { community add export-community-name; } } term export { from { protocol [ protocol-list ]; } then accept; } term reject-others { then reject; } }
where vrf-export-policy is the identifier for the VRF export policy definition (Orch_RD-number-export-to-PEs), export-community-name is the community name (route target) to be added to the exported routes, and protocol-list is the list of protocols used for PE to CE connectivity within a VPN.
If an interface is associated with multiple VPNs, a community add statement is defined for each VPN. For example:
term add_communities {
then {
community add France;
community add Europe;
}
}
where France and Europe are VPN names.
The import policy defines whether a route advertised by a peer PE device is imported into a VRF table. There is one VRF import policy per VRF table.
The policy consists of two terms:
The first term accepts routes received via iBGP from other PE devices that are tagged with the specified route targets
The second term rejects any routes that are not accepted by the first term
If a route passes the import criteria, it is added to the VRF table.
By default, the VRF import policy for hub sites specifies community_0 community_1, and for spoke sites, community_1.
IP Service Activator names the VRF import policy in the following format:
Orch_RD-number-import-from-PEs
where RD-number is the route distinguisher associated with a site. For information about route distinguishers, see "Exporting Routes Between Routing Instances in Overlapping VPNs".
The VRF import policy is referenced at the [edit routing-instances vrf-table-name protocols] level and configured at the [edit groups orchestream policy-options] level as follows:
policy-statement vrf-import-policy-name { term import { from { protocol bgp; community [ community-list ]; } then accept; } term reject-others { then reject; } }
where vrf-import-policy-name is the identifier for the VRF import policy definition (Orch_RD-no-import-from-PEs) and community-list is a list of one or more communities, depending on how many VPNs the interface is associated with.
Starting with IP Service Activator version 4.2, the JUNOS auto-export command is used by default to implement policy-based export of routes between routing instances in overlapping MPLS VPNs. This greatly simplifies the device configuration required to set up overlapping VPNs.
If you want to override the use of the auto-export command and continue to use RIB groups, use the -UseRIBGroup command line parameter. See "Exporting Routes Between Routing Instances in Overlapping MPLS VPNs".
The auto-export command comes into play when:
Two or more PE interfaces are associated with some, but not all, of the same VPNs.
Two or more PE interfaces are associated with the same VPNs, but at least one interface has been given ownership of its VRF table to prevent VRF re-use optimization being performed by IP Service Activator. For more information, see "About VRF Tables" and "About VRF Re-use and Reduction".
In these instances, routing information is not exchanged by iBGP, as the exchange is between VRF tables located on the same PE device. Auto-export enables routing information to be exchanged between VRF tables that are located on the same PE device.
For more information, see "PE-CE Communication Using eBGP".
A VRF table is set up on the device for each PE interface that is a member of a VPN. However, by default, if multiple VRF tables contain exactly the same routes (for example, if one site connects to two interfaces, or there are two sites that are members of the same VPN) IP Service Activator normally reduces them to just one, in order to minimize resource usage. This is known as VRF re-use.
In some cases automatic VRF re-use may not be required. For example, you may want to provision dual links to customer sites in order to implement load balancing, requiring a separate VRF table for each connecting interface, or to reduce the impact of future reconfiguration. In this case you can override VRF re-use by specifying that particular interfaces are always to have their own VRF table, and by specifying that other VRF tables are allowed to be merged with this VRF table by selecting the Shareable option.
On the client, you can select the Force Install and Shareable options per interface on the VRF property page of the Site dialog box.
If you are setting up a single VRF table name or RD number per VPN, settings for VRF re-use are made at the VPN level. In this case it is not possible to select Force Install. See "Setting RD Number per VPN".
Note:
Specifying a user-defined VRF table name affects how IP Service Activator performs VRF reduction. Where system-defined VRF table names are used, VRF reduction is based on the site's RD number and a site with a lower RD number takes precedence over a site with a higher RD number. Where user-defined VRF table names are used, IP Service Activator performs VRF reduction based on table namesFor complete details on VRF re-use and reduction, see IP Service Activator VPN User's Guide.
The Export map name option allows you to specify the name of a manually pre-configured export policy to be applied to routes exported to PE peers. The policy is associated with the VRF table for the selected interface. The user-defined export policy is referenced in the VRF table's export policy. This allows greater flexibility for determining which routes are exported. You can assign the same user-defined export policy to several VRFs.
For information on setting up an export map, see "About Predefined Export Maps".
In order to exchange information throughout the VPN, each PE router needs to run an iBGP session with each other PE router connected to a site within the same VPN.
You must configure this manually.
iBGP is the protocol used for communication of VPN routes between PE devices in an MPLS VPN. In order for devices to exchange routing information, an iBGP session must be configured between the PE devices that comprise the VPN.
iBGP peering should be manually configured. When the Configure IBGP Peering option at the domain level is deselected on the IP Service Activator client the configuration will not be touched.
Note:
Do not use IP Service Activator to configure iBGP.The identity of iBGP peers and the integrity of data exchanged during iBGP sessions is verified using MD5 authentication, a digital signature algorithm. Users specify a key of up to 255 characters to generate a checksum of the iBGP data that is to be sent from a PE device to its peer. The iBGP data and its checksum are then sent to the peer device using TCP. The recipient device uses MD5 and the same key used by the sender to generate a checksum of the received iBGP data. If both checksums match, the identity of the sender and the integrity of the received iBGP data is verified.
On the IP Service Activator client, this is controlled by the domain-level parameter MD5 Authentication. If this option is selected, IP Service Activator configures an MD5 authentication key on each iBGP peer.
IP Service Activator configures the MD5 authentication key at the [edit protocols bgp group group-name neighbor address] level as follows:
authentication-key key;
where key is the authentication password. The password can be up to 255 characters and can comprise any ASCII strings.
IP Service Activator configures MPLS on logical interfaces associated with a VPN.
MPLS is enabled on an interface at the [edit interfaces] level and the [edit protocols] level:
The following configuration is added to the PE device:
interfaces {
vpn-access-interface {
unit unit-number {
family mpls;
}
}
}
protocols {
mpls {
interface logical-interface-name;
}
}
where vpn-access-interface is the name of the logical interface's parent interface, unit-number is the number of the logical interface, and logical-interface-name is the name of the logical interface.
If the IP address specified for an interface through IP Service Activator differs from the currently-configured values on the device, IP Service Activator changes the address within the main configuration. Note that the change is commented:
interfaces {
vpn-access-interface {
unit unit-number {
family inet {
/* Orchestream has changed this address */
address public-or-private-ip-address;
}
}
}
}
This change is made in the main configuration because any interface addresses defined in the orchestream group are merged with those in the main configuration.
This section describes the different ways in which PE-CE communication can be configured.
In order to exchange information to and from customer sites in the VPN, each PE router also needs to communicate with each of its external neighbors (the CE routers to which it is connected).
The effect is to advertise network reachability information between the CE and the PE, which in turn converts IPv4 addresses to VPN-IPv4 addresses for traffic passing from the CE to the PE and vice versa.
The details here explain the configuration of the PE routers using eBGP. The corresponding configuration of the CE routers is not performed by IP Service Activator. See "Manually Configuring CE Routers".
As well as eBGP, IP Service Activator supports RIP and OSPF routing protocols. Static routes can also be defined (either alone or in conjunction with another protocol).
If you use eBGP, specify:
The ASN of the site
The IP address of the corresponding interface on the CE router
You can optionally specify:
The number of times the same ASN can appear in an incoming prefix for it to be accepted by the site PE or all PEs in the domain
AS Override for the site
Authentication for a PE-CE session
eBGP is configured at the [edit routing-instances vrf-table-name protocols] level as follows:
bgp {
group EBGP-to-CEs {
type external;
export CE-export-policy;
local-as local-AS-number;
neighbor CE-address {
description "EBGP to site: site-name";
local-address VPN-interface-address;
peer-as AS-no;
}
}
where CE-export-policy is the name of the export policy to be applied to routes being exported into BGP, local-AS-number is the local AS number, CE-address is the IP address of a CE peer, site-name is the name of the site as defined in the client, VPN-interface-address is the address of the access interface on the gateway device that is used to accept the incoming connections to the PE device and to establish connections to the CE device, and AS-no is the AS number of the site.
The following sections describe options which can be defined within the neighbor definition.
If eBGP is selected as the routing protocol, IP Service Activator creates a BGP group named EBGP-to-CEs which contains:
The type external directive – specifies that all peers are in an external BGP group, that is, they are in different Autonomous Systems
The PE-CE export policy
The local AS number
A neighbor statement for each of the CE devices with which the PE device communicates. Each neighbor statement specifies:
The address of the local end of the BGP session
The peer system's AS number
Some topologies require the core network AS number to occur several times in the AS_PATH attribute of a route prefix advertised to the PE device. For example, if two CE devices are connected to each other by BGP, and each belongs to a different VPN, routes advertised by the PE to one of the CEs are also advertised to its CE neighbor who advertises the routes back to the core network. This means that the PE receives routes that have its AS number. Normally, this indicates that a routing loop has occurred, and the PE denies these routes. However, to allow VPN configurations to work, the PEs have to accept these routes.
The maximum number of times the same ASN is allowed in an incoming route for it to be accepted by the PE device is enabled using the loops option when configuring the ASN at the [edit routing-instances vrf-table-name routing-options] level as follows:
autonomous-system AS-no loops loops-no;
The value of loops-no can be from 1 to 10 inclusive; the default is 0 (unconfigured).
The loops option applies to the entire VRF table and therefore to all the neighbor PE devices that the VRF connects to. This may cause undesirable behavior if VRF tables using iBGP which have different loop values are allowed to merge. A condition has been added to IP Service Activator's VRF table reduction logic to prevent this.
Because of a JUNOS restriction, when setting the AS number, the same value must be used for the loops parameter of all sites in the VPN rather than independently per BGP neighbor. Ensure that the same value is set in IP Service Activator, or set values globally per device outside IP Service Activator. On the client, this is set on the Allow AS in: Use parameter on the EBGP page of the Site dialog box.
Because of a JUNOS restriction, only the values 0 and 1 are accepted for Allow AS in. On the Juniper device, Allow AS in configures the autonomous-system loop attribute at the routing-instance routing-options CLI level.
You can specify that the ASN of a provider is used to override the ASN of a site. When AS override is turned on, a PE device that receives route prefixes whose AS_PATH attributes have one or more ASNs matching the ASN of its neighboring CE devices, substitute those ASN instances with the ASN of the service provider network. Prefixes with the substituted ASNs are then re-advertised to neighboring CE devices. The PE device also adds its ASN to routes before exporting them to the CE device.
This allows CE devices to accept routes that have been re-advertised by devices having the same ASN, and which would otherwise be rejected. Normally, a CE device rejects routes whose AS_PATH attribute contains ASNs matching its own ASN, to prevent routing loops.
Within IP Service Activator, AS override can be specified at domain level, to apply to all sites, or set up for individual sites.
If this option is selected, the following command is configured:
as-override;
Where multiple PE interfaces are associated with a site, the local preference for an interface can be set. The preference value may be between 1-4294967295, and the higher the value the higher the priority. The default is Router Default (100). Local preference is configured by means of a route map, which can include other conditions.
In the IP Service Activator client, the local preferences parameter is set on the EBGP page of the Site dialog box.
If this option is selected, the following command is configured:
local-preference value;
where value is in the range 0 to 4 294 967 295.
The identity of eBGP peers and the integrity of data exchanged during eBGP sessions can be verified using Authentication. If this option is selected, the following command is configured:
authentication-key "private-key";
You can configure a route list filter which filters incoming (CE-PE) and or outgoing (PE-CE) routes. The route list filter must be manually configured on the device as a policy-statement. Alternatively, you can specify an import or an export policy-statement which specifies a prefix list for filtering either incoming (CE-PE) or outgoing (PE-CE) routes. The prefix list must be manually configured on the device. The policy-statement and the specified prefix list must both exist on the device before the policy-statement can be implemented by IP Service Activator.
You apply a route list filter or a prefix list filter to a site by entering the name of its policy-statement in the Prefix filters In or Out fields on the Site properties, EBGP Advanced page:
import policy-statement policy-name; export policy-statement policy-name;
where policy-name is the policy-statement defining the routing policy using a predefined prefix-list.
If you add the policy statement to the device after it is provisioned by IP Service Activator, you must either manually add the appropriate import and/or export policy statement(s) to the relevant group in the IP Service Activator configuration, or allow IP Service Activator to re-propagate the configuration to the device.
For information about configuring a route list filter, see "Configuring a Route List Filter". For more information about configuring a prefix list filter, see "Configuring a Prefix List Filter".
You can specify the maximum number of eBGP IP address prefixes that the PE device is allowed to receive from a CE device. You can also allow a warning message to be generated in the device log either when the prefix limit is reached or when a percentage of the prefix limit value is reached. The maximum value you can specify is 4 294 967 296:
family inet {
unicast {
prefix-limit {
maximum prefix-limit-value;
teardown percentage-value;
where prefix-limit-value specifies the maximum allowed number of prefixes and percentage-value specifies that a device log warning message is generated at a percentage of prefix-limit-value.
If a warning only is specified, the teardown percentage-value line does not appear
If a site is multi-homed, that is, there are multiple links to a site, it is possible for routing loops (when routes learned from a site are advertised back to that site) to occur.
To prevent routing loops, when using eBGP, IP Service Activator automatically configures Site of Origin (SOO) as follows:
An additional BGP extended community is applied to routes learned from the CE device and imported into the relevant interface's VRF table.
An additional import policy is defined to tag routes with the BGP extended community.
An additional export policy is defined that rejects routes tagged with the BGP extended community. This prevents the route being advertised back to the CE device from which it originated.
AS override is configured by default so that the site's AS number is substituted with the AS number of the service provider. This ensures that routes are not rejected by sites that share the same AS number. However, AS override can be disabled if required. For more information, see "AS Override".
The Site of Origin is defined as follows:
origin:SOO;
where SOO is an extended community comprising the site's ASN and internal object ID number.
IP Service Activator uses the following naming conventions:
For the Import policy: Orch-site-name-add-SOO
For the Export policy: Orch-site-name-deny-SOO
The following configuration is added at the [edit groups orchestream policy-options] level:
policy-statement SOO-import-policy { then { community add SOO-community-name; } policy-statement SOO-export-policy { from community SOO-community-name; then reject; } community SOO-community-name members SOO-community-value; }
where SOO-import-policy is the name of the routing policy that is to be applied to routes being imported into the interface's VRF routing table from BGP, SOO-community-name is the community name (Orch-Site-name-SOO), SOO-export-policy is the name of the routing policy that is to be applied to routes being exported from the interface's RF routing table, and SOO-community-value is the community definition.
The import and export policies are referenced within the eBGP protocol configuration, at the [edit routing-instances vrf-table-name protocols bgp group neighbor] level:
import SOO-import-policy; export [ SOO-export-policy CE-export-policy ];
The CE export policy is repeated at this level as the export statement defined at the neighbor level overrides the group level export statement.
AS override is configured at the [edit routing-instances <vrf-table-name> protocols bgp group neighbor] level for relevant sites:
as-override;
You can enable load-balancing between eBGP peers. This allows BGP to select more than one eBGP path to a given prefix over which traffic can be shared. Routes for each path are maintained in a PE device's routing table. By default, this option is disabled and no alternative routes are held.
In the IP Service Activator client, the eBGP maximum paths parameter is set at global level on the VPN BGP page of the Domain dialog box and overridden for specific devices by a setting on the EBGP Adv. page of the Site dialog box.
JUNOS does not apply the Maximum Paths value, it only enables multiple paths to be configured and maintained if a value greater than 1 is specified.
Load-balancing is configured at the [edit routing-instances routing-instance-name protocols bgp group group-name] hierarchy level by the statement:
multipath;
Route dampening is a mechanism that attempts to minimize network instability by suppressing the advertisement of poorly-behaved routes. Penalties are applied when a route is withdrawn, readvertised or changed. When a predefined penalty limit is reached, further advertisement of the route is suppressed. The penalty is reduced according to a defined half-life setting, and once the penalty decreases below a limit, the route can be readvertised.
On the IP Service Activator client, route dampening is set up on the EBGP Damp. property page of the Site dialog box.
If this option is selected, the following commands are configured at the [edit policy-options] level:
damping dampingName { disable; half-life minutes; reuse number; suppress number; max-suppress minutes; }
were dampingName is the identifier for the group of damping parameters (Orch_RD-no), half-life minutes is the time, from 1 to 45 minutes, at which a penalty applying to a route is decreased by half, max-suppress minutes is the maximum time, from 1 to 720 minutes, that a route can be suppressed.
When a penalty applying a route falls below reuse number, which can be from 1 to 20000, the route becomes unsuppressed. When a penalty applying to a route exceeds suppress number, which can be from 1 to 20000, the route becomes suppressed.
Damping is applied by a policy statement which is configured at the [edit policy-options] level as follows:
policy-statement PolicyName { then damping DampingName; }
where PolicyName is the identifier for the group of damping parameters (Orch_RD-no-EBGP-damper) and DampingName is the identifier for the group of damping parameters.
The policy statement may be applied to all eBGP peers or to a specific eBGP neighbor, depending on the parameters configured in the client. Damping is applied to all eBGP peers at the [edit routing-instances vrf-table-name protocols bgp group] level as follows:
import PolicyName;
Damping is applied to a specific eBGP neighbor at the [edit routing-instances vrf-table-name protocols bgp group neighbor] level as follows:
import PolicyName;
If RIP is selected as the routing protocol, IP Service Activator creates a RIP group named RIP-to-CEs which contains:
An export policy statement that applies to all members of the group
A neighbor statement for each of the interfaces over which RIP is running
Where VRF re-use has been carried out, a number of neighbor statements are defined.
IP Service Activator adds the following configuration at the [edit groups orchestream routing-instances vrf-table-name protocols] level:
rip {
group RIP-to-CEs {
export CE-export-policy;
neighbor VPN-interface;
}
}
where CE-export-policy is the name of the export policy to apply to routes being exported from the routing table into BGP and VPN-interface is the name of the logical interface over which the PE device communicates with a CE neighbor.
Note:
RIP does not support routing table groups. This means that if a CE device belongs to more than one VPN, the VRF tables on the neighboring PE device cannot share the same routes.If OSPF is selected as the routing protocol, IP Service Activator adds the interface to the OSPF backbone, area 0.0.0.0.
Routes advertised from other sites in the VPN that are not using OSPF for PE-CE connectivity are advertised as AS-External routes. BGP routes distributed into OSPF carry a default metric of 20. OSPF area numbers and Link State Advertisement (LSA) types are carried over the MPLS backbone using the BGP extended community attribute 0x8000.
Note:
IP Service Activator does not support use of OSPF as the PE-CE routing protocol in non-broadcast multi-access networksIP Service Activator configures the following:
An export policy statement that applies to the area
An interface statement for each of the interfaces over which OSPF is running
Where VRF re-use has been carried out, a number of interface statements are defined.
IP Service Activator adds the following configuration at the [edit groups orchestream routing-instances vrf-table-name] level:
protocols {
ospf {
area 0.0.0.0 {
export CE-export-policy;
interface VPN-interface;
…
}
}
}
where CE-export-policy is the name of the export policy to apply to routes being exported from the routing table into OSPF and VPN-interface is the name of the logical interface over which the PE device communicates with a CE neighbor.
Using OSPF as the routing protocol between a CE and PE device in an MPLS VPN can result in routing loops if OSPF routes can be passed between PEs in the same network and VPN.
IP Service Activator supports VPN Route tags when OSPF is selected as a routing protocol. The VPN Route tag is one mechanism that can be used to prevent routing loops in multi-homed VPNs.
The Domain Tag field appears on the Site Properties dialog, Connectivity page.
When the Domain Tag field is selected, a tag value must be specified. This causes a VPN Route tag (domain-vpn-tag in Juniper devices) to be configured. In this case, the PE includes the tag in all LSA-5 advertisements sent to attached CE devices. The tag value must be distinct from any OSPF VPN Route Tag being used in the OSPF domain.
Using a different VPN Route tag causes the advertisement not to be distributed through the OSPF area to another connected domain.
If static routing is selected, IP Service Activator configures a static route between the PE and CE devices. The following statement is added at the [edit groups orchestream routing-instances vrf-table-name] level:
routing-options {
static {
route destination-prefix/prefix-length next-hop address;
}
}
where destination-prefix is the network portion of the destination IP address, prefix-length is the destination prefix length/subnet mask, and address is the IP address or interface name for the next-hop router.
Note:
Routing table groups are not supported by static routing on some versions of JUNOS. Where VRF tables with overlapping VPN membership use static routes, IP Service Activator configures additional static routes in place of those that would have been exchanged by routing table groups.You can specify that the next-hop address is in the default routing table and not the VRF table by selecting the Global option on a site's Static Routing page. IP Service Activator adds this information to the static route at the [edit routing-instances VRF-name routing-options static route] level as follows:
next-table inet.0;
You can specify that a static route is maintained in the VRF table when the protocol process shuts down by selecting the Permanent option on a site's Static Routing page.
IP Service Activator adds this information to the static route at the [edit routing-instances VRF-name routing-options static route] level.
retain;
By default, most dynamic routing protocols only distribute routes that have been learned via the same protocol. The PE-CE export policy ensures the exchange of routing information between CE devices and PE peers within the same VPN no matter what routing protocol or method is used for PE-CE connectivity.
Note:
If you configure a VPN which includes sites whose interfaces are on devices running different versions of JUNOS, there can be redistribution issues. This incompatibility occurs between Junos 6.0 and releases earlier than Junos 5.71The following routes can be distributed to all CE devices within the same VPN:
Routes received via iBGP from other PE devices
Routes from all interfaces in the VRF
Routes learnt via rib groups from interfaces in other VRF tables
Static routes
Connected routes
The PE-CE export policy includes one or more terms, depending on the options selected in the client. A term is always configured for BGP.
IP Service Activator applies the following default metrics to redistributed routes:
EBGP:
A metric of 0 is applied to connected and static routes distributed into BGP
RIP:
A metric of 0 is applied to connected and static routes and RIP routes distributed into BGP
A metric of 0 is applied to connected and static routes distributed into RIP
A metric of 1 is applied to BGP routes distributed into RIP
OSPF:
A metric of 0 is applied to connected and static routes and OSPF routes distributed into BGP
A metric of 20 is applied to connected and static routes and BGP routes distributed into OSPF
You can specify the metric to associate with routes distributed from the selected PE-CE routing protocol into other Internal Gateway Protocols (IGPs) and BGP, and vice versa and associate a manually pre-configured policy statement to routes to filter their redistribution.
The PE-CE export policy is configured at the [edit policy-options] level as follows:
policy-statement PE-CE-export-policy {
…
}
where PE-CE-export-policy is the identifier for the PE-CE export policy definition in the form Orch_RD-no-redistribute-protocol, where RD-no is the route distinguisher of the site and protocol is the name of the protocol used for PE-CE connectivity.
The PE-CE export policy consists of one or more term statements that define the protocols from which routes must be redistributed into the protocol used for PE-CE connectivity. The format of a statement depends on whether a metric applies to the redistributed routes.
If a metric applies to routes redistributed from a protocol, the term statement is configured as follows:
term export-protocol { from protocol protocol; then { metric value; accept; } }
where protocol is the name of the source protocol from which routes are redistributed and value is a metric to be applied when redistributing routes into the PE-CE protocol.
If a metric does not apply to routes redistributed from a protocol, the term statement is configured as follows:
term export {
from protocol [export-list];
}
where export-list is the list of source protocols from which routes are redistributed. The list contains only those protocols with which no metric is associated.
The CE-PE export policy always contains a term statement that defines how routes that do not match any other term are treated:
term reject-others {
then reject;
}
You can specify the metric to associate with routes distributed from BGP into the routing protocol used for PE-CE connectivity. You can also filter and refine the redistribution of routes by associating a manually pre-configured policy statement with redistributed routes.
The client allows you to define parameters for distribution of routes from all protocols potentially used by sites within the VPN into the PE-CE protocol. In general, however, only the value entered for BGP affects device configuration. A value specified for redistribution from any other protocol affects configuration only where two or more interfaces on the PE device participate in the same VPN, use different protocols for PE-CE connectivity and share the same VRF table.
If a metric has been defined for routes redistributed into the protocol used for PE-CE connectivity, the term statement at the [edit policy-options policy-statement PE-CE-export-policy] level is configured as follows:
term export-protocol { from protocol protocol; then { metric <value>; accept; } }
where protocol is the name of the source protocol from which routes are redistributed and value is a metric to be applied when redistributing routes into the PE-CE protocol.
If a manually preconfigured policy statement has been associated with the routes redistributed from a protocol, the term statement contains an extract from clause as follows:
term export-protocol { from { protocol protocol; policy PolicyStatement; } … }
where PolicyStatement is the name of the manually preconfigured policy statement to associate with redistributed routes.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|