| 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 |
In order for Oracle Communications IP Service Activator to correctly manage Juniper devices through the Juniper M-series Device Driver and to configure features on them, various values must be preconfigured on the devices. This chapter describes the manual Juniper device preconfiguration steps that are required.
SNMP must be enabled on all Juniper M-series routers for the IP Service Activator discovery process to work and so that the capabilities of Juniper routers can be obtained. Ensure the following statement is included in the configuration:
[edit] snmp;
IP Service Activator's network discovery process uses a default community of public; you must amend the appropriate SNMP parameter on the client's Discovery dialog box if you set a different read community on the devices.
To configure the community string:
Use the following command:
[edit snmp] community community-string { authorization read-only; clients { default restrict; address; } }
where community-string is the community string, the value for authorization is the access authorization level, and address is an SNMP client that is authorized to access the router.
For the Juniper M-series Device Driver to configure a device, the user specified in IP Service Activator's device security settings must have access privileges that permit interface configuration, routing configuration, firewall, and firewall-control permissions.
Users are assigned access privileges by login classes. To assign the appropriate privileges to a user:
At the [edit system login] level, create a login class with the appropriate access level as follows:
class class-name { permissions [ access-privileges ]; }
The access privileges required are: [configure edit interface interface-control routing routing-control maintenance view firewall firewall-control]
At the [edit system login user] level, associate the class with the relevant user as follows:
user user-name { full-name full-name; uid user-id; class class-name;
Access to a device can be authenticated through Telnet or SSH.
To enable Telnet and SSH login:
At the [edit services] level, use the following commands:
services {
ssh;
telnet;
}
When using SSH, or other non-Telnet authentication, configurations are sent to the device using the set command. Using this notation generates a syntax error when applying communities to the import and export policy statements. Specifically, the string community[ will fail the VPN configuration. and comment delimiters of /* */ and # are not accepted.
In both cases, comment commands must done with the CLI annotate command. The annotate command is explained in the JUNOS Software CLI User Guide (v7.6 to v8.3), available on the Juniper Networks Technical Documentation Web site:
Router configurations generated by the Juniper Device Driver may fail or be inactive when interfaces on the device are already configured by other users at the master system or group configuration hierarchies.
To prevent this situation, at the system or (active) groups configuration hierarchy level, check for existing configuration operating on interfaces where policy is to be applied that might potentially conflict with the planned IP Service Activator provisioning commands. In particular, check that there are no input or output firewall filters, VRFs, l2circuits, cross-connects and/or PHB Groups already configured on those interfaces.
Before using IP Service Activator to set up VPNs, some manual configuration of routers is required.
The following preconfiguration is required for each device role.
Perform the following mandatory manual configuration on all PE (gateway) routers in the core VPN:
Configure core interfaces to carry IP and MPLS traffic. See "Configuring IP and MPLS on Core Interfaces".
Note:
The Juniper M-series Device Driver assigns IP addresses and enables MPLS only on access interfaces.Correctly assign IP addresses.
Set up a loopback interface. See "Configuring Loopback Interfaces".
Implement an IGP (such as OSPF or IS-IS) in order to distribute IP routes.
Configure LSPs between the loopback addresses of all PE devices. See "Enabling LSPs".
Configure IBGP sessions between PE peers.
To configure IP on an interface:
Use the following command:
interface-name { unit logical-interface-number { family inet { address IP-address; } }
To enable MPLS on an interface:
Use the following command:
protocols { mpls { interface {interface-name | all }; }}
To configure a loopback interface:
Use the following command:
interfaces {
lo0 {
unit 0 {
family inet {
loopback-address;
}
}
}
}
Oracle recommends that you allow LSPs to be set up as required by enabling LDP on all PE and P routers.
To enable LDP:
Use the following command:
ldp {
interface {interface-name | all };
}
Perform the following mandatory manual configuration on all P (core) routers:
Configure core interfaces to carry IP and MPLS traffic. See "Configuring IP and MPLS on Core Interfaces".
Correctly assign IP addresses.
Enable the protocol used to set up LSPs. See "Enabling LSPs".
Implement an IGP (such as OSPF or IS-IS) in order to distribute IP routes.
The CE (access) routers at customer sites are not configured to control routing by IP Service Activator, since they may not be under the control of the network service provider. Therefore they need to be manually configured.
Perform the following mandatory manual configuration:
Configure BGP, RIP, OSPF or static routing in order to advertise reachability information between the CE and the PE.
Set up a loopback interface on each CE router (see "Configuring IP and MPLS on Core Interfaces" and "Configuring Loopback Interfaces").
You can manually preconfigure routers with data which provide specific operational requirements for your MPLS VPNs. IP Service Activator is able to incorporate the following preconfigured data into the device configuration:
Export maps, see "About Predefined Export Maps"
Route list filters, see "About Predefined Route List Filters"
Filtering policies for route redistribution, see "About Predefined Filtering Policies for Route Redistribution"
You can manually predefine an export policy on a PE router and assign it to a VRF table in the Advanced VPN property page of the Site dialog box. The export policy only allows those routes in the VRF table whose route prefixes match those specified in the export policy to be advertised to other PE routers. The exported routes are tagged with an RT value specified by the export map.
Using a manually predefined export policy enables you to control the redistribution of routing information into iBGP without affecting route redistribution into eBGP. This is in contrast to the route redistribution feature, where route redistribution parameters affect both eBGP and iBGP.
You can configure an export policy to specify any of the following options:
To reject routes that match those in the export policy (route is not exported)
To accept routes that match those in the export policy (the route is exported without evaluating the IP Service Activator defined export policy)
To neither reject or accept routes (the IP Service Activator defined export policy only applies)
In all cases other policy actions, such as modifying or adding route targets, will be applied to routes.
Note:
The user-defined export policy must be defined in the main configuration and not within the orchestream configuration group.You configure a community to associate with exported routes using the commands described in "VPN Topology and Route Targets".
The number of routes that are received from or sent to a CE router can be selectively reduced using a manually predefined route list filter installed on the neighboring PE router. Routes whose prefixes match the condition specified by the route list filter will either be accepted or rejected by the PE router depending on the action specified by the filter. You also need to specify in the client that the route list filter is to filter routes that are either incoming (CE-PE) or outgoing (PE-CE).
Another method for selectively reducing the number of routes that are received from or sent to a CE router is to use a prefix list filter installed on the neighboring PE router. A prefix list filter exactly matches the prefixes that are listed in the prefix list, whereas a route list filter supports a range of matching conditions which can apply to specific routes or a range of routes.
The name of the preconfigured route list filter must be specified in a policy-statement. You apply the route list filter to a site by entering the name of the policy-statement in the Prefix filters In or Out fields on the Site properties, EBGP Advanced page.
To configure a route list filter on the PE device in router configuration mode:
Use the following syntax at the [edit routing-options policy-options] level:
policy-statement policy-name { term term-name { from { route-filter destination-prefix match-type actions; source-address-filter destination-prefix match-type actions; } then actions; } } }
where:
route-filter matches outgoing prefixes (PE-CE) and source-address-filter matches incoming prefixes (CE-PE)
destination-prefix is an IPv4 prefix in the format of prefix/prefix length. If prefix length is not entered, default is 32.
match-type is the type of match applied to destination_prefix. See table Table 4-1 for possible match types.
actions is an action taken if destination_prefix matches. Can be one or several actions listed in Table 4-2. Actions can either be specified in the route-filter and source-address-filter sections or in the then-statement.
Table 4-1 describes the possible match types.
| Type | Description |
|---|---|
|
exact |
The destination-prefix prefix (specified by the prefix-length) and prefix-length match the route's prefix and prefix length. |
|
longer |
The destination-prefix prefix (specified by the prefix-length) matches the route's prefix and its prefix-length is greater than the route's prefix length. |
|
orlonger |
The destination-prefix prefix (specified by the prefix-length) matches the route's prefix and its prefix-length is equal to, or greater than the route's prefix length. |
|
prefix-length-range prefix-length-value1 prefix-length-value2 |
The destination-prefix prefix (specified by the prefix-length) matches the route's prefix and the route's prefix length is within value1 and value2. |
|
first-destination-prefix through last-destination-prefix |
Matches all of the following:
|
|
upto prefix-length-value2 |
The destination-prefix prefix (specified by the prefix-length) matches the route's prefix and the route's prefix length is within destination-prefix prefix-length and prefix-length-value2 |
Table 4-2 describes the possible actions.
| Action | Description |
|---|---|
|
accept |
Accepts the route. After a route is accepted, no other terms in the routing policy and no other routing policies are evaluated. |
|
reject |
Rejects the route. After a route is rejected, no other terms in the routing policy and no other routing policies are evaluated. |
|
next term |
Skips to and evaluates the next term in the same routing policy. Any accept or reject action specified in the then statement is skipped. This is the default action if no action is specified. |
|
next policy |
Skips to and evaluates the next routing policy. Any accept or reject action specified in the then statement is skipped. |
The policy statement is referenced at the [edit routing-instances VRF-table-name protocols bgp group neighbor] level. For more information, see "Allow AS In".
Another method for selectively reducing the number of routes that are received from, or sent to, a CE router is to use a prefix list filter installed on the neighboring PE router. The IP address prefixes of routes that you want to filter are listed in a prefix-list. Routes whose IP address prefixes match those in the prefix-list will either be allowed or rejected by the PE router depending on the action specified in the route list filter. The route list filter has to specify that the prefix-list is required to only filter routes that are either incoming (CE - PE) or outgoing (PE - CE).
The name of the prefix-list must be specified in a policy-statement. Both the prefix-list and the policy-statement must be preconfigured on the PE device. You apply a preconfigured prefix list filter to a site by entering the name of the policy-statement in the Prefix filters In or Out fields on the Site properties, EBGP Advanced page.
To define a prefix list:
Use the following syntax at the [edit routing-options] level:
prefix-list name { ip-addresses; }
You can list any number of ip-addresses.
You define a policy-statement which defines the prefix list filter and specifies the prefix-list at the [edit routing-options policy-options] level.
To define the policy-statement for outgoing (export) routes:
Use the following syntax, entering the previously-defined prefix list name in the from-statement. Use either accept or reject in the then actions statement to accept or reject prefixes:
policy-statement policy-name { term term-name { from { match-conditions; prefix-list name; } to { match-conditions; neighbor address; } then actions; accept; reject; } }
To define the policy-statement for incoming (import) routes:
Use the following syntax, entering the previously-defined prefix list name in the from-statement. Use either accept or reject in the then actions statement to accept or reject prefixes:
policy-statement policy-name { term term-name { from { match-conditions; neighbor address; } to { match-conditions; prefix-list name; } then actions; accept; reject; } }
A policy-statement policy-name is added at the [edit routing-instances VRF-table-name protocols bgp group neighbor] level. For more information, see "Allow AS In".
You can specify a manually preconfigured policy statement to filter routes redistributed from the site's VRF table into BGP and routes received from other sites by BGP. A different policy can be specified for the protocol used for PE-CE connectivity, connected routes and static routes. By applying a policy to redistributed routes you can eliminate the routing loops and convergence problems that can potentially result from route redistribution.
Users apply filters to a site by specifying the name of a policy-statement in the BGP Policy and/or ProtocolName Policy field on the Site's Redist property page.
To configure a filter on the PE device in router configuration mode:
Use the following syntax at the [edit routing-options policy-options] level:
policy-statement forwarding-policy { term one { from { protocol protocol-name; route-filter destination-prefix match-type actions; } then { actions; } } term x { … } }
where destination-prefix is the IP route prefix to match, match-type is the type of match (see Table 4-1), and actions is the action to take if destination-prefix matches (see Table 4-2).
If the policy is applied to routes distributed into iBGP, IP Service Activator applies the policy statement to the export policy for the relevant VRF table. For more information, see "Exporting Routes Between Routing Instances in Overlapping VPNs".
If the policy is applied to routes distributed into the protocol used for PE-CE connectivity, IP Service Activator applies the policy statement to the PE-CE export policy. For more information, see "Specifying Metrics for Route Redistribution".
Perform the following preconfiguration tasks for CCs on Ethernet interfaces:
For 802.1Q VLANs and/or VLAN-based CCCs: ensure that vlan-tagging is enabled on physical interfaces and that each logical subinterface has a VLAN ID configured. However, in some JUNOS devices, it is possible for a logical subinterface to have vlan-tagging without a VLAN ID. The validation is removed from Juniper Device Driver code.
For physical Ethernet interfaces to be used in port-based CCCs: ensure that there is no vlan-tagging and only unit 0, or none of logical subinterfaces, are present.
For more information, refer to the JUNOS Software MPLS Applications Configuration Guide, available on the Juniper Networks Technical Documentation Web site:
Oracle recommends that you enable RSVP on all core router interfaces except for those on the Autonomous System (AS) border. RSVP must be configured manually on all routers.
To configure RSVP:
Use the following command syntax:
protocols {
rsvp {
interface {interface-name | all };
}
}
IP Service Activator configures BGP peering in two different cases:
PE routers in the same AS
PE routers in more than one AS
iBGP peering must be manually preconfigured between PE routers that reside in the same AS.
For example:
protocols {
bgp {
group VPN-IBGP-Peers {
type internal;
local-as global-asn;
family inet-vpn {
unicast;
}
neighbor peer-loopback-address {
local-address local-loopback-address;
}
neighbor peer-loopback-address {
local-address local-loopback-address;
}
more neighbours...
}
}
}
You can use IP Service Activator to manage manually preconfigured multi-AS VPNs.
When managing multi-AS VPNs with IP Service Activator, the domain-level property Configure iBGP Peering must be de-selected in the client. For more information, see IP Service Activator VPN User's Guide.
eBGP peering must be manually preconfigured between PE routers where each PE router resides in a different AS. The type is external, the update source must be explicitly set to the loopback address. The multihop option is likely required.
For example:
group VPN-EBGP-Peers {
type external;
family inet-vpn {
unicast;
}
local-as 2;
neighbor 1.1.1.1 {
multihop;
local-address 2.2.2.2;
peer-as 12345;
}
}
For MPLS tunneling CCCs, the nodes between the endpoints must have MPLS enabled manually. RSVP must be configured on all routers, including the LSP's ingress and egress routers. For information on enabling MPLS, see "Configuring IP and MPLS on Core Interfaces".
The device driver configures MPLS on the CCC's ingress and egress routers. MPLS must be manually configured on all intervening routers.
A loopback interface must also be configured on the LSP's ingress and egress devices to provide termination points for the CCC. For information on configuring the loopback interface, see "Configuring Loopback Interfaces".
In MPLS tunneling CCCs, the LSP is dynamic and packet routing may change if the network topology is changed. Oracle therefore recommends that you configure MPLS and RSVP on all devices that may potentially be used in the LSP.
IP Service Activator detects incompatibilities in the physical interface encapsulation pre-existing on the router when the device driver creates a new configuration for CCCs and/or l2circuits. When this occurs, an error is flagged in the client. You are then given the option to manually correct the interface encapsulation. In order to expedite the configuration process, ensure that proper interface encapsulations are provisioned as per the JUNOS documentation and this guide.
Before using IP Service Activator to set up Layer 2 Martini VPNs, some manual configuration of routers is required. Since Martini tunnels use MPLS label switched paths, much of the necessary setup is the same as that which is required to support MPLS VPNs.
Perform the following manual configuration tasks on core routers on the path to the neighbor PE, and core interfaces:
Enable MPLS support on all appropriate interfaces using the following command:
protocols {
mpls {
interface {<interface-name> | all };
}
}
Configure OSPF (or another IGP) using the following command:
protocols {
ospf {
traffic-engineering
area <address> {
interface <interface-id>
interface <loopback-id>
}
}
}
Configure LDP. On PE devices LSPs must be configured between the loopback addresses of all PE and P devices. Use the following command:
protocols {
ldp {
interface <interface-id>
interface <loopback-id>
}
}
For 802.1Q VLANs and/or VLAN-based l2circuits, ensure that vlan-tagging is enabled on physical interfaces and that each logical subinterface has a VLAN ID configured.
For physical Ethernet interfaces to be used in port-based Martini circuits, ensure that there is no vlan-tagging and only unit 0, or none of logical subinterfaces, are present.
For more information, refer to the JUNOS Software MPLS Applications Configuration Guide, available on the Juniper Networks Technical Documentation Web site:
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|