| Oracle® Communications IP Service Activator Cisco IOS Cartridge Guide Release 7.2 E47722-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Cisco IOS Cartridge Guide Release 7.2 E47722-01 |
|
|
PDF · Mobi · ePub |
This chapter details the authentication methods supported on Oracle Communications IP Service Activator Cisco IOS cartridge and describes the required manual pre-configuration to support various options and services.
The IP Service Activator Cisco IOS cartridge supports the following authentication methods on all devices:
Telnet with TACACS+
Telnet with Named User
Telnet with Anonymous
SSH with password authentication
SSH with keyed authentication
Note:
Anonymous without enable is invalid for Cisco.This section describes the manual pre-configuration required by the Cisco IOS cartridge to support various options and services.
SNMP must be enabled on all routers for the IP Service Activator discovery process to work. Ensure the following line is included in the configuration:
snmp-server community community-name RO
Note:
Setup SNMP for the IP Service Activator discovery process using a community name (typically public). You can set the authentication as required. As a best practice make the Community read-only. The network discovery process uses a default community of public; you will need to amend the appropriate SNMP parameter in the Discovery dialog if you set a different read community on the devices.To use SSH authentication, you need to configure an SSH server on the device.
The device must have a hostname and domain-name.
In configuration mode, enter the following commands:
crypto key generate rsa
You are prompted for a modulus size for the key. The default is 512, but Cisco recommends the use of a minimum modulus size of 1024 bits.
ip ssh time-out 120 ip ssh authentication-retries 3
Note:
On later versions of IOS, SSH is configured automatically when the device is booted. For more information, see the Cisco documentation.Before using IP Service Activator to set up VPNs, some manual configuration of routers is required. The following pre-configuration is required for each device role.
On all PE (gateway) routers in the core VPN, you should ensure the following configuration is present:
IP Addresses
IP addresses must be correctly assigned. IPv4 and IPv6 addresses are supported.
Loopback Interfaces
A loopback interface must be set up and allocated an IP address.
Configuring MPLS
Cisco Express Forwarding (CEF) or Distributed CEF (dCEF) is a prerequisite for label switching. The relevant Cisco commands are:
ip cef ip cef distributed
For IPv6:
ipv6 cef
MPLS must be enabled on all appropriate interfaces. On each of the appropriate interfaces, enable MPLS using one of the following commands:
On IOS 12.1 or earlier:
(config-if)tag-switching ip
On IOS 12.2:
(config-if)mpls ip
Note:
The
mpls ip command is a new syntax for the tag-switching ip command, so in the running-config you will still see tag-switching ip.On 7200, 7500, and 12000 series routers running IOS 12.2, you also need to run the following command to enable LDP:
(config)mpls label switching protocol
IPv6 Routing
You must manually enable IPv6 routing to be able to configure the router for IPv6 routing. The relevant Cisco command is:
ipv6 unicast-routing
IGP
A suitable IGP (such as OSPF, IS-IS, or EIGRP) must be implemented in order to distribute IP routes in the core. The IGP for PE-CE communication is configured by IP Service Activator.
Note that OSPFv3 and RIPng are not supported for IPv6.
On all P routers in the core VPN, the following manual configuration is required.
IP Addresses
IP addresses must be correctly assigned.
Loopback Interfaces
It is recommended that a loopback interface be set up and allocated an IP address.
Configuring MPLS
CEF or Distributed CEF is a prerequisite for label switching. The relevant Cisco commands are:
ip cef ip cef distributed
For IPv6:
ipv6 cef
MPLS must be enabled on all appropriate interfaces. On each of the appropriate interfaces, enable MPLS using one of the following commands:
On IOS 12.1 or earlier:
(config-if)tag-switching ip
or, on IOS 12.2:
(config-if)mpls ip
Note:
Thempls ip command is a new syntax for the tag-switching ip command, so in the running-config you will still see tag-switching ip.On 7200, 7500, and 12000 series routers running IOS 12.2, you also need to run the following command to enable Label Distribution Protocol (LDP):
(config)mpls label switching protocol
IPv6 Routing
You must manually enable IPv6 routing to be able to configure the router for IPv6 routing. The relevant Cisco command is:
ipv6 unicast-routing
IGP
An Interior Gateway Protocol (IGP), such as OSPF, IS-IS, or EIGRP must be implemented in order to distribute IP routes. These are required for creating Label Switched Paths (LSPs).
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. You need to ensure the following are set up:
BGP, RIP, OSPF, or static routing must be configured in order to advertise reachability information between the CE and the PE.
It is recommended that a loopback interface be set up on each CE router.
You can manually pre-configure routers with data which provide specific operational requirements for MPLS VPNs. IP Service Activator is able to incorporate the following pre-configured data into the device configuration.
You can manually configure VRF tables on a PE router. When a pre-defined VRF table exists on a device, IP Service Activator can treat it in three different ways:
IP Service Activator has no control of the VRF table or its contents.
IP Service Activator has control of the VRF table and preserves its contents.
IP Service Activator has control of the VRF table and removes its contents.
You can specify the amount of control IP Service Activator has over a VRF table by setting certain site-specific values (on the VRF property page of the Site dialog box).
Restrictions
VRF Table Name: The name of a user-defined VRF table must be unique on the device. It may consist of up to a maximum of 30 alphanumeric and underscore characters.
VRF Table Description: The description of a pre-defined VRF table can only be changed on the device. If the description is changed on the device, the description will not be affected by a propagated configuration update. If you want to transfer control of the VRF table description to IP Service Activator, you must manually delete its description field from the VRF table on the device.
Adding Route Targets and External Features: It is possible to manually add route targets and parameters (for example, parameters that cannot be configured by IP Service Activator) to a pre-defined VRF table that is controlled by IP Service Activator. However, these parameters are preserved only until IP Service Activator either deletes the VRF table or merges it into another one. This normally occurs if you change the property settings of the relevant site, in which case the manually added route targets and parameters are no longer required.
You can choose to implement externally defined inbound and outbound BGP route-maps on a per-interface basis, or have IP Service Activator generate route-maps.
Specifying an external route map will result in the following command being configured within the ipv4-vrf level:
neighbor <ip-address> route-map <map-name> in|out
where the neighbor ip-address and map-name are taken from the Route Map property page on the Site dialog box.
Note:
Use a naming scheme different from IP Service Activator's for external inbound and outbound route-maps. IP Service Activator will remove route-maps with the same naming as those which it generates when the device is unmanaged and re-managed.You can manually pre-define import maps for VRFs on a PE router.
A VRF Import Map allows the site to selectively import routes learned elsewhere.
Note:
If different import maps are provisioned against different interfaces in a site, the site will be provisioned using multiple VRFs since only a single VRF import map applies to a VRF.As well, VRF reduction will not occur between sites with different provisioned import (or export) maps. VRF sharing occurs only if both sites have no import maps, or have the same import maps.
A manually defined import map can be assigned to a VRF table (on theVRF Export property page of the Site dialog box).
Import map names longer than the maximum supported by the device are truncated.
You can manually pre-define export maps for VRFs on a PE router. The export map only allows those routes in the VRF table whose route prefixes match those specified in the export map to be advertised to other PE routers. The exported routes are tagged with an RT value specified by the export map.
A manually defined export map can be assigned to a VRF table (on the VRF Export property page of the Site dialog box).
Export map names longer than the maximum supported by the device are truncated.
Configuring an Export Map
The following commands provide an example of configuring an export map.
access-list 1 permit 128.1.1.1
Defines access list 1 which accepts routes with IP address 128.1.1.1
access-list 2 permit any
Defines access list 2 which accepts any routes
route-map export-map-name permit sequence-number match ip address 1 set extcommunity rt 100:94
Export map export-map-name attaches route target 100:94 to routes specified in access list 1. The sequence-number identifies the order in which the route-map is implemented.
route-map export-map-name permit sequence-number match ip address 2 set extcommunity rt 100:26
Export map export-map-name attaches route target 100:26 to routes specified in access list 2. The sequence-number must be a higher value than the preceding sequence-number.
If an export map is used by a management VPN, the spoke sites are not required to export route targets. To prevent management spoke sites exporting route targets, set Spoke to None for the spoke site's export policy route target on the MPLS property page in the VPN dialog box, or alternatively, use the pre-defined export map configuration shown in the following example:
export map 'ExpMapCust#1' route-target export 1:1111 route-target export 1:1394 route-target export 1:1614
where ExpMapCust#1 is a pre-defined export map used by both management and customer VPN sites; 1:1111 is the route target of the management hub site, 1:1394 and1:1614 are the route targets of the customer sites in the VRF table of each spoke site.
ip access-list extended ExpMap_Mng deny ip 192.168.65.0.0.0.0.255 any deny ip 20.20.20.0.0.0.0.255 any permit ip any any
where deny ip 192.168.65.0.0.0.0.255 any rejects matching routes to the management hub site, deny ip 20.20.20.0.0.0.0.255 any rejects routes to the customer LAN, permit ip any any accepts all other routes.
route-map ExpMapCust#1 permit 10 match ip address ExpMap_Mng set extcommunity rt 1:1394 1:1614
Export map ExpMapCust#1 attaches route targets 1:1394 and1:1614 to routes permitted by access list extended ExpMap_Mng. Note that the management hub site route target 1:1111 is not attached to these routes.
When eBGP is used as the CE-PE protocol, the number of routes that are received from, or sent to, a CE router can be selectively reduced using a manually pre-defined prefix list installed on the neighboring PE router. Routes whose prefixes match those in the prefix list will either be allowed or rejected by the PE router depending on their designation in the prefix list. You need to specify in the user interface that the prefix list is required to only filter routes that are either incoming (CE to PE) or outgoing (PE to CE).
A pre-defined prefix list can be used instead of an access list for configuring a pre-defined export map described in "Pre-defined VRF Export Maps".
Creating a Prefix List
You can configure a prefix list using the commands described below in router configuration mode. You can apply a pre-configured prefix list filter to a site by entering the name of the prefix list in the Prefix filters In or Out fields on the EBGP Advanced property page of the Site dialog box.
If a route prefix received by the PE matches a prefix in the prefix list, that prefix will either be accepted or rejected depending on whether the entry is designated as permit or deny. The following conditions also apply:
A prefix is denied if it cannot be matched with any prefixes in the prefix list.
If a prefix matches several prefixes in the prefix list, the prefix with the lowest sequence value is used.
This command adds a single entry to a prefix list:
ip prefix-list list-name [seq sequence-value] deny|permit prefix|prefix-length [ge ge-value] [le le-value]
Sequence values are automatically generated by default. You only need to specify a sequence value if the automatic generation of sequence values is disabled. For more information, see "Sequence Values".
You must specify either deny or permit for the specified prefix to be either allowed or rejected by the PE router.
ge and le values specify a prefix length range, where:
prefix length < ge-value <= le-value <= 32.
Examples: 198.0.0.0/8 ge 16 le 16 specifies all prefixes in the range 198.0.0.0/8 to 198.0.0.0/16.
198.0.0.0/0 ge 16 le 24 specifies all prefixes in the range 198.0.0.0/16 to 198.0.0.0/24.
If only the ge-value is specified, the prefix range is from ge-value to 32.
If only the le-value is specified, the prefix range is from the prefix-length-value to le-value.
Sequence values are generated automatically by default, but generation can be disabled using:
no ip prefix-list sequence-number
Sequence values are, by default, automatically generated in increments of 5, so that the first list entry has a value of 5 and the next entry has a value of 10 and so on.
Examples of Configuring a Prefix List
Deny routes with prefixes 196.0.0.0/8 and prefix lengths greater than 25 up to 32 in network 192/8:
ip prefix-list filter1 deny 192.0.0.0/8 ge 25
Deny all routes in Class A network 22/8 by specifying prefix lengths from /8 to /32:
ip prefix-list filter1 deny 22.0.0.0/8 le 32
Deny routes with prefixes 100.70.1/ with prefix lengths from /24 to /25:
ip prefix-list filter1 deny 100.70.1.0/24 ge 25
Permit route 36.0.0.0/8:
ip prefix-list filter1 36.0.0.0/8
Permit routes with prefix lengths of 8 to 24; make list entry sequence value 5:
ip prefix-list filter1 seq 5 permit 0.0.0.0/0 ge 8 le 24
You can use IP Service Activator to manage manually pre-configured multi-AS VPNs.
When managing multi-AS VPNs with IP Service Activator, the domain-level property Configure iBGP Peering must be deselected in the user interface. For more information, see IP Service Activator VPN User's Guide.
PE Routers in the Same AS
iBGP peering must be manually pre-configured between PE routers that reside in the same AS.
For example:
router bgp 65057
no synchronization
no auto-summary
neighbor 10.52.0.1 remote-as 65057
neighbor 10.52.0.1 update-source 10.52.20.1
address-family vpnv4 unicast
neighbor 10.52.0.1 activate
neighbor 10.52.0.1 next-hop-self
neighbor 10.52.0.1 send-community extended
exit
Inter-AS PE routers
eBGP peering must be manually pre-configured between PE routers where each PE router resides in a different AS.
For example:
router bgp 65057
no synchronization
no auto-summary
neighbor 10.52.0.1 remote-as 65056
neighbor 10.52.0.1 ebgp-multihop
neighbor 10.52.0.1 update-source 10.52.20.1
address-family vpnv4 unicast
neighbor 10.52.0.1 activate
neighbor 10.52.0.1 next-hop-self
neighbor 10.52.0.1 send-community extended
exit
To configure the necessary functionality on the device, see the Cisco documentation: http://www.cisco.com/cisco/web/psa/default.html
Before configuring Layer 2 Martini VPNs, ensure that devices are preconfigured as described in this section.
Specify the LDP on each interface to be used for a Layer 2 Martini connection. If you do not specify LDP, tag distribution protocol (TDP) is used instead.
Log into the PE router and enter: mpls label protocol ldp
To assign LDP router IDs to the PE routers, perform the following steps. Both PE routers require a loopback address that you can use to create a virtual circuit between the routers.
Enter interface configuration mode: interface loopback0
Note:
The LDP router ID must be configured with a 32-bit mask to ensure proper operation of MPLS forwarding between PE routers.Assign an IP address to the loopback interface: ip address <ip-address>
Assign the loopback IP address as the router ID: mpls ldp router-id loopback0 force
Note:
This command forces the loopback interface to be the LDP router ID on each PE router. Without force, the router can assign a different router ID, thereby preventing the establishment of virtual circuits between PE routers.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|