Configuring T1 and E1 WAN Interfaces

Configuring T1 and E1 WAN Interfaces
Configuration Guide
5991-3823
December 2005
Configuring T1 and E1 WAN Interfaces
This configuration guide explains the processes for configuring your
Secure Router Operating System (SROS) T1/E1 product for some
common applications. This guide discusses configuring the T1/E1
interfaces, various Layer 2 (L2) protocols, many-to-one Network Address
Translation (NAT), and adding static routes to the route table. For more
detailed information regarding specific command syntax, refer to the
SROS Command Line Interface Reference Guide on your ProCurve SROS
Documentation CD.
This guide consists of the following sections:
• Overview of T1/E1 WAN Applications on page 2
• Physical Interface Configurations (T1, E1, and Ethernet) on page 3
• Configuring Layer 2 Protocols (Frame Relay, PPP, HDLC) on page 7
• Binding Physical and Virtual Interfaces on page 17
• Creating Access Lists and Policies on page 17
• Configuring Routing Information (Static Routes) on page 22
• Configuration Examples on page 24
61195880L1-29.7A
Printed in the USA
1
Overview of T1/E1 WAN Applications
Understanding SROS Queuing Methods
Overview of T1/E1 WAN Applications
Wide area networks (WANs) provide the mechanism for connecting remote sites together and connecting
your local network to the Internet through a connection to an ISP. WANs use a variety of physical
transports; T1/E1 connections are a common means of transport.T1 circuits are generally used in domestic
applications, while E1 circuits are widely deployed internationally. T1/E1 circuits are a relatively
inexpensive investment because they allow remote sites to share corporate resources at other locations and
thus eliminate the need for redundant equipment at multiple locations. For example, a corporation with
many small branch offices can consolidate their Internet access through a single interface and avoid paying
for Internet connectivity at each small office. Not only does this provide a cost savings, but it also gives the
corporation’s IT department more control over Internet usage and protection at each of the branch offices.
Many companies have centralized databases that must be used by employees at remote locations. Creating
a WAN connection between the centralized database and the remote location allows the remote users full
access to the resources.
Configuring T1/E1 WAN applications includes six steps:
1. Configure the physical interfaces (Ethernet and WAN interfaces)
2. Configure the L2 protocol(s)
3. Bind the physical and virtual (L2) interfaces
4. Create access lists and policies (including NAT parameters)
5. Apply the policies to interfaces
6. Configure the routing information (static routes, OSPF, RIP, etc.)
These configuration steps are explained on the following pages. Each step includes a brief discussion of
available settings, but does not elaborate on parameters that are normally left in the default state. In
addition, each step provides a sample command listing for a generic configuration. Specific example
configurations (with configuration scripts) are provided at the end of this document. For detailed
information regarding WAN configuration parameters, refer to the documentation provided on your
ProCurve SROS Documentation CD.
2
5991-3823
Understanding SROS Queuing Methods
Physical Interface Configurations (T1, E1, and Ethernet)
Physical Interface Configurations (T1, E1, and Ethernet)
Note
Interface Modules use a slot/port notation for interface identification (e.g., t1 1/1). All
non-modular interfaces built into the base unit are identified using 0 as the slot number
(e.g. eth 0/1).
To begin configuring physical interfaces, you must first activate the appropriate interface configuration
mode from the Global configuration prompt. For example, enter the following commands to activate the
interface configuration mode for the first T1 interface on a T1 module inserted in slot 1:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface t1 1/1
ProCurve(config-t1 1/1)#
All interfaces are disabled by default and must be activated using the no shutdown command. Interfaces
will not be able to pass data until this command is entered.
Interfaces can also be configured using the Web GUI. To activate the configuration page for a physical
interface located in the unit, click on the Physical Interfaces link under the System heading in the
navigation bar on the left side of the screen (see below). Select the physical interface to configure from the
list.
5991-3823
3
Configuring Ethernet Interfaces
Understanding SROS Queuing Methods
Configuring Ethernet Interfaces
Ethernet interface configuration can range from assigning an IP address and activating the interface to
activating the DHCP client to poll the network DHCP server to gain an IP address. Standard Ethernet
configurations generally contain an IP address, a speed, and a duplex setting. By default, all Secure Router
Ethernet interfaces are configured to auto-detect the speed (as 10 or 100 Mbps) and are set to full-duplex.
For most cases, these settings should suffice and will not be changed from the default state.
The following example commands configure an IP address of (10.10.0.7/24) and activates the interface for
the eth 0/1 interface:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface eth 0/1
ProCurve(config-eth 0/1)#ip address 10.10.0.7 255.255.255.0
ProCurve(config-eth 0/1)#no shutdown
ProCurve(config-eth 0/1)#exit
ProCurve(config)#
The following example configures an IP address of (10.10.0.7/24) and activates the interface for the
eth 0/1 interface using the Web GUI:
4
5991-3823
Understanding SROS Queuing Methods
Configuring Ethernet Interfaces
Configuring T1 Interfaces
There are four main settings to consider when configuring T1 network interfaces. The line coding
(coding), framing format (framing), active channels (tdm-group), and clock source (clock source) must
all be configured to match the circuit supplied by your network provider. By default, all Secure Router T1
interfaces are configured for ESF (framing esf) and B8ZS (coding b8zs), and to recover clocking from the
network circuit (clock source line). Generally, the line coding, framing format, and clock source default
values will be the correct ones for your application and should not be changed.
Each configured T1 interface must have the active channels specified using the tdm-group command
because there are no default TDM groups defined. The active channels are entered as a single number
representing 1 of the 24 T1 channel timeslots or as a contiguous group of channels.
The following example commands specify the configuration parameters required for a standard T1
interface:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface t1 1/1
ProCurve(config-t1 1/1)#tdm-group 1 timeslots 1-24
ProCurve(config-t1 1/1)#no shutdown
ProCurve(config-t1 1/1)#exit
The following example specifies the configuration parameters required for a standard T1 interface using
the Web GUI:
T1 Interface
Configuration
Parameters
5991-3823
5
Configuring Ethernet Interfaces
Understanding SROS Queuing Methods
Configuring E1 Interfaces
There are four main settings to consider when configuring E1 network interfaces. The line coding
(coding), framing format (framing), active channels (tdm-group), and clock source (clock source) must
all be configured to match the circuit supplied by your network provider. By default, all SROS router E1
interfaces are configured for standard multi-frame without the optional CRC4 error correction (no framing
crc4), and to recover clocking from the network circuit (clock source line). Generally, the line coding,
framing format, and clock source default values will be the correct ones for your application and should
not be changed.
Each configured E1 interface must have the active channels specified using the tdm-group command
because there are no default TDM groups. The active channels are entered as a single number representing
1 of the 31 E1 channel timeslots or as a contiguous group of channels.
The following example commands specify the configuration parameters required for a standard E1
interface:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface e1 1/1
ProCurve(config-e1 1/1)#tdm-group 1 timeslots 1-31
ProCurve(config-e1 1/1)#no shutdown
ProCurve(config-e1 1/1)#exit
The following example specifies the configuration parameters required for a standard E1 interface using
the Web GUI:
E1 Interface
Configuration
Parameters
6
5991-3823
Understanding SROS Queuing Methods
Configuring Layer 2 Protocols (Frame Relay, PPP, HDLC)
Configuring Layer 2 Protocols (Frame Relay, PPP, HDLC)
Each WAN connection in your SROS product must contain a physical interface (T1, E1, ADSL, etc.) and a
Layer 2 protocol (ATM, Frame Relay/multilink Frame Relay, PPP/multilink PPP, or HDLC). The physical
interface provides the actual bandwidth between your device and the network provider. The Layer 2
protocol defines how the data is packaged and presented on the physical interface. Layer 2 protocols must
be configured to match the protocol provided on the circuit. For example, configuring the
SROS product for PPP operation on a Frame Relay circuit would not be successful.
SROS currently supports the following Layer 2 protocols for T1/E1 physical links:
• Frame Relay, including multilink Frame Relay (FRF.16)
• point-to-point protocol (PPP), including multilink PPP
• high-level data link control (HDLC) protocol
Configuring the Frame Relay Interfaces (and Sub-Interfaces)
There are two settings to consider when configuring Frame Relay interfaces. The interface type
(frame-relay intf-type) and signaling type (frame-relay lmi-type) must be configured to match the
specifications supplied on your Frame Relay circuit by your network provider. By default, all SROS Frame
Relay interfaces are configured as a DTE interface (frame-relay intf-type dte) with Annex D signaling
(frame-relay lmi-type ansi).
Frame relay interfaces have a sub-interface component for each PVC which must also be configured. Each
Frame Relay sub-interface contains a DLCI (frame-relay interface-dlci) and IP address (ip address). You
must manually configure the Frame Relay sub-interface DLCI and IP address because there are no default
DLCIs or IP addresses defined. Access policies are also applied at the sub-interface level (see Creating
Access Lists and Policies on page 17).
Each PVC should also have a configured committed burst value (frame-relay bc) which is equivalent to
the committed information rate (CIR) given to you by your network provider. PVCs will also have a
negotiated burst rate (frame-relay be) which is equivalent to the excess information rate (EIR) given to
you by your network provider. Both the CIR and EIR should be decided on by you and your service
provider when defining your service agreement. To determine the appropriate committed burst value and
EIR, you need to know the CIR and physical bandwidth for both the local and remote connections. If one
side transmits data at a rate much higher than the other side’s CIR (or physical bandwidth), packets will be
dropped causing a decrease in efficiency. A general rule is to provision the committed burst value with the
remote side CIR and configure the EIR with the difference between the CIR and the actual physical
bandwidth at the location. The committed burst value plus the EIR should not be greater than the physical
bandwidth.
The following commands specify the configuration parameters required for a standard Frame Relay
interface:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface fr 2
ProCurve(config-fr 2)#no shutdown
ProCurve(config-fr 2)#exit
Note
5991-3823
The Web GUI automatically chooses the label for the created Frame Relay Interface.
Labels are chosen sequentially starting at 1.
7
Configuring the Frame Relay Interfaces (and Sub-Interfaces)
Understanding SROS Queuing Methods
The following commands specify the configuration parameters required for a standard Frame Relay
sub-interfaces:
ProCurve(config)#interface fr 2.16
ProCurve(config-fr 2.16)#frame-relay interface-dlci 16
ProCurve(config-fr 2.16)#frame-relay bc 768000
ProCurve(config-fr 2.16)#frame-relay be 768000
ProCurve(config-fr 2.16)#ip address 192.168.72.1 /30
ProCurve(config-fr 2.16)#no shutdown
ProCurve(config-fr 2.16)#exit
Note
Labeling the Frame Relay sub-interfaces using the DLCI (such as 1.16 indicating a DLCI
of 16) is useful for quickly determining (from a configuration printout) which sub-interface
corresponds to which PVC. The Web GUI automatically uses the configured DLCI for the
sub-interface label.
L2 protocol interfaces are created in the Web GUI on the configuration page for the physical interface to
which they are bound. For example, to create the Frame Relay interface to bind to a T1 interface, activate
the T1 interface configuration page and specify Frame Relay in the Encapsulation section:
Create the
L2 Protocol
Interface
8
5991-3823
Understanding SROS Queuing Methods
Configuring the Frame Relay Interfaces (and Sub-Interfaces)
After clicking Apply, the Frame Relay configuration page displays:
Click the Add button (in the Permanent Virtual Circuits section) to create a new Frame Relay
sub-interface.
5991-3823
9
Configuring the Frame Relay Interfaces (and Sub-Interfaces)
Understanding SROS Queuing Methods
Specify the Frame Relay sub-interface configuration parameters on the DLCI Configuration page:
Click Apply to create the Frame Relay sub-interface.
Multilink Frame Relay Operation
Multilink Frame Relay operation increases bandwidth on your Frame Relay service by aggregating
multiple physical links into a single logical bundle. All the physical links in a multilink bundle are
treated as a single entity by the system, allowing each PVC on the connection to dynamically share the
total bandwidth of the bundle. Single data packets can be fragmented into smaller pieces which may or
may not be transmitted to the network over the same physical link. Multilink Frame Relay devices
balance the transmitted information to evenly use all the physical links in a bundle.
SROS products support multilink Frame Relay (FRF.16), requiring that the multilink operation be
supported from the network provider. Remote side Frame Relay connections are unaffected by
multilink operation; the multilink FRF.16 functionality provides an effective way to increase the total
bandwidth at a single site between the Frame Relay device and the network provider.
Physical links can be dynamically added and removed from the logical bundle, so a failure on one
physical link does not halt the overall operation of the bundle. Since all PVCs have access to the entire
bundle bandwidth, failure of a single physical connection in the bundle does not decrease efficiency.
Multilink Frame Relay requires minimal configuration in your SROS product. You must first enable
multilink operation on the Frame Relay interface (not sub-interface) and then bind the multiple
physical interfaces to the single Frame Relay interface. Optionally, you can set a bundle ID (label for
10
5991-3823
Understanding SROS Queuing Methods
Configuring the Frame Relay Interfaces (and Sub-Interfaces)
the bundle), but SROS will automatically define one based on the specified Frame Relay interface. For
example, if multilink operation is enabled on a Frame Relay interface labeled fr 1, the bundle ID
becomes mfr1 (with the 1 corresponding to the label of the Frame Relay interface). Bundle IDs can be
character strings containing 1 to 48 characters. Manually defining the bundle ID can make it easier to
differentiate between bundles in systems with more than one multilink bundle. In systems with a single
multilink bundle, leaving the bundle ID to the default value is the easiest solution.
The following commands specify the configuration parameters required for a standard multilink Frame
Relay interface:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface fr 1
ProCurve(config-fr 1)#frame-relay multilink
ProCurve(config-fr 1)#no shutdown
ProCurve(config-fr 1)#exit
Now, bind multiple physical interfaces to the same multilink Frame Relay interface:
ProCurve(config)#bind 1 t1 3/1 1 fr 1
ProCurve(config)#bind 2 t1 3/2 2 fr 1
ProCurve(config)#bind 3 t1 3/3 3 fr 1
To create a standard multilink Frame Relay interface using the Web GUI, follow the same procedure
for a standard Frame Relay interface (see Configuring the Frame Relay Interfaces (and
Sub-Interfaces) on page 7) and click the Multilink checkbox. Interfaces configured for multilink
operation can be bound to more than one physical interface. To bind a physical interface to an existing
multilink interface, specify multilink operation and select the interface from the drop down list.
Multilink
L2 Interface
Drop Down
List
5991-3823
11
Configuring PPP Interfaces
Understanding SROS Queuing Methods
Configuring PPP Interfaces
There are two settings to consider when configuring PPP interfaces: the IP address and the maximum
transmission unit (MTU). There are no default IP addresses, so each interface must be manually
programmed with the appropriate address (ip address). All SROS router PPP interfaces have a default
MTU of 1500 bytes, which works for most applications.
The following commands specify the configuration parameters required for a standard PPP interface:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface ppp 1
ProCurve(config-ppp 1)#ip address 172.22.15.2 /30
ProCurve(config-ppp 1)#no shutdown
ProCurve(config-ppp 1)#exit
L2 protocol interfaces are created in the Web GUI on the configuration page for the physical interface to
which they are bound. For example, to create the PPP interface to bind to a T1 interface, activate the T1
interface configuration page and specify PPP in the Encapsulation section:
Create the
L2 Protocol
Interface
12
5991-3823
Understanding SROS Queuing Methods
Configuring PPP Interfaces
After clicking Apply, the PPP configuration page displays:
Specify the IP address parameters at the bottom of the page:
Click Apply to create the PPP interface.
5991-3823
13
Configuring PPP Interfaces
Understanding SROS Queuing Methods
Multilink PPP Operation
Multilink PPP operation increases bandwidth on your PPP connection by aggregating multiple
physical links into a single logical bundle. All the physical links in a multilink bundle are treated as a
single entity by the system, allowing each PPP session on the connection to dynamically share the total
bandwidth of the bundle. Single data packets can be fragmented into smaller pieces which may or may
not be transmitted to the network over the same physical link. Multilink PPP devices balance the
transmitted information to evenly use all the physical links in a bundle.
The multilink bundle will remain active with a minimum of one physical link. Physical links can be
dynamically added and removed from the logical bundle with a minor interruption to data flow, so a
failure on one physical link does not halt the overall operation of the bundle. Since all PPP sessions
have access to the entire bundle bandwidth, failure of a single physical connection in the bundle does
not decrease efficiency.
Remote side PPP peers are virtually unaffected by multilink operation; however, they must be aware
that multilink PPP operation is occurring and be able to handle the fragmented frames transmitted on
multiple physical links. Each PPP fragmented frame will include a sequence number to aid in the
reconstruction of PPP frames.
Multilink PPP requires minimal configuration in your SROS product. You must first enable multilink
operation on the PPP interface and then bind the multiple physical interfaces to the single PPP
interface.
The fragmentation and interleave options can be used to enhance multilink operation. Fragmentation is
used to reduce serialization delays during the transmission of large packets. The fragmentation process
evenly divides the data among all the links in the bundle with a minimum packet size of 96 bytes. Use
the ppp multilink fragmentation command (at the Global configuration level) to activate the
fragmentation option for all multilink PPP bundles configured on the system. The interleave process is
used with streaming protocols to reduce delay by giving priority to packets identified as high priority.
Sequential delivery is guaranteed with multilink fragmentation, but is not guaranteed with multilink
interleave operation. Use the ppp multilink interleave command (at the Global configuration level) to
activate the interleave option for all multilink PPP bundles configured on the system.
The following commands specify the configuration parameters required for a standard multilink PPP
interface:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface ppp 1
ProCurve(config-ppp 1)#ppp multilink
ProCurve(config-ppp 1)#no shutdown
ProCurve(config-ppp 1)#exit
Now, bind multiple physical interfaces to the same multilink PPP interface:
ProCurve(config)#bind 1 t1 3/1 1 ppp 1
ProCurve(config)#bind 2 t1 3/2 2 ppp 1
ProCurve(config)#bind 3 t1 3/3 3 ppp 1
To create a standard multilink PPP interface using the Web GUI, follow the same procedure for a
standard PPP interface (see Configuring PPP Interfaces on page 12) and click the Multilink
checkbox. Interfaces configured for multilink operation can be bound to more than one physical
interface. To bind a physical interface to an existing multilink interface, specify multilink operation
14
5991-3823
Understanding SROS Queuing Methods
Configuring HDLC Interfaces
and select the interface from the drop down list.
Multilink
L2 Interface
Drop Down
List
Configuring HDLC Interfaces
HDLC is a protocol developed by the International Organization for Standardization (ISO) under standards
ISO 3309 and 4335. Originally created for the mainframe environment, HDLC has become popularly used
in many network environments because of its flexibility and ease of configuration. HDLC provides
synchronous data transmission regardless of the physical layer access. Because HDLC is totally unaware
of the physical layer access, it supports both half duplex and full duplex communication lines, can work in
both point-to-point and multi-point network configurations, and can be transmitted over switched or
non-switched channels. The SROS supports HDLC transmission over T1, E1, and serial interfaces.
HDLC configuration in SROS products consists of creating the HDLC interface and assigning an IP
address. There are no protocol-specific configuration parameters for HDLC.
The following commands specify the configuration parameters required for a standard HDLC interface:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface hdlc 1
ProCurve(config-hdlc 1)#ip address 172.22.15.2 /30
ProCurve(config-hdlc 1)#no shutdown
ProCurve(config-hdlc 1)#exit
ProCurve(config)#
5991-3823
15
Configuring HDLC Interfaces
Understanding SROS Queuing Methods
L2 protocol interfaces are created in the Web GUI on the configuration page for the physical interface to
which they are bound. For example, to create the HDLC interface to bind to a T1 interface, activate the T1
interface configuration page and specify HDLC in the Encapsulation section:
Create the
L2 Protocol
Interface
After clicking Apply, the HDLC configuration page displays. Enter the configuration parameters and click
Apply to create the HDLC interface.
16
5991-3823
Understanding SROS Queuing Methods
Binding Physical and Virtual Interfaces
Binding Physical and Virtual Interfaces
Virtual interfaces must be bound to physical interfaces to create a WAN interface where L2 signaling
occurs. Use the bind command to connect the physical and virtual interfaces. A single virtual interface is
assigned to a single physical interface, except in the case of multilink operation, where one virtual interface
is connected with multiple physical interfaces. Each created bind has a unique label identifier and specifies
a virtual and a physical interface.
The following command listing depicts three binds to a multilink Frame Relay interface and a single bind
to a PPP interface. Each bind has a unique label identifier (1 through 4):
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#bind 1 t1 3/1 1 fr 1
ProCurve(config)#bind 2 t1 3/2 2 fr 1
ProCurve(config)#bind 3 t1 3/3 3 fr 1
ProCurve(config)#bind 4 t1 3/8 4 ppp 1
Note
When configuring interfaces using the Web GUI, binding virtual interfaces to physical
interfaces is automatic and does not require an additional step.
Creating Access Lists and Policies
Access lists (ACLs) and access policies (ACPs) are used to regulate traffic through your routed network.
ACLs and ACPs can block, filter, and manipulate traffic to make your network more secure.
ACLs are traffic selectors that include a “matching” parameter (to select the traffic) and an action
statement (to either permit or deny the matched traffic). Standard ACLs (using the ip access-list standard
command) provide pattern matching for source IP addresses only. Use extended ACLs (using the ip
access-list extended command) for more flexible pattern matching (including destination IP addresses).
ACPs use configured ACLs to permit, deny, or manipulate (using NAT) data on each interface where the
ACP is applied. When packets are received on an interface, the configured ACPs are applied to determine
whether the data will be processed or discarded. Creating access policies is a five-step process:
1. Determine what traffic needs to be regulated.
2. Enable the security features (using the ip firewall command).
3. Create an ACL to act as a traffic selector.
4. Create an ACP to either permit, deny, or manipulate (using NAT) the traffic selected using an access list.
5. Apply the ACP to an interface (or multiple interfaces).
Access List Traffic Selectors
ACLs include a matching parameter (to select traffic) and an action statement (to either permit or deny the
matched traffic). Standard ACLs provide pattern matching for source IP addresses only. To create a
standard ACL (labeled MYLIST), use the following command:
(config)#ip access-list standard MYLIST
(config-std-nacl)#
5991-3823
17
Access Policy Action Statements
Understanding SROS Queuing Methods
The following outlines the syntax for creating a standard ACL entry:
permit | deny <source address>
Select the traffic into the list using the permit keyword, or block the traffic from the list using the deny
keyword. The source IP addresses can be entered in one of three ways:
1. Using the keyword any to match any IP address. For example, entering deny any will effectively shut
down the interface that uses the access list because all traffic will match the any keyword.
2. Using the host <A.B.C.D> to specify a single host address. For example, entering permit host
192.168.22.253 will allow all traffic from the host with an IP address of 192.168.22.253.
3. Using the <A.B.C.D> <wildcard> format to match all IP addresses in a “range.” Wildcard masks work
in reverse logic from subnet mask. Specifying a one in the wildcard mask equates to a “don’t care.” For
example, entering permit 192.168.0.0 0.0.0.255 will permit all traffic from the 192.168.0.0/24 network.
Extended ACLs provide flexible pattern matching on various different parameters. The following lists the
complete syntax for the ip access-list extended commands:
<action> <protocol> <source IP> <source port> <destination ip> <destination port>
For example:
Source IP Address
[permit | deny] [ip | tcp | udp] [any | host <A.B.C.D> | <A.B.C.D> <W.W.W.W>]
<source port>* [any | host <A.B.C.D> | <A.B.C.D> <W.W.W.W>] <destination port>*
Destination IP Address
or:
Source IP Address
[permit | deny icmp [any | host <A.B.C.D> | <A.B.C.D> <W.W.W.W>]
[any | host <A.B.C.D> | <A.B.C.D> <W.W.W.W>] <icmp-type>* <icmp-code>* <icmp-message>*
Destination IP Address
* = optional
For detailed information regarding the extended ACL matching parameters, refer to the SROS Command
Line Interface Reference Guide on your ProCurve Secure Router OS System Documentation CD.
Access Policy Action Statements
SROS access policies are used to permit, deny, or manipulate (using NAT) data for each interface. Each
ACP consists of a selector (access list) and an action (allow, discard, NAT). When packets are received on
an interface, the configured ACPs are applied to determine whether the data will be processed or discarded.
Possible actions performed by the access policy are as follows:
18
5991-3823
Understanding SROS Queuing Methods
Access Policy Action Statements
allow list <access list names>
All packets permitted by the access list(s) will be allowed to enter the router system.
allow list <access list names> policy <access policy name>
All packets permitted by the access list(s) and destined for the interface using the access policy listed will
be allowed to enter the router system. This command creates configurations to allow packets to a single
interface and not the entire system.
allow list <access list names> self
All packets permitted by the access list(s) and destined for any local interface on the unit will be allowed to
enter the router system. These packets are terminated by the unit and are not routed or forwarded to other
destinations. This access list can be used for external access to Telnet or the Web GUI.
allow reverse list <access list names>
All packets denied by the access list(s) will be allowed to enter the router system.
allow reverse list <access list names> policy <access policy name>
All packets denied by the access list(s) and destined for the interface using the access policy listed will be
allowed to enter the router system. This command creates configurations to allow packets to a single
interface and not the entire system.
allow reverse list <access list names> self
All packets denied by the access list(s) and destined for any local interface on the unit will be allowed to
enter the router system. These packets are terminated by the unit and are not routed or forwarded to other
destinations. This access list can be used for external access to Telnet or the Web GUI.
discard list <access list names>
All packets permitted by the access list(s) will be dropped from the router system.
discard list <access list names> policy <access policy name>
All packets permitted by the access list(s) and destined for the interface using the access policy listed will
be discarded from the router system. This command creates configurations to discard packets on a
specified interface.
discard list <access list names> self
All packets permitted by the access list(s) and destined for any local interface on the unit will be discarded
from the router system. This command creates configurations to deny external access to the router on a
specified interface.
nat destination list <access list names> address <IP address> port
All packets permitted by the access list(s) will be modified to replace the destination IP address with the
entered IP address. This hides private IP addresses from outside the local network. The overload keyword
is not an option when performing NAT on the destination IP address; each private address must have a
unique public address. This function is known as “one-to-one NAT.” The port keyword takes all packets
and replaces the destination TCP/UDP port with the specified port number. This function is known as “port
forwarding.”
5991-3823
19
Access List and Access Policy Example
Understanding SROS Queuing Methods
nat source list <access list names> address <IP address> overload policy <access policy name>
All packets permitted by the access list(s) will be modified to replace the source IP address with the
entered IP address. The overload keyword allows multiple source IP addresses to be replaced with the
single IP address entered. This hides private IP addresses from outside the local network. This function is
also known as “many-to-one NAT.” The optional policy keyword specifies that all packets passed by the
access list(s) and destined for the interface using the listed access policy will be modified to replace the
source IP address with the entered IP address.
nat source list <access list names> interface <interface> overload policy <access policy name>
All packets permitted by the access list(s) entered will be modified to replace the source IP address with
the primary IP address of the listed interface. The overload keyword allows multiple source IP addresses
to be replaced with the single IP address of the specified interface. This hides private IP addresses from
outside the local network. This function is also known as “many-to-one NAT.” The optional policy
keyword specifies that all packets passed by the access list(s) and destined for the interface using the listed
access policy will be modified to replace the source IP address with the entered IP address.
Caution
Before applying an access control policy to an interface, verify your Telnet connection will
not be affected by the policy. If a policy is applied to the interface you are connecting
through and it does not allow Telnet traffic, your connection will be lost.
Access List and Access Policy Example
Let’s review the following example to illustrate the ACL and ACP creation process.
10.25.15.0/24
10.10.4.0/24
ProCurve
Secure Router 7203dl
ProCurve
Secure Router 7203dl
68.22.15.2/30
Internet
PPP
For our example, evaluate the incoming and outgoing traffic on the WAN and local Ethernet interfaces.
Use ACLs and ACPs to provide connectivity for traffic between the private LANs (branch site 10.10.4.0
network and corporate HQ 10.25.15.0 network), grant access to the public internet connection for all users
(branch site and corporate HQ), and hide private IP addresses for all traffic transmitted to the public
domain over the PPP connection (to protect the network). The following table outlines our traffic concerns:
Interface
Traffic to Select
Connection to
Branch Office
traffic from remote LAN (10.10.4.0/24) destined for the local LAN (10.25.15.0/24)
traffic from remote LAN (10.10.4.0/24) to the Internet through the PPP interface
Local Network
(Ethernet Interface)
traffic destined for the remote LAN (10.10.4.0/24)
traffic to the Internet through the PPP interface
20
5991-3823
Understanding SROS Queuing Methods
Access List and Access Policy Example
Begin by planning the ACL selectors for the traffic received on the connection to the branch office. Use
extended ACLs to use source and destination IP addresses to sort the traffic received from the remote
LANs into two categories – traffic destined for the corporate LAN or traffic destined for the public
Internet. Each category requires an extended ACL to select the appropriate traffic. All traffic destined for
the public Internet requires a many-to-one NAT configuration to hide the private IP addresses and to allow
a single, public IP address for access to the Internet.
Next, plan the ACL selectors for the traffic received on the local network (Ethernet interface). Use
extended ACLs to use source and destination IP addresses to sort the traffic received from the local
network into two categories – traffic destined for the branch office LAN or traffic destined for the public
Internet. Each category requires an extended ACL to select the appropriate traffic. All traffic destined for
the public Internet requires a many-to-one NAT configuration to hide private IP addresses and to allow a
single, public IP address for access to the Internet.
The following table provides sample ACL commands for the various traffic on our sample network.
Action
Description
Command(s)
Allow
traffic between LANs (10.10.4.0/16 to
10.25.15.0/24)
permit ip 10.10.4.0 0.0.0.255 10.25.15.0 0.0.0.255
Allow
traffic from remote LAN (10.10.4.0/24) to the
Internet through the PPP interface
permit ip 10.10.4.0 0.0.0.255 any
Allow
traffic from Corp LAN (10.25.15.0/24) to remote permit ip 10.25.15.0 0.0.0.255 10.10.4.0 0.0.0.255
LAN (10.10.4.0/24)
Allow
traffic from Corp LAN (10.25.15.0/24) to the
Internet
permit ip 10.10.0.0 0.0.0.255 any
The traffic selectors required for traffic on the connection to the branch office and the local network are
basically identical but contain different IP subnets on the 10.0.0.0 network. If we modify the IP addresses
listed in the permit statements to encompass the entire 10.0.0.0 network (by using 10.0.0.0 with wildcard
bits 0.255.255.255), we can create a single set of ACLs that can be used in ACPs on both interfaces. All
traffic on IP subnets of the 10.0.0.0 network will be allowed to transmit data to one another and the
Internet.
The following activates the security features in the SROS router and creates two extended ACLs to select
our traffic:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#ip firewall
ProCurve(config)#ip access-list extended INTERLAN
ProCurve(config-ext-nacl)#permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
ProCurve(config-ext-nacl)#exit
ProCurve(config)#ip access-list extended INTERNET
ProCurve(config-ext-nacl)#permit ip 10.0.0.0 0.255.255.255 any
ProCurve(config-ext-nacl)#exit
ProCurve(config)#
5991-3823
21
Configuring Routing Information (Static Routes)
Understanding SROS Queuing Methods
Now, create the access policy to allow the traffic between the LANs and to NAT traffic bound for the
public Internet.
ProCurve(config)#ip policy-class INTERLANwNAT
ProCurve(config-policy-class)#allow list INTERLAN
ProCurve(config-policy-class)#nat source list INTERNET interface ppp 1 overload
ProCurve(config-policy-class)#exit
ProCurve(config)#
Apply the ACPs to the interface(s) to complete the configuration. For our example, the
INTERLANwNAT ACP should be applied to fr 1.16 (PVC to the branch office) and eth 0/1 (local
network connection).
The following command listing applies the ACP to the fr 1.16 and eth 0/1 interfaces:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#interface fr 1.16
ProCurve(config-fr 1.16)#access-policy INTERLANwNAT
ProCurve(config-fr 1.16)#exit
ProCurve(config)#interface eth 0/1
ProCurve(config-eth 0/1)#access-policy INTERLANwNAT
ProCurve(config-eth 0/1)#exit
ProCurve(config)#
Configuring Routing Information (Static Routes)
SROS products support various routing protocols including static routes, RIP, OSPF, and BGP.
RIP, OPSF, and BGP are all routing protocols which allow routers to share the information contained in
their route tables with other routers in the network. These routing protocols are generally used on networks
that frequently change or contain a large number of nodes. For small applications, manually adding static
routes to the router’s route table is the easiest method of configuration.
Manually adding static routes to the route table requires two steps:
1. Determine the routes needed (destination address and subnet mask as well as the next-hop address or
forwarding interface). Be sure to plan the default route.
2. Use the ip route command to add the route to the route table.
The following lists the complete syntax for the ip route command:
ip route <ip address> <subnet mask> <interface or ip address> <administrative distance>
<ip address>
Specifies the network address (in dotted decimal notation) to add to the route table.
<subnet mask>
Specifies the subnet mask (in dotted decimal notation) associated with the listed network IP address.
<interface or ip address>
Specifies the gateway peer IP address (in dotted decimal notation) or a configured interface in the unit.
<administrative distance>
Specifies an administrative distance associated with this router (1 to 255). The administrative distance
provides a way for a router to determine the best route when multiple routes to the same destination exist.
The smaller the administrative distance, the more reliable the route.
22
5991-3823
Understanding SROS Queuing Methods
Static Route Example
Static Route Example
Let’s review the following example to illustrate the static route creation process.
10.25.15.0/24
10.10.4.0/24
ProCurve
Secure Router 7203dl
ProCurve
Secure Router 7102dl
68.22.15.2/30
68.22.15.1/30
(ISP Router)
Internet
PPP
The following table outlines the static routes needed in the Corporate HQ router.
Destination Address
Subnet Mask
Next-Hop Address/Forwarding Interface
10.10.10.0
255.255.255.0
fr 1.19 (WAN connection to the branch
office)
Default Route (0.0.0.0)
0.0.0.0
ppp 1 (public Internet)
The following command listing adds the necessary static routes to the Corporate router’s route table:
ProCurve>enable
ProCurve#config terminal
ProCurve(config)#ip route 10.10.10.0 255.255.255.0 fr 1.19
ProCurve(config)#ip route 0.0.0.0 0.0.0.0 ppp 1
ProCurve(config)#
5991-3823
23
Configuration Examples
Understanding SROS Queuing Methods
Configuration Examples
This guide contains four examples for basic WAN applications.
• Frame relay/multilink Frame Relay between sites
• PPP/multilink PPP in a point-to-point scenario between sites
• PPP/multilink PPP for a public connection to an ISP
• HDLC for a public connection to an ISP
Each example provides a network diagram, configuration parameters (to explain complicated network
diagrams), and the sample script. Brief explanations are provided beside the example scripts when needed
to differentiate between Layer 2 protocol configurations. For more details on configuring Layer 2
protocols, refer to Configuring Layer 2 Protocols (Frame Relay, PPP, HDLC) on page 7.
Frame Relay/Multilink Frame Relay Application
1
ProCurve Secure Router
7102dl/7203dl
ProCurve
Secure Router 7203dl
1 to 8 T1s/E1s
2
Frame
Relay
ProCurve Secure Router
7102dl/7203dl
T1/E1
Frame Relay
(Multilink Optional)
Internet
PPP
ProCurve Secure Router
7102dl/7203dl
3
Configuration Parameters
Parameter
Corporate HQ
Branch 1
Branch 2
Branch 3
WAN Interface(s)
t1 3/1 (1-24)
t1 3/2 (1-24)
t1 3/3 (1-24)
t1 1/1 (1-24)
t1 1/1 (1-24)
t1 1/1 (1-24)
LAN: Eth 0/1 IP
10.10.0.7/24
10.10.10.1/24
10.10.20.1/24
10.10.30.1/24
fr 1.19
fr 1.20
fr 1.21
Frame Relay Interface(s) fr 1.16
fr 1.17
fr 1.18
DLCI
16
17
18
19
20
21
Signaling Type
Annex D
Annex D
Annex D
Annex D
IP Address
192.168.72.1/30 (fr 1.16)
192.168.72.5/30 (fr 1.17)
192.168.72.9/30 (fr 1.18)
192.168.72.2/30
192.168.72.6/30
192.168.72.10/30
t1 3/8 (1-18)
N/A
N/A
N/A
Internet Connection
24
PPP Interface
ppp 1
IP Address
68.22.15.2/30
5991-3823
Understanding SROS Queuing Methods
Frame Relay/Multilink Frame Relay Application
Example Configuration Script
!
!
hostname "Corporate HQ"
enable password md5 encrypted 7f1a02ddd2cf3df129eb99c8408a5e28
!
!
ip firewall
no ip firewall alg h323
ip firewall alg sip
!
!
interface eth 0/1
ip address 10.10.0.7 255.255.255.0
access-policy INTERLANwNAT
no shutdown
!
!
interface t1 3/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/2
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/3
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/8
tdm-group 1 timeslots 1-18 speed 64
no shutdown
!
Enables multilink Frame Relay
!
on the interface. For regular
interface fr 1 point-to-point
Frame Relay applications,
frame-relay lmi-type ansi
remove this statement.
frame-relay multilink
no shutdown
bind 1 t1 3/1 1 frame-relay 1
bind 2 t1 3/2 1 frame-relay 1
Multiple binds for multilink
bind 3 t1 3/3 1 frame-relay 1
Frame Relay. Regular Frame
!
Relay applications have a
interface fr 1.16 point-to-point
single bind for each Frame
frame-relay interface-dlci 16
Relay interface.
frame-relay bc 768000
frame-relay be 768000
ip address 192.168.72.1 255.255.255.252
access-policy INTERLANwNAT
!
interface fr 1.17 point-to-point
frame-relay interface-dlci 17
frame-relay bc 768000
frame-relay be 768000
5991-3823
25
Frame Relay/Multilink Frame Relay Application
Understanding SROS Queuing Methods
ip address 192.168.72.5 255.255.255.252
!
interface fr 1.18 point-to-point
frame-relay interface-dlci 18
frame-relay bc 768000
frame-relay be 768000
ip address 192.168.72.9 255.255.255.252
!
interface ppp 1
ip address 68.22.15.2 255.255.255.252
no shutdown
bind 4 t1 3/8 1 ppp 1
!
!
ip access-list extended InterLAN
permit ip 10.10.0.0 0.0.255.255 10.10.0.0 0.0.255.255
!
ip access-list extended INTERNET
permit ip 10.10.0.0 0.0.255.255 any
!
!
ip policy-class INTERLANwNAT
allow list InterLAN
nat source list INTERNET interface ppp 1 overload
!
!
!
ip route 0.0.0.0 0.0.0.0 ppp 1
ip route 10.10.10.0 255.255.255.0 fr 1.16
ip route 10.10.20.0 255.255.255.0 fr 1.17
ip route 10.10.30.0 255.255.255.0 fr 1.18
!
!
end
26
5991-3823
Understanding SROS Queuing Methods
PPP/Multilink PPP (Point-to-Point) Example
PPP/Multilink PPP (Point-to-Point) Example
Customer Site A
Customer Site B
1 to 8 T1s/E1s
T1/E1 PPP
(Multilink Optional)
10.10.10.1/24
192.168.72.1/30
192.168.72.2/30
10.10.20.1/24
Example Configuration Script
!
!
hostname "Customer Site A"
enable password md5 encrypted 7f1a02ddd2cf3df129eb99c8408a5e28
!
!
ip firewall
no ip firewall alg h323
ip firewall alg sip
!
interface eth 0/1
ip address 10.10.10.1 255.255.255.0
no shutdown
!
!
interface t1 3/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/2
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/3
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
Enables multilink PPP on the
!
interface ppp 1
interface. For regular PPP
ip address 192.168.72.1 255.255.255.252
applications, remove this
access-policy INTERLAN
statement.
ppp multilink
no shutdown
Multiple binds for multilink
bind 1 t1 3/1 1 ppp 1
PPP. Regular PPP applications
bind 2 t1 3/2 1 ppp 1
have a single bind for each
bind 3 t1 3/3 1 ppp 1
PPP interface.
5991-3823
27
PPP/Multilink PPP (Point-to-Point) Example
Understanding SROS Queuing Methods
!
!
!
ip access-list extended INTERLAN
permit ip 10.10.20.0 0.0.0.255 10.10.10.0 0.0.0.255
!
ip policy-class INTERLAN
allow list INTERLAN
!
!
ip route 10.10.20.0 255.255.255.0 ppp 1
!
!
end
28
5991-3823
Understanding SROS Queuing Methods
PPP/Multilink PPP (Public Internet) Example
PPP/Multilink PPP (Public Internet) Example
Internet Service
Provider (ISP)
Customer Site
1 to 8 T1s/E1s
Internet
T1/E1 PPP
(Multilink Optional)
10.10.10.1/24
172.16.1.2/30
172.16.1.1/30
Example Configuration Script
!
!
hostname "Customer Site"
enable password md5 encrypted 7f1a02ddd2cf3df129eb99c8408a5e28
!
!
ip firewall
no ip firewall alg h323
ip firewall alg sip
!
!
!
interface eth 0/1
ip address 10.10.10.1 255.255.255.0
access-policy NAT
no shutdown
!
!
!
interface t1 3/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/2
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 3/3
tdm-group 1 timeslots 1-241 speed 64
no shutdown
!
!
5991-3823
29
PPP/Multilink PPP (Public Internet) Example
interface ppp 1
ip address 172.16.1.2 255.255.255.252
ppp multilink
no shutdown
bind 1 t1 3/1 1 ppp 1
bind 2 t1 3/2 1 ppp 1
bind 3 t1 3/3 1 ppp 1
!
!
!
ip access-list extended MATCHALL
permit ip any any
!
ip policy-class NAT
nat source list MATCHALL interface ppp 1 overload
!
!
end
30
Understanding SROS Queuing Methods
Enables multilink PPP on the
interface. For regular PPP
applications, remove this
statement.
Multiple binds for multilink
PPP. Regular PPP applications
have a single bind for each
PPP interface.
5991-3823
Understanding SROS Queuing Methods
HDLC (Public Internet) Example
HDLC (Public Internet) Example
Internet Service
Provider (ISP)
Customer Site
Internet
T1/E1 HDLC
10.10.10.1/24
172.16.1.2/30
172.16.1.1/30
Example Configuration Script
!
!
hostname "Customer Site"
enable password md5 encrypted 7f1a02ddd2cf3df129eb99c8408a5e28
!
!
ip firewall
no ip firewall alg h323
ip firewall alg sip
!
interface eth 0/1
ip address 10.10.10.1 255.255.255.0
access-policy NAT
no shutdown
!
!
interface t1 3/1
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
!
interface hdlc 1
ip address 172.16.1.2 255.255.255.252
no shutdown
bind 1 t1 3/1 1 hdlc 1
!
!
!
ip access-list extended MATCHALL
permit ip any any
!
ip policy-class NAT
nat source list MATCHALL interface hdlc 1 overload
!
!
end
5991-3823
31
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising