Cabletron Systems IA1100, IA1200 User's Reference Manual
Cabletron Systems IA1100 is a powerful and versatile Internet appliance that combines the functionality of a personal computer with the simplicity of a home appliance. It is designed to provide users with a secure and easy-to-use platform for accessing the Internet, checking email, and performing other basic tasks. The IA1100 comes with a variety of pre-installed software applications, including a web browser, email client, and media player. It also features a built-in Ethernet port and Wi-Fi connectivity, making it easy to connect to the Internet and other devices.
Advertisement
Advertisement
9033371
Internet Appliance
User Reference Manual
Changes
Cabletron Systems, Inc., reserves the right to make changes in specifications and other information contained in this document without prior notice. The reader should in all cases consult Cabletron
Systems, Inc., to determine whether any such changes have been made.
The hardware, firmware, or software described in this manual is subject to change without notice.
Disclaimer
IN NO EVENT SHALL CABLETRON SYSTEMS BE LIABLE FOR ANY INCIDENTAL, INDIRECT,
SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED
TO LOST PROFITS) ARISING OUT OF OR RELATED TO THIS MANUAL OR THE INFORMATION
CONTAINED IN IT, EVEN IF CABLETRON SYSTEMS HAS BEEN ADVISED OF, KNOWN, OR
SHOULD HAVE KNOWN, THE POSSIBILITY OF SUCH DAMAGES.
Copyright
© 2000 by Cabletron Systems, Inc. All rights reserved.
Cabletron Systems, Inc.
35 Industrial Way
Rochester, NH 03867-5005
Printed in the United States of America
Trademarks
AppleTalk is a registered trademark of Apple Computer, Inc.
Cabletron Systems is a registered trademark and Cabletron, SmartSwitch, and GIGAswitch are trademarks of Cabletron Systems, Inc.
Catalyst and EtherChannel are registered trademarks of Cisco Systems, Inc.
DEC is a registered trademark and Decnet is a trademark of Digital Equipment Corporation.
All other product names mentioned in this manual may be trademarks or registered trademarks of their respective companies.
Regulatory Compliance Information
Regulatory Compliance Information
This product complies with the following:
Safety
UL 1950; CSA C22.2, No. 950; 73/23/EEC; EN 60950; IEC 950
Electromagnetic
FCC Part 15; CSA C108.8; 89/336/EEC; EN 55022; EN 61000-3-2
Compatibility (EMC)
EN 61000-3-3; EN 50082-1, AS/NZS 3548; VCCI V-3
Regulatory Compliance Statements
FCC Compliance Statement
This device complies with Part 15 of the FCC rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.
NOTE: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment.
This equipment uses, generates, and can radiate radio frequency energy and if not installed in accordance with the operator’s manual, may cause harmful interference to radio communications.
Operation of this equipment in a residential area is likely to cause interference in which case the user will be required to correct the interference at his own expense.
WARNING: Changes or modifications made to this device that are not expressly approved by the party responsible for compliance could void the user’s authority to operate the equipment.
Industry Canada Compliance Statement
This digital apparatus does not exceed the Class A limits for radio noise emissions from digital apparatus set out in the Radio Interference Regulations of the Canadian Department of
Communications.
Le présent appareil numérique n’émet pas de bruits radioélectriques dépassant les limites applicables aux appareils numériques de la class A prescrites dans le Règlement sur le brouillage radioélectrique
édicté par le ministère des Communications du Canada.
Internet Appliance User Reference Manual iii
Regulatory Compliance Statements
NOTICE: The Industry Canada label identifies certified equipment. This certification means that the equipment meets telecommunications network protective, operational, and safety requirements as prescribed in the appropriate Terminal Equipment Technical Requirements document(s). The department does not guarantee the equipment will operate to the user’s satisfaction.
Before installing this equipment, users should ensure that it is permissible to be connected to the facilities of the local telecommunications company. The equipment must also be installed using an acceptable method of connection. The customer should be aware that compliance with the above conditions may not prevent degradation of service in some situations.
Repairs to certified equipment should be coordinated by a representative designated by the supplier.
Any repairs or alterations made by the user to this equipment, or equipment malfunctions, may give the telecommunications company cause to request the user to disconnect the equipment.
Users should ensure for their own protection that the electrical ground connections of the power utility, telephone lines, and internal metallic water pipe system, if present, are connected together. This precaution may be particularly important in rural areas.
CAUTION: Users should not attempt to make such connections themselves, but should contact the appropriate electric inspection authority, or electrician, as appropriate.
NOTICE: The Ringer Equivalence Number (REN) assigned to each terminal device provides an indication of the maximum number of terminals allowed to be connected to a telephone interface. The termination on an interface may consist of any combination of devices subject only to the requirement that the sum of the Ringer Equivalence Numbers of all the devices does not exceed 5.
VCCI Compliance Statement
This is a Class A product based on the standard of the Voluntary Control Council for Interference by
Information Technology Equipment (VCCI). If this equipment is used in a domestic environment, radio disturbance may arise. When such trouble occurs, the user may be required to take corrective actions.
iv Internet Appliance User Reference Manual
Safety Information: Class 1 Laser Transceivers
Safety Information: Class 1 Laser Transceivers
This product may use Class 1 laser transceivers. Read the following safety information before installing or operating this product.
The Class 1 laser transceivers use an optical feedback loop to maintain Class 1 operation limits. This control loop eliminates the need for maintenance checks or adjustments. The output is factory set and does not allow any user adjustment. Class 1 laser transceivers comply with the following safety standards:
• 21 CFR 1040.10 and 1040.11, U.S. Department of Health and Human Services (FDA)
• IEC Publication 825 (International Electrotechnical Commission)
• CENELEC EN 60825 (European Committee for Electrotechnical Standardization)
When operating within their performance limitations, laser transceiver output meets the Class 1 accessible emission limit of all three standards. Class 1 levels of laser radiation are not considered hazardous.
Laser Radiation and Connectors
When the connector is in place, all laser radiation remains within the fiber. The maximum amount of radiant power exiting the fiber (under normal conditions) is –12.6 dBm or 55 x 10
-6
watts.
Removing the optical connector from the transceiver allows laser radiation to emit directly from the optical port. The maximum radiance from the optical port (under worst case conditions) is 0.8 W cm
-2 or 8 x 10
3
W m
2
sr–1.
Do not use optical instruments to view the laser output. The use of optical instruments to view laser output increases eye hazard. When viewing the output optical port, power must be removed from the network adapter.
Internet Appliance User Reference Manual v
Cabletron Systems, Inc. Program License Agreement vi
Cabletron Systems, Inc.
Program License Agreement
IMPORTANT: THIS LICENSE APPLIES FOR USE OF PRODUCT IN THE FOLLOWING
GEOGRAPHICAL REGIONS:
CANADA
MEXICO
CENTRAL AMERICA
SOUTH AMERICA
BEFORE OPENING OR UTILIZING THE ENCLOSED PRODUCT, CAREFULLY READ THIS
LICENSE AGREEMENT.
This document is an agreement (“Agreement”) between You, the end user, and Cabletron Systems, Inc.
(“Cabletron”) that sets forth your rights and obligations with respect to the Cabletron software program (“Program”) in the package. The Program may be contained in firmware, chips or other media. UTILIZING THE ENCLOSED PRODUCT, YOU ARE AGREEING TO BECOME BOUND BY
THE TERMS OF THIS AGREEMENT, WHICH INCLUDES THE LICENSE AND THE LIMITATION
OF WARRANTY AND DISCLAIMER OF LIABILITY. IF YOU DO NOT AGREE TO THE TERMS OF
THIS AGREEMENT, RETURN THE UNOPENED PRODUCT TO CABLETRON OR YOUR DEALER,
IF ANY, WITHIN TEN (10) DAYS FOLLOWING THE DATE OF RECEIPT FOR A FULL REFUND.
IF YOU HAVE ANY QUESTIONS ABOUT THIS AGREEMENT, CONTACT CABLETRON SYSTEMS
(603) 332-9400. Attn: Legal Department.
1.
LICENSE.
You have the right to use only the one (1) copy of the Program provided in this package subject to the terms and conditions of this License Agreement.
You may not copy, reproduce or transmit any part of the Program except as permitted by the
Copyright Act of the United States or as authorized in writing by Cabletron.
2.
OTHER RESTRICTIONS.
You may not reverse engineer, decompile, or disassemble the
Program.
3.
APPLICABLE LAW.
This License Agreement shall be interpreted and governed under the laws and in the state and federal courts of New Hampshire. You accept the personal jurisdiction and venue of the New Hampshire courts.
4.
EXPORT REQUIREMENTS.
You understand that Cabletron and its Affiliates are subject to regulation by agencies of the U.S. Government, including the U.S. Department of Commerce, which prohibit export or diversion of certain technical products to certain countries, unless a license to export the product is obtained from the U.S. Government or an exception from obtaining such license may be relied upon by the exporting party.
If the Program is exported from the United States pursuant to the License Exception CIV under the
U.S. Export Administration Regulations, You agree that You are a civil end user of the Program and agree that You will use the Program for civil end uses only and not for military purposes.
If the Program is exported from the United States pursuant to the License Exception TSR under the
U.S. Export Administration Regulations, in addition to the restriction on transfer set forth in
Internet Appliance User Reference Manual
Cabletron Systems, Inc. Program License Agreement
Sections 1 or 2 of this Agreement, You agree not to (i) reexport or release the Program, the source code for the Program or technology to a national of a country in Country Groups D:1 or E:2
(Albania, Armenia, Azerbaijan, Belarus, Bulgaria, Cambodia, Cuba, Estonia, Georgia, Iraq,
Kazakhstan, Kyrgyzstan, Laos, Latvia, Libya, Lithuania, Moldova, North Korea, the People’s
Republic of China, Romania, Russia, Rwanda, Tajikistan, Turkmenistan, Ukraine, Uzbekistan,
Vietnam, or such other countries as may be designated by the United States Government), (ii) export to Country Groups D:1 or E:2 (as defined herein) the direct product of the Program or the technology, if such foreign produced direct product is subject to national security controls as identified on the U.S. Commerce Control List, or (iii) if the direct product of the technology is a complete plant o r any major component of a plant, export to Country Groups D:1 or E:2 the direct product of the plant or a major component thereof, if such foreign produced direct product is subject to national security controls as identified on the U.S. Commerce Control List or is subject to
State Department controls under the U.S. Munitions List.
5.
UNITED STATES GOVERNMENT RESTRICTED RIGHTS.
The enclosed Product (i) was developed solely at private expense; (ii) contains “restricted computer software” submitted with restricted rights in accordance with section 52.227-19 (a) through (d) of the Commercial Computer
Software-Restricted Rights Clause and its successors, and (iii) in all respects is proprietary data belonging to Cabletron and/or its suppliers. For Department of Defense units, the Product is considered commercial computer software in accordance with DFARS section 227.7202-3 and its successors, and use, duplication, or disclosure by the Government is subject to restrictions set forth herein.
6.
EXCLUSION OF WARRANTY.
Except as may be specifically provided by Cabletron in writing,
Cabletron makes no warranty, expressed or implied, concerning the Program (including its documentation and media).
CABLETRON DISCLAIMS ALL WARRANTIES, OTHER THAN THOSE SUPPLIED TO YOU BY
CABLETRON IN WRITING, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE, WITH RESPECT TO THE PROGRAM, THE ACCOMPANYING WRITTEN
MATERIALS, AND ANY ACCOMPANYING HARDWARE.
7.
NO LIABILITY FOR CONSEQUENTIAL DAMAGES.
IN NO EVENT SHALL CABLETRON OR
ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT
LIMITATION, DAMAGES FOR LOSS OF BUSINESS, PROFITS, BUSINESS INTERRUPTION,
LOSS OF BUSINESS INFORMATION, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR
RELIANCE DAMAGES, OR OTHER LOSS) ARISING OUT OF THE USE OR INABILITY TO USE
THIS CABLETRON PRODUCT, EVEN IF CABLETRON HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES DO NOT ALLOW THE
EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL
DAMAGES, OR IN THE DURATION OR LIMITATION OF IMPLIED WARRANTIES IN SOME
INSTANCES, THE ABOVE LIMITATION AND EXCLUSIONS MAY NOT APPLY TO YOU.
Internet Appliance User Reference Manual vii
Cabletron Systems Sales and Service, Inc. Program License Agreement
Cabletron Systems Sales and Service, Inc.
Program License Agreement
IMPORTANT: THIS LICENSE APPLIES FOR USE OF PRODUCT IN THE UNITED STATES OF
AMERICA AND BY UNITED STATES OF AMERICA GOVERNMENT END USERS.
BEFORE OPENING OR UTILIZING THE ENCLOSED PRODUCT, CAREFULLY READ THIS
LICENSE AGREEMENT.
This document is an agreement (“Agreement”) between You, the end user, and Cabletron Systems
Sales and Service, Inc. (“Cabletron”) that sets forth your rights and obligations with respect to the
Cabletron software program (“Program”) in the package. The Program may be contained in firmware, chips or other media. UTILIZING THE ENCLOSED PRODUCT, YOU ARE AGREEING TO BECOME
BOUND BY THE TERMS OF THIS AGREEMENT, WHICH INCLUDES THE LICENSE AND THE
LIMITATION OF WARRANTY AND DISCLAIMER OF LIABILITY. IF YOU DO NOT AGREE TO THE
TERMS OF THIS AGREEMENT, RETURN THE UNOPENED PRODUCT TO CABLETRON OR YOUR
DEALER, IF ANY, WITHIN TEN (10) DAYS FOLLOWING THE DATE OF RECEIPT FOR A FULL
REFUND.
IF YOU HAVE ANY QUESTIONS ABOUT THIS AGREEMENT, CONTACT CABLETRON SYSTEMS
(603) 332-9400. Attn: Legal Department.
1.
LICENSE.
You have the right to use only the one (1) copy of the Program provided in this package subject to the terms and conditions of this License Agreement.
You may not copy, reproduce or transmit any part of the Program except as permitted by the
Copyright Act of the United States or as authorized in writing by Cabletron.
2.
OTHER RESTRICTIONS.
You may not reverse engineer, decompile, or disassemble the
Program.
3.
APPLICABLE LAW.
This License Agreement shall be interpreted and governed under the laws and in the state and federal courts of New Hampshire. You accept the personal jurisdiction and venue of the New Hampshire courts.
4.
EXPORT REQUIREMENTS.
You understand that Cabletron and its Affiliates are subject to regulation by agencies of the U.S. Government, including the U.S. Department of Commerce, which prohibit export or diversion of certain technical products to certain countries, unless a license to export the product is obtained from the U.S. Government or an exception from obtaining such license may be relied upon by the exporting party.
If the Program is exported from the United States pursuant to the License Exception CIV under the
U.S. Export Administration Regulations, You agree that You are a civil end user of the Program and agree that You will use the Program for civil end uses only and not for military purposes.
If the Program is exported from the United States pursuant to the License Exception TSR under the
U.S. Export Administration Regulations, in addition to the restriction on transfer set forth in
Sections 1 or 2 of this Agreement, You agree not to (i) reexport or release the Program, the source code for the Program or technology to a national of a country in Country Groups D:1 or E:2
(Albania, Armenia, Azerbaijan, Belarus, Bulgaria, Cambodia, Cuba, Estonia, Georgia, Iraq,
Kazakhstan, Kyrgyzstan, Laos, Latvia, Libya, Lithuania, Moldova, North Korea, the People’s viii Internet Appliance User Reference Manual
Cabletron Systems Sales and Service, Inc. Program License Agreement
Republic of China, Romania, Russia, Rwanda, Tajikistan, Turkmenistan, Ukraine, Uzbekistan,
Vietnam, or such other countries as may be designated by the United States Government), (ii) export to Country Groups D:1 or E:2 (as defined herein) the direct product of the Program or the technology, if such foreign produced direct product is subject to national security controls as identified on the U.S. Commerce Control List, or (iii) if the direct product of the technology is a complete plant o r any major component of a plant, export to Country Groups D:1 or E:2 the direct product of the plant or a major component thereof, if such foreign produced direct product is subject to national security controls as identified on the U.S. Commerce Control List or is subject to
State Department controls under the U.S. Munitions List.
5.
UNITED STATES GOVERNMENT RESTRICTED RIGHTS.
The enclosed Product (i) was developed solely at private expense; (ii) contains “restricted computer software” submitted with restricted rights in accordance with section 52.227-19 (a) through (d) of the Commercial Computer
Software-Restricted Rights Clause and its successors, and (iii) in all respects is proprietary data belonging to Cabletron and/or its suppliers. For Department of Defense units, the Product is considered commercial computer software in accordance with DFARS section 227.7202-3 and its successors, and use, duplication, or disclosure by the Government is subject to restrictions set forth herein.
6.
EXCLUSION OF WARRANTY.
Except as may be specifically provided by Cabletron in writing,
Cabletron makes no warranty, expressed or implied, concerning the Program (including its documentation and media).
CABLETRON DISCLAIMS ALL WARRANTIES, OTHER THAN THOSE SUPPLIED TO YOU BY
CABLETRON IN WRITING, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE, WITH RESPECT TO THE PROGRAM, THE ACCOMPANYING WRITTEN
MATERIALS, AND ANY ACCOMPANYING HARDWARE.
7.
NO LIABILITY FOR CONSEQUENTIAL DAMAGES.
IN NO EVENT SHALL CABLETRON
OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING,
WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS, PROFITS, BUSINESS
INTERRUPTION, LOSS OF BUSINESS INFORMATION, SPECIAL, INCIDENTAL,
CONSEQUENTIAL, OR RELIANCE DAMAGES, OR OTHER LOSS) ARISING OUT OF THE USE
OR INABILITY TO USE THIS CABLETRON PRODUCT, EVEN IF CABLETRON HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES DO NOT
ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR
INCIDENTAL DAMAGES, OR IN THE DURATION OR LIMITATION OF IMPLIED
WARRANTIES IN SOME INSTANCES, THE ABOVE LIMITATION AND EXCLUSIONS MAY
NOT APPLY TO YOU.
Internet Appliance User Reference Manual ix
x
Cabletron Systems Limited Program License Agreement
Cabletron Systems Limited
Program License Agreement
IMPORTANT: THIS LICENSE APPLIES FOR THE USE OF THE PRODUCT IN THE FOLLOWING
GEOGRAPHICAL REGIONS:
EUROPE
MIDDLE EAST
AFRICA
ASIA
AUSTRALIA
PACIFIC RIM
BEFORE OPENING OR UTILIZING THE ENCLOSED PRODUCT, CAREFULLY READ THIS
LICENSE AGREEMENT.
This document is an agreement (“Agreement”) between You, the end user, and Cabletron Systems
Limited (“Cabletron”) that sets forth your rights and obligations with respect to the Cabletron software program (“Program”) in the package. The Program may be contained in firmware, chips or other media. UTILIZING THE ENCLOSED PRODUCT, YOU ARE AGREEING TO BECOME BOUND
BY THE TERMS OF THIS AGREEMENT, WHICH INCLUDES THE LICENSE AND THE
LIMITATION OF WARRANTY AND DISCLAIMER OF LIABILITY. IF YOU DO NOT AGREE TO THE
TERMS OF THIS AGREEMENT, RETURN THE UNOPENED PRODUCT TO CABLETRON OR YOUR
DEALER, IF ANY, WITHIN TEN (10) DAYS FOLLOWING THE DATE OF RECEIPT FOR A FULL
REFUND.
IF YOU HAVE ANY QUESTIONS ABOUT THIS AGREEMENT, CONTACT CABLETRON SYSTEMS
(603) 332-9400. Attn: Legal Department.
1.
LICENSE.
You have the right to use only the one (1) copy of the Program provided in this package subject to the terms and conditions of this License Agreement.
You may not copy, reproduce or transmit any part of the Program except as permitted by the
Copyright Act of the United States or as authorized in writing by Cabletron.
2.
OTHER RESTRICTIONS.
You may not reverse engineer, decompile, or disassemble the
Program.
3.
APPLICABLE LAW.
This License Agreement shall be governed in accordance with English law.
The English courts shall have exclusive jurisdiction in the event of any disputes.
4.
EXPORT REQUIREMENTS.
You understand that Cabletron and its Affiliates are subject to regulation by agencies of the U.S. Government, including the U.S. Department of Commerce, which prohibit export or diversion of certain technical products to certain countries, unless a license to export the product is obtained from the U.S. Government or an exception from obtaining such license may be relied upon by the exporting party.
If the Program is exported from the United States pursuant to the License Exception CIV under the
U.S. Export Administration Regulations, You agree that You are a civil end user of the Program and agree that You will use the Program for civil end uses only and not for military purposes.
Internet Appliance User Reference Manual
Cabletron Systems Limited Program License Agreement
If the Program is exported from the United States pursuant to the License Exception TSR under the
U.S. Export Administration Regulations, in addition to the restriction on transfer set forth in
Sections 1 or 2 of this Agreement, You agree not to (i) reexport or release the Program, the source code for the Program or technology to a national of a country in Country Groups D:1 or E:2
(Albania, Armenia, Azerbaijan, Belarus, Bulgaria, Cambodia, Cuba, Estonia, Georgia, Iraq,
Kazakhstan, Kyrgyzstan, Laos, Latvia, Libya, Lithuania, Moldova, North Korea, the People’s
Republic of China, Romania, Russia, Rwanda, Tajikistan, Turkmenistan, Ukraine, Uzbekistan,
Vietnam, or such other countries as may be designated by the United States Government), (ii) export to Country Groups D:1 or E:2 (as defined herein) the direct product of the Program or the technology, if such foreign produced direct product is subject to national security controls as identified on the U.S. Commerce Control List, or (iii) if the direct product of the technology is a complete plant o r any major component of a plant, export to Country Groups D:1 or E:2 the direct product of the plant or a major component thereof, if such foreign produced direct product is subject to national security controls as identified on the U.S. Commerce Control List or is subject to
State Department controls under the U.S. Munitions List.
5.
UNITED STATES GOVERNMENT RESTRICTED RIGHTS.
The enclosed Product (i) was developed solely at private expense; (ii) contains “restricted computer software” submitted with restricted rights in accordance with section 52.227-19 (a) through (d) of the Commercial Computer
Software-Restricted Rights Clause and its successors, and (iii) in all respects is proprietary data belonging to Cabletron and/or its suppliers. For Department of Defense units, the Product is considered commercial computer software in accordance with DFARS section 227.7202-3 and its successors, and use, duplication, or disclosure by the Government is subject to restrictions set forth herein.
6.
EXCLUSION OF WARRANTY.
Except as may be specifically provided by Cabletron in writing,
Cabletron makes no warranty, expressed or implied, concerning the Program (including its documentation and media).
CABLETRON DISCLAIMS ALL WARRANTIES, OTHER THAN THOSE SUPPLIED TO YOU BY
CABLETRON IN WRITING, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE, WITH RESPECT TO THE PROGRAM, THE ACCOMPANYING WRITTEN
MATERIALS, AND ANY ACCOMPANYING HARDWARE.
7.
NO LIABILITY FOR CONSEQUENTIAL DAMAGES. IN NO EVENT SHALL CABLETRON OR
ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT
LIMITATION, DAMAGES FOR LOSS OF BUSINESS, PROFITS, BUSINESS INTERRUPTION,
LOSS OF BUSINESS INFORMATION, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR
RELIANCE DAMAGES, OR OTHER LOSS) ARISING OUT OF THE USE OR INABILITY TO USE
THIS CABLETRON PRODUCT, EVEN IF CABLETRON HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES DO NOT ALLOW THE
EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL
DAMAGES, OR IN THE DURATION OR LIMITATION OF IMPLIED WARRANTIES IN SOME
INSTANCES, THE ABOVE LIMITATION AND EXCLUSIONS MAY NOT APPLY TO YOU.
Internet Appliance User Reference Manual xi
Declaration of Conformity Addendum
Declaration of Conformity
Addendum
Application of Council Directive(s)
Manufacturer’s Name
Manufacturer’s Address
European Representative’s Name
European Representative’s Address
Conformance to Directive(s)/Product
Standards
Equipment Type/Environment
89/336/EEC
73/23/EEC
Cabletron Systems, Inc.
35 Industrial Way
PO Box 5005
Rochester, NH 03867
Mr. J. Solari
Cabletron Systems Limited
Nexus House, Newbury
Business Park
London Road, Newbury
Berkshire RG13 2PZ, England
EC Directive 89/336/EEC
EC Directive 73/23/EEC
EN 55022
EN 50082-1
EN 60950
Networking equipment for use in a commercial or light-industrial environment
We the undersigned, hereby declare, under our sole responsibility, that the equipment packaged with this notice conforms to the above directives.
Manufacturer Legal Representative in Europe
Mr. Ronald Fotino
Full Name
Principal Compliance Engineer
Title
Rochester, NH, USA
Location
Mr. J. Solari
Full Name
Managing Director, E.M.E.A.
Title
Newbury, Berkshire, England
Location xii Internet Appliance User Reference Manual
Contents
Preface .................................................................................................. xxiii
About This Manual ............................................................................................................ xx iii
Who Should Read This Manual? ..................................................................................... xxiii
Related Documentation..................................................................................................... xxiii
Chapter 1: Introduction .......................................................................... 25
Reviewing Configuration Files ............................................................................................25
Using the Command Line Interface ....................................................................................26
Command Modes............................................................................................................26
User Mode.................................................................................................................26
Enable Mode.............................................................................................................27
Configure Mode .......................................................................................................27
Boot PROM Mode....................................................................................................27
Getting Help with CLI Commands ..............................................................................28
Line Editing Commands ................................................................................................29
Displaying and Changing Configuration Information.....................................................31
Identifying Ports on the IA-1100 and IA-1200 ...................................................................33
Chapter 2: Bridging Configuration Guide ............................................. 35
Bridging Overview.................................................................................................................35
Spanning Tree (IEEE 802.1d) .........................................................................................35
Bridging Modes (Flow-Based and Address-Based) ...................................................36
VLAN Overview ....................................................................................................................36
Port-Based VLANs..........................................................................................................37
MAC Address-Based VLANs........................................................................................37
Protocol-Based VLANs ..................................................................................................37
Subnet-Based VLANs.....................................................................................................38
Policy-Based VLANs ......................................................................................................38
IA VLAN Support ..................................................................................................................38
VLANs and the IA ..........................................................................................................38
Ports, VLANs, and Layer-3 Interfaces .........................................................................39
Access Ports and Trunk Ports (802.1Q Support) ........................................................39
Explicit and Implicit VLANs.........................................................................................40
Internet Appliance User Reference Manual xiii
Contents xiv
Configuring IA Bridging Functions.................................................................................... 40
Configuring Address-Based or Flow-Based Bridging .............................................. 40
Configuring Spanning Tree .......................................................................................... 42
Adjusting Spanning-Tree Parameters ......................................................................... 42
Setting the Bridge Priority ..................................................................................... 43
Setting a Port Priority ............................................................................................. 43
Assigning Port Costs .............................................................................................. 43
Adjusting Bridge Protocol Data Unit (BPDU) Intervals.................................... 44
Adjusting the Interval between Hello Times............................................... 44
Defining the Forward Delay Interval............................................................ 44
Defining the Maximum Age .......................................................................... 45
Configuring a Port- or Protocol-Based VLAN ........................................................... 45
Creating a Port- or Protocol-Based VLAN .......................................................... 45
Adding Ports to a VLAN ....................................................................................... 45
Configuring VLAN Trunk Ports .................................................................................. 46
Configuring VLANs for Bridging................................................................................ 46
Monitoring Bridging ............................................................................................................. 46
Configuration Examples....................................................................................................... 47
Creating an IP VLAN .................................................................................................... 47
Creating a Non-IP VLAN.............................................................................................. 47
Chapter 3: SmartTRUNK Configuration Guide ...................................... 49
Overview ................................................................................................................................ 49
Configuring SmartTRUNKs ................................................................................................ 50
Creating a SmartTRUNK .............................................................................................. 50
Add Physical Ports to the SmartTRUNK.................................................................... 51
Specify Traffic Distribution Policy (Optional) ........................................................... 51
Monitoring SmartTRUNKs .................................................................................................. 52
Example Configurations....................................................................................................... 53
Chapter 4: IP Routing Configuration Guide .......................................... 55
IP Routing Overview ............................................................................................................ 55
IP Routing Protocols ...................................................................................................... 56
Configuring IP Interfaces and Parameters ........................................................................ 56
Configuring IP Addresses to Ports .............................................................................. 56
Configuring IP Interfaces for a VLAN ........................................................................ 57
Specifying Ethernet Encapsulation Method............................................................... 57
Configuring Address Resolution Protocol (ARP) ..................................................... 57
Configuring ARP Cache Entries ........................................................................... 58
Configuring Proxy ARP ......................................................................................... 58
Configuring DNS Parameters ...................................................................................... 58
Configuring IP Services (ICMP)................................................................................... 59
Configuring IP Helper................................................................................................... 59
Configuring Direct Broadcast....................................................................................... 60
Configuring Denial of Service (DOS) .......................................................................... 60
Monitoring IP Parameters............................................................................................. 61
Configuration Examples....................................................................................................... 61
Assigning IP Interfaces.................................................................................................. 61
Internet Appliance User Reference Manual
Contents
Chapter 5: VRRP Configuration Guide................................................... 63
VRRP Overview .....................................................................................................................63
Configuring VRRP .................................................................................................................64
Basic VRRP Configuration.............................................................................................64
Configuration of Router R1 ....................................................................................65
Configuration for Router R2 ..................................................................................65
Symmetrical Configuration ...........................................................................................65
Configuration of Router R1 ....................................................................................67
Configuration of Router R2 ....................................................................................67
Multi-Backup Configuration .........................................................................................68
Configuration of Router R1 ....................................................................................69
Configuration of Router R2 ....................................................................................70
Configuration of Router R3 ....................................................................................71
Additional Configuration ..............................................................................................72
Setting the Backup Priority ....................................................................................72
Setting the Advertisement Interval .......................................................................72
Setting Pre-empt Mode ...........................................................................................73
Setting an Authentication Key ...............................................................................73
Monitoring VRRP...................................................................................................................74
ip-redundancy trace........................................................................................................74
ip-redundancy show.......................................................................................................74
VRRP Configuration Notes...................................................................................................75
Chapter 6: RIP Configuration Guide ...................................................... 77
RIP Overview..........................................................................................................................77
Configuring RIP .....................................................................................................................78
Enabling and Disabling RIP ..........................................................................................78
Configuring RIP Interfaces ............................................................................................78
Configuring RIP Parameters .........................................................................................79
Configuring RIP Route Preference ...............................................................................80
Configuring RIP Route Default-Metric........................................................................80
Monitoring RIP .......................................................................................................................81
Configuration Example .........................................................................................................82
Chapter 7: OSPF Configuration Guide................................................... 83
OSPF Overview .................................................................................................................. ....83
OSPF Multipath...............................................................................................................84
Configuring OSPF ............................................................................................................... ...84
Enabling OSPF.................................................................................................................8 4
Configuring OSPF Interface Parameters .....................................................................85
Configuring an OSPF Area ............................................................................................86
Configuring OSPF Area Parameters ............................................................................87
Creating Virtual Links....................................................................................................88
Configuring Autonomous System External (ASE) Link Advertisements ..............88
Configuring OSPF over Non-Broadcast Multiple Access .........................................89
Monitoring OSPF....................................................................................................................89
OSPF Configuration Examples.............................................................................................90
Exporting All Interface and Static Routes to OSPF....................................................91
Exporting All RIP, Interface, and Static Routes to OSPF ..........................................92
Internet Appliance User Reference Manual xv
Contents
Chapter 8: BGP Configuration Guide ..................................................... 97
BGP Overview ................................................................................................................... .... 97
The Internet Appliance (IA) BGP Implementation ................................................... 98
Basic BGP Tasks................................................................................................................ ..... 98
Setting the Autonomous System Number.................................................................. 99
Setting the Router ID ..................................................................................................... 99
Configuring a BGP Peer Group.................................................................................. 100
Adding and Removing a BGP Peer ........................................................................... 101
Starting BGP.................................................................................................................. 1 01
Using AS-Path Regular Expressions ......................................................................... 102
AS-Path Regular Expression Examples ............................................................. 103
Using the AS Path Prepend Feature .......................................................................... 104
Notes on Using the AS Path Prepend Feature.................................................. 104
BGP Configuration Examples............................................................................................ 105
BGP Peering Session Example.................................................................................... 105
IBGP Configuration Example..................................................................................... 107
IBGP Routing Group Example............................................................................ 108
IBGP Internal Group Example ............................................................................ 111
EBGP Multihop Configuration Example .................................................................. 114
Community Attribute Example ................................................................................. 117
Notes on Using Communities ............................................................................. 124
Local_Pref Attribute Example .................................................................................... 124
Notes on Using the Local_Pref Attribute .......................................................... 126
Multi-Exit Discriminator Attribute Example ........................................................... 126
EBGP Aggregation Example....................................................................................... 128
Route Reflection Example........................................................................................... 129
Notes on Using Route Reflection........................................................................ 132
Chapter 9: Routing Policy Configuration Guide.................................. 133
Route Import and Export Policy Overview..................................................................... 133
Preference ...................................................................................................................... 134
Import Policies.............................................................................................................. 135
Import-Source........................................................................................................ 135
Route-Filter ............................................................................................................ 136
Export Policies .............................................................................................................. 136
Export-Destination................................................................................................ 136
Export-Source ........................................................................................................ 137
Route-Filter ............................................................................................................ 137
Specifying a Route Filter ............................................................................................. 138
Aggregates and Generates .......................................................................................... 139
Aggregate-Destination ......................................................................................... 139
Aggregate-Source.................................................................................................. 139
Route-Filter ............................................................................................................ 140
Authentication .............................................................................................................. 140
Authentication Methods ...................................................................................... 141
Authentication Keys and Key Management ..................................................... 141 xvi Internet Appliance User Reference Manual
Contents
Configuring Simple Routing Policies................................................................................142
Redistributing Static Routes ........................................................................................142
Redistributing Directly Attached Networks.............................................................143
Redistributing RIP into RIP .........................................................................................143
Redistributing RIP into OSPF......................................................................................143
Redistributing OSPF to RIP .........................................................................................144
Redistributing Aggregate Routes ...............................................................................144
Simple Route Redistribution Examples .....................................................................144
Example 1: Redistribution into RIP.....................................................................144
Exporting a Given Static Route to All RIP Interfaces ................................146
Exporting All Static Routes to All RIP Interfaces.......................................146
Exporting All Static Routes Except the Default Route to All RIP
Interfaces...................................................................................................146
Example 2: Redistribution into OSPF .................................................................146
Exporting All Interface & Static Routes to OSPF .......................................147
Exporting All RIP, Interface & Static Routes to OSPF...............................148
Configuring Advanced Routing Policies..........................................................................148
Export Policies ...............................................................................................................149
Creating an Export Destination ..................................................................................150
Creating an Export Source...........................................................................................150
Import Policies...............................................................................................................150
Creating an Import Source ..........................................................................................151
Creating a Route Filter .................................................................................................151
Creating an Aggregate Route......................................................................................152
Creating an Aggregate Destination............................................................................153
Creating an Aggregate Source ....................................................................................153
Examples of Import Policies........................................................................................153
Example 1: Importing from RIP...........................................................................153
Importing a Selected Subset of Routes from One RIP Trusted
Gateway ....................................................................................................155
Importing a Selected Subset of Routes from All RIP Peers
Accessible Over a Certain Interface......................................................156
Example 2: Importing from OSPF .......................................................................157
Importing a Selected Subset of OSPF-ASE Routes ....................................159
Examples of Export Policies ........................................................................................160
Example 1: Exporting to RIP ................................................................................160
Exporting a Given Static Route to All RIP Interfaces ................................161
Exporting a Given Static Route to a Specific RIP Interface ......................162
Exporting All Static Routes Reachable Over a Given Interface to a
Specific RIP-Interface ..............................................................................163
Exporting Aggregate-Routes into RIP .........................................................164
Example 2: Exporting to OSPF.............................................................................165
Exporting All Interface & Static Routes to OSPF .......................................166
Exporting All RIP, Interface & Static Routes to OSPF...............................167
Internet Appliance User Reference Manual xvii
Contents xviii
Chapter 10: IP Policy-Based Forwarding Configuration Guide .......... 171
Overview .............................................................................................................................. 171
Configuring IP Policies....................................................................................................... 172
Defining an ACL Profile.............................................................................................. 172
Associating the Profile with an IP Policy.................................................................. 173
Creating Multi-statement IP Policies ................................................................. 173
Setting Load Distribution for Next-Hop Gateways ......................................... 174
Setting the IP Policy Action ................................................................................. 174
Checking the Availability of Next-Hop Gateways .......................................... 175
Applying an IP Policy to an Interface ....................................................................... 176
Applying an IP Policy to Locally Generated Packets ...................................... 176
IP Policy Configuration Examples .................................................................................... 176
Routing Traffic to Different ISPs................................................................................ 176
Prioritizing Service to Customers .............................................................................. 178
Authenticating Users through a Firewall ................................................................. 179
Firewall Load Balancing.............................................................................................. 180
Monitoring IP Policies ........................................................................................................ 181
Chapter 11: Network Address Translation Configuration Guide ...... 185
Overview .............................................................................................................................. 185
Configuring NAT ................................................................................................................ 186
Setting Inside and Outside Interfaces ....................................................................... 186
Setting NAT Rules........................................................................................................ 187
Static........................................................................................................................ 187
Dynamic ................................................................................................................. 187
Managing Dynamic Bindings............................................................................................ 187
NAT and FTP ....................................................................................................................... 188
Monitoring NAT.................................................................................................................. 188
Configuration Examples..................................................................................................... 189
Static Configuration ..................................................................................................... 189
Using Static NAT .................................................................................................. 190
Dynamic Configuration............................................................................................... 190
Using Dynamic NAT ............................................................................................ 191
Dynamic NAT with IP Overload (PAT) Configuration ......................................... 192
Using Dynamic NAT with IP Overload ............................................................ 193
Dynamic NAT with Outside Interface Redundancy .............................................. 193
Using Dynamic NAT with Matching Interface Redundancy......................... 194
Chapter 12: Web Hosting Configuration Guide.................................. 195
Overview .............................................................................................................................. 195
Load Balancing .................................................................................................................... 196
Configuring Load Balancing ...................................................................................... 196
Creating the Server Group................................................................................... 196
Adding Servers to the Load Balancing Group.................................................. 197
Optional Group or Server Operating Parameters ................................................... 197
Specifying Load Balancing Policy ...................................................................... 197
Specifying a Connection Threshold ................................................................... 198
Verifying Servers and Applications ................................................................... 198
Verifying Extended Content................................................................................ 199
Internet Appliance User Reference Manual
Contents
Setting Server Status .....................................................................................................200
Load Balancing and FTP ..............................................................................................201
Allowing Access to Load Balancing Servers.............................................................201
Setting Timeouts for Load Balancing Mappings......................................................201
Specifying the VPN Port Number ..............................................................................202
Displaying Load Balancing Information ...................................................................202
Configuration Examples ..............................................................................................203
Web Hosting with One Virtual Group and Multiple Destination Servers....203
Web Hosting with Multiple Virtual Groups and Multiple Destination
Servers ..............................................................................................................204
Virtual IP Address Ranges ...................................................................................205
Web Caching.........................................................................................................................206
Configuring Web Caching ...........................................................................................207
Creating the Cache Group....................................................................................207
Specifying the Client(s) for the Cache Group (Optional).................................207
Redirecting HTTP Traffic on an Interface ..........................................................208
Configuration Example ................................................................................................208
Other Configurations ...................................................................................................209
Bypassing Cache Servers ......................................................................................209
Proxy Server Redundancy ....................................................................................209
Distributing Frequently-Accessed Sites Across Cache Servers.......................210
Monitoring Web Caching ............................................................................................210
Chapter 13: Access Control List Configuration Guide ........................ 211
ACL Basics ............................................................................................................................212
Defining Selection Criteria in ACL Rules..................................................................212
How ACL Rules are Evaluated...................................................................................213
Implicit Deny Rule........................................................................................................214
Allowing External Responses to Established TCP Connections ............................215
Creating and Modifying ACLs...........................................................................................216
Editing ACLs Offline....................................................................................................216
Maintaining ACLs Using the ACL Editor .................................................................217
Using ACLs ...........................................................................................................................218
Applying ACLs to Interfaces.......................................................................................218
Applying ACLs to Services .........................................................................................219
Using ACLs as Profiles.................................................................................................219
Using Profile ACLs with the IP Policy Facility .................................................220
Using Profile ACLs with the Traffic Rate Limiting Facility ............................221
Using Profile ACLs with Dynamic NAT............................................................222
Using Profile ACLs with the Port Mirroring Facility .......................................222
Using Profile ACLs with the Web Caching Facility .........................................223
Redirecting HTTP Traffic to Cache Servers................................................223
Preventing Web Objects From Being Cached.............................................224
Enabling ACL Logging........................................................................................................225
Monitoring ACLs .................................................................................................................225
Internet Appliance User Reference Manual xix
Contents
Chapter 14: Security Configuration Guide .......................................... 227
Security Overview............................................................................................................... 227
Configuring IA Access Security ........................................................................................ 228
Configuring RADIUS .................................................................................................. 228
Monitoring RADIUS............................................................................................. 229
Configuring TACACS ................................................................................................. 229
Monitoring TACACS............................................................................................ 229
Configuring TACACS Plus......................................................................................... 230
Monitoring TACACS Plus ................................................................................... 231
Configuring Passwords............................................................................................... 231
Chapter 15: QoS Configuration Guide................................................. 233
QoS & Layer-2, -3, and -4 Flow Overview ....................................................................... 233
Layer-2, -3, and -4 Flow Specification ....................................................................... 234
Precedence for Layer-3 Flows .................................................................................... 234
IA Queuing Policies ..................................................................................................... 235
Traffic Prioritization for Layer-2 Flows............................................................................ 235
Configuring Layer-2 QoS ............................................................................................ 236
Traffic Prioritization for Layer-3 and -4 Flows ............................................................... 236
Configuring IP QoS Policies ....................................................................................... 236
Setting an IP QoS Policy....................................................................................... 237
Specifying Precedence for an IP QoS Policy ..................................................... 237
Configuring IA Queueing Policy ...................................................................................... 237
Allocating Bandwidth for a Weighted-Fair Queuing Policy ................................. 238
ToS Rewrite .......................................................................................................................... 238
Configuring ToS Rewrite for IP Packets ................................................................... 239
Monitoring QoS ................................................................................................................... 241
Limiting Traffic Rate ........................................................................................................... 241
Example Configuration ............................................................................................... 242
Displaying Rate Limit Information ........................................................................... 242
Chapter 16: Performance Monitoring Guide....................................... 243
Performance Monitoring Overview ................................................................................. 243
Configuring the IA for Port Mirroring ............................................................................. 245
Monitoring Broadcast Traffic............................................................................................. 245
Chapter 17: RMON Configuration Guide............................................. 247
RMON Overview ................................................................................................................ 247
Configuring and Enabling RMON.................................................................................... 248
Example of RMON Configuration Commands ....................................................... 248
RMON Groups ............................................................................................................. 249
Lite RMON Groups .............................................................................................. 250
Standard RMON Groups ..................................................................................... 250
Professional RMON Groups................................................................................ 250
Control Tables............................................................................................................... 251
Using RMON ....................................................................................................................... 252 xx Internet Appliance User Reference Manual
Contents
Configuring RMON Groups...............................................................................................254
Configuration Examples ..............................................................................................256
Displaying RMON Information .........................................................................................257
RMON CLI Filters.........................................................................................................258
Creating RMON CLI Filters .................................................................................259
Using RMON CLI Filters ......................................................................................259
Troubleshooting RMON .....................................................................................................260
Allocating Memory to RMON............................................................................................261
Internet Appliance User Reference Manual xxi
Preface
About This Manual
This manual provides detailed information and procedures for configuring the software for the Cabletron
™
Internet Appliance (IA). If you have not yet installed the IA, follow the instructions in the Internet Appliance 1100/1200 Getting Started Guide to install the chassis and perform basic setup tasks. Then return to this manual for more detailed configuration information.
Who Should Read This Manual?
Read this manual if you are a network administrator responsible for configuring and monitoring the IA.
Related Documentation
The Internet Appliance documentation set includes the following items. Refer to these documents to learn more about the IA.
For information about…
Installing and setting up the IA
The complete syntax for all command line interface commands
System messages
Refer to…
Internet Appliance 1100/1200 Getting Started
Guide
Internet Appliance Command Line Interface
Reference
Internet Appliance Error Reference
Internet Appliance User Reference Manual xxiii
Chapter 1
Introduction
This chapter provides information that you need to know before configuring the Internet
Appliance (IA) software. If you have not yet installed the IA, follow the instructions in the
Internet Appliance 1100/1200 Getting Started Guide to install the chassis and perform basic setup tasks. Then return to this manual for more detailed configuration information.
Reviewing Configuration Files
The Internet Appliance 1100/1200 Getting Started Guide introduced the following configuration files used by the IA:
• Startup – The configuration file that the IA uses to configure itself when the system is powered on. The Startup configuration remains even when the system is rebooted.
• Active – The commands from the Startup configuration file and any configuration commands that you have made active from the scratchpad. The active configuration remains in effect until you power down or reboot the system.
• Scratchpad – The configuration commands you have entered during a CLI session.
These commands are temporary and do not become active until you explicitly make them part of the active configuration.
Note: Because some commands depend on other commands for successful execution, the IA scratchpad simplifies system configuration by allowing you to enter configuration commands in any order, even when dependencies exist. When you activate the commands in the scratchpad, the IA sorts out the dependencies and executes the command in the proper sequence.
Entering commands and saving configuration files are discussed in more detail in the following section.
Internet Appliance User Reference Manual 25
Chapter 1: Introduction
Using the Command Line Interface
The CLI allows you to enter and execute commands from the IA Console or from Telnet sessions. Up to four simultaneous Telnet sessions are allowed. CLI commands are grouped by subsystems. For example, the set of commands that let you configure and display IP routing table information all start with ip . Within the set of ip commands are commands such as set , show , start , stop , configure , etc. The complete set of commands for each subsystem is described in the Internet Appliance Command Line Interface Reference
Manual .
Command Modes
The CLI provides access to four different command modes. Each command mode provides a group of related commands. This section describes how to access and list the commands available in each command mode and explains the primary uses for each command mode.
User Mode
After you log in to the IA, you are automatically in User mode. The User commands available are a subset of those available in Enable mode. In general, the User commands allow you to display basic information and use basic utilities such as ping.
The User mode command prompt consists of the ia name followed by the angle bracket
( > ), as shown below: ia>
The default name is ia unless it has been changed during initial configuration. Refer to the
Internet Appliance 1100/1200 Getting Started Guide for the procedures for changing the system name.
26 Internet Appliance User Reference Manual
Chapter 1: Introduction
Enable Mode
Enable mode provides more facilities than User mode. You can display critical features within Enable mode including router configuration, access control lists, and SNMP statistics. To enter Enable mode from the User mode, enter the command enable (or en ), and then supply the password when prompted.
The Enable mode command prompt consists of the ia name followed by the pound sign ( # ): ia#
To exit Enable mode and return to User mode, either type exit and press Return or press
Ctrl+Z.
Configure Mode
Configure mode provides the capabilities to configure all features and functions on the IA.
These include router configuration, access control lists, and spanning tree. To enter
Configure mode, enter the command config from Enable mode.
Note: As mentioned previously, up to four Telnet sessions can be run simultaneously on the IA. All four sessions can be in Configure mode at the same time, so you should consider limiting access to the IA to authorized users.
The Configure mode command prompt consists of the ia name followed by (config) and a pound sign ( # ): ia(config)#
To exit Configure mode and return to Enable mode, either type exit and press Return or press Ctrl+Z.
Boot PROM Mode
If your IA does not find a valid system image on the external PCMCIA flash, the system might enter programmable read-only memory (PROM) mode. You should then reboot the
IA (enter the command reboot at the boot PROM prompt) to restart the system. If the system fails to reboot successfully, call Cabletron Systems, Inc., Technical Support to resolve the problem.
For information on how to upgrade the boot PROM software and boot using the upgraded image, see the Internet Appliance 1100/1200 Getting Started Guide .
Internet Appliance User Reference Manual 27
Chapter 1: Introduction
Getting Help with CLI Commands
Interactive help is available from the CLI by entering the question mark (?) character at any time. The help is context-sensitive; the help provided is based on where in the command you are. For example, if you are at the User mode prompt, enter a question mark (?), as shown in the following example, to list the commands available in User mode: ia> ?
aging
cli
enable
exit
file
help
ip-redundancy
- Show L2 and L3 Aging information
- Modify the command line interface behavior
- Enable privileged user mode
- Exit current mode
- File manipulation commands
- Describe online help facility
- Show IP Redundancy information (VRRP)
l2-tables
logout
multicast
ping
- Show L2 Tables information
- Log off the system
- Configure Multicast related parameters
- Ping utility
pvst - Show Per Vlan Spanning Tree Protocol (PVST)
parameters
statistics
stp
- Show or clear IA statistics
- Show STP status
telnet
traceroute
vlan
- Telnet utility
- Traceroute utility
- Show VLAN-related parameters
You can also type the ?
character following a command to see a description of the parameters or options that you can enter. Once the help information is displayed, the command line is redisplayed as before but without the ? character. The following is an example of invoking help while entering a command: ia(config)# load-balance create ?
group-name - Name of this Load Balanced group of servers
vip-range-name - Name of this Virtual IP range ia(config)# load-balance create
If you enter enough characters of a command keyword to uniquely identify it and press the space bar, the CLI attempts to complete the command. If you do not enter enough characters or you enter the wrong characters, the CLI cannot complete the command. For example, if you enter the following in Enable mode and press the spacebar as indicated: ia# system show e[space] the CLI completes the command as follows: ia# system show environmental
28 Internet Appliance User Reference Manual
Chapter 1: Introduction
If you are entering several commands for the same subsystem, you can enter the subsystem name from the CLI. Then, execute individual commands for the subsystem without typing the subsystem name each time. For example, if you are configuring several entries for the IP routing table, you can simply enter ip at the CLI Configure prompt. The prompt changes to indicate that the context for the commands to be entered has changed to that of the IP subsystem. If you type a ?, only those commands that are valid for the IP subsystem are displayed. The following is an example: ia(config)# ip ia(config)(ip)# ?
add - Add a static route
dos - Configure specific denial of service features
disable - Disable certain IP function
enable - Enable certain IP function
helper-address - Specify IP helper address for an interface
l3-hash - Change IP hash variant for channel
set - Set ip stack properties
Ctrl-z - Exits to previous level
top - Exits to the top level ia(config)(ip)# [Ctrl-Z] ia(config)#
Line Editing Commands
The IA provides line editing capabilities that are similar to Emacs, a UNIX text editor. For example, you can use certain line editing keystrokes to move forwards or backwards on a line, delete or transpose characters, and delete portions of a line. To use the line editing commands, you need to have a VT-100 terminal or terminal emulator. The line editing commands that you can use with CLI are detailed in the following table:
Command
Ctrl-a
Ctrl-b
Ctrl-c
Ctrl-d
Ctrl-e
Ctrl-f
Ctrl-g
Ctrl-h
Ctrl-i
Ctrl-j
Resulting Action
Move to beginning of line
Move back one character
Abort current line
Delete character under cursor
Move to end of line
Move forward one character
Abort current line
Delete character just prior to the cursor
Insert one space (tab substitution)
Carriage return (executes command)
Internet Appliance User Reference Manual 29
Chapter 1: Introduction
Command
Ctrl-k
Ctrl-l
Ctrl-m
Ctrl-n
Ctrl-o
Ctrl-p
Ctrl-q
Ctrl-r
Ctrl-s
Ctrl-t
Ctrl-u
Ctrl-v
Ctrl-w
Ctrl-x
Ctrl-y
Ctrl-z
ESC-b
ESC-d
ESC-f
ESC-
BackSpace
SPACE
!*
Resulting Action
Kill line from cursor to end of line
Refresh current line
Carriage return (executes command)
Next command from history buffer
None
Previous command from history buffer
None
Refresh current line
None
Transpose character under cursor with the character just prior to the cursor
Delete line from the beginning of line to cursor
None
None
Move forward one word
Paste back what was deleted by the previous Ctrl-k or Ctrl-w command. Text is pasted back at the cursor location.
If inside a subsystem, it exits back to the top level. If in Enable mode, it exits back to User mode. If in Configure mode, it exits back to Enable mode.
Move backward one word
Kill word from cursor’s current location until the first white space
Move forward one word
Delete backwards from cursor to the previous space (essentially a delete-word-backward command)
Attempts to complete command keyword. If word is not expected to be a keyword, the space character is inserted.
Show all commands currently stored in the history buffer.
30 Internet Appliance User Reference Manual
Chapter 1: Introduction
Command
!#
“<string>”
Resulting Action
Recall a specific history command. # is the number of the history command to be recalled as shown via the !* command.
Opaque strings may be specified using double quotes. This prevents interpretation of otherwise special CLI characters.
Displaying and Changing Configuration Information
The IA provides many commands for displaying and changing configuration information.
For example, the CLI allows for the disabling of a command in the active configuration.
Use the negate command on a specific line of the active configuration to disable a feature or function that has been enabled. For example, Spanning Tree Protocol is disabled by default. If, after enabling the Spanning Tree Protocol on the IA, you want to disable STP, you must specify the negate command with the line number in the active configuration that contains the stp enable command.
The following table shows some useful commands for configuring the IA:
Task Command
Enable Mode:
Show active configuration of the system.
Show the non-activated configuration changes in the scratchpad. system show active-config system show scratchpad
Show the startup configuration for the next reboot.
system show startup-config
Copy between scratchpad, active configuration, startup configuration, TFTP server, RCP server, or
URL.
copy <source> to <destination>
Configure Mode:
Show the running system configuration and the non-activated changes in the scratchpad.
show diff <filename> | startup Compare activated commands with the startup configuration file.
Erase commands in the scratchpad.
Erase the startup configuration.
Negate one or more commands by line number.
Negate commands that match a specified command string.
erase scratchpad erase startup negate no
<line number>
<string>
Internet Appliance User Reference Manual 31
Chapter 1: Introduction
Task
Save scratchpad to the active configuration.
Save the active configuration to startup.
Command save active save startup
The following figure illustrates the configuration files and the commands you can use to save your configuration:
Scratchpad temporary location; contents lost at reboot
Active in effect until reboot
Startup remains through reboot
(config)# save active (config)# save startup
Figure 1. Commands to Save Configurations
32 Internet Appliance User Reference Manual
Chapter 1: Introduction
Identifying Ports on the IA-1100 and IA-1200
The term port refers to a physical connector installed in the IA-1100 and IA-1200. Each port in the IA is referred to by the type of connector (Ethernet or Gigabit Ethernet) and its location.
Figure 2 shows the names of the ports on the IA-1100; et stands for Ethernet, and gi stands for Gigabit Ethernet.
et.3 .1 –et.3.8
g i.4.1
gi.4.2
3
10/100BASE-TX 1
1
1 2 3 4
2 3 4
5 6 7
10/100BASE-TX
8
5 6 7 8 10/100 MGMT
OK
ERR
HBT
DIAG
CONSOLE
Tx Link
1
Rx AN
2 3
1
4
Tx Link
Rx AN
5 6
2
7
1000BASE-SX
4
8 10/100BASE-TX
2 et.1 .1 –et.1.8
Figure 2. Port Names on the IA-1100 et.2 .1– et.2.8
Figure 3 shows the names of the ports on the IA-1200; et stands for Ethernet, and gi stands for Gigabit Ethernet.
gi.3 .1 gi.3.2
g i.4.1
gi.4 .2
3
Rx AN
Tx Link
1
Tx Link
Rx AN
1
1 g i.1.1
Tx Link
Rx AN
Tx Link
Rx AN
2
2 10/100 MGMT
CONSOLE
Tx Link
Rx AN
Tx Link
Rx AN
1
1
OK HBT
ERR DIAG g i.1.2
gi.2.1
Figure 3. Port Names on the IA-1200
Tx Link
Rx AN
Tx Link
Rx AN
2
2 g i.2.2
4
2
There are a few shortcut notations you can use to refer to a range of port numbers. For example:
• et.(1-3).(1-8) refers to the following ports: et.1.1 through et.1.8, et.2.1 through et.2.8, and et.3.1 through et.3.8.
• et.(1,3).(1-8) refers to the following ports: et.1.1 through et.1.8, and et.3.1 through et.3.8.
• et.(1-3).(1,8) refers to the following ports: et.1.1, et.1.8, et.2.1, et.2.8, et.3.1, et.3.8.
Internet Appliance User Reference Manual 33
Chapter 2
Bridging
Configuration
Guide
Bridging Overview
The Internet Appliance (IA) provides the following bridging functions:
• Compliance with the IEEE 802.1d standard
• Wire-speed address-based bridging or flow-based bridging
• Ability to logically segment a transparently bridged network into virtual local-area networks (VLANs) based on physical ports or protocol (IP or bridged protocols such as AppleTalk
®
)
• Integrated routing and bridging that supports bridging of intra-VLAN traffic and routing of inter-VLAN traffic
Spanning Tree (IEEE 802.1d)
Spanning tree (IEEE 802.1d) allows bridges to dynamically discover a subset of the topology that is loop free. In addition, the loop-free tree that is discovered contains paths to every LAN segment.
Internet Appliance User Reference Manual 35
Chapter 2: Bridging Configuration Guide
Bridging Modes (Flow-Based and Address-Based)
The IA provides the following types of wire-speed bridging:
Address-based bridging - The IA performs this type of bridging by looking up the destination address in a Layer-2 lookup table on the line card that receives the bridge packet from the network. The Layer-2 lookup table indicates the exit port(s) for the bridged packet. If the packet is addressed to the IA's own MAC address, the packet is routed rather than bridged.
Flow-based bridging - The IA performs this type of bridging by looking up an entry in the Layer-2 lookup table containing both the source and destination addresses of the received packet in order to determine how the packet is to be handled.
The IA ports perform address-based bridging by default, but can be configured to perform flow-based bridging instead, on a per-port basis. A port cannot be configured to perform both types of bridging at the same time.
The IA performance is equivalent when performing flow-based bridging or address-based bridging. However, address-based bridging is more efficient because it requires fewer table entries while flow-based bridging provides tighter management and control over bridged traffic.
VLAN Overview
Virtual LANs (VLANs) are a means of dividing a physical network into several logical
(virtual) LANs. The division can be done on the basis of various criteria, giving rise to different types of VLANs. For example, the simplest type of VLAN is the port-based
VLAN. Port-based VLANs divide a network into a number of VLANs by assigning a
VLAN to each port of a switching device. Then, any traffic received on a given port of a switch belongs to the VLAN associated with that port.
VLANs are primarily used for broadcast containment. A Layer-2 broadcast frame is normally transmitted all over a bridged network. By dividing the network into VLANs, the range of a broadcast is limited, that is, the broadcast frame is transmitted only to the
VLAN to which it belongs. This reduces the broadcast traffic on a network by an appreciable factor.
36 Internet Appliance User Reference Manual
Chapter 2: Bridging Configuration Guide
The type of VLAN depends upon one criterion: how a received frame is classified as belonging to a particular VLAN. VLANs can be categorized into the following types:
• Port-based
• MAC address-based
• Protocol-based
• Subnet-based
• Policy-based
Detailed information about these types of VLANs is beyond the scope of this manual.
Each type of VLAN is briefly explained in the following subsections.
Port-Based VLANs
Ports of Layer-2 devices (switches, bridges) are assigned to VLANs. Any traffic received by a port is classified as belonging to the VLAN to which the port belongs. For example, if ports 1, 2, and 3 belong to the VLAN named Marketing , then a broadcast frame received by port 1 is transmitted on ports 2 and 3. It is not transmitted on any other port.
MAC Address-Based VLANs
In this type of VLAN, each switch (or a central VLAN information server) keeps track of all MAC addresses in a network and maps them to VLANs based on information configured by the network administrator. When a frame is received at a port, its destination MAC address is looked up in the VLAN database. The VLAN database returns the name of the VLAN to which this frame belongs.
This type of VLAN is powerful in the sense that network devices such as printers and workstations can be moved anywhere in the network without the need for network reconfiguration. However, the administration is intensive because all MAC addresses on the network need to be known and configured.
Protocol-Based VLANs
Protocol-based VLANs divide the physical network into logical VLANs based on protocol. When a frame is received at a port, its VLAN is determined by the protocol of the packet. For example, there could be separate VLANs for IP and AppleTalk. An IP broadcast frame will only be sent to all ports in the IP VLAN.
Internet Appliance User Reference Manual 37
Chapter 2: Bridging Configuration Guide
Subnet-Based VLANs
Subnet-based VLANs are a subset of protocol-based VLANs and determine the VLAN of a frame based on the subnet to which the frame belongs. To do this, the switch must look into the network layer header of the incoming frame. This type of VLAN behaves similarly to a router by segregating different subnets into different broadcast domains.
Policy-Based VLANs
Policy-based VLANs are the most general definition of VLANs. Each incoming
(untagged) frame is looked up in a policy database, which determines the VLAN to which the frame belongs. For example, you could set up a policy that creates a special VLAN for all email traffic between the management officers of a company so that this traffic will not be seen anywhere else.
IA VLAN Support
The IA supports the following VLANs:
• Port-based
• Protocol-based
• Subnet-based
When using the IA as a Layer-2 bridge/switch, use the port-based and protocol-based
VLAN types. When using the IA as a combined switch and router, use the subnet-based
VLANs in addition to port-based and protocol-based VLANs. It is not necessary to remember the types of VLANs in order to configure the IA, as seen in the section on configuring the IA.
VLANs and the IA
VLANs are an integral part of the IA family of switching routers. The IA switching routers can function as Layer-2 switches as well as fully functional Layer-3 routers. Hence, they can be viewed as a switch and a router in one box. To provide maximum performance and functionality, the Layer-2 and Layer-3 aspects of the IA switching routers are tightly coupled.
The IA can be used purely as a Layer-2 switch. Frames arriving at any port are bridged and not routed. In this case, setting up VLANs and associating ports with VLANs is all that is required. You can set up the IA switching router to use port-based VLANs, protocol-based VLANs, or a mixture of the two types.
38 Internet Appliance User Reference Manual
Chapter 2: Bridging Configuration Guide
The IA can also be used purely as a router, that is, each physical port of the IA is a separate routing interface. Packets received at any interface are routed and not bridged. In this case, no VLAN configuration is required. Note that VLANs are still created implicitly by the IA as a result of creating Layer-3 interfaces for IP. However, these implicit VLANs do not need to be created or configured manually. The implicit VLANs created by the IA are subnet-based VLANs.
Most commonly, an IA is used as a combined switch and router. For example, it may be connected to two subnets: S1 and S2. Ports 1 through 8 belong to S1, and ports 9 through
16 belong to S2. The required behavior of the IA is that intra-subnet frames be bridged and inter-subnet packets be routed. In other words, traffic between two workstations that belong to the same subnet should be bridged, and traffic between two workstations that belong to different subnets should be routed.
The IA switching routers use VLANs to achieve this behavior. This means that a Layer-3 subnet (that is, an IP subnet) is mapped to a VLAN. A given subnet maps to exactly one and only one VLAN. With this definition, the terms VLAN and subnet are almost interchangeable.
To configure an IA as a combined switch and router, the administrator must create VLANs whenever multiple ports of the IA are to belong to a particular VLAN/subnet. Then the
VLAN must be bound to a Layer-3 (IP) interface so that the IA knows which VLAN maps to which IP subnet.
Ports, VLANs, and Layer-3 Interfaces
The term port refers to a physical connector on the IA, such as an Ethernet port. Each port must belong to at least one VLAN. When the IA is unconfigured, each port belongs to a
VLAN called the default VLAN . By creating VLANs and adding ports to the created
VLANs, the ports are moved from the default VLAN to the newly created VLANs.
Unlike traditional routers, the IA has the concept of logical interfaces rather than physical interfaces. A Layer-3 interface is a logical entity created by the administrator. It can contain more than one physical port. When a Layer-3 interface contains exactly one physical port, it is equivalent to an interface on a traditional router. When a Layer-3 interface contains several ports, it is equivalent to an interface of a traditional router that is connected to a Layer-2 device such as a switch or bridge.
Access Ports and Trunk Ports (802.1Q Support)
The ports of an IA can be classified into two types, based on VLAN functionality: access ports and trunk ports . By default, a port is an access port. An access port can belong to at most one VLAN of the following type: IP or bridged protocols. The IA can automatically determine whether or not a received frame is an IP frame. Based on this, it selects a VLAN for the frame. Frames transmitted out of an access port are untagged , meaning that they contain no special information about the VLAN to which they belong. Untagged frames
Internet Appliance User Reference Manual 39
Chapter 2: Bridging Configuration Guide are classified as belonging to a particular VLAN based on the protocol of the frame and the VLAN configured on the receiving port for that protocol.
For example, if port 1 belongs to VLAN IP_VLAN for IP and VLAN OTHER_VLAN for any other protocol, then an IP frame received by port 1 is classified as belonging to VLAN
IP_VLAN .
Trunk ports (802.1Q) are usually used to connect one VLAN-aware switch to another.
They carry traffic belonging to several VLANs. For example, suppose that IA A and B are both configured with VLANs V1 and V2.
Then a frame arriving at a port on IA A must be sent to IA B if the frame belongs to VLAN
V1 or to VLAN V2. Thus, the ports on IA A and B that connect the two IAs must belong to both VLAN V1 and VLAN V2. Also, when these ports receive a frame, they must be able to determine whether the frame belongs to V1 or to V2. This is accomplished by tagging the frames, that is, by prepending information to the frame in order to identify the VLAN to which the frame belongs. In the IA switching routers, trunk ports always transmit and receive tagged frames only. The format of the tag is specified by the IEEE 802.1Q standard.
The only exception to this is Spanning Tree Protocol frames, which are transmitted as untagged frames.
Explicit and Implicit VLANs
As mentioned earlier, VLANs can either be created explicitly by the administrator (explicit
VLANs) or are created implicitly by the IA when Layer-3 interfaces are created (implicit
VLANs).
Configuring IA Bridging Functions
Configuring Address-Based or Flow-Based Bridging
The IA ports perform address-based bridging by default, but can be configured to perform flow-based bridging instead of address-based bridging on a per-port basis. A port cannot be configured to perform both types of bridging at the same time.
The IA performance is equivalent when performing flow-based bridging or address-based bridging. However, address-based bridging is more efficient because it requires fewer table entries, while flow-based bridging provides tighter management and control over bridged traffic.
40 Internet Appliance User Reference Manual
Chapter 2: Bridging Configuration Guide
For example, the following illustration shows an IA with traffic being sent from port A to port B, port B to port A, port B to port C, and port A to port C.
IA
A B C
The corresponding bridge tables for address-based and flow-based bridging are shown in the following table. The bridge table contains more information on the traffic patterns when flow-based bridging is enabled compared to address-based bridging.
Address-Based Bridge Table Flow-Based Bridge Table
A (source)
B (source)
C (destination)
A
→
B
B → A
B → C
A
→
C
With the IA configured in flow-based bridging mode, the network manager has per-flow control of Layer-2 traffic. The network manager can then apply Quality of Service (QoS) policies based on Layer-2 traffic flows.
To enable flow-based bridging on a port, enter the following command in Configure mode.
Configure a port for flow-based bridging. port flow-bridging <port-list> |all-ports
To change a port from flow-based bridging to address-based bridging, enter the following command in Configure mode:
Change a port from flow-based bridging to address-based bridging. negate <line-number of active config containing command> : port flow-bridging <portlist> |all-ports
Internet Appliance User Reference Manual 41
Chapter 2: Bridging Configuration Guide
Configuring Spanning Tree
The IA supports per VLAN spanning tree. By default, all the VLANs defined belong to the default spanning tree. You can create a separate instance of spanning tree using the following command:
Create spanning tree for a VLAN. pvst create spanningtree vlan-name
<string>
By default, spanning tree is disabled on the IA. To enable spanning tree on the IA, you perform the following tasks on the ports where you want spanning tree enabled.
stp enable port <port-list> Enable spanning tree on one or more ports for default spanning tree.
Enable spanning tree on one or more ports for a particular VLAN.
pvst enable port
<string>
<port-list> spanning-tree
Adjusting Spanning-Tree Parameters
You may need to adjust certain spanning-tree parameters if the default values are not suitable for your bridge configuration. Parameters affecting the entire spanning tree are configured with variations of the bridge global configuration command. Interface-specific parameters are configured with variations of the bridge-group interface configuration command.
You can adjust spanning-tree parameters by performing any of the tasks in the next two sections:
• “Setting the Bridge Priority”
• “Setting a Port Priority”
Note: Only network administrators with a good understanding of how bridges and the
Spanning-Tree Protocol work should make adjustments to spanning-tree parameters. Poorly chosen adjustments to these parameters can have a negative impact on performance. A good source on bridging is the IEEE 802.1d specification.
42 Internet Appliance User Reference Manual
Chapter 2: Bridging Configuration Guide
Setting the Bridge Priority
You can globally configure the priority of an individual bridge when two bridges tie for position as the root bridge, or you can configure the likelihood that a bridge will be selected as the root bridge. The lower the bridge's priority, the more likely the bridge will be selected as the root bridge. This priority is determined by default; however, you can change it.
To set the bridge priority, enter the following command in Configure mode:
Set the bridge priority for default spanning tree.
Set the bridge priority for a particular instance of spanning tree.
stp set bridging priority <num> pvst set bridging spanning-tree <string> priority <num>
Setting a Port Priority
You can set a priority for an interface. When two bridges tie for position as the root bridge, you configure an interface priority to break the tie. The bridge with the lowest interface value is elected.
To set an interface priority, enter the following command in Configure mode:
Establish a priority for a specified interface for default spanning tree.
Establish a priority for a specified interface for a particular instance of spanning tree.
stp set port <port-list> priority <num> pvst set port <port-list> spanning-tree
<string> priority <num>
Assigning Port Costs
Each interface has a port cost associated with it. By convention, the port cost is 1000/data rate of the attached LAN, in Mbps. You can set different port costs.
To assign port costs, enter the following command in Configure mode:
Set a different port cost other than the defaults for default spanning tree.
Set a different port cost other than the defaults for a particular instance of spanning tree.
stp set port <port-list> port-cost <num> pvst set port <port-list> spanning-tree
<string> port-cost <num>
Internet Appliance User Reference Manual 43
Chapter 2: Bridging Configuration Guide
Adjusting Bridge Protocol Data Unit (BPDU) Intervals
You can adjust BPDU intervals as described in the next three sections:
• “Adjusting the Interval between Hello Times”
• “Defining the Forward Delay Interval”
• “Defining the Maximum Age”
Adjusting the Interval between Hello Times
You can specify the interval between hello time.
To adjust this interval, enter the following command in Configure mode: stp set bridging hello-time <num> Specify the interval between hello time for default spanning tree.
Specify the interval between hello time for a particular instance of spanning tree.
pvst set bridging spanning-tree hello-time <num>
<string>
Defining the Forward Delay Interval
The forward delay interval is the amount of time spent listening for topology change information after an interface has been activated for bridging and before forwarding actually begins.
To change the default interval setting, enter the following command in Configure mode:
Set the default of the forward delay interval for default spanning tree.
Set the default of the forward delay interval for a particular instance of spanning tree.
stp set bridging forward-delay <num> pvst set bridging spanning-tree <string> forward-delay <num>
44 Internet Appliance User Reference Manual
Chapter 2: Bridging Configuration Guide
Defining the Maximum Age
If a bridge does not hear BPDUs from the root bridge within a specified interval, it assumes that the network has changed and recomputes the spanning-tree topology.
To change the default interval setting, enter the following command in Configure mode:
Change the amount of time a bridge will wait to hear BPDUs from the root bridge for default spanning tree.
Change the amount of time a bridge will wait to hear BPDUs from the root bridge for a particular instance of spanning tree.
stp set bridging max-age <num> pvst set bridging spanning-tree
<string> max-age <num>
Configuring a Port- or Protocol-Based VLAN
To create a port- or protocol-based VLAN, perform the following steps in the Configure mode:
1.
Create a port or protocol based VLAN.
2.
Add physical ports to a VLAN.
Creating a Port- or Protocol-Based VLAN
To create a VLAN, enter the following command in Configure mode:
Create a VLAN.
vlan create <vlan-name> <type> id <num>
Adding Ports to a VLAN
To add ports to a VLAN, enter the following command in Configure mode.
Add ports to a VLAN.
vlan add ports <port-list> to <vlan-name>
Internet Appliance User Reference Manual 45
Chapter 2: Bridging Configuration Guide
Configuring VLAN Trunk Ports
The IA supports standards-based VLAN trunking between multiple IAs as defined by
IEEE 802.1Q. 802.1Q adds a header to a standard Ethernet frame that includes a unique
VLAN ID per trunk between two IAs. These VLAN IDs extend the VLAN broadcast domain to more than one IA.
To configure a VLAN trunk, enter the following command in the Configure mode.:
Configure 802.1Q VLAN trunks.
vlan make <port-type> <port-list>
Configuring VLANs for Bridging
The IA allows you to create VLANs for AppleTalk, DECnet
™
, SNA, and IPv6 traffic as well as for IP traffic. You can create a VLAN for handling traffic for a single protocol, such as a DECnet VLAN, or you can create a VLAN that supports several specific protocols, such as SNA and IP traffic.
Monitoring Bridging
The IA provides a display of bridging statistics and configurations contained in the IA.
To display bridging information, enter the following commands in Enable mode:
Show IP routing table.
Show all MAC addresses currently in the l2 tables.
Show l2 table information on a specific port.
Show information the master MAC table.
Show information on a specific
MAC address.
Show information on MACs registered.
Show all VLANs.
ip show routes l2-tables show all-macs l2-tables show port-macs l2-tables show mac-table-stats l2-tables show mac l2-table show bridge-management vlan show
46 Internet Appliance User Reference Manual
Chapter 2: Bridging Configuration Guide
Configuration Examples
VLANs are used to associate physical ports on the IA with connected hosts that may be physically separated but need to participate in the same broadcast domain. To associate ports to a VLAN, you must first create a VLAN and then assign ports to the VLAN. This section shows examples of creating an IP VLAN and a DECnet, SNA, and AppleTalk
VLAN.
Creating an IP VLAN
In this example, servers connected to ports gi.1.1 and gi.1.2 on the IA need to communicate with clients connected to ports et.4.1 through et.4.8. You can associate all the ports containing the clients and servers to an IP VLAN named BLUE .
First, enter the following command to create an IP VLAN named BLUE : ia(config)# vlan create BLUE ip
Next, enter the following command to assign ports to the VLAN named BLUE : ia(config)# vlan add ports et.4.(1-8),gi.1.(1-2) to BLUE
Creating a Non-IP VLAN
In this example, SNA, DECnet, and AppleTalk hosts are connected to ports et.1.1 and et.2.1 through et.2.4. You can associate all the ports containing these hosts to a VLAN named RED with the VLAN ID 5.
First, enter the following command to create a VLAN named RED : ia(config)# vlan create RED sna dec appletalk id 5
Next, enter the following command to assign ports to the RED VLAN: ia(config)# vlan add ports et.1.1, et.2.(1-4) to RED
Internet Appliance User Reference Manual 47
Chapter 3
SmartTRUNK
Configuration
Guide
Overview
This chapter explains how to configure and monitor SmartTRUNKs on the Internet
Appliance (IA). A SmartTRUNK is Cabletron’s technology for load balancing and load sharing. For a description of the SmartTRUNK commands, see the “ smarttrunk
Command” section of the Internet Appliance Command Line Interface Reference .
On the IA, a SmartTRUNK is a group of two or more ports that have been logically combined into a single port. Multiple physical connections between devices are aggregated into a single logical high-speed path that acts as a single link. Traffic is balanced across all interfaces in the combined link, thereby increasing overall available system bandwidth.
SmartTRUNKs allow administrators to increase bandwidth at congestion points in the network, thus eliminating potential traffic bottlenecks. SmartTRUNKs also provide improved data-link resiliency. If one port in a SmartTRUNK should fail, its load is distributed evenly among the remaining ports and the entire SmartTRUNK link remains operational.
SmartTRUNK is Cabletron’s standard for building high-performance links between
Cabletron’s switching platforms. SmartTRUNKs can interoperate with switches, routers, and servers from other vendors as well as Cabletron platforms.
SmartTRUNKs are compatible with all IA features, including VLANs, STP, VRRP, etc.
SmartTRUNK operation is supported over different media types and a variety of technologies including 10/100/1000 Mbps Ethernet.
Internet Appliance User Reference Manual 49
Chapter 3: SmartTRUNK Configuration Guide
Configuring SmartTRUNKs
To create a SmartTRUNK
1.
Create a SmartTRUNK, and specify a control protocol for it.
2.
Add physical ports to the SmartTRUNK.
3.
Specify the policy for distributing traffic across SmartTRUNK ports. This step is optional; by default, the IA distributes traffic to ports in a round-robin (sequential) manner.
Creating a SmartTRUNK
When you create a SmartTRUNK, you specify whether the DEC
®
Hunt Group control protocol is to be used or no control protocol is to be used according to the following criteria:
• If you are connecting the SmartTRUNK to another IA, other Cabletron devices (such as the SmartSwitch
™
6000 or SmartSwitch 9000), or DIGITAL GIGAswitch
™
/Router, specify the DEC Hunt Group control protocol. The Hunt Group protocol is useful in detecting errors such as transmit/receive failures, and misconfiguration.
• If you are connecting the SmartTRUNK to a device that does not support the DEC Hunt
Group control protocol, such as those devices that support Cisco’s EtherChannel
® technology, specify no control protocol. Only link failures are detected in this mode.
To create a SmartTRUNK, enter the following command in Configure mode:
Create a SmartTRUNK that will be connected to a device that supports the DEC Hunt Group control protocol.
Create a SmartTRUNK that will be connected to a device that does not support the DEC Hunt Group control protocol.
smarttrunk create <smarttrunk> protocol huntgroup smarttrunk create <smarttrunk> protocol no-protocol
50 Internet Appliance User Reference Manual
Chapter 3: SmartTRUNK Configuration Guide
Add Physical Ports to the SmartTRUNK
You can add any number of ports to a SmartTRUNK. The limit is the number of ports on the IA. Any port on any module can be part of a SmartTRUNK. If one module fails, the remaining ports on other modules remain operational.
Ports added to a SmartTRUNK must:
• Be set to full-duplex.
• Be in the same VLAN.
• Have the same properties (Layer-2 aging, STP state, and so on).
To add ports to a SmartTRUNK, enter the following command in Configure mode:
Create a SmartTRUNK that will be connected to a device that supports the DEC Hunt Group control protocol.
smarttrunk add ports <port list> to
<smarttrunk>
Specify Traffic Distribution Policy (Optional)
The default policy for distributing traffic across the ports in a SmartTRUNK is round-robin , where the IA selects the port on a rotating basis. The other policy that can be chosen is linkutilization , where packets are sent to the least-used port in a SmartTRUNK. You can choose to specify the link-utilization policy for a particular SmartTRUNK, a list of
SmartTRUNKs, or for all SmartTRUNKs on the IA.
Specify traffic distribution policy.
smarttrunk set load-policy on <smarttrunk list> |all-smarttrunks round-robin|linkutilization
Internet Appliance User Reference Manual 51
Chapter 3: SmartTRUNK Configuration Guide
Monitoring SmartTRUNKs
Statistics are gathered for data flowing through a SmartTRUNK and each port in the
SmartTRUNK.
To display SmartTRUNK statistics, enter one of the following commands in Enable mode:
Display information about all
SmartTRUNKS and the control protocol used.
Display statistics on traffic distribution on SmartTRUNK.
Display information about the control protocol on a SmartTRUNK.
Display information about the
SmartTRUNK connection (DEC
Hunt Group control protocol connections only).
smarttrunk show trunks smarttrunk show distribution
< smarttrunk list> |all-smarttrunks smarttrunk show protocol-state
< smarttrunk list> |all-smarttrunks smarttrunk show connections < smarttrunk list> |all-smarttrunks
To clear statistics for SmartTRUNK ports, enter the following command in Enable mode:.
Clear load distribution statistics for SmartTRUNK ports.
smarttrunk clear load-distribution
< smarttrunk list> |all-smarttrunk
52 Internet Appliance User Reference Manual
Chapter 3: SmartTRUNK Configuration Guide
Example Configurations
The following illustration shows a network design based on SmartTRUNKs. R1 is an IA operating as a router, while S1 and S2 are IAs operating as switches.
Cisco
7500
Router
10.1.1.1/24 st.1
10.1.1.2/24 to-cisco st.2
Router
R1
12.1.1.2/24 to-s2
11.1.1.2/24 to-s1 st.3
Switch
S1 st.4
Server
Switch
S2 st.5
Cisco
Catalyst
®
5K Switch
The following is the configuration for the Cisco 7500 router: interface port-channel 1 ip address 10.1.1.1 255.255.255.0
ip route-cache distributed interface fasteth 0/0 no ip address channel-group 1
The following is the configuration for the Cisco Catalyst 5K switch: set port channel 3/1-2 on
Internet Appliance User Reference Manual 53
Chapter 3: SmartTRUNK Configuration Guide
The following is the SmartTRUNK configuration for the IA labeled R1 in the diagram: smarttrunk create st.1 protocol no-protocol smarttrunk create st.2 protocol huntgroup smarttrunk create st.3 protocol huntgroup smarttrunk add ports et.1(1-2) to st.1
smarttrunk add ports et.2(1-2) to st.2
smarttrunk add ports et.3(1-2) to st.3
interface create ip to-cisco address-netmask 10.1.1.2/24 port st.1
interface create ip to-s1 address-netmask 11.1.1.2/24 port st.2
interface create ip to-s2 address-netmask 12.1.1.2/24 port st.3
The following is the SmartTRUNK configuration for the IA labeled S1 in the diagram: smarttrunk create st.2 protocol huntgroup smarttrunk create st.4 protocol no-protocol smarttrunk add ports et.1(1-2) to st.2
smarttrunk add ports et.2(1-2) to st.4
The following is the SmartTRUNK configuration for the IA labeled S2 in the diagram: smarttrunk create st.3 protocol huntgroup smarttrunk create st.5 protocol no-protocol smarttrunk add ports et.1(1-2) to st.3
smarttrunk add ports et.2(1-2) to st.5
54 Internet Appliance User Reference Manual
Chapter 4
IP Routing
Configuration
Guide
This chapter describes how to configure IP interfaces and general non-protocol-specific routing parameters.
IP Routing Overview
Internet Protocol (IP) is a packet-based protocol used to exchange data over computer networks. IP handles addressing, routing, fragmentation, reassembly, and protocol demultiplexing. In addition, IP specifies how hosts and routers should process packets, handle errors, and discard packets. IP forms the foundation upon which transport layer protocols, such as TCP or UDP, interoperate over a routed network.
The Transmission Control Protocol (TCP) is built upon the IP layer. TCP is a connectionoriented protocol that specifies the data format, buffering, and acknowledgments used in the transfer of data. TCP is a full-duplex connection that also specifies the procedures that the computers use to ensure that the data arrives correctly.
The User Datagram Protocol (UDP) provides the primary mechanism that applications use to send datagrams to other application programs. UDP is a connectionless protocol that does not guarantee delivery of datagrams between applications. Applications that use UDP are responsible for ensuring successful data transfer by employing error handling, retransmission, and sequencing techniques.
Internet Appliance User Reference Manual 55
Chapter 4: IP Routing Configuration Guide
TCP and UDP also specify ports that identify the application that is using TCP/UDP. For example, a web server would typically use TCP/UDP port 80, which specifies HTTP-type traffic.
The IA supports standards-based TCP, UDP, and IP.
IP Routing Protocols
The Internet Appliance (IA) supports standards-based unicast routing. Unicast routing protocol support includes Interior Gateway Protocols and Exterior Gateway Protocols.
Interior Gateway Protocols are used for routing networks that are within an autonomous system , a network of relatively limited size. All IP Interior Gateway Protocols must be specified with a list of associated networks before routing activities can begin. A routing process listens to updates from other routers on these networks and broadcasts its own routing information on those same networks. The IA supports the following Interior
Gateway Protocols:
• Routing Information Protocol (RIP) Version 1, 2 (RFC 1058, 1723)
• Open Shortest Path First (OSPF) Version 2 (RFC 1583)
Exterior Gateway Protocols are used to transfer information between different autonomous systems. The IA supports the following Exterior Gateway Protocol:
• Border Gateway Protocol (BGP), Version 3, 4 (RFC 1267, 1771)
Configuring IP Interfaces and Parameters
This section provides an overview of configuring various IP parameters and setting up IP interfaces.
Configuring IP Addresses to Ports
You can configure one IP interface directly to physical ports. Each port can be assigned multiple IP addresses representing multiple subnets connected to the physical port.
To configure an IP interface to a port, enter one of the following commands in Configure mode:
Configure an IP interface to a physical port.
Configure a secondary address to an existing IP interface.
interface create ip <InterfaceName> address-mask <ipAddr-mask> port <port> interface add ip <InterfaceName> address-netmask <ipAddr-mask>
[broadcast <ipaddr> ]
56 Internet Appliance User Reference Manual
Chapter 4: IP Routing Configuration Guide
Configuring IP Interfaces for a VLAN
You can configure one IP interface per VLAN. Once an IP interface has been assigned to a
VLAN, you can add a secondary IP addresses to the VLAN.
To configure a VLAN with an IP interface, enter the following command in Configure mode:
Create an IP interface for a VLAN.
interface create ip <InterfaceName> address-mask <ipAddr-mask> vlan <name>
Configure a secondary address to an existing VLAN.
interface add ip <InterfaceName> address-netmask <ipAddr-mask> vlan <name>
Specifying Ethernet Encapsulation Method
The IA supports two encapsulation types for IP. You can configure encapsulation type on a per-interface basis.
• Ethernet II: The standard ARPA Ethernet Version 2.0 encapsulation, which uses a 16-bit protocol type code (the default encapsulation method)
• 802.3 SNAP: SNAP IEEE 802.3 encapsulation, in which the type code becomes the frame length for the IEEE 802.2 LLC encapsulation (destination and source Service
Access Points and a control byte)
To configure IP encapsulation, enter one of the following commands in Configure mode:
Configure Ethernet II encapsulation.
Configure 802.3
SNAP encapsulation.
interface create ip <InterfaceName> output-mac-encapsulation ethernet_II interface create ip <InterfaceName> output-mac-encapsulation ethernet_snap
Configuring Address Resolution Protocol (ARP)
The IA allows you to configure Address Resolution Protocol (ARP) table entries and parameters. ARP is used to associate IP addresses with media or MAC addresses. Taking an IP address as input, ARP determines the associated MAC address. Once a media or
MAC address is determined, the IP address/media address association is stored in an
ARP cache for rapid retrieval. Then the IP datagram is encapsulated in a link-layer frame and sent over the network.
Internet Appliance User Reference Manual 57
Chapter 4: IP Routing Configuration Guide
Configuring ARP Cache Entries
You can add and delete entries in the ARP cache. To add or delete static ARP entries, enter one of the following commands in Configure mode:
Add a static ARP entry.
Clear a static ARP entry.
arp add <host> mac-addr <MAC-addr> exit-port <port> arp clear <host>
Configuring Proxy ARP
The IA can be configured for proxy ARP. The IA uses proxy ARP (as defined in
RFC 1027) to help hosts with no knowledge of routing to determine the MAC address of hosts on other networks or subnets. Through Proxy ARP, the IA will respond to ARP requests from a host with a ARP reply packet containing the IA MAC address. Proxy ARP is enabled by default on the IA.
To disable proxy ARP, enter the following command in Configure mode:
Disable Proxy ARP on an interface.
ip disable-proxy-arp interface <InterfaceName> |all
Configuring DNS Parameters
The IA can be configured to specify DNS servers, which supply name services for DNS requests. You can specify up to three DNS servers.
To configure DNS servers, enter the following command in Configure mode:
Configure a DNS server.
system set dns server <IPaddr>
[, <IPaddr> [, <IPaddr> ]]
You can also specify a domain name for the IA. The domain name is used by the IA to respond to DNS requests.
To configure a domain name, enter the following command in Configure mode:
Configure a domain name.
system set dns domain <name>
58 Internet Appliance User Reference Manual
Chapter 4: IP Routing Configuration Guide
Configuring IP Services (ICMP)
The IA provides ICMP message capabilities, including ping and traceroute. Ping allows you to determine the reachability of a certain IP host. Traceroute allows you to trace the IP gateways to an IP host.
To access ping or traceroute on the IA, enter the following commands in Enable mode:
Specify ping.
ping <hostname-or-IPaddr> packets <num> wait <num> [flood] [dontroute] size <num>
Specify traceroute.
traceroute <host> [max-ttl <num> ] [probes <num> ]
[size <num> ] [source <secs> ] [tos <num> ]
[wait-time <secs> ] [verbose] [noroute]
Configuring IP Helper
You can configure the IA to forward UDP broadcast packets received on a given interface to all other interfaces or to a specified IP address. You can specify a UDP port number for which UDP broadcast packets with that destination port number will be forwarded. By default, if no UDP port number is specified, the IA will forward UDP broadcast packets for the following five services:
• DNS (port 37)
• NetBIOS Name Server (port 137)
• NetBIOS Datagram Server (port 138)
• TACACS Server (port 49)
• Time Service (port 37)
To configure a destination to which UDP packets will be forwarded, enter the following command in Configure mode:
Specify local subnet interface, destination helper IP address, and UDP port number to forward.
ip helper-address interface <interface-name>
<helper-address> | all-interfaces [ <udp-port#> ]
Internet Appliance User Reference Manual 59
Chapter 4: IP Routing Configuration Guide
Configuring Direct Broadcast
You can configure the IA to forward all directed broadcast traffic from the local subnet to a specified IP address or all associated IP addresses. This is a more efficient method than defining only one local interface and remote IP address destination at a time with the ip-helper command when you are forwarding traffic from more than one interface in the local subnet to a remote destination IP address.
To forward all directed broadcast traffic to a specified IP address, enter the following command in Configure mode:
Forward directed broadcast traffic.
ip enable directed-broadcast interface
<interface name> |all
Configuring Denial of Service (DOS)
By default, the IA installs flows in the hardware so that packets sent as directed broadcasts are dropped in hardware, if directed broadcast is not enabled on the interface where the packet is received. You can disable this feature, causing directed broadcast packets to be processed on the IA even if directed broadcast is not enabled on the interface receiving the packet.
Similarly, the IA installs flows to drop packets destined for the IA for which service is not provided by the IA. This prevents packets for unknown services from slowing the CPU.
You can disable this behavior, causing these packets to be processed by the CPU.
Disables the directedbroadcast-protection feature of the IA.
Disables the port-attackprotection feature of the IA.
ip dos disable directed-broadcast-protection ip dos disable port-attack-protection
60 Internet Appliance User Reference Manual
Chapter 4: IP Routing Configuration Guide
Monitoring IP Parameters
The IA provides display of IP statistics and configurations contained in the routing table.
Information displayed provides routing and performance information.
To display IP information, enter the following commands in Enable mode:
Show ARP table entries.
arp show all
Show IP interface configuration.
Show all TCP/UDP connections and services.
interface show ip ip show connections [no-lookup]
Show configuration of IP interfaces.
ip show interfaces [ <interface-name> ]
Show IP routing table information.
ip show routes
Show ARP entries in routing table.
ip show routes show-arps
Show DNS parameters.
system show dns
Configuration Examples
Assigning IP Interfaces
To enable routing on the IA, you must assign an IP interface to a VLAN. To assign an IP interface named RED to the BLUE VLAN, enter the following command: ia(config)# interface create ip RED address-netmask
10.50.0.1/255.255.0.0 vlan BLUE
You can also assign an IP interface directly to a physical port. For example, to assign IP interface RED to physical port et.3.4, enter the following command: ia(config)# interface create ip RED address-netmask
10.50.0.0/255.255.0.0 port et.3.4
Internet Appliance User Reference Manual 61
Chapter 5
VRRP
Configuration
Guide
VRRP Overview
This chapter explains how to set up and monitor the Virtual Router Redundancy Protocol
(VRRP) on the Internet Appliance (IA). VRRP is defined in RFC 2338.
En- host systems on a LAN are often configured to send packets to a statically configured default router. If this default router becomes unavailable, all the hosts that use it as their first hop router become isolated on the network. VRRP provides a way to ensure the availability of an end host’s default router.
This is done by assigning IP addresses that end hosts use as their default route to a virtual router . A Master router is assigned to forward traffic designated for the virtual router. If the Master router becomes unavailable, a Backup router takes over and begins forwarding traffic for the virtual router. As long as one of the routers in a VRRP configuration is up, the IP addresses assigned to the virtual router are always available and the end hosts can send packets to these IP addresses without interruption.
Internet Appliance User Reference Manual 63
Chapter 5: VRRP Configuration Guide
Configuring VRRP
This section presents three sample VRRP configurations:
• A basic VRRP configuration with one virtual router
• A symmetrical VRRP configuration with two virtual routers
• A multi-backup VRRP configuration with three virtual routers
Basic VRRP Configuration
Figure 4 shows a basic VRRP configuration with a single virtual router. Routers R1 and R2 are both configured with one virtual router ( VRID=1 ). Router R1 serves as the Master and
Router R2 serves as the Backup. The four end hosts are configured to use 10.0.0.1/16 as the default route. IP address 10.0.0.1/16 is associated with virtual router VRID=1 .
Master Backup
R1
Interface Addr. = 10.0.0.1/16
VRID=1 ; Addr. = 10.0.0.1/16
VRID=1
10.0.0.1/16
R2
Interface Addr. = 10.0.0.2/16
VRID=1 ; Addr. = 10.0.0.1/16
H1 H2 H3 H4
Default Route = 10.0.0.1/16
Figure 4. Basic VRRP Configuration
If Router R1 becomes unavailable, Router R2 takes over virtual router VRID=1 and its associated IP addresses. Packets sent to 10.0.0.1/16 go to Router R2. When Router R1 comes up again, it takes over as Master, and Router R2 reverts to Backup.
64 Internet Appliance User Reference Manual
Chapter 5: VRRP Configuration Guide
Configuration of Router R1
The following is the configuration file for Router R1 in Figure 4 :
1: interface create ip test address-netmask 10.0.0.1/16 port et.1.1
2: ip-redundancy create vrrp 1 interface test
3: ip-redundancy associate vrrp 1 interface test address 10.0.0.1/16
4: ip-redundancy start vrrp 1 interface test
Line 1 adds IP address 10.0.0.1/16 to interface test, making Router R1 the owner of this IP address. Line 2 creates virtual router VRID=1 on interface test. Line 3 associates IP address
10.0.0.1/16 with virtual router VRID=1 . Line 4 starts VRRP on interface test.
In VRRP, the router that owns the IP address associated with the virtual router is the
Master. Any other routers that participate in this virtual router are Backups. In this configuration, Router R1 is the Master for virtual router VRID=1 because it owns
10.0.0.1/16, the IP address associated with virtual router VRID=1 .
Configuration for Router R2
The following is the configuration file for Router R2 in Figure 4 :
1: interface create ip test address-netmask 10.0.0.2/16 port et.1.1
2: ip-redundancy create vrrp 1 interface test
3: ip-redundancy associate vrrp 1 interface test address 10.0.0.1/16
4: ip-redundancy start vrrp 1 interface test
The configuration for Router R2 is nearly identical to Router R1. The difference is that
Router R2 does not own IP address 10.0.0.1/16. Since Router R2 does not own this IP address, it is the Backup. It takes over from the Master if the Master becomes unavailable.
Symmetrical Configuration
Figure 5 shows a VRRP configuration with two routers and two virtual routers. Routers
R1 and R2 are both configured with two virtual routers ( VRID=1 and VRID=2 ).
Router R1 serves as:
• Master for VRID=1
• Backup for VRID=2
Router R2 serves as:
• Master for VRID=2
• Backup for VRID=1
Internet Appliance User Reference Manual 65
Chapter 5: VRRP Configuration Guide
This configuration allows you to load-balance traffic coming from the hosts on the
10.0.0.0/16 subnet and provides a redundant path to either virtual router.
Note: This is the recommended configuration on a network using VRRP.
Master for VRID=1
Backup for VRID=2
R1
Interface Addr. = 10.0.0.1/16
VRID=1 ; Addr. = 10.0.0.1/16
VRID=2 ; Addr. = 10.0.0.2/16
VRID=1
10.0.0.1/16
Master for VRID=2
Backup for VRID=1
R2
VRID=2
10.0.0.2/16
Interface Addr. = 10.0.0.2/16
VRID=1 ; Addr. = 10.0.0.1/16
VRID=2 ; Addr. = 10.0.0.2/16
H1 H2 H3 H4
Default Route = 10.0.0.1/16 Default Route = 10.0.0.2/16
Figure 5. Symmetrical VRRP Configuration
In this configuration, half the hosts use 10.0.0.1/16 as their default route, and half use
10.0.0.2/16. IP address 10.0.0.1/16 is associated with virtual router VRID=1 , and IP address
10.0.0.2/16 is associated with virtual router VRID=2 .
If Router R1, the Master for virtual router VRID=1 , goes down, Router R2 takes over the IP address 10.0.0.1/16. Similarly, if Router R2, the Master for virtual router VRID=2 , goes down, Router R1 takes over the IP address 10.0.0.2/16.
66 Internet Appliance User Reference Manual
Chapter 5: VRRP Configuration Guide
Configuration of Router R1
The following is the configuration file for Router R1 in Figure 5 :
1: interface create ip test address-netmask 10.0.0.1/16 port et.1.1
!
2: ip-redundancy create vrrp 1 interface test
3: ip-redundancy create vrrp 2 interface test
!
4: ip-redundancy associate vrrp 1 interface test address 10.0.0.1/16
5: ip-redundancy associate vrrp 2 interface test address 10.0.0.2/16
!
6: ip-redundancy start vrrp 1 interface test
7: ip-redundancy start vrrp 2 interface test
Router R1 is the owner of IP address 10.0.0.1/16. Line 4 associates this IP address with virtual router VRID=1 , so Router R1 is the Master for virtual router VRID=1 .
On line 5, Router R1 associates IP address 10.0.0.2/16 with virtual router VRID=2 .
However, since Router R1 does not own IP address 10.0.0.2/16, it is not the default Master for virtual router VRID=2 .
Configuration of Router R2
The following is the configuration file for Router R2 in Figure 5 :
1: interface create ip test address-netmask 10.0.0.2/16 port et.1.1
!
2: ip-redundancy create vrrp 1 interface test
3: ip-redundancy create vrrp 2 interface test
!
4: ip-redundancy associate vrrp 1 interface test address 10.0.0.1/16
5: ip-redundancy associate vrrp 2 interface test address 10.0.0.2/16
!
6: ip-redundancy start vrrp 1 interface test
7: ip-redundancy start vrrp 2 interface test
On line 1, Router R2 is made owner of IP address 10.0.0.2/16. Line 5 associates this IP address with virtual router VRID=2 , so Router R2 is the Master for virtual router VRID=2 .
Line 4 associates IP address 10.0.0.1/16 with virtual router VRID=1 , making Router R2 the
Backup for virtual router VRID=1 .
Internet Appliance User Reference Manual 67
Chapter 5: VRRP Configuration Guide
Multi-Backup Configuration
Figure 6 shows a VRRP configuration with three routers and three virtual routers. Each router serves as a Master for one virtual router and as a Backup for each of the others.
When a Master router goes down, one of the Backups takes over the IP addresses of its virtual router.
In a VRRP configuration where more than one router is backing up a Master, you can specify which Backup router takes over when the Master goes down by setting the priority for the Backup routers.
Master for VRID=1
1st Backup for VRID=2
1st Backup for VRID=3
R1
VRID=1
10.0.0.1/16
Master for VRID=2
1st Backup for VRID=1
2nd Backup for VRID=3
R2
VRID=2
10.0.0.2/16
Master for VRID=3
2nd Backup for VRID=1
2nd Backup for VRID=2
R3
VRID=3
10.0.0.3/16
68
H1 H2 H3 H4 H5 H6
Default Route = 10.0.0.1/16 Default Route = 10.0.0.2/16 Default Route = 10.0.0.3/16
Figure 6. Multi-Backup VRRP Configuration
In this configuration, Router R1 is the Master for virtual router VRID=1 and the primary
Backup for virtual routers VRID=2 and VRID=3 . If Router R2 or R3 go down, Router R1 assumes the IP addresses associated with virtual routers VRID=2 and VRID=3 .
Router R2 is the Master for virtual router VRID=2 , the primary Backup for virtual router
VRID=1 , and the secondary Backup for virtual router VRID=3 . If Router R1 fails, Router R2 becomes the Master for virtual router VRID=1 . If both Routers R1 and R3 fail, Router R2 becomes the Master for all three virtual routers. All packets sent to IP addresses
10.0.0.1/16, 10.0.0.2/16, and 10.0.0.3/16 go to Router R2.
Router R3 is the secondary Backup for virtual routers VRID=1 and VRID=2 . Router R3 becomes a Master router only if both Routers R1 and R2 fail. In this case, Router R3 becomes the Master for all three virtual routers.
Internet Appliance User Reference Manual
Chapter 5: VRRP Configuration Guide
Configuration of Router R1
The following is the configuration file for Router R1 in Figure 6 :
1: interface create ip test address-netmask 10.0.0.1/16 port et.1.1
!
2: ip-redundancy create vrrp 1 interface test
3: ip-redundancy create vrrp 2 interface test
4: ip-redundancy create vrrp 3 interface test
!
5: ip-redundancy associate vrrp 1 interface test address 10.0.0.1/16
6: ip-redundancy associate vrrp 2 interface test address 10.0.0.2/16
7: ip-redundancy associate vrrp 3 interface test address 10.0.0.3/16
!
8: ip-redundancy set vrrp 2 interface test priority 200
9: ip-redundancy set vrrp 3 interface test priority 200
!
10: ip-redundancy start vrrp 1 interface test
11: ip-redundancy start vrrp 2 interface test
12: ip-redundancy start vrrp 3 interface test
Router R1’s IP address on interface test is 10.0.0.1. There are three virtual routers on this interface:
• VRID=1 – IP address=10.0.0.1/16
• VRID=2 – IP address=10.0.0.2/16
• VRID=3 – IP address=10.0.0.3/16
Since the IP address of virtual router VRID=1 is the same as the interface’s IP address
(10.0.0.1), then the router automatically becomes the address owner of virtual router
VRID=1 .
A priority is associated with each of the virtual routers. The priority determines whether the router becomes the Master or the Backup for a particular virtual router. Priorities can have values between 1 and 255. When a Master router goes down, the router with the next-highest priority takes over the virtual router. If more than one router has the nexthighest priority, the router that has the highest-numbered interface IP address becomes the Master.
If a router is the address owner for a virtual router, then its priority for that virtual router is 255 and cannot be changed. If a router is not the address owner for a virtual router, then the router’s priority for that virtual router is 100 by default and can be changed by the user.
Since Router R1 is the owner of the IP address associated with virtual router VRID=1 , it has a priority of 255 (the highest) for virtual router VRID=1 . Lines 8 and 9 set Router R1’s priority for virtual routers VRID=2 and VRID=3 at 200. If no other routers in the VRRP configuration have a higher priority, Router R1 will take over as Master for virtual routers
VRID=2 and VRID=3 should Router R2 or R3 go down.
Internet Appliance User Reference Manual 69
Chapter 5: VRRP Configuration Guide
The following table shows the priorities for each virtual router configured on Router R1:
Virtual Router
VRID=1 – IP address=10.0.0.1/16
VRID=2 – IP address=10.0.0.2/16
VRID=3 – IP address=10.0.0.3/16
Default Priority
255 (address owner)
100
100
Configured Priority
255 (address owner)
200 (see line 8)
200 (see line 9)
Configuration of Router R2
The following is the configuration file for Router R2 in Figure 6 :
1: interface create ip test address-netmask 10.0.0.2/16 port et.1.1
!
2: ip-redundancy create vrrp 1 interface test
3: ip-redundancy create vrrp 2 interface test
4: ip-redundancy create vrrp 3 interface test
!
5: ip-redundancy associate vrrp 1 interface test address 10.0.0.1/16
6: ip-redundancy associate vrrp 2 interface test address 10.0.0.2/16
7: ip-redundancy associate vrrp 3 interface test address 10.0.0.3/16
!
8: ip-redundancy set vrrp 1 interface test priority 200
9: ip-redundancy set vrrp 3 interface test priority 100
!
10: ip-redundancy start vrrp 1 interface test
11: ip-redundancy start vrrp 2 interface test
12: ip-redundancy start vrrp 3 interface test
Line 8 sets the Backup priority for virtual router VRID=1 to 200. Since this number is higher than Router R3’s Backup priority for virtual router VRID=1 , Router R2 is the primary Backup and Router R3 is the secondary Backup for virtual router VRID=1 .
On line 9, the Backup priority for virtual router VRID=3 is set to 100. Since Router R1’s
Backup priority for this virtual router is 200, Router R1 is the primary Backup and Router
R2 is the secondary Backup for virtual router VRID=3 .
70 Internet Appliance User Reference Manual
Chapter 5: VRRP Configuration Guide
The following table shows the priorities for each virtual router configured on Router R2:
Virtual Router
VRID=1 – IP address=10.0.0.1/16
VRID=2 – IP address=10.0.0.2/16
VRID=3 – IP address=10.0.0.3/16
Default Priority
100
255 (address owner)
100
Configured Priority
200 (see line 8)
255 (address owner)
100 (see line 9)
Note: Since 100 is the default priority, line 9, which sets the priority to 100, is actually unnecessary. It is included for illustration purposes only.
Configuration of Router R3
The following is the configuration file for Router R3 in Figure 6 :
1: interface create ip test address-netmask 10.0.0.3/16 port et.1.1
!
2: ip-redundancy create vrrp 1 interface test
3: ip-redundancy create vrrp 2 interface test
4: ip-redundancy create vrrp 3 interface test
!
5: ip-redundancy associate vrrp 1 interface test address 10.0.0.1/16
6: ip-redundancy associate vrrp 2 interface test address 10.0.0.2/16
7: ip-redundancy associate vrrp 3 interface test address 10.0.0.3/16
!
8: ip-redundancy set vrrp 1 interface test priority 100
9: ip-redundancy set vrrp 2 interface test priority 100
!
10: ip-redundancy start vrrp 1 interface test
11: ip-redundancy start vrrp 2 interface test
12: ip-redundancy start vrrp 3 interface test
Lines 8 and 9 set the Backup priority for Router R3 at 100 for virtual routers VRID=1 and
VRID=2 . Since Router R1 has a priority of 200 for backing up virtual router VRID=2 , and
Router R2 has a priority of 200 for backing up virtual router VRID=1 , Router R3 is the secondary Backup for both virtual routers VRID=1 and VRID=2 .
Internet Appliance User Reference Manual 71
Chapter 5: VRRP Configuration Guide
The following table shows the priorities for each virtual router configured on Router R3:
Virtual Router
VRID=1 – IP address=10.0.0.1/16
VRID=2 – IP address=10.0.0.2/16
VRID=3 – IP address=10.0.0.3/16
Default Priority
100
100
255 (address owner)
Configured Priority
100 (see line 8)
100 (see line 9)
255 (address owner)
Note: Since 100 is the default priority, lines 8 and 9, which set the priority to 100, are actually unnecessary. They are included for illustration purposes only.
Additional Configuration
This section covers settings you can modify in a VRRP configuration, including Backup priority, advertisement interval, pre-empt mode, and authentication key.
Setting the Backup Priority
As described in “Multi-Backup Configuration” on page 68 , you can specify which Backup router takes over when the Master router goes down by setting the priority for the Backup routers. To set the priority for a Backup router, enter the following command in Configure mode:
Set the Backup priority for a virtual router.
ip-redundancy set vrrp <vrid> interface
<interface> priority <number>
The priority can be between 1 (lowest) and 254. The default is 100. The priority for the IP address owner is 255 and cannot be changed.
Setting the Advertisement Interval
The VRRP Master router sends periodic advertisement messages to let the other routers know that the Master is up and running. By default, advertisement messages are sent once each second. To change the VRRP advertisement interval, enter the following command in
Configure mode:
Set the Advertisement interval for a virtual router.
ip-redundancy set vrrp <vrid> interface
<interface> adv-interval <seconds>
72 Internet Appliance User Reference Manual
Chapter 5: VRRP Configuration Guide
Setting Pre-empt Mode
When a Master router goes down, the Backup with the highest priority takes over the IP addresses associated with the Master. By default, when the original Master comes back up, it takes over from the Backup router that assumed its role as Master. When a VRRP router does this, it is said to be in pre-empt mode . Pre-empt mode is enabled by default on the IA. You can prevent a VRRP router from taking over from a lower-priority Master by disabling pre-empt mode. To do this, enter the following command in Configure mode:
Disable pre-empt mode for a virtual router.
ip-redundancy set vrrp
<interface>
<vrid> interface
preempt-mode disabled
Note: If the IP address owner is available, then it will always take over as the Master, regardless of whether pre-empt mode is on or off.
Setting an Authentication Key
By default, no authentication of VRRP packets is performed on the IA. You can specify a clear-text password to be used to authenticate VRRP exchanges. To enable authentication, enter the following command in Configure mode:
Set an authentication key for a virtual router.
ip-redundancy set vrrp <vrid> interface
<interface> auth-type text auth-key <key> where <key> is a clear-text password.
Note: The IA does not currently support the IP Authentication Header method of authentication.
Internet Appliance User Reference Manual 73
Chapter 5: VRRP Configuration Guide
Monitoring VRRP
The IA provides two commands for monitoring a VRRP configuration: ip-redundancy trace , which displays messages when VRRP events occur, and ip-redundancy show , which reports statistics about virtual routers.
ip-redundancy trace
The ip-redundancy trace command is used for troubleshooting purposes. This command causes messages to be displayed when certain VRRP events occur on the IA. To trace
VRRP events, enter the following commands in Enable mode:
Display a message when any
VRRP event occurs. (Disabled by default.)
Display a message when a
VRRP router changes from one state to another; for example
Backup to Master. (Enabled by default.)
Display a message when a
VRRP packet error is detected.
(Enabled by default.)
Enable all VRRP tracing.
ip-redundancy trace vrrp events enabled ip-redundancy trace vrrp state-transitions enabled ip-redundancy trace vrrp packet-errors enabled ip-redundancy trace vrrp all enabled
ip-redundancy show
The ip-redundancy show command reports information about a VRRP configuration. To display VRRP information, enter the following commands in Enable mode:
Display information about all virtual routers.
Display information about all virtual routers on a specified interface.
Display detailed statistics about a specific virtual router ip-redundancy show vrrp ip-redundancy show vrrp interface <interface> ip-redundancy show vrrp <vrid> interface
<interface> verbose
74 Internet Appliance User Reference Manual
Chapter 5: VRRP Configuration Guide
VRRP Configuration Notes
• The Master router sends keep-alive advertisements. The frequency of these keep-alive advertisements is determined by setting the Advertisement interval parameter. The default value is 1 second.
• If a Backup router doesn’t receive a keep-alive advertisement from the current Master within a certain period of time, it will transition to the Master state and start sending advertisements itself. The amount of time that a Backup router will wait before it becomes the new Master is based on the following equation:
Master-down-interval = (3 * advertisement-interval) + skew-time
The skew-time depends on the Backup router's configured priority:
Skew-time = ( (256 - Priority) / 256 )
Therefore, the higher the priority, the faster a Backup router will detect that the Master is down. For example:
– Default advertisement-interval = 1 second
– Default Backup router priority = 100
– Master-down-interval = time it takes a Backup to detect the Master is down
= (3 * adv-interval) + skew-time
= (3 * 1 second) + ((256 - 100) / 256)
= 3.6 seconds
• If a Master router is manually rebooted, or if its interface is manually brought down, it will send a special keep-alive advertisement that lets the Backup routers know that a new Master is needed immediately.
• A virtual router will respond to ARP requests with a virtual MAC address. This virtual
MAC depends on the virtual router ID: virtual MAC address = 00005E:0001 XX where XX is the virtual router ID
This virtual MAC address is also used as the source MAC address of the keep-alive
Advertisements transmitted by the Master router.
• If multiple virtual routers are created on a single interface, the virtual routers must have unique identifiers. If virtual routers are created on different interfaces, you can reuse virtual router IDs.
For example, the following configuration is valid: ip-redundancy create vrrp 1 interface test-A ip-redundancy create vrrp 1 interface test-B
Internet Appliance User Reference Manual 75
Chapter 5: VRRP Configuration Guide
• As specified in RFC 2338, a Backup router that has transitioned to Master will not respond to pings, accept telnet sessions, or field SNMP requests directed at the virtual router's IP address.
Not responding allows network management to notice that the original Master router
(i.e., the IP address owner) is down.
76 Internet Appliance User Reference Manual
Chapter 6
RIP Configuration
Guide
RIP Overview
This chapter describes how to configure the Routing Information Protocol (RIP) on the
Internet Appliance (IA). RIP is a distance-vector routing protocol for use in small networks. RIP is described in RFC 1723. A router running RIP broadcasts updates at set intervals. Each update contains paired values where each pair consists of an IP network address and an integer distance to that network. RIP uses a hop count metric to measure the distance to a destination.
The IA provides support for RIP Version 1 and 2. The IA implements plain text and MD5 authentication methods for RIP Version 2.
The protocol independent features that apply to RIP are described in Chapter 4, “IP
Routing Configuration Guide.”
Internet Appliance User Reference Manual 77
Chapter 6: RIP Configuration Guide
Configuring RIP
By default, RIP is disabled on the IA and on each of the attached interfaces. To configure
RIP on the IA, follow these steps:
1.
Start the RIP process by entering the rip start command.
2.
Use the rip add interface command to inform RIP about the attached interfaces.
Enabling and Disabling RIP
To enable or disable RIP, enter one of the following commands in Configure mode:
Enable RIP.
Disable RIP.
rip start rip stop
Configuring RIP Interfaces
To configure RIP in the IA, you must first add interfaces to inform RIP about attached interfaces.
To add RIP interfaces, enter the following commands in Configure mode: rip add interface <interfacename-or-IPaddr> Add interfaces to the RIP process.
Add gateways from which the IA will accept RIP updates.
Define the list of routers to which RIP sends packets directly, not through multicast or broadcast.
rip add trusted-gateway <interfacename-or-IPaddr> rip add source-gateway <interfacename-or-IPaddr>
78 Internet Appliance User Reference Manual
Chapter 6: RIP Configuration Guide
Configuring RIP Parameters
No further configuration is required, and the system default parameters will be used by
RIP to exchange routing information. These default parameters may be modified to suit your needs by using the rip set interface command.
RIP Parameter Default Value
Version number
Check-zero for RIP reserved parameters
Whether RIP packets should be broadcast
Preference for RIP routes
RIP v1
Enabled
Choose
100
Metric for incoming routes
Metric for outgoing routes
1
0
Authentication None
Update interval 30 seconds
To change RIP parameters, enter the following commands in Configure mode.
Set RIP Version on an interface to RIP V1.
Set RIP Version on an interface to RIP V2.
Specify that RIP V2 packets should be multicast on this interface.
Specify that RIP V2 packets that are RIP V1-compatible should be broadcast on this interface.
Change the metric on incoming
RIP routes.
Change the metric on outgoing
RIP routes.
Set the authentication method to simple text up to 8 characters.
Set the authentication method to MD5.
rip set interface <interfacename-or-IPaddr> |all version 1 rip set interface <interfacename-or-IPaddr> |all version 2 rip set interface type multicast
<interfacename-or-IPaddr> |all rip set interface <interfacename-or-IPaddr> |all type broadcast rip set interface <interfacename-or-IPaddr> |all metric-in <num> rip set interface <interfacename-or-IPaddr> |all metric-out <num> rip set interface <interfacename-or-IPaddr> |all authentication-method simple rip set interface <interfacename-or-IPaddr> |all authentication-method md5
Internet Appliance User Reference Manual 79
Chapter 6: RIP Configuration Guide
Specify the metric to be used when advertising routes that were learned from other protocols.
Enable automatic summarization and redistribution of RIP routes.
Specify broadcast of RIP packets regardless of number of interfaces present.
Check that reserved fields in incoming RIP V1 packets are zero.
Enable acceptance of RIP routes that have a metric of zero.
Enable poison reverse, as specified by RFC 1058.
rip set default-metric <num> rip set auto-summary disable|enable rip set broadcast-state always|choose|never rip set check-zero disable|enable rip set check-zero-metric disable|enable rip set poison-reverse disable|enable
Configuring RIP Route Preference
You can set the preference of routes learned from RIP.
To configure RIP route preference, enter the following command in Configure mode:
Set the preference of routes learned from RIP.
rip set preference <num>
Configuring RIP Route Default-Metric
You can define the metric used when advertising routes via RIP that were learned from other protocols. The default value for this parameter is 16 (unreachable). To export routes from other protocols into RIP, you must explicitly specify a value for the default-metric parameter. The metric specified by the default-metric parameter may be overridden by a metric specified in the export command.
To configure default-metric, enter the following command in Configure mode:
Define the metric used when advertising routes via RIP that were learned from other protocols.
rip set default-metric <num>
For <num> , you must specify a number between 1 and 16.
80 Internet Appliance User Reference Manual
Chapter 6: RIP Configuration Guide
Monitoring RIP
The rip trace command can be used to trace all rip request and response packets.
To monitor RIP information, enter the following commands in Enable mode:
Show all RIP information.
Show RIP export policies.
Show RIP global information.
Show RIP import policies.
Show RIP information on the specified interface.
Show RIP interface policy information.
Show detailed information of all RIP packets.
Show detailed information of all packets received by the router.
Show detailed information of all packets sent by the router.
Show detailed information of all request received by the router.
Show detailed information of all response received by the router.
Show detailed information of response packets sent by the router.
Show detailed information of request packets sent by the router.
Show RIP timer information.
rip show all rip show export-policy rip show globals rip show import-policy rip show interface <Name or IP-addr> rip show interface-policy rip trace packets detail rip trace packets receive rip trace packets send rip trace request receive rip trace response receive rip trace response send rip trace send request rip show timers
Internet Appliance User Reference Manual 81
Chapter 6: RIP Configuration Guide
Configuration Example
IA 1
Interface 1.1.1.1
IA 2
Interface 3.2.1.1
! Example configuration
!
! Create interface IA 1-if1 with ip address 1.1.1.1/16 on port et.1.1 on
IA -1 interface create ip IA 1-if1 address-netmask 1.1.1.1/16 port et.1.1
!
! Configure rip on IA -1 rip add interface IA 1-if1 rip set interface IA 1-if1 version 2 rip start
!
!
! Set authentication method to md5 rip set interface IA 1-if1 authentication-method md5
!
! Change default metric-in rip set interface IA 1-if1 metric-in 2
!
! Change default metric-out rip set interface IA 1-if1 metric-out 3
82 Internet Appliance User Reference Manual
Chapter 7
OSPF
Configuration
Guide
OSPF Overview
Open Shortest Path First (OSPF) is a link-state routing protocol that supports IP subnetting and authentication. The Internet Appliance (IA) supports OSPF Version 2.0 as defined in RFC 1583. Each link-state message contains all the links connected to the router with a specified cost associated with the link.
The IA supports the following OSPF functions:
• Stub Areas: Definition of stub areas is supported.
• Authentication: Simple password and MD5 authentication methods are supported within an area.
• Virtual Links: Virtual links are supported.
• Route Redistribution: Routes learned via RIP, BGP, or any other sources can be redistributed into OSPF. OSPF routes can be redistributed into RIP or BGP.
• Interface Parameters: Parameters that can be configured include interface output cost, retransmission interval, interface transmit delay, router priority, router dead and hello intervals, and authentication key.
Internet Appliance User Reference Manual 83
Chapter 7: OSPF Configuration Guide
OSPF Multipath
The IA also supports OSPF and static Multi-path. If multiple equal-cost OSPF or static routes have been defined for any destination, then the IA discovers and uses all of them.
The IA will automatically learn up to four equal-cost OSPF or static routes and retain them in its forwarding information base (FIB). The forwarding module then installs flows for these destinations in a round-robin fashion.
Configuring OSPF
To configure OSPF on the IA, you must enable OSPF, create OSPF areas, assign interfaces to OSPF areas, and, if necessary, specify any of the OSPF interface parameters.
To configure OSPF, you may need to perform some or all of the following tasks:
• Enable OSPF.
• Create OSPF areas.
• Create an IP interface or assign an IP interface to a VLAN.
• Add IP interfaces to OSPF areas.
• Configure OSPF interface parameters, if necessary.
Note: By default, the priority of an OSPF router for an interface is set to zero, which makes the router ineligible from becoming a designated router on the network to which the interface belongs. To make the router eligible to become a designated router, you must set the priority to a non-zero value.
The default cost of an OSPF interface is 1. The cost of the interface should be inversely proportional to the bandwidth of the interface; if the IA has interfaces with differing bandwidths, the OSPF costs should be set accordingly.
• Add IP networks to OSPF areas.
• Create virtual links, if necessary.
Enabling OSPF
OSPF is disabled by default on the IA.
To enable or disable OSPF, enter one of the following commands in Configure mode.
Enable OSPF.
Disable OSPF.
ospf start ospf stop
84 Internet Appliance User Reference Manual
Chapter 7: OSPF Configuration Guide
Configuring OSPF Interface Parameters
You can configure the OSPF interface parameters shown in Table 1 .
Table 1. OSPF Interface Parameters
OSPF Parameter
Interface OSPF State (Enable/Disable)
Cost
No multicast
Retransmit interval
Transit delay
Priority
Hello interval
Router dead interval
Poll Interval
Key chain
Authentication Method
Default Value
Enable (except for virtual links)
1
Default is using multicast mechanism
5 seconds
1 second
0
10 seconds (broadcast), 30 (non broadcast)
4 times the hello interval
120 seconds
N/A
None
To configure OSPF interface parameters, enter one of the following commands in
Configure mode:
Enable OSPF state on interface.
Specify the cost of sending a packet on an OSPF interface.
Specify the priority for determining the designated router on an OSPF interface.
Specify the interval between OSPF hello packets on an OSPF interface.
Configure the retransmission interval between link state advertisements for adjacencies belonging to an OSPF interface.
ospf set interface < name-or-IPaddr > |all state disable|enable ospf set interface cost <num> ospf set interface priority <num>
< name-or-IPaddr > |all
< name-or-IPaddr > |all ospf set interface < name-or-IPaddr > |all hello-interval <num> ospf set interface < name-or-IPaddr > |all retransmit-interval <num>
Internet Appliance User Reference Manual 85
Chapter 7: OSPF Configuration Guide
Specify the number of seconds required to transmit a link state update on an OSPF interface.
Specify the time a neighbor router will listen for OSPF hello packets before declaring the router down.
Disable IP multicast for sending OSPF packets to neighbors on an OSPF interface.
Specify the poll interval on an OSPF interface.
Specify the identifier of the key chain containing the authentication keys.
Specify the authentication method to be used on this interface.
ospf set interface < name-or-IPaddr > |all transit-delay <num> ospf set interface < name-or-IPaddr > |all router-dead-interval <num> ospf set interface < name-or-IPaddr > |all no-multicast ospf set interface < name-or-IPaddr > |all poll-interval <num> ospf set interface < name-or-IPaddr > |all key-chain <num-or-string> ospf set interface < name-or-IPaddr > |all authentication-method none|simple|md5
Configuring an OSPF Area
OSPF areas are a collection of subnets that are grouped in a logical fashion. These areas communicate with other areas via the backbone area. Once OSPF areas are created, you can add interfaces, stub hosts, and summary ranges to the area.
In order to reduce the amount of routing information propagated between areas, you can configure summary-ranges on Area Border Routers (ABRs). On the IA, summary-ranges are created using the ospf add network command. The networks specified using this command describe the scope of an area. Intra-area Link State Advertisements (LSAs) that fall within the specified ranges are not advertised into other areas as inter-area routes.
Instead, the specified ranges are advertised as summary network LSAs.
86 Internet Appliance User Reference Manual
Chapter 7: OSPF Configuration Guide
To create areas and assign interfaces, enter the following commands in the Configure mode:
Create an OSPF area.
Add an interface to an OSPF area.
Add a stub host to an OSPF area.
Add a network to an OSPF area for summarization.
ospf create area <area-num> |backbone ospf add interface < name-or-IPaddr >
[to-area <area-addr> |backbone]
[type broadcast|non-broadcast] ospf add stub-host [to-area <areaaddr> |backbone]
[cost <num> ] ospf add network <IPaddr/mask> [to-area
<area-addr> |backbone] [restrict]
[host-net]
Configuring OSPF Area Parameters
The IA allows configuration of various OSPF area parameters, including stub areas, stub cost, and authentication method. Stub areas are areas into which information on external routes is not sent. Instead, there is a default external route generated by the ABR, into the stub area for destinations outside the autonomous system. Stub cost specifies the cost to be used to inject a default route into a stub area. An authentication method for OSPF packets can be specified on a per-area basis.
To configure OSPF area parameters, enter the following commands in the Configure mode:
Specify an OSPF stub area.
Specify the cost to be used to inject a default route into an area.
Specify the authentication method to be used by neighboring OSPF routers.
ospf set area <area-num> stub ospf set area <area-num> stub-cost <num> ospf set area <area-num> [stub]
[authentication-method none|simple|md5]
Internet Appliance User Reference Manual 87
Chapter 7: OSPF Configuration Guide
Creating Virtual Links
In OSPF, virtual links can be established:
• To connect an area via a transit area to the backbone
• To create a redundant backbone connection via another area
Each Area Border Router must be configured with the same virtual link. Note that virtual links cannot be configured through a stub area.
To configure virtual links, enter the following commands in the Configure mode:
Create a virtual link.
Set virtual link parameters.
ospf add virtual-link <number-or-string> [neighbor <IPaddr> ]
[transit-area <area-num> ] ospf set virtual-link <number-or-string>
[state disable|enable] [cost <num> ]
[retransmit-interval <num> ] [transit-delay <num> ]
[priority <num> ] [hello-interval <num> ]
[router-dead-interval <num> ] [poll-interval <num> ]
Configuring Autonomous System External (ASE) Link
Advertisements
These parameters specify the defaults used when importing OSPF AS External (ASE) routes into the routing table and exporting routes from the routing table into OSPF ASEs.
To specify AS external link advertisements parameters, enter the following commands in the Configure mode:
Specify the interval which AS external link advertisements will be generated and flooded to an OSPF AS.
Specify the number of AS external link advertisements which will be generated and flooded to an OSPF AS.
Specify AS external link advertisement default parameters.
ospf set export-interval <num> ospf set export-limit <num> ospf set ase-defaults [preference <num> ]
[cost <num> ] [type <num> ]
[inherit-metric]
88 Internet Appliance User Reference Manual
Chapter 7: OSPF Configuration Guide
Configuring OSPF over Non-Broadcast Multiple Access
You can configure OSPF over NBMA circuits to limit the number of Link State
Advertisements (LSAs). LSAs are limited to initial advertisements and any subsequent changes. Periodic LSAs over NBMA circuits are suppressed.
To configure OSPF over WAN circuits, enter the following command in Configure mode:
Configure OSPF over a WAN circuit.
ospf add nbma-neighbor <hostname-or-IPaddr> to-interface < name-or-IPaddr > [eligible]
Monitoring OSPF
The IA lets you display OSPF statistics and configurations contained in the routing table.
Information displayed provides routing and performance information.
To display OSPF information, enter the following commands in Enable mode:
Show IP routing table.
Monitor OSPF error conditions.
Show information on all interfaces configured for OSPF.
Display link state advertisement information.
Display the link state database.
Shows information about all OSPF routing neighbors.
Show information on valid next hops.
Display OSPF routing table.
Monitor OSPF statistics for a specified destination.
Shows information about all OSPF routing version
Shows OSPF Autonomous System
External Link State Database.
Show all OSPF tables.
ip show table routing ospf monitor errors destination
<hostname-or-IPaddr> ospf monitor interfaces destination
<hostname-or-IPaddr> ospf monitor lsa destination
<hostname-or-IPaddr> ospf monitor lsdb destination
<hostname-or-IPaddr> ospf monitor neighborsdestination
<hostname-or-IPaddr> ospf monitor next-hop-list destination <hostname-or-IPaddr> ospf monitor routes destination
<hostname-or-IPaddr> ospf monitor statistics destination
<hostname-or-IPaddr> ospf monitor version ospf sbow AS-External-LSDB ospf show all
Internet Appliance User Reference Manual 89
Chapter 7: OSPF Configuration Guide
Show all OSPF areas.
Show OSPF errors.
Show information about OSPF export policies.
Shows routes redistributed into OSPF.
Show all OSPF global parameters.
Show information about OSPF import policies.
Show OSPF interfaces.
Shows information about all valid next hops mostly derived from the SPF calculation.
Show OSPF statistics.
Shows information about OSPF Border
Routes.
Show OSPF timers.
Show OSPF virtual-links.
ospf show areas ospf show errors ospf show export-policies ospf show exported-routes ospf show globals ospf show import-policies ospf show interfaces ospf show next-hop-list ospf show statistics ospf show summary-asb ospf show timers ospf show virtual-links
OSPF Configuration Examples
For all examples in this section, refer to the configuration shown in Figure 7 on page 95 .
The following configuration commands for router R1:
• Determine the IP address for each interface
• Specify the static routes configured on the router
90 Internet Appliance User Reference Manual
Chapter 7: OSPF Configuration Guide
• Determine its OSPF configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Create the various IP interfaces.
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
interface create ip to-r2 address-netmask 120.190.1.1/16 port et.1.2
interface create ip to-r3 address-netmask 130.1.1.1/16 port et.1.3
interface create ip to-r41 address-netmask 140.1.1.1/24 port et.1.4
interface create ip to-r42 address-netmask 140.1.2.1/24 port et.1.5
interface create ip to-r6 address-netmask 140.1.3.1/24 port et.1.6
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure default routes to the other subnets reachable through R2.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route 202.1.0.0/16 gateway 120.1.1.2
ip add route 160.1.5.0/24 gateway 120.1.1.2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! OSPF Box Level Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ospf start
ospf create area 140.1.0.0
ospf create area backbone
ospf set ase-defaults cost 4
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! OSPF Interface Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ospf add interface 140.1.1.1 to-area 140.1.0.0
ospf add interface 140.1.2.1 to-area 140.1.0.0
ospf add interface 140.1.3.1 to-area 140.1.0.0
ospf add interface 130.1.1.1 to-area backbone
Exporting All Interface and Static Routes to OSPF
Router R1 has several static routes. We would export these static routes as type-2 OSPF routes. The interface routes would be redistributed as type-1 OSPF routes.
1.
Create a OSPF export destination for type-1 routes since we would like to redistribute certain routes into OSPF as type 1 OSPF-ASE routes.
ip-router policy create ospf-export-destination ospfExpDstType1 type 1 metric 1
2.
Create a OSPF export destination for type-2 routes since we would like to redistribute certain routes into OSPF as type 2 OSPF-ASE routes.
ip-router policy create ospf-export-destination ospfExpDstType2 type 2 metric 4
Internet Appliance User Reference Manual 91
Chapter 7: OSPF Configuration Guide
3.
Create a Static export source since we would like to export static routes.
ip-router policy create static-export-source statExpSrc
4.
Create a Direct export source since we would like to export interface/direct routes.
ip-router policy create direct-export-source directExpSrc
5.
Create the Export-Policy for redistributing all interface routes and static routes into
OSPF.
ip-router policy export destination ospfExpDstType1 source directExpSrc network all ip-router policy export destination ospfExpDstType2 source statExpSrc network all
Exporting All RIP, Interface, and Static Routes to OSPF
Note: Also export interface, static, RIP, OSPF, and OSPF-ASE routes into RIP.
In the configuration shown in Figure 7 on page 95 , RIP Version 2 is configured on the interfaces of routers R1 and R2 on network 120.190.0.0/16.
We would like to redistribute these RIP routes as OSPF type-2 routes and associate the tag
100 with them. Router R1 would also like to redistribute its static routes as type-2 OSPF routes. The interface routes would redistributed as type-1 OSPF routes.
Router R1 would like to redistribute its OSPF, OSPF-ASE, RIP, Static, and Interface/Direct routes into RIP.
1.
Enable RIP on interface 120.190.1.1/16.
rip add interface 120.190.1.1
rip set interface 120.190.1.1 version 2 type multicast
2.
Create a OSPF export destination for type-1 routes.
ip-router policy create ospf-export-destination ospfExpDstType1 type 1 metric 1
3.
Create a OSPF export destination for type-2 routes.
ip-router policy create ospf-export-destination ospfExpDstType2 type 2 metric 4
92 Internet Appliance User Reference Manual
Chapter 7: OSPF Configuration Guide
4.
Create a OSPF export destination for type-2 routes with a tag of 100.
ip-router policy create ospf-export-destination ospfExpDstType2t100 type 2 tag 100 metric 4
5.
Create a RIP export source.
ip-router policy export destination ripExpDst source ripExpSrc network all
6.
Create a Static export source.
ip-router policy create static-export-source statExpSrc
7.
Create a Direct export source.
ip-router policy create direct-export-source directExpSrc
8.
Create the Export-Policy for redistributing all interface, RIP, and static routes into
OSPF.
ip-router policy export destination ospfExpDstType1 source directExpSrc network all ip-router policy export destination ospfExpDstType2 source statExpSrc network all ip-router policy export destination ospfExpDstType2t100 source ripExpSrc network all
9.
Create a RIP export destination.
ip-router policy create rip-export-destination ripExpDst
10. Create OSPF export source.
ip-router policy create ospf-export-source ospfExpSrc type OSPF
11. Create OSPF-ASE export source.
ip-router policy create ospf-export-source ospfAseExpSrc type OSPF-
ASE
Internet Appliance User Reference Manual 93
Chapter 7: OSPF Configuration Guide
12. Create the Export-Policy for redistributing all interface, RIP, static, OSPF and
OSPF-ASE routes into RIP.
ip-router policy export destination ripExpDst source statExpSrc network all ip-router policy export destination ripExpDst source ripExpSrc network all ip-router policy export destination ripExpDst source directExpSrc network all ip-router policy export destination ripExpDst source ospfExpSrc network all ip-router policy export destination ripExpDst source ospfAseExpSrc network all
94 Internet Appliance User Reference Manual
R6
140.1.4/24
R42
Figure 7. Exporting to OSPF
140.1.5/24
R41
140.1.1.2/24
A r e a 140.1.0.0
BGP
A r e a B a c k b o n e
140.1.3.1/24
140.1.2.1/24
140.1.1.1/24
R1
190.1.1.1/16
130.1.1.1/16
130.1.1.3/16
120.190.1.1/16
R3 R5 R7
150.20.3.1/16
150.20.3.2/16
R8
A r e a 150.20.0.0
R11
120.190.1.2/16
202.1.2.2/16
R2
160.1.5.2/24
160.1.5.2/24
R10
Chapter 8
BGP Configuration
Guide
BGP Overview
The Border Gateway Protocol (BGP) is an exterior gateway protocol that allows IP routers to exchange network reachability information. BGP became an internet standard in 1989
(RFC 1105) and the current version, BGP-4, was published in 1994 (RFC 1771). BGP is typically run between Internet Service Providers. It is also frequently used by multihomed ISP customers, as well as in large commercial networks.
Autonomous systems that wish to connect their networks together must agree on a method of exchanging routing information. Interior gateway protocols such as RIP and
OSPF may be inadequate for this task since they were not designed to handle multi-AS, policy, and security issues. Similarly, using static routes may not be the best choice for exchanging AS-AS routing information because there may be a large number of routes, or the routes may change often.
Note: This chapter uses the term Autonomous System (AS) throughout. An AS is defined as a set of routers under a central technical administration that has a coherent interior routing plan and accurately portrays to other ASs what routing destinations are reachable by way of it.
In an environment where using static routes is not feasible, BGP is often the best choice for an AS-AS routing protocol. BGP prevents the introduction of routing loops created by multi-homed and meshed AS topologies. BGP also provides the ability to create and enforce policies at the AS level, such as selectively determining which AS routes are to be accepted or what routes are to be advertised to BGP peers.
Internet Appliance User Reference Manual 97
Chapter 8: BGP Configuration Guide
The Internet Appliance (IA) BGP Implementation
The Internet Appliance (IA) routing protocol implementation is based on GateD 4.0.3 code
( http://www.gated.org
). GateD is a modular software program consisting of core services, a routing database, and protocol modules supporting multiple routing protocols
(RIP versions 1 and 2, OSPF version 2, BGP version 2 through 4, and Integrated IS-IS).
Since the IA IP routing code is based upon GateD, BGP can also be configured using a
GateD configuration file (gated.conf) instead of the IA Command Line Interface (CLI).
Additionally, even if the IA is configured using the CLI, the gated.conf equivalent can be displayed by entering the ip-router show configuration-file command at the IA Enable prompt.
VLANs, interfaces, ACLs, and many other IA configurable entities and functionality can only be configured using the IA CLI. Therefore, a gated.conf file is dependent upon some
IA CLI configuration.
Basic BGP Tasks
This section describes the basic tasks necessary to configure BGP on the IA. Due to the abstract nature of BGP, many BGP designs can be extremely complex. For any one BGP design challenge, there may only be one solution out of many that is relevant to common practice.
When designing a BGP configuration, it may be prudent to refer to information in RFCs,
Internet drafts, and books about BGP. Some BGP designs may also require the aid of an experienced BGP network consultant.
Basic BGP configuration involves the following tasks:
• Setting the autonomous system number
• Setting the router ID
• Creating a BGP peer group
• Adding and removing a BGP peer host
• Starting BGP
• Using AS path regular expressions
• Using AS path prepend
98 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
Setting the Autonomous System Number
An autonomous system number identifies your autonomous system to other routers. To set the IA’s autonomous system number, enter the following command in Configure mode:
Set the IA’s autonomous system number.
ip-router global set autonomous-system <num1> loops <num2>
The a utonomous-system <num1> parameter sets the AS number for the router. Specify a number from 1 to 65534. The loops <num2> parameter controls the number of times the
AS may appear in the as-path. The default is 1.
Setting the Router ID
The router ID uniquely identifies the IA. To set the router ID to be used by BGP, enter the following command in Configure mode:
Set the IA’s router ID.
ip-router global set router-id <hostname-or-IPaddr>
If you do not explicitly specify the router ID, then an ID is chosen implicitly by the IA. A secondary address on the loopback interface (the primary address being 127.0.0.1) is the most preferred candidate for selection as the IA’s router ID. If there are no secondary addresses on the loopback interface, then the default router ID is set to the address of the first interface that is in the up state that the IA encounters (except the interface en0, which is the Control Module’s interface). The address of a non point-to-point interface is preferred over the local address of a point-to-point interface. If the router ID is implicitly chosen to be the address of a non-loopback interface, and if that interface were to go down, then the router ID is changed. When the router ID changes, an OSPF router has to flush all its LSAs from the routing domain.
If you explicitly specify a router ID, then it would not change, even if all interfaces were to go down.
Internet Appliance User Reference Manual 99
Chapter 8: BGP Configuration Guide
Configuring a BGP Peer Group
A BGP peer group is a group of neighbor routers that have the same update policies. To configure a BGP peer group, enter the following command in Configure mode:
Configure a BGP peer group.
bgp create peer-group <number-or-string> type external|internal|igp|routing
[autonomous-system <number> ]
[proto any|rip|ospf|static]
[interface <interface-name-or-ipaddr> |all] where: peer-group <number-or-string>
Is a group ID, which can be a number or a character string.
type Specifies the type of BGP group you are adding. You can specify one of the following: external In the classic external BGP group, full policy checking is applied to all incoming and outgoing advertisements. The external neighbors must be directly reachable through one of the machine's local interfaces.
routing An internal group which uses the routes of an interior protocol to resolve forwarding addresses. Type Routing groups will determine the immediate next hops for routes by using the next hop received with a route from a peer as a forwarding address, and using this to look up an immediate next hop in an IGP’s routes. Such groups support distant peers, but need to be informed of the IGP whose routes they are using to determine immediate next hops. This implementation comes closest to the IBGP implementation of other router vendors.
internal An internal group operating where there is no IP-level IGP, for example an SMDS network. Type Internal groups expect all peers to be directly attached to a shared subnet so that, like external peers, the next hops received in BGP advertisements may be used directly for forwarding.
All Internal group peers should be L2 adjacent.
igp An internal group operating where there is no IP-level IGP; for example, an SMDS network.
autonomous-system <number>
Specifies the autonomous system of the peer group. Specify a number from 1 –
65534.
100 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide proto Specifies the interior protocol to be used to resolve BGP next hops. Specify one of the following: any Use any igp to resolve BGP next hops.
rip Use RIP to resolve BGP next hops.
ospf Use OSPF to resolve BGP next hops.
static Use static to resolve BGP next hops.
interface <name-or-IPaddr> | all
Interfaces whose routes are carried via the IGP for which third-party next hops may be used instead. Use only for type Routing group. Specify the interface or all for all interfaces.
Adding and Removing a BGP Peer
There are two ways to add BGP peers to peer groups. You can explicitly add a peer host, or you can add a network. Adding a network allows for peer connections from any addresses in the range of network and mask pairs specified in the bgp add network command.
To add BGP peers to BGP peer groups, enter one of the following commands in Configure mode:
Add a host to a BGP peer group.
Add a network to a BGP peer group.
bgp add peer-host <ipaddr> group <number-or-string> bgp add network <ip-addr-mask> |all group <numberor-string>
You may also remove a BGP peer from a peer group. To do so, enter the following command in Configure mode:
Remove a host from a BGP peer group.
bgp clear peer-host < ipaddr >
Starting BGP
BGP is disabled by default. To start BGP, enter the following command in Configure mode:
Start BGP.
bgp start
Internet Appliance User Reference Manual 101
Chapter 8: BGP Configuration Guide
Using AS-Path Regular Expressions
An AS-path regular expression is a regular expression where the alphabet is the set of AS numbers. An AS-path regular expression is composed of one or more AS-path expressions. An AS-path expression is composed of AS path terms and AS-path operators.
An AS path term is one of the following three objects: autonomous_system
Is any valid autonomous system number, from one through 65534 inclusive.
.
(dot)
Matches any autonomous system number.
( aspath_regexp )
Parentheses group subexpressions. An operator, such as * or ? works on a single element or on a regular expression enclosed in parentheses.
An AS-path operator is one of the following: aspath_term {m,n}
A regular expression followed by {m,n} (where m and n are both non-negative integers and m <= n) means at least m and at most n repetitions. aspath_term {m}
A regular expression followed by {m} (where m is a positive integer) means exactly m repetitions.
aspath_term {m,}
A regular expression followed by {m,} (where m is a positive integer) means m or more repetitions. aspath_term *
An AS path term followed by * means zero or more repetitions. This is shorthand for {0,}. aspath_term +
A regular expression followed by + means one or more repetitions. This is shorthand for {1,}. aspath_term ?
A regular expression followed by ? means zero or one repetition. This is shorthand for {0,1}. aspath_term | aspath_term
Matches the AS term on the left, or the AS term on the right.
102 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
For example:
(4250 .*) Means anything beginning with 4250.
(.* 6301 .*) Means anything with 6301.
(.* 4250) Means anything ending with 4250.
(. * 1104|1125|1888|1135 .*)
Means anything containing 1104 or 1125 or 1888 or 1135.
AS-path regular expressions are used as one of the parameters for determining which routes are accepted and which routes are advertised.
AS-Path Regular Expression Examples
To import MCI routes with a preference of 165: ip-router policy create bgp-import-source mciRoutes aspath-regularexpression "(.* 3561 .*)" origin any sequence-number 10 ip-router policy import source mciRoutes network all preference 165
To import all routes (.* matches all AS paths) with the default preference: ip-router policy create bgp-import-source allOthers aspath-regularexpression "(.*)" origin any sequence-number 20 ip-router policy import source allOthers network all
To export all active routes from 284 or 813 or 814 or 815 or 816 or 3369 or 3561 to autonomous system 64800.
ip-router policy create bgp-export-destination to-64800 autonomoussystem 64800 ip-router policy create aspath-export-source allRoutes aspath-regularexpression "(.*(284|813|814|815|816|3369|3561) .*)" origin any protocol all ip-router policy export destination to-64800 source allRoutes network all
Internet Appliance User Reference Manual 103
Chapter 8: BGP Configuration Guide
Using the AS Path Prepend Feature
When BGP compares two advertisements of the same prefix that have differing AS paths, the default action is to prefer the path with the lowest number of transit AS hops; in other words, the preference is for the shorter AS path length. The AS path prepend feature is a way to manipulate AS path attributes to influence downstream route selection. AS path prepend involves inserting the originating AS into the beginning of the AS prior to announcing the route to the exterior neighbor.
Lengthening the AS path makes the path less desirable than would otherwise be the case.
However, this method of influencing downstream path selection is feasible only when comparing prefixes of the same length because an instance of a more specific prefix always is preferable.
On the IA, the number of instances of an AS that are put in the route advertisement is controlled by the as-count option of the bgp set peer-host command.
The following is an example:
#
# insert two instances of the AS when advertising the route to this peer
# bgp set peer-host 194.178.244.33 group nlnet as-count 2
#
# insert three instances of the AS when advertising the route to this
# peer
# bgp set peer-host 194.109.86.5 group webnet as-count 3
Notes on Using the AS Path Prepend Feature
• Use the as-count option for external peer-hosts only.
• If the as-count option is entered for an active BGP session, routes will not be resent to reflect the new setting. To have routes reflect the new setting, you must restart the peer session. To do this: a.
Enter Configure mode.
b. Negate the command that adds the peer-host to the peer-group. (If this causes the number of peer-hosts in the peer-group to drop to zero, then you must also negate the command that creates the peer group.) c.
Exit Configure mode.
104 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide d. Re-enter Configure mode.
e.
Add the peer-host back to the peer-group.
If the as-count option is part of the startup configuration, the above steps are unnecessary.
BGP Configuration Examples
This section presents sample configurations illustrating BGP features. The following features are demonstrated:
• BGP peering
• Internal BGP (IBGP)
• External BGP (EBGP) multihop
• BGP community attribute
• BGP local preference (local_pref) attribute
• BGP Multi-Exit Discriminator (MED) attribute
• EBGP aggregation
• Route reflection
BGP Peering Session Example
The router process used for a specific BGP peering session is known as a BGP speaker . A single router can have several BGP speakers. Successful BGP peering depends on the establishment of a neighbor relationship between BGP speakers. The first step in creating a BGP neighbor relationship is the establishment of a TCP connection (using TCP port
179) between peers.
A BGP Open message can then be sent between peers across the TCP connection to establish various BGP variables (BGP Version, AS number (ASN), hold time, BGP identifier, and optional parameters). Upon successful completion of the BGP Open negotiations, BGP Update messages containing the BGP routing table can be sent between peers.
BGP does not require a periodic refresh of the entire BGP routing table between peers.
Only incremental routing changes are exchanged. Therefore, each BGP speaker is required to retain the entire BGP routing table of their peer for the duration of the peer’s connection.
Internet Appliance User Reference Manual 105
Chapter 8: BGP Configuration Guide
BGP keepalive messages are sent between peers periodically to ensure that the peers stay connected. If one of the routers encounters a fatal error condition, a BGP notification message is sent to its BGP peer, and the TCP connection is closed.
Figure 8 illustrates a sample BGP peering session.
AS-1
IA1
1.1
10.0.0.1/16
AS-2
10.0.0.2/16
1.1
IA2
106
Legend:
Physical Link
Peering Relationship
Figure 8. Sample BGP Peering Session
The CLI configuration for router IA1 is as follows: interface create ip et.1.1 address-netmask 10.0.0.1/16 port et.1.1
#
# Set the AS of the router
# ip-router global set autonomous-system 1
#
# Set the router ID
# ip-router global set router-id 10.0.0.1
#
# Create EBGP peer group pg1w2 for peering with AS 2
# bgp create peer-group pg1w2 type external autonomous-system 2
#
# Add peer host 10.0.0.2 to group pg1w2
# bgp add peer-host 10.0.0.2 group pg1w2 bgp start
Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
The gated.conf file for router IA1 is as follows: autonomoussystem 1 ; routerid 10.0.0.1 ; bgp yes {
group type external peeras 2
{
peer 10.0.0.2
;
};
};
The CLI configuration for router IA2 is as follows: interface create ip et.1.1 address-netmask 10.0.0.2/16 port et.1.1
ip-router global set autonomous-system 2 ip-router global set router-id 10.0.0.2
bgp create peer-group pg2w1 type external autonomous-system 1 bgp add peer-host 10.0.0.1 group pg2w1 bgp start
The gated.conf file for router IA2 is as follows: autonomoussystem 2 ; routerid 10.0.0.2 ; bgp yes {
group type external peeras 1
{
peer 10.0.0.1
;
};
};
IBGP Configuration Example
Connections between BGP speakers within the same AS are referred to as internal links. A peer in the same AS is an internal peer. Internal BGP is commonly abbreviated IBGP; external BGP is EBGP.
An AS that has two or more EBGP peers is referred to as a multihomed AS. A multihomed
AS can transit traffic between two ASs by advertising to one AS routes that it learned from the other AS. To successfully provide transit services, all EBGP speakers in the transit AS must have a consistent view of all of the routes reachable through their AS.
Multihomed transit ASs can use IBGP between EBGP-speaking routers in the AS to synchronize their routing tables. IBGP requires a full-mesh configuration; all EBGP speaking routers must have an IBGP peering session with every other EBGP speaking router in the AS.
Internet Appliance User Reference Manual 107
Chapter 8: BGP Configuration Guide
An IGP, like OSPF, could possibly be used instead of IBGP to exchange routing information between EBGP speakers within an AS. However, injecting full Internet routes
(50,000+ routes) into an IGP puts an expensive burden on the IGP routers. Additionally,
IGPs cannot communicate all of the BGP attributes for a given route. It is, therefore, recommended that an IGP not be used to propagate full Internet routes between EBGP speakers. IBGP should be used instead.
IBGP Routing Group Example
An IBGP Routing group uses the routes of an interior protocol to resolve forwarding addresses. An IBGP Routing group will determine the immediate next hops for routes by using the next hop received with a route from a peer as a forwarding address, and using this to look up an immediate next hop in an IGP’s routes. Such groups support distant peers, but need to be informed of the IGP whose routes they are using to determine immediate next hops. This implementation comes closest to the IBGP implementation of other router vendors.
You should use the IBGP Routing group as the mechanism to configure the IA for IBGP. If the peers are directly connected, then IBGP using group-type Internal can also be used.
Note that for running IBGP using group-type Routing you must run an IGP such as OSPF to resolve the next hops that come with external routes. You could also use protocol any so that all protocols are eligible to resolve the BGP forwarding address.
108 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
Figure 9 shows a sample BGP configuration that uses the Routing group type.
AS-64801
10.12.1.2/30
IA4
172.23.1.5/30
10.12.1.1/30
Cisco
10.12.1.6/30 lo0 172.23.1.25/30
OSPF
IBGP
10.12.1.5/30
IA1
172.23.1.10/30 lo0 172.23.1.26/30
IA6
172.23.1.6/30 172.23.1.9/30
Figure 9. Sample IBGP Configuration (Routing Group Type)
Internet Appliance User Reference Manual 109
Chapter 8: BGP Configuration Guide
In this example, OSPF is configured as the IGP in the autonomous system. The following lines in the router IA6 configuration file configure OSPF:
#
# Create a secondary address for the loopback interface
# interface add ip lo0 address-netmask 172.23.1.26/30 ospf create area backbone ospf add interface to-IA4 to-area backbone ospf add interface to-IA1 to-area backbone
#
# This line is necessary because we want CISCO to peer with our loopback
# address.This will make sure that the loopback address gets announced
# into OSPF domain
# ospf add stub-host 172.23.1.26 to-area backbone cost 1 ospf set interface to-IA4 priority 2 ospf set interface to-IA1 priority 2 ospf set interface to-IA4 cost 2 ospf start
The following lines in the Cisco router configure OSPF:
The following lines on the CISCO 4500 configures it for OSPF.
router ospf 1
network 10.12.1.1 0.0.0.0 area 0
network 10.12.1.6 0.0.0.0 area 0
network 172.23.1.14 0.0.0.0 area 0
The following lines in the IA6 set up peering with the Cisco router using the Routing group type.
# Create a internal routing group.
bgp create peer-group ibgp1 type routing autonomous-system 64801 proto any interface all
# Add CISCO to the above group bgp add peer-host 172.23.1.25 group ibgp1
# Set our local address. This line is necessary because we want CISCO to
# peer with our loopback bgp set peer-group ibgp1 local-address 172.23.1.26
# Start BGP bgp start
110 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
The following lines on the Cisco router set up IBGP peering with router IA6.
router bgp 64801
!
! Disable synchronization between BGP and IGP
!
no synchronization neighbor 172.23.1.26 remote-as 64801
!
! Allow internal BGP sessions to use any operational interface for TCP
! connections
!
neighbor 172.23.1.26 update-source Loopback0
IBGP Internal Group Example
The IBGP Internal group expects all peers to be directly attached to a shared subnet so that, like external peers, the next hops received in BGP advertisements may be used directly for forwarding. All Internal group peers should be L2 adjacent.
Internet Appliance User Reference Manual 111
Chapter 8: BGP Configuration Guide
Figure 10 illustrates a sample IBGP Internal group configuration.
C2
16.122.128.9/24
C1
16.122.128.8/24
AS-1
16.122.128.1/24
IA1
17.122.128.1/24
16.122.128.1/24
IA2
17.122.128.2/24
112
Legend:
Physical Link
Peering Relationship
Figure 10. Sample IBGP Configuration (Internal Group Type)
The CLI configuration for router IA1 is as follows: ip-router global set autonomous-system 1 bgp create peer-group int-ibgp-1 type internal autonomous-system 1 bgp add peer-host 16.122.128.2 group int-ibgp-1 bgp add peer-host 16.122.128.8 group int-ibgp-1 bgp add peer-host 16.122.128.9 group int-ibgp-1
Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
The gated.conf file for router IA1 is as follows: autonomoussystem 1 ; routerid 16.122.128.1 ; bgp yes {
traceoptions aspath detail packets detail open detail update ;
group type internal peeras 1
{
peer 16.122.128.2
;
peer 16.122.128.8
;
peer 16.122.128.9
;
};
};
The CLI configuration for router IA2 is as follows: ip-router global set autonomous-system 1 bgp create peer-group int-ibgp-1 type internal autonomous-system 1 bgp add peer-host 16.122.128.1 group int-ibgp-1 bgp add peer-host 16.122.128.8 group int-ibgp-1 bgp add peer-host 16.122.128.9 group int-ibgp-1
The gated.conf file for router IA2 is as follows: autonomoussystem 1 ; routerid 16.122.128.2 ; bgp yes {
traceoptions aspath detail packets detail open detail update ;
group type internal peeras 1
{
peer 16.122.128.1
;
peer 16.122.128.8
;
peer 16.122.128.9
;
};
};
Internet Appliance User Reference Manual 113
Chapter 8: BGP Configuration Guide
The configuration for router C1 (a Cisco router) is as follows: router bgp 1
no synchronization
network 16.122.128.0 mask 255.255.255.0
network 17.122.128.0 mask 255.255.255.0
neighbor 16.122.128.1 remote-as 1
neighbor 16.122.128.1 next-hop-self
neighbor 16.122.128.1 soft-reconfiguration inbound
neighbor 16.122.128.2 remote-as 1
neighbor 16.122.128.2 next-hop-self
neighbor 16.122.128.2 soft-reconfiguration inbound
neighbor 16.122.128.9 remote-as 1
neighbor 16.122.128.9 next-hop-self
neighbor 16.122.128.9 soft-reconfiguration inbound
neighbor 18.122.128.4 remote-as 4
The configuration for router C2 (a Cisco router) is as follows: router bgp 1
no synchronization
network 16.122.128.0 mask 255.255.255.0
network 17.122.128.0 mask 255.255.255.0
neighbor 14.122.128.5 remote-as 5
neighbor 16.122.128.1 remote-as 1
neighbor 16.122.128.1 next-hop-self
neighbor 16.122.128.1 soft-reconfiguration inbound
neighbor 16.122.128.2 remote-as 1
neighbor 16.122.128.2 next-hop-self
neighbor 16.122.128.2 soft-reconfiguration inbound
neighbor 16.122.128.8 remote-as 1
neighbor 16.122.128.8 next-hop-self
neighbor 16.122.128.8 soft-reconfiguration inbound
EBGP Multihop Configuration Example
EBGP Multihop refers to a configuration where external BGP neighbors are not connected to the same subnet. Such neighbors are logically, but not physically connected. For example, BGP can be run between external neighbors across non-BGP routers. Some additional configuration is required to indicate that the external peers are not physically attached.
114 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
The sample configuration in Figure 11 shows External BGP peers, IA1 and IA4, which are not connected to the same subnet.
AS-64800
IA1
16.122.128.1/16
16.122.128.3/16
IA2
17.122.128.4/16
17.122.128.3/16
IA3
18.122.128.3/16
Legend:
AS-64801
18.122.128.4/16
IA4
Physical Link
Peering Relationship
Figure 11. EBGP Multihop Configuration Example
The CLI configuration for router IA1 is as follows: bgp create peer-group ebgp_multihop autonomous-system 64801 type external bgp add peer-host 18.122.128.2 group ebgp_multihop
!
! Specify the gateway option, which indicates EBGP multihop. Set the
! gateway option to the address of the router that has a route to the
! peer.
!
bgp set peer-host 18.122.128.2 gateway 16.122.128.3 group ebgp_multihop
Internet Appliance User Reference Manual 115
Chapter 8: BGP Configuration Guide
The gated.conf file for router IA1 is as follows: autonomoussystem 64800 ; routerid 0.0.0.1 ; bgp yes {
traceoptions state ;
group type external peeras 64801
{
peer 18.122.128.2
gateway 16.122.128.3
;
};
}; static {
18.122.0.0 masklen 16
gateway 16.122.128.3
;
};
The CLI configuration for router IA2 is as follows: interface create ip to-R1 address-netmask 16.122.128.3/16 port et.1.1
interface create ip to-R3 address-netmask 17.122.128.3/16 port et.1.2
#
# Static route needed to reach 18.122.0.0/16
# ip add route 18.122.0.0/16 gateway 17.122.128.4
The gated.conf file for router IA2 is as follows: static {
18.122.0.0 masklen 16
gateway 17.122.128.4
;
};
The CLI configuration for router IA3 is as follows: interface create ip to-R2 address-netmask 17.122.128.4/16 port et.4.2
interface create ip to-R4 address-netmask 18.122.128.4/16 port et.4.4
ip add route 16.122.0.0/16 gateway 17.122.128.3
116 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
The gated.conf file for router IA3 is as follows: static {
16.122.0.0 masklen 16
gateway 17.122.128.3
;
};
The CLI configuration for router IA4 is as follows: bgp create peer-group ebgp_multihop autonomous-system 64801 type external bgp add peer-host 18.122.128.2 group ebgp_multihop
!
! Specify the gateway option, which indicates EBGP multihop. Set the
! gateway option to the address of the router that has a route to the
! peer.
!
bgp set peer-host 18.122.128.2 gateway 16.122.128.3 group ebgp_multihop
The gated.conf file for router IA4 is as follows: autonomoussystem 64800 ; routerid 0.0.0.1 ; bgp yes {
traceoptions state ;
group type external peeras 64801
{
peer 18.122.128.2
gateway 16.122.128.3
Community Attribute Example
The following configuration illustrates the BGP community attribute. Community is specified as one of the parameters in the optional attributes list option of the ip-router policy create command.
Figure 12 shows a BGP configuration where the specific community attribute is used.
Figure 13 shows a BGP configuration where the well-known community attribute is used.
Internet Appliance User Reference Manual 117
Chapter 8: BGP Configuration Guide
AS-64901
ISP1
R11 1.6
172.25.1.1/16
1.1
192.168.20.2/16
AS-64902
ISP2
172.25.1.2/16
1.1
R13
1.6
172.26.1.2/16
AS-64900
192.168.20.1/16
100.200.12.1/24
1.6
1.1
100.200.13.1/24
1.3
R10
1.8
CS1
192.169.20.1/16
AS-64899
172.26.1.1/16
192.169.20.2/16
1.8
1.1
10.200.14.1/24
1.6
R14
1.3
10.200.15.1/24
CS2
Legend:
Physical Link
Peering Relationship
Information Flow
Figure 12. Sample BGP Configuration (Specific Community)
118 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
AS-64901
IA11
172.25.1.1/16
192.168.20.2/16
AS-64902
172.25.1.2/16
ISP2
IA13
10.220.1.1/16
AS-64900
100.200.12.20/24
100.200.13.1/24
192.168.20.1/16
IA10
Legend:
Physical Link
Peering Relationship
Information Flow
Figure 13. Sample BGP Configuration (Well-Known Community)
The Community attribute can be used in three ways:
1.
In a BGP Group Statement: Any packets sent to this group of BGP peers will have the communities attribute in the BGP packet modified to be this communities attribute value from this AS.
2.
In an Import Statement: Any packets received from a BGP peer will be checked for the community attribute. The optional-attributes-list option of the ip-router policy create command allows the specification of an import policy based on optional path attributes (for instance, the community attribute) found in the BGP update. If multiple communities are specified in the optional-attributes-list option, only updates carrying all of the specified communities will be matched. If well-known-community none is specified, only updates lacking the community attribute will be matched.
Note that it is quite possible for several BGP import clauses to match a given update.
If more than one clause matches, the first matching clause will be used; all later matching clauses will be ignored. For this reason, it is generally desirable to order import clauses from most to least specific. An import clause without an optionalattributes-list option will match any update with any (or no) communities.
Internet Appliance User Reference Manual 119
Chapter 8: BGP Configuration Guide
In Figure 13 , router IA11 has the following configuration:
#
# Create an optional attribute list with identifier color1 for a community
# attribute (community-id 160 AS 64901)
# ip-router policy create optional-attributes-list color1 community-id 160 autonomous-system 64901
#
# Create an optional attribute list with identifier color2 for a community
# attribute (community-id 155 AS 64901)
# ip-router policy create optional-attributes-list color2 community-id 155 autonomous-system 64901
#
# Create a BGP import source for importing routes from AS 64900 containing the
# community attribute (community-id 160 AS 64901). This import source is given an
# identifier 901color1 and sequence-number 1.
# ip-router policy create bgp-import-source 901color1 optional-attributes-list color1 autonomous-system 64900 sequence-number 1 ip-router policy create bgp-import-source 901color2 optional-attributes-list color2 autonomous-system 64900 sequence-number 2 ip-router policy create bgp-import-source 901color3 optional-attributes-list color1 autonomous-system 64902 sequence-number 3 ip-router policy create bgp-import-source 901color4 optional-attributes-list color2 autonomous-system 64902 sequence-number 4
#
# Import all routes matching BGP import source 901color1 (from AS 64900 having
# community attribute with ID 160 AS 64901) with a preference of 160
# ip-router policy import source 901color1 network all preference 160 ip-router policy import source 901color2 network all preference 155 ip-router policy import source 901color3 network all preference 160 ip-router policy import source 901color4 network all preference 155
120 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
In Figure 13 on page 119 , router IA13 has the following configuration: ip-router policy create optional-attributes-list color1 community-id 160 autonomous-system 64902 ip-router policy create optional-attributes-list color2 community-id 155 autonomous-system 64902 ip-router policy create bgp-import-source 902color1 optional-attributes-list color1 autonomous-system 64899 sequence-number 1 ip-router policy create bgp-import-source 902color2 optional-attributes-list color2 autonomous-system 64899 sequence-number 2 ip-router policy create bgp-import-source 902color3 optional-attributes-list color1 autonomous-system 64901 sequence-number 3 ip-router policy create bgp-import-source 902color4 optional-attributes-list color2 autonomous-system 64901 sequence-number 4 ip-router policy import source 902color1 network all preference 160 ip-router policy import source 902color2 network all preference 155 ip-router policy import source 902color3 network all preference 160 ip-router policy import source 902color4 network all preference 155
3.
In an Export Statement: The optional-attributes-list option of the ip-router policy create bgp-export-destination command may be used to send the BGP community attribute. Any communities specified with the optional-attributes-list option are sent in addition to any received in the route or specified with the group.
Internet Appliance User Reference Manual 121
Chapter 8: BGP Configuration Guide
In Figure 13 on page 119 , router IA10 has the following configuration:
#
# Create an optional attribute list with identifier color1 for a community
# attribute (community-id 160 AS 64902)
# ip-router policy create optional-attributes-list color1 community-id 160 autonomous-system 64902
#
# Create an optional attribute list with identifier color2 for a community
# attribute (community-id 155 AS 64902)
# ip-router policy create optional-attributes-list color2 community-id 155 autonomous-system 64902
#
# Create a direct export source
# ip-router policy create direct-export-source 900toanydir metric 10
#
# Create BGP export-destination for exporting routes to AS 64899 containing the
# community attribute (community-id 160 AS 64902). This export-destination has an
# identifier 900to899dest
# ip-router policy create bgp-export-destination 900to899dest autonomous-system
64899 optional-attributes-list color1 ip-router policy create bgp-export-destination 900to901dest autonomous-system
64901 optional-attributes-list color2
#
# Export routes to AS 64899 with the community attribute (community-id 160 AS
# 64902)
# ip-router policy export destination 900to899dest source 900toanydir network all ip-router policy export destination 900to901dest source 900toanydir network all
In Figure 13 , router IA14 has the following configuration: ip-router policy create bgp-export-destination 899to900dest autonomous-system
64900 optional-attributes-list color1 ip-router policy create bgp-export-destination 899to902dest autonomous-system
64902 optional-attributes-list color2 ip-router policy create bgp-export-source 900toany autonomous-system 64900 metric
10 ip-router policy create optional-attributes-list color1 community-id 160 autonomous-system 64901 ip-router policy create optional-attributes-list color2 community-id 155 autonomous-system 64901 ip-router policy export destination 899to900dest source 899toanydir network all ip-router policy export destination 899to902dest source 899toanydir network all
Any communities specified with the optional-attributes-list option are sent in addition to any received with the route or associated with a BGP export destination.
122 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
The community attribute may be a single community or a set of communities. A maximum of 10 communities may be specified.
The community attribute can take any of the following forms:
• Specific community
The specific community consists of the combination of the AS-value and community
ID.
• Well-known-community no-export
Well-known-community no-export is a special community which indicates that the routes associated with this attribute must not be advertised outside a BGP confederation boundary. Since the IA’s implementation does not support
Confederations, this boundary is an AS boundary.
For example, router IA10 in Figure 13 on page 119 has the following configuration: ip-router policy create optional-attributes-list noexport well-knowncommunity no-export ip-router policy create bgp-export-destination 900to901dest autonomoussystem 64901 optional-attributes-list noexport ip-router policy export destination 900to901dest source 900to901src network all ip-router policy export destination 900to901dest source 900to901dir network all
• Well-known-community no-advertise
Well-known-community no-advertise is a special community indicating that the routes associated with this attribute must not be advertised to other bgp peers. A packet can be modified to contain this attribute and passed to its neighbor. However, if a packet is received with this attribute, it cannot be transmitted to another BGP peer.
• Well-known-community no-export-subconfed
Well-known-community no-export-subconfed is a special community indicating the routes associated with this attribute must not be advertised to external BGP peers.
(This includes peers in other members’ autonomous systems inside a BGP confederation.)
A packet can be modified to contain this attribute and passed to its neighbor. However, if a packet is received with this attribute, the routes (prefix-attribute pair) cannot be advertised to an external BGP peer.
• Well-known-community none
This is not actually a community, but rather a keyword that specifies that a received
BGP update is only to be matched if no communities are present. It has no effect when originating communities.
Internet Appliance User Reference Manual 123
Chapter 8: BGP Configuration Guide
Notes on Using Communities
When originating BGP communities, the set of communities that is actually sent is the union of the communities received with the route (if any), those specified in group policy
(if any), and those specified in export policy (if any).
When receiving BGP communities, the update is only matched if all communities specified in the optional-attributes-list option of the ip-router policy create command are present in the BGP update. (If additional communities are also present in the update, it will still be matched.)
Local_Pref Attribute Example
Figure 14 shows a BGP configuration that uses the BGP local preference (Local_Pref) attribute in a sample BGP configuration with two autonomous systems.
The local preference is not set directly in the CLI, but rather is a function of the GateD preference and setpref metric. The setpref option allows GateD to set the local preference to reflect GateD's own internal preference for the route, as given by the global protocol preference value. The setpref option may be used with routing or internal type groups.
BGP routes with a larger Local_Pref are preferred.
The formula used to compute the local preference is as follows:
Local_Pref = 254 – (global protocol preference for this route) + set preference metric
Note: A value greater than 254 will be reset to 254. GateD will only send Local_Pref values between 0 and 254.
In a mixed GateD and non-GateD network, the non-GateD IBGP implementation may send Local_Pref values that are greater than 254. When operating a mixed network of this type, you should make sure that all routers are restricted to sending Local_Pref values in the range metric to 254.
124 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
In the sample network in Figure 14 , all the traffic exits Autonomous System 64901 through the link between router IA13 and router IA11. This is accomplished by setting the
Local_Pref attribute.
10.200.12.1/24 10.200.13.1/24 10.200.14.1/24 10.200.15.1/24
AS-64900
1.1
1.3
IA10
192.169.20.1/16
1.6
192.168.20.1/16
192.169.20.2/16
1.1
1.3
IA11
1.6
172.28.1.1/16
EBGP EBGP
192.168.20.2/16
1.1
IA12
1.6
1.3
172.25.1.1/16
172.26.1.1/16
172.26.1.2/16
172.27.1.2/16
1.3
IA14
1.1
172.28.1.2/16
172.27.1.1/16
1.1
172.25.1.2/16
1.3
IA13
1.6
AS-64901
Legend:
Physical Link
Peering Relationship
Information Flow
Figure 14. Sample BGP Configuration (Local_Pref Attribute)
Internet Appliance User Reference Manual 125
Chapter 8: BGP Configuration Guide
In router IA12’s CLI configuration file, the import preference is set to 160:
#
# Set the set-pref metric for the IBGP peer group
# bgp set peer-group as901 set-pref 100 ip-router policy create bgp-import-source as900 autonomous-system 64900 preference 160
Using the formula for local preference [Local_Pref = 254 - (global protocol preference for this route) + metric], the Local_Pref value put out by router IA12 is 254 - 160+100 = 194.
For router IA13, the import preference is set to 150. The Local_Pref value put out by router
IA12 is 254 - 160+100 = 204.
ip-router policy create bgp-import-source as900 autonomous-system 64900 preference 150
Notes on Using the Local_Pref Attribute
• All routers in the same network that are running GateD and participating in IBGP should use the setpref metric, and the setpref metric should be set to the same value.
For example, in Figure 14 , routers IA12, IA13, and IA14 have the following line in their
CLI configuration files: bgp set peer-group as901 set-pref 100
• The value of the setpref metric should be consistent with the import policy in the network.
The metric value should be set high enough to avoid conflicts between BGP routes and
IGP or static routes. For example, if the import policy sets GateD preferences ranging from 170 to 200, a setpref metric of 170 would make sense. You should set the metric high enough to avoid conflicts between BGP routes and IGP or static routes.
Multi-Exit Discriminator Attribute Example
Multi-Exit Discriminator (MED) is a BGP attribute that affects the route selection process.
MED is used on external links to discriminate among multiple exit or entry points to the same neighboring AS. All other factors being equal, the exit or entry point with a lower metric should be preferred. If received over external links, the MED attribute may be propagated over internal links to other BGP speakers within the same AS. The MED attribute is never propagated to other BGP speakers in neighboring autonomous systems.
Figure 15 shows a sample BGP configuration where the MED attribute has been used.
126 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
10.200.12.4/24
IA4
172.16.200.4/24
172.16.200.6/24
IA6
10.200.12.6/24
AS 64752
N1
10.200.12.0/24
10.200.12.15/24
C1
Legend:
AS 64751
Physical Link
Peering Relationship
Information Flow
Figure 15. Sample BGP Configuration (MED Attribute)
Routers IA4 and IA6 inform router C1 about network 172.16.200.0/24 through External
BGP (EBGP). Router IA6 announced the route with a MED of 10, whereas router IA4 announces the route with a MED of 20. Of the two EBGP routes, router C1 chooses the one with a smaller MED. Thus router C1 prefers the route from router IA6, which has a MED of 10.
Router IA4 has the following CLI configuration: bgp create peer-group pg752to751 type external autonomous-system 64751 bgp add peer-host 10.200.12.15 group pg752to751
#
# Set the MED to be announced to peer group pg752to751
# bgp set peer-group pg752to751 metric-out 20
Router IA6 has the following CLI configuration: bgp create peer-group pg752to751 type external autonomous-system 64751 bgp add peer-host 10.200.12.15 group pg752to751 bgp set peer-group pg752to751 metric-out 10
Internet Appliance User Reference Manual 127
Chapter 8: BGP Configuration Guide
EBGP Aggregation Example
Figure 16 shows a simple EBGP configuration in which one peer is exporting an aggregated route to its upstream peer and restricting the advertisement of contributing routes to the same peer. The aggregated route is 212.19.192.0/19.
AS-64900
212.19.199.62/24
212.19.198.1/24
212.19.192.2/24
IA8
194.109.86.6
AS-64901
194.109.86.5
IA9
128
Legend:
Physical Link
Peering Relationship
Figure 16. Sample BGP Configuration (Route Aggregation)
Router IA8 has the following CLI configuration: interface add ip xleapnl address-netmask 212.19.192.2/24 interface create ip hobbygate address-netmask 212.19.199.62/24 port et.1.2
interface create ip xenosite address-netmask 212.19.198.1/24 port et.1.7
interface add ip lo0 address-netmask 212.19.192.1/30 bgp create peer-group webnet type external autonomous system 64901 bgp add peer-host 194.109.86.5 group webnet
#
# Create an aggregate route for 212.19.192.0/19 with all its subnets as
# contributing routes
# ip-router policy summarize route 212.19.192.0/19 ip-router policy redistribute from-proto aggregate to-proto bgp targetas 64901 network 212.19.192.0/19 ip-router policy redistribute from-proto direct to-proto bgp target-as
64901 network all restrict
Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
Router IA9 has the following CLI configuration: bgp create peer-group rtr8 type external autonomous system 64900 bgp add peer-host 194.109.86.6 group rtr8
Route Reflection Example
In some ISP networks, the internal BGP mesh becomes quite large, and the IBGP full mesh does not scale well. For such situations, route reflection provides a way to alleviate the need for a full IBGP mesh. In route reflection, the clients peer with the route reflector and exchange routing information with it. In turn, the route reflector passes on (reflects) information between clients.
The IBGP peers of the route reflector fall under two categories: clients and non-clients. A route reflector and its clients form a cluster. All peers of the route reflector that are not part of the cluster are non-clients. The IA supports client peers as well as non-client peers of a route reflector.
Internet Appliance User Reference Manual 129
Chapter 8: BGP Configuration Guide
Figure 17 shows a sample configuration that uses route reflection.
AS-64900 AS-64902
IA8
IA14
192.68.20.2
192.68.222.1
EBGP
Peer
EBGP
Peer
AS-64901
IBGP
Cluster
Client
IA9
IBGP
Cluster
Client
IA12
192.68.20.1
IA13
172.16.30.2
IBGP
Cluster
Client
IA11
IA10
IBGP
Non-Cluster
Client
Figure 17. Sample BGP Configuration (Route Reflection)
In this example, there are two clusters. Router IA10 is the route reflector for the first cluster and router IA11 is the route reflector for the second cluster. Router IA10 has router
IA9 as a client peer and router IA11 as a non-client peer.
The following line in router IA10’s configuration file causes it to be a route reflector.
bgp set peer-group IA9 reflector-client
130 Internet Appliance User Reference Manual
Chapter 8: BGP Configuration Guide
Router IA11 has router IA12 and router IA13 as client peers and router IA10 as non-client peer. The following line in router IA11’s configuration file specifies it to be a route reflector bgp set peer-group rtr11 reflector-client
Even though the IBGP Peers are not fully meshed in AS 64901, the direct routes of router
IA14, that is, 192.68.222.0/24 in AS 64902 (which are redistributed in BGP) do show up in the route table of router IA8 in AS64900, as shown below:
*********************************************
* Route Table (FIB) of Router 8 *
********************************************* rtr-8# ip show routes
Destination Gateway Owner Netif
----------- ------- ----- -----
10.50.0.0/16 directly connected - en
127.0.0.0/8 127.0.0.1 Static lo
127.0.0.1 127.0.0.1 - lo
172.16.20.0/24 directly connected - mls1
172.16.70.0/24 172.16.20.2 BGP mls1
172.16.220.0/24 172.16.20.2 BGP mls1
192.68.11.0/24 directly connected - mls0
192.68.20.0/24 172.16.20.2 BGP mls1
192.68.222.0/24 172.16.20.2 BGP mls1
The direct routes of router IA8, i.e. 192.68.11.0/24 in AS64900 (which are redistributed in
BGP), do show up in the route table of router IA14 in AS64902, as shown below:
**********************************************************
* Route Table (FIB) of Router 14 *
********************************************************** rtr-14# ip show routes
Destination Gateway Owner Netif
----------- ------- ----- -----
10.50.0.0/16 directly connected - en0
127.0.0.0/8 127.0.0.1 Static lo0
127.0.0.1 127.0.0.1 - lo0
172.16.20.0/24 192.68.20.1 BGP mls1
172.16.30.0/24 192.68.20.1 BGP mls1
172.16.90.0/24 192.68.20.1 BGP mls1
192.68.11.0/24 192.68.20.1 BGP mls1
192.68.20.0/24 directly connected - mls1
192.68.222.0/24 directly connected - mls0
Internet Appliance User Reference Manual 131
Chapter 8: BGP Configuration Guide
Notes on Using Route Reflection
• Two types of route reflection are supported:
– By default, all routes received by the route reflector from a client are sent to all internal peers (including the client’s group, but not the client itself).
– If the no-client-reflec t option is enabled, routes received from a route reflection client are sent only to internal peers that are not members of the client's group. In this case, the client's group must itself be fully meshed.
In either case, all routes received from a non-client internal peer are sent to all route reflection clients.
• Typically, a single router acts as the reflector for a cluster of clients. However, for redundancy, two or more may also be configured to be reflectors for the same cluster.
In this case, a cluster ID should be selected to identify all reflectors serving the cluster, using the clusterid option. Gratuitous use of multiple redundant reflectors is not advised, since it can lead to an increase in the memory required to store routes on the redundant reflectors’ peers.
• No special configuration is required on the route reflection clients. From a client's perspective, a route reflector is simply a normal IBGP peer. Any BGP version 4 speaker can be a reflector client.
• It is necessary to export routes from the local AS into the local AS when acting as a route reflector.
To accomplish this, routers IA10 and IA11 have the following line in their configuration files: ip-router policy redistribute from-proto bgp source-as 64901 toproto bgp target-as 64901
• If the cluster ID is changed, all BGP sessions with reflector clients will be dropped and restarted.
132 Internet Appliance User Reference Manual
Chapter 9
Routing Policy
Configuration
Guide
Route Import and Export Policy Overview
The Internet Appliance (IA) family of routers supports extremely flexible routing policies.
The IA allows the network administrator to control import and export of routing information based on criteria including:
• Individual protocol
• Source and destination autonomous system
• Source and destination interface
• Previous hop router
• Autonomous system path
• Tag associated with routes
• Specific destination address
The network administrator can specify a preference level for each combination of routing information being imported by using a flexible masking capability.
The IA also provides the ability to create advanced and simple routing policies. Simple routing policies provide a quick route redistribution between various routing protocols
(RIP and OSPF). Advanced routing policies provide more control over route redistribution.
Internet Appliance User Reference Manual 133
Chapter 9: Routing Policy Configuration Guide
Preference
Preference is the value the IA routing process uses to order preference of routes from one protocol or peer over another. Preference can be set using several different configuration commands. Preference can be set based on one network interface over another, from one protocol over another, or from one remote gateway over another. Preference may not be used to control the selection of routes within an Interior Gateway Protocol (IGP). This is accomplished automatically by the protocol based on metric.
Preference may be used to select routes from the same Exterior Gateway Protocol (EGP) learned from different peers or autonomous systems. Each route has only one preference value associated with it, even though the preference can be set at many places using configuration commands. The last or most specific preference value set for a route is the value used. A preference value is an arbitrarily assigned value used to determine the order of routes to the same destination in a single routing database. The active route is chosen by the lowest preference value.
A default preference is assigned to each source from which the IA routing process receives routes. Preference values range from 0 to 255, with the lowest number indicating the most preferred route.
Table 2 summarizes the default preference values for routes learned in various ways. The table lists the CLI commands that set preference and shows the types of routes to which each CLI command applies. A default preference for each type of route is listed, and the table notes preference precedence between protocols. The narrower the scope of the statement, the higher precedence its preference value is given, but the smaller the set of routes it affects.
Table 2. Default Preference Values
Preference
Direct connected networks
OSPF routes
Static routes from config
RIP routes
Point-to-point interface
Routes to interfaces that are down
Aggregate/generate routes
OSPF AS external routes
BGP routes
Defined by CLI Command ip-router global set interface ospf ip add route rip set preference ip-router global set interface down-preference aggr-gen ospf set ase-defaults preference bgp set preference
Default
0
10
60
100
110
120
130
150
170
134 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
Import Policies
Import policies control the importation of routes from routing protocols and their installation in the routing databases (Routing Information Base and Forwarding
Information Base). Import Policies determine which routes received from other systems are used by the IA routing process. Every import policy can have up to two components:
• Import-Source
• Route-Filter
Import-Source
This component specifies the source of the imported routes. It can also specify the preference to be associated with the routes imported from this source.
The routes to be imported can be identified by their associated attributes:
• Type of the source protocol (RIP, OSPF, BGP).
• Source interface or gateway from which the route was received.
• Source autonomous system from which the route was learned.
• AS path associated with a route. Besides autonomous system, BGP also supports importation of routes using AS path regular expressions and AS path options.
• If multiple communities are specified using the optional-attributes-list, only updates carrying all of the specified communities will be matched. If the specified optionalattributes-list has the value none for the well-known-community option, then only updates lacking the community attribute will be matched.
In some cases, a combination of the associated attributes can be specified to identify the routes to be imported.
Note: It is quite possible for several BGP import policies to match a given update. If more than one policy matches, the first matching policy will be used. All later matching policies will be ignored. For this reason, it is generally desirable to order import policies from most to least specific. An import policy with an optionalattributes-list will match any update with any (or no) communities.
The importation of RIP routes may be controlled by source interface and source gateway.
RIP does not support the use of preference to choose between RIP routes. That is left to the protocol metrics.
Due to the nature of OSPF, only the importation of ASE routes may be controlled. OSPF intra- and inter-area routes are always imported into the routing table with a preference of
10. If a tag is specified with the import policy, routes with the specified tag will only be imported.
Internet Appliance User Reference Manual 135
Chapter 9: Routing Policy Configuration Guide
It is only possible to restrict the importation of OSPF ASE routes when functioning as an
AS border router.
Like the other interior protocols, preference cannot be used to choose between OSPF ASE routes. That is done by the OSPF costs.
Route-Filter
This component specifies the individual routes which are to be imported or restricted. The preference to be associated with these routes can also be explicitly specified using this component.
The preference associated with the imported routes are inherited unless explicitly specified. If there is no preference specified with a route-filter, then the preference is inherited from the one specified with the import-source.
Every protocol (RIP, OSPF, and BGP) has a configurable parameter that specifies the default-preference associated with routes imported to that protocol. If a preference is not explicitly specified with the route-filter, as well as the import-source, then it is inherited from the default-preference associated with the protocol for which the routes are being imported.
Export Policies
Export policies control the redistribution of routes to other systems. They determine which routes are advertised by the Unicast Routing Process to other systems. Every export policy can have up to three components:
• Export-Destination
• Export-Source
• Route-Filter
Export-Destination
This component specifies the destination where the routes are to be exported. It also specifies the attributes associated with the exported routes. The interface, gateway, or the autonomous system to which the routes are to be redistributed are a few examples of export-destinations. The metric, type, tag, and AS-Path are a few examples of attributes associated with the exported routes.
136 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
Export-Source
This component specifies the source of the exported routes. It can also specify the metric to be associated with the routes exported from this source.
The routes to be exported can be identified by their associated attributes:
• Their protocol type (RIP, OSPF, BGP, Static, Direct, Aggregate).
• Interface or the gateway from which the route was received.
• Autonomous system from which the route was learned.
• AS path associated with a route. When BGP is configured, all routes are assigned an AS path when they are added to the routing table. For interior routes, this AS path specifies IGP as the origin and no ASs in the AS path (the current AS is added when the route is exported). For BGP routes, the AS path is stored as learned from BGP.
• Tag associated with a route. Both OSPF and RIP version 2 currently support tags. All other protocols have a tag of zero.
In some cases, a combination of the associated attributes can be specified to identify the routes to be exported.
Route-Filter
This component specifies the individual routes which are to exported or restricted. The metric to be associated with these routes can also be explicitly specified using this component.
The metric associated with the exported routes are inherited unless explicitly specified. If there is no metric specified with a route-filter, then the metric is inherited from the one specified with the export-source.
If a metric was not explicitly specified with both the route-filter and the export-source, then it is inherited from the one specified with the export-destination.
Every protocol (RIP, OSPF, and BGP) has a configurable parameter that specifies the default-metric associated with routes exported to that protocol. If a metric is not explicitly specified with the route-filter, export-source as well as export-destination, then it is inherited from the default-metric associated with the protocol to which the routes are being exported.
Internet Appliance User Reference Manual 137
Chapter 9: Routing Policy Configuration Guide
Specifying a Route Filter
Routes are filtered by specifying a route-filter that will match a certain set of routes by destination, or by destination and mask. Among other places, route filters are used with martians and in import and export policies.
The action taken when no match is found is dependent on the context. For instance, a route that does match any of the route-filters associated with the specified import or export policies is rejected.
A route will match the most specific filter that applies. Specifying more than one filter with the same destination, mask, and modifiers generates an error.
There are three possible formats for a route filter. Not all of these formats are available in all places. In most cases, it is possible to associate additional options with a filter. For example, while creating a martian, it is possible to specify the allow option, while creating an import policy, one can specify a preference , and while creating an export policy one can specify a metric .
The three forms of a route-filter are:
• Network [ exact | refines | between number,number]
• Network/mask
• Network/masklen
[ exact | refines | between number,number]
[ exact | refines | between number,number]
Matching usually requires both an address and a mask, although the mask is implied in the shorthand forms listed below. These three forms vary in how the mask is specified. In the first form, the mask is implied to be the natural mask of the network. In the second, the mask is explicitly specified. In the third, the mask is specified by the number of contiguous one bits.
If no optional parameters (exact, refines, or between) are specified, any destination that falls in the range given by the network and mask is matched, so the mask of the destination is ignored. If a natural network is specified, the network, any subnets, and any hosts will be matched. Three optional parameters that cause the mask of the destination to also be considered are:
• Exact: Specifies that the mask of the destination must match the supplied mask exactly.
This is used to match a network, but no subnets or hosts of that network.
• Refines: Specifies that the mask of the destination must be more specified (i.e., longer) than the filter mask. This is used to match subnets and/or hosts of a network, but not the network.
• Between number, number: Specifies that the mask of the destination must be as or more specific (i.e., as long as or longer) than the lower limit (the first number parameter) and no more specific (i.e., as long as or shorter) than the upper limit (the second number). Note that exact and refines are both special cases of between.
138 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
Aggregates and Generates
Route aggregation is a method of generating a more general route, given the presence of a specific route. It is used, for example, at an autonomous system border to generate a route to a network to be advertised via BGP given the presence of one or more subnets of that network learned via OSPF. The routing process does not perform any aggregation unless explicitly requested.
Route aggregation is also used by regional and national networks to reduce the amount of routing information passed around. With careful allocation of network addresses to clients, regional networks can just announce one route to regional networks instead of hundreds.
Aggregate routes are not actually used for packet forwarding by the originator of the aggregate route, but only by the receiver (if it wishes). Instead of requiring a route-peer to know about individual subnets which would increase the size of its routing table, the peer is only informed about an aggregate-route which contains all the subnets.
Like export policies, aggregate-routes can have up to three components:
• Aggregate-Destination
• Aggregate-Source
• Route-Filter
Aggregate-Destination
This component specifies the aggregate/summarized route. It also specifies the attributes associated with the aggregate route. The preference to be associated with an aggregate route can be specified using this component.
Aggregate-Source
This component specifies the source of the routes contributing to an aggregate/ summarized route. It can also specify the preference to be associated with the contributing routes from this source. This preference can be overridden by explicitly specifying a preference with the route-filter.
Internet Appliance User Reference Manual 139
Chapter 9: Routing Policy Configuration Guide
The routes contributing to an aggregate can be identified by their associated attributes:
• Protocol type (RIP, OSPF, BGP, Static, Direct, Aggregate).
• Autonomous system from which the route was learned.
• AS path associated with a route. When BGP is configured, all routes are assigned an AS path when they are added to the routing table. For interior routes, this AS path specifies IGP as the origin and no ASs in the AS path (the current AS is added when the route is exported). For BGP routes, the AS path is stored as learned from BGP.
• Tag associated with a route. Both OSPF and RIP version 2 currently support tags. All other protocols have a tag of zero.
In some cases, a combination of the associated attributes can be specified to identify the routes contributing to an aggregate.
Route-Filter
This component specifies the individual routes that are to be aggregated or summarized.
The preference to be associated with these routes can also be explicitly specified using this component.
The contributing routes are ordered according to the aggregation preference that applies to them. If there is more than one contributing route with the same aggregating preference, the route's own preferences are used to order the routes. The preference of the aggregate route will be that of contributing route with the lowest aggregate preference.
A route may only contribute to an aggregate route that is more general than itself; it must match the aggregate under its mask. Any given route may only contribute to one aggregate route, which will be the most specific configured, but an aggregate route may contribute to a more general aggregate.
An aggregate-route only comes into existence if at least one of its contributing routes is active.
Authentication
Authentication guarantees that routing information is only imported from trusted routers.
Many protocols like RIP V2 and OSPF provide mechanisms for authenticating protocol exchanges. A variety of authentication schemes can be used. Authentication has two components: an Authentication Method and an Authentication Key. Many protocols allow different authentication methods and keys to be used in different parts of the network.
140 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
Authentication Methods
There are mainly two authentication methods:
Simple Password: In this method, an authentication key of up to 8 characters is included in the packet. If this does not match what is expected, the packet is discarded. This method provides little security, as it is possible to learn the authentication key by watching the protocol packets.
MD5: This method uses the MD5 algorithm to create a crypto-checksum of the protocol packet and an authentication key of up to 16 characters. The transmitted packet does not contain the authentication key itself; instead, it contains a crypto-checksum, called the digest. The receiving router performs a calculation using the correct authentication key and discard the packet if the digest does not match. In addition, a sequence number is maintained to prevent the replay of older packets. This method provides a much stronger assurance that routing data originated from a router with a valid authentication key.
Many protocols allow the specification of two authentication keys per interface. Packets are always sent using the primary keys, but received packets are checked with both the primary and secondary keys before being discarded.
Authentication Keys and Key Management
An authentication key permits the generation and verification of the authentication field in protocol packets. In many situations, the same primary and secondary keys are used on several interfaces of a router. To make key management easier, the concept of a key-chain was introduced. Each key-chain has an identifier and can contain up to two keys. One key is the primary key and other is the secondary key. Outgoing packets use the primary authentication key, but incoming packets may match either the primary or secondary authentication key. In Configure mode, instead of specifying the key for each interface
(which can be up to 16 characters long), you can specify a key-chain identifier.
The IA supports MD5 specification of OSPF RFC 2178 which uses the MD5 algorithm and an authentication key of up to 16 characters. Thus there are now three authentication schemes available per interface: none, simple and RFC 2178 OSPF MD5 authentication. It is possible to configure different authentication schemes on different interfaces.
RFC 2178 allows multiple MD5 keys per interface. Each key has two times associated with the key:
• A time period that the key will be generated
• A time period that the key will be accepted
The IA only allows one MD5 key per interface. Also, there are no options provided to specify the time period during which the key would be generated and accepted; the specified MD5 key is always generated and accepted. Both these limitations would be removed in a future release.
Internet Appliance User Reference Manual 141
Chapter 9: Routing Policy Configuration Guide
Configuring Simple Routing Policies
Simple routing policies provide an efficient way for routing information to be exchanged between routing protocols. The redistribute command can be used to redistribute routes from one routing domain into another routing domain. Redistribution of routes between routing domains is based on route policies. A route policy is a set of conditions based on which routes are redistributed. While the redistribute command may fulfill the export policy requirement for most users, complex export policies may require the use of the commands listed under Export Policies.
The general syntax of the redistribute command is as follows: ip-router policy redistribute from-proto <protocol> to-proto <protocol> [ network <ipAddrmask> [ exact | refines | between <low-high> ]] [ metric <number> | restrict ] [ source-as
<number> ] [ target-as <number> ]
The from-proto parameter specifies the protocol of the source routes. The values for the from-proto parameter can be rip , ospf , bgp , direct , static , aggregate and ospf-ase . The toproto parameter specifies the destination protocol where the routes are to be exported.
The values for the to-proto parameter can be rip , ospf and bgp . The network parameter provides a means to define a filter for the routes to be distributed. The network parameter defines a filter that is made up of an IP address and a mask. Routes that match the filter are considered as eligible for redistribution.
Every protocol (RIP, OSPF, and BGP) has a configurable parameter that specifies the default-metric associated with routes exported to that protocol. If a metric is not explicitly specified with the redistribute command, then it is inherited from the default-metric associated with the protocol to which the routes are being exported.
Redistributing Static Routes
Static routes may be redistributed to another routing protocol such as RIP or OSPF by the following command. The network parameter specifies the set of static routes that will be redistributed by this command. If all static routes are to be redistributed set the network parameter to all . Note that the network parameter is a filter that is used to specify routes that are to be redistributed.
To redistribute static routes, enter one of the following commands in Configure mode:
To redistribute static routes into RIP.
To redistribute static routes into OSPF.
ip-router policy redistribute from-proto static to-proto rip network all ip-router policy redistribute from-proto static to-proto ospf network all
142 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
Redistributing Directly Attached Networks
Routes to directly attached networks are redistributed to another routing protocol such as
RIP or OSPF by the following command. The network parameter specifies a set of routes that will be redistributed by this command. If all direct routes are to be redistributed set the network parameter to all .
Note that the network parameter is a filter that is used to specify routes that are to be redistributed.
To redistribute direct routes, enter one of the following commands in Configure mode:
To redistribute direct routes into RIP.
To redistribute direct routes into OSPF.
ip-router policy redistribute from-proto direct to-proto rip network all ip-router policy redistribute from-proto direct to-proto ospf network all
Redistributing RIP into RIP
The IA routing process requires RIP redistribution into RIP if a protocol is redistributed into RIP.
To redistribute RIP into RIP, enter the following command in Configure mode:
To redistribute RIP into RIP.
ip-router policy redistribute from-proto rip to-proto rip
Redistributing RIP into OSPF
RIP routes may be redistributed to OSPF.
To redistribute RIP into OSPF, enter the following command in Configure mode:
To redistribute RIP into OSPF.
ip-router policy redistribute from-proto rip to-proto ospf
Internet Appliance User Reference Manual 143
Chapter 9: Routing Policy Configuration Guide
Redistributing OSPF to RIP
For the purposes of route redistribution and import-export policies, OSPF intra- and interarea routes are referred to as ospf routes, and external routes redistributed into OSPF are referred to as ospf-ase routes. Examples of ospf-ase routes include static routes, rip routes, direct routes, bgp routes, or aggregate routes, which are redistributed into an
OSPF domain.
OSPF routes may be redistributed into RIP. To redistribute OSPF into RIP, enter the following command in Configure mode:
To redistribute ospf-ase routes into rip.
To redistribute ospf routes into rip.
ip-router policy redistribute from-proto ospf-ase to-proto rip ip-router policy redistribute from-proto ospf to-proto rip
Redistributing Aggregate Routes
The aggregate parameter causes an aggregate route with the specified IP address and subnet mask to be redistributed.
Note: The aggregate route must first be created using the aggr-gen command . This command creates a specified aggregate route for routes that match the aggregate.
To redistribute aggregate routes, enter one of the following commands in Configure mode:
To redistribute aggregate routes into RIP.
To redistribute aggregate routes into OSPF.
ip-router policy redistribute from-proto aggregate to-proto rip ip-router policy redistribute from-proto aggregate to-proto OSPF
Simple Route Redistribution Examples
Example 1: Redistribution into RIP
For all examples given in this section, refer to the configurations shown in Figure 18 on page 154 .
The following configuration commands for router R1:
• Determine the IP address for each interface
• Specify the static routes configured on the router
144 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
• Determine its RIP configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Create the various IP interfaces.
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
interface create ip to-r2 address-netmask 120.190.1.1/16 port et.1.2
interface create ip to-r3 address-netmask 130.1.1.1/16 port et.1.3
interface create ip to-r41 address-netmask 140.1.1.1/24 port et.1.4
interface create ip to-r42 address-netmask 140.1.2.1/24 port et.1.5
interface create ip to-r6 address-netmask 160.1.1.1/16 port et.1.6
interface create ip to-r7 address-netmask 170.1.1.1/16 port et.1.7
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure a default route through 170.1.1.7
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route default gateway 170.1.1.7
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure static routes to the 135.3.0.0 subnets reachable through
! R3.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route 135.3.1.0/24 gateway 130.1.1.3
ip add route 135.3.2.0/24 gateway 130.1.1.3
ip add route 135.3.3.0/24 gateway 130.1.1.3
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure default routes to the other subnets reachable through R2.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route 202.1.0.0/16 gateway 120.190.1.2
ip add route 160.1.5.0/24 gateway 120.190.1.2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! RIP Box Level Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rip start
rip set default-metric 2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! RIP Interface Configuration. Create a RIP interfaces, and set
! their type to (version II, multicast).
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rip add interface to-r41
rip add interface to-r42
rip add interface to-r6
rip set interface to-r41 version 2 type multicast
rip set interface to-r42 version 2 type multicast
rip set interface to-r6 version 2 type multicast
Internet Appliance User Reference Manual 145
Chapter 9: Routing Policy Configuration Guide
Exporting a Given Static Route to All RIP Interfaces
Router R1 has several static routes of which one is the default route. We would export this default route over all RIP interfaces.
ip-router policy redistribute from-proto static to-proto rip network default
Exporting All Static Routes to All RIP Interfaces
Router R1 has several static routes. We would export these routes over all RIP interfaces.
ip-router policy redistribute from-proto static to-proto rip network all
Exporting All Static Routes Except the Default Route to All RIP Interfaces
Router R1 has several static routes. We would export all these routes except the default route to all RIP interfaces.
ip-router policy redistribute from-proto static to-proto rip network all ip-router policy redistribute from-proto static to-proto rip network default restrict
Example 2: Redistribution into OSPF
For all examples given in this section, refer to the configurations shown in Figure 19 on page 158 .
The following configuration commands for router R1:
• Determine the IP address for each interface
• Specify the static routes configured on the router
146 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
• Determine its OSPF configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Create the various IP interfaces.
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
interface create ip to-r2 address-netmask 120.190.1.1/16 port et.1.2
interface create ip to-r3 address-netmask 130.1.1.1/16 port et.1.3
interface create ip to-r41 address-netmask 140.1.1.1/24 port et.1.4
interface create ip to-r42 address-netmask 140.1.2.1/24 port et.1.5
interface create ip to-r6 address-netmask 140.1.3.1/24 port et.1.6
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure default routes to the other subnets reachable through R2.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route 202.1.0.0/16 gateway 120.1.1.2
ip add route 160.1.5.0/24 gateway 120.1.1.2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! OSPF Box Level Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ospf start
ospf create area 140.1.0.0
ospf create area backbone
ospf set ase-defaults cost 4
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! OSPF Interface Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ospf add interface 140.1.1.1 to-area 140.1.0.0
ospf add interface 140.1.2.1 to-area 140.1.0.0
ospf add interface 140.1.3.1 to-area 140.1.0.0
ospf add interface 130.1.1.1 to-area backbone
Exporting All Interface & Static Routes to OSPF
Router R1 has several static routes. We would like to export all these static routes and direct-routes (routes to connected networks) into OSPF.
ip-router policy redistribute from-proto static to-proto ospf ip-router policy redistribute from-proto direct to-proto ospf
Note: The network parameter specifying the network-filter is optional. The default value for this parameter is all , indicating all networks. Since in the above example, we would like to export all static and direct routes into OSPF, we have not specified this parameter.
Internet Appliance User Reference Manual 147
Chapter 9: Routing Policy Configuration Guide
Exporting All RIP, Interface & Static Routes to OSPF
Note: Also export interface, static, RIP, OSPF, and OSPF-ASE routes into RIP.
In the configuration shown in Figure 19 on page 158 , suppose we decide to run RIP
Version 2 on network 120.190.0.0/16, connecting routers R1 and R2.
Router R1 would like to export all RIP, interface, and static routes to OSPF. ip-router policy redistribute from-proto rip to-proto ospf ip-router policy redistribute from-proto direct to-proto ospf ip-router policy redistribute from-proto static to-proto ospf
Router R1 would also like to export interface, static, RIP, OSPF, and OSPF-ASE routes into
RIP.
ip-router policy redistribute from-proto direct to-proto rip ip-router policy redistribute from-proto static to-proto rip ip-router policy redistribute from-proto rip to-proto rip ip-router policy redistribute from-proto ospf to-proto rip ip-router policy redistribute from-proto ospf-ase to-proto rip
Configuring Advanced Routing Policies
Advanced Routing Policies are used for creating complex import/export policies that cannot be done using the redistribute command. Advanced export policies provide granular control over the targets where the routes are exported, the source of the exported routes, and the individual routes which are exported. It provides the capability to send different routes to the various route-peers. They can be used to provide the same route with different attributes to the various route-peers.
Import policies control the importation of routes from routing protocols and their installation in the routing database (Routing Information Base and Forwarding
Information Base). Import policies determine which routes received from other systems are used by the IA routing process. Using import policies, it is possible to ignore route updates from an unreliable peer and give better preference to routes learned from a trusted peer.
148 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
Export Policies
Advanced export policies can be constructed from one or more of the following building blocks:
• Export Destinations - This component specifies the destination where the routes are to be exported. It also specifies the attributes associated with the exported routes. The interface, gateway or the autonomous system to which the routes are to be redistributed are a few examples of export-destinations. The metric, type, tag, and AS-
Path are a few examples of attributes associated with the exported routes.
• Export Sources - This component specifies the source of the exported routes. It can also specify the metric to be associated with the routes exported from this source. The routes to be exported can be identified by their associated attributes, such as protocol type, interface or the gateway from which the route was received, and so on.
• Route Filter - This component provides the means to define a filter for the routes to be distributed. Routes that match a filter are considered as eligible for redistribution. This can be done using one of two methods:
– Creating a route-filter and associating an identifier with it. A route-filter has several network specifications associated with it. Every route is checked against the set of network specifications associated with all route-filters to determine its eligibility for redistribution. The identifier associated with a route-filter is used in the ip-router policy export command.
– Specifying the networks as needed in the ip-router policy export command.
If you want to create a complex route-filter, and you intend to use that route-filter in several export policies, then the first method is recommended. It you do not have complex filter requirements, then use the second method.
After you create one or more building blocks, they are tied together by the ip-router policy export command.
To create route export policies, enter the following command in Configure mode:
Create an export policy.
ip-router policy export destination <exp-dest-id>
[source <exp-src-id> [filter <filter-id> |[network
<ipAddr-mask> [exact|refines|between <low-high> ]
[metric <number> |restrict]]]]
The <exp-dest-id> is the identifier of the export-destination which determines where the routes are to be exported. If no routes to a particular destination are to be exported, then no additional parameters are required.
The <exp-src-id> , if specified, is the identifier of the export-source which determines the source of the exported routes. If a export-policy for a given export-destination has more than one export-source, then the ip-router policy export destination <exp-dest-id> command should be repeated for each <exp-src-id> .
Internet Appliance User Reference Manual 149
Chapter 9: Routing Policy Configuration Guide
The <filter-id> , if specified, is the identifier of the route-filter associated with this exportpolicy. If there is more than one route-filter for any export-destination and export-source combination, then the ip-router policy export destination <exp-dest-id> source <exp-src-id> command should be repeated for each <filter-id> .
Creating an Export Destination
To create an export destination, enter one the following commands in Configure mode:
Create a RIP export destination.
ip-router policy create rip-exportdestination < name>
Create an OSPF export destination.
ip-router policy create ospf-exportdestination < name>
Creating an Export Source
To create an export source, enter one of the following commands in Configure mode:
Create a RIP export source.
Create an OSPF export source.
ip-router policy create rip-export-source <name> ip-router policy create ospf-export-source <name>
Import Policies
Import policies can be constructed from one or more of the following building blocks:
• Import-source - This component specifies the source of the imported routes. It can also specify the preference to be associated with the routes imported from this source. The routes to be imported can be identified by their associated attributes, including source protocol, source interface, or gateway from which the route was received, and so on.
• Route Filter - This component provides the means to define a filter for the routes to be imported. Routes that match a filter are considered as eligible for importation. This can be done using one of two methods:
– Creating a route-filter and associating an identifier with it. A route-filter has several network specifications associated with it. Every route is checked against the set of network specifications associated with all route-filters to determine its eligibility for importation. The identifier associated with a route-filter is used in the ip-router policy import command.
– Specifying the networks as needed in the ip-router policy import command.
150 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
If you want to create a complex route-filter, and you intend to use that route-filter in several import policies, then the first method is recommended. It you do not have complex filter requirements, then use the second method.
After you create one or more building blocks, they are tied together by the ip-router policy import command.
To create route import policies, enter the following command in Configure mode:
Create an import policy.
ip-router policy import source <imp-src-id>
[filter <filter-id> |[network <ipAddr-mask>
[exact|refines|between <low-high> ]
[preference <number> |restrict]]]
The <imp-src-id> is the identifier of the import-source that determines the source of the imported routes. If no routes from a particular source are to be imported, then no additional parameters are required.
The <filter-id> , if specified, is the identifier of the route-filter associated with this importpolicy. If there is more than one route-filter for any import-source, then the ip-router policy import source <imp-src-id> command should be repeated for each <filter-id> .
Creating an Import Source
Import sources specify the routing protocol from which the routes are imported. The source may be RIP or OSPF.
To create an import source, enter one of the following commands in Configure mode:
Create a RIP import destination.
Create an OSPF import destination.
ip-router policy create rip-import-source <name> ip-router policy create ospf-import-source <name>
Creating a Route Filter
Route policies are defined by specifying a set of filters that will match a certain route by destination or by destination and mask.
To create route filters, enter the following command in Configure mode:
Create a route filter.
ip-router policy create filter < name-id> network
<IP-address/mask>
Internet Appliance User Reference Manual 151
Chapter 9: Routing Policy Configuration Guide
Creating an Aggregate Route
Route aggregation is a method of generating a more general route, given the presence of a specific route. The routing process does not perform any aggregation unless explicitly requested. Aggregate-routes can be constructed from one or more of the following building blocks:
• Aggregate-Destination - This component specifies the aggregate/summarized route. It also specifies the attributes associated with the aggregate route. The preference to be associated with an aggregate route can be specified using this component.
• Aggregate-Source - This component specifies the source of the routes contributing to an aggregate/summarized route. It can also specify the preference to be associated with the contributing routes from this source. The routes contributing to an aggregate can be identified by their associated attributes, including protocol type, tag associated with a route, and so on.
• Route Filter - This component provides the means to define a filter for the routes to be aggregated or summarized. Routes that match a filter are considered as eligible for aggregation. This can be done using one of two methods:
– Creating a route-filter and associating an identifier with it. A route-filter has several network specifications associated with it. Every route is checked against the set of network specifications associated with all route-filters to determine its eligibility for aggregation. The identifier associated with a route-filter is used in the ip-router policy aggr-gen command.
– Specifying the networks as needed in the ip-router policy aggr-gen command.
• If you want to create a complex route-filter, and you intend to use that route-filter in several aggregates, then the first method is recommended. It you do not have complex filter requirements, then use the second method.
After you create one or more building blocks, they are tied together by the ip-router policy aggr-gen command.
To create aggregates, enter the following command in Configure mode:
Create an aggregate route.
ip-router policy aggr-gen destination <aggr-dest-id>
[source <aggr-src-id> [filter <filter-id> |[network
<ipAddr-mask> [exact|refines|between <low-high> ]
[preference <number> |restrict]]]]
The <aggr-dest-id> is the identifier of the aggregate-destination that specifies the aggregate/summarized route.
The <aggr-src-id> is the identifier of the aggregate-source that contributes to an aggregate route. If an aggregate has more than one aggregate-source, then the ip-router policy aggrgen destination <aggr-dest-id> command should be repeated for each <aggr-src-id> .
152 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
The <filter-id> is the identifier of the route-filter associated with this aggregate. If there is more than one route-filter for any aggregate-destination and aggregate-source combination, then the ip-router policy aggr-gen destination <aggr-dest-id> source <aggrsrc-id> command should be repeated for each <filter-id> .
Creating an Aggregate Destination
To create an aggregate destination, enter the following command in Configure mode:
Create an aggregate destination.
ip-router policy create aggr-gen-dest < name> network < ipAddr-mask >
Creating an Aggregate Source
To create an aggregate source, enter the following command in Configure mode:
Create an aggregate source.
ip-router policy create aggr-gen-source < name> protocol <protocol-name>
Examples of Import Policies
Example 1: Importing from RIP
The importation of RIP routes may be controlled by any of protocol, source interface, or source gateway. If more than one is specified, they are processed from most general
(protocol) to most specific (gateway).
RIP does not support the use of preference to choose between routes of the same protocol.
That is left to the protocol metrics.
For all examples in this section, refer to the configuration shown in Figure 18 .
Internet Appliance User Reference Manual 153
Chapter 9: Routing Policy Configuration Guide
RIP V2
lt fau de
154
The following configuration commands for router R1
• Determine the IP address for each interface.
• Specify the static routes configured on the router.
• Determine its RIP configuration.
Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Create the various IP interfacesdfff+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++ interface create ip to-r2 address-netmask 120.190.1.1/16 port et.1.2 interface create ip to-r3 address-netmask 130.1.1.1/16 port et.1.3
interface create ip to-r41 address-netmask 140.1.1.1/24 port et.1.4
interface create ip to-r42 address-netmask 140.1.2.1/24 port et.1.5
interface create ip to-r6 address-netmask 160.1.1.1/16 port et.1.6
interface create ip to-r7 address-netmask 170.1.1.1/16 port et.1.7
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure a default route through 170.1.1.7
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ip add route default gateway 170.1.1.7
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure default routes to the 135.3.0.0 subnets reachable through
! R3.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ip add route 135.3.1.0/24 gateway 130.1.1.3
ip add route 135.3.2.0/24 gateway 130.1.1.3
ip add route 135.3.3.0/24 gateway 130.1.1.3
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure default routes to the other subnets reachable through R2.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ip add route 202.1.0.0/16 gateway 120.190.1.2
ip add route 160.1.5.0/24 gateway 120.190.1.2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! RIP Box Level Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ rip start rip set default-metric 2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! RIP Interface Configuration. Create a RIP interfaces, and set
! their type to (version II, multicast).
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ rip add interface to-r41 rip add interface to-r42 rip add interface to-r6 rip set interface to-r41 version 2 type multicast rip set interface to-r42 version 2 type multicast rip set interface to-r6 version 2 type multicast
Importing a Selected Subset of Routes from One RIP Trusted Gateway
Router R1 has several RIP peers. Router R41 has an interface on the network 10.51.0.0. By default, router R41 advertises network 10.51.0.0/16 in its RIP updates. Router R1 would like to import all routes except the 10.51.0.0/16 route from its peer R41.
Internet Appliance User Reference Manual 155
Chapter 9: Routing Policy Configuration Guide
1.
Add the peer 140.1.1.41 to the list of trusted and source gateways.
rip add source-gateways 140.1.1.41
rip add trusted-gateways 140.1.1.41
2.
Create a RIP import source with the gateway as 140.1.1.4 since we would like to import all routes except the 10.51.0.0/16 route from this gateway.
ip-router policy create rip-import-source ripImpSrc144 gateway
140.1.1.4
3.
Create the Import-Policy, importing all routes except the 10.51.0.0/16 route from gateway 140.1.1.4
ip-router policy import source ripImpSrc144 network all ip-router policy import source ripImpSrc144 network 10.51.0.0/16 restrict
Importing a Selected Subset of Routes from All RIP Peers Accessible Over a Certain
Interface
Router R1 has several RIP peers. Router R41 has an interface on the network 10.51.0.0. By default, router R41 advertises network 10.51.0.0/16 in its RIP updates. Router R1 would like to import all routes except the 10.51.0.0/16 route from all its peer which are accessible over interface 140.1.1.1.
1.
Create a RIP import source with the interface as 140.1.1.1, since we would like to import all routes except the 10.51.0.0/16 route from this interface.
ip-router policy create rip-import-source ripImpSrc140 interface
140.1.1.1
2.
Create the Import-Policy importing all routes except the 10.51.0.0/16 route from interface 140.1.1.1
ip-router policy import source ripImpSrc140 network all ip-router policy import source ripImpSrc140 network 10.51.0.0/16 restrict
156 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
Example 2: Importing from OSPF
Due to the nature of OSPF, only the importation of ASE routes may be controlled. OSPF intra- and inter-area routes are always imported into the IA routing table with a preference of 10. If a tag is specified, the import clause will only apply to routes with the specified tag.
It is only possible to restrict the importation of OSPF ASE routes when functioning as an
AS border router.
Like the other interior protocols, preference cannot be used to choose between OSPF ASE routes. That is done by the OSPF costs. Routes that are rejected by policy are stored in the table with a negative preference.
For all examples in this section, refer to the configuration shown in Figure 19 .
Internet Appliance User Reference Manual 157
R6
140.1.4/24
R42
Figure 19. Exporting to OSPF
140.1.5/24
R41
140.1.1.2/24
A r e a 140.1.0.0
BGP
A r e a B a c k b o n e
140.1.3.1/24
140.1.2.1/24
140.1.1.1/24
R1
190.1.1.1/16
130.1.1.1/16
130.1.1.3/16
120.190.1.1/16
R3 R5 R7
150.20.3.1/16
150.20.3.2/16
R8
A r e a 150.20.0.0
R11
120.190.1.2/16
202.1.2.2/16
R2
160.1.5.2/24
160.1.5.2/24
R10
Chapter 9: Routing Policy Configuration Guide
The following configuration commands for router R1:
• Determine the IP address for each interface
• Specify the static routes configured on the router
• Determine its OSPF configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Create the various IP interfaces.
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
interface create ip to-r2 address-netmask 120.190.1.1/16 port et.1.2
interface create ip to-r3 address-netmask 130.1.1.1/16 port et.1.3
interface create ip to-r41 address-netmask 140.1.1.1/24 port et.1.4
interface create ip to-r42 address-netmask 140.1.2.1/24 port et.1.5
interface create ip to-r6 address-netmask 140.1.3.1/24 port et.1.6
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure default routes to the other subnets reachable through R2.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route 202.1.0.0/16 gateway 120.1.1.2
ip add route 160.1.5.0/24 gateway 120.1.1.2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! OSPF Box Level Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ospf start
ospf create area 140.1.0.0
ospf create area backbone
ospf set ase-defaults cost 4
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! OSPF Interface Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ospf add interface 140.1.1.1 to-area 140.1.0.0
ospf add interface 140.1.2.1 to-area 140.1.0.0
ospf add interface 140.1.3.1 to-area 140.1.0.0
ospf add interface 130.1.1.1 to-area backbone
Importing a Selected Subset of OSPF-ASE Routes
1.
Create a OSPF import source so that only routes that have a tag of 100 are considered for importation.
ip-router policy create ospf-import-source ospfImpSrct100 tag 100
2.
Create the Import-Policy importing all OSPF ASE routes with a tag of 100 except the default ASE route. ip-router policy import source ospfImpSrct100 network all ip-router policy import source ospfImpSrct100 network default restrict
Internet Appliance User Reference Manual 159
Chapter 9: Routing Policy Configuration Guide
Examples of Export Policies
Example 1: Exporting to RIP
Exporting to RIP is controlled by any of protocol, interface or gateway. If more than one is specified, they are processed from most general (protocol) to most specific (gateway).
It is not possible to set metrics for exporting RIP routes into RIP. Attempts to do this are silently ignored.
If no export policy is specified, RIP and interface routes are exported into RIP. If any policy is specified, the defaults are overridden; it is necessary to explicitly specify everything that should be exported.
RIP version 1 assumes that all subnets of the shared network have the same subnet mask so it is only able to propagate subnets of that network. RIP version 2 removes that restriction and is capable of propagating all routes when not sending version 1 compatible updates.
To announce routes which specify a next hop of the loopback interface (that is, static and internally generated default routes) via RIP, it is necessary to specify the metric at some level in the export policy. Just setting a default metric for RIP is not sufficient. This is a safeguard to verify that the announcement is intended.
For all examples in this section, refer to the configuration shown in Figure 18 on page 154 .
The following configuration commands for router R1:
• Determine the IP address for each interface
• Specify the static routes configured on the router
160 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
• Determine its RIP configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Create the various IP interfaces.
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
interface create ip to-r2 address-netmask 120.190.1.1/16 port et.1.2
interface create ip to-r3 address-netmask 130.1.1.1/16 port et.1.3
interface create ip to-r41 address-netmask 140.1.1.1/24 port et.1.4
interface create ip to-r42 address-netmask 140.1.2.1/24 port et.1.5
interface create ip to-r6 address-netmask 160.1.1.1/16 port et.1.6
interface create ip to-r7 address-netmask 170.1.1.1/16 port et.1.7
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure a default route through 170.1.1.7
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route default gateway 170.1.1.7
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure default routes to the 135.3.0.0 subnets reachable through
! R3.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route 135.3.1.0/24 gateway 130.1.1.3
ip add route 135.3.2.0/24 gateway 130.1.1.3
ip add route 135.3.3.0/24 gateway 130.1.1.3
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure default routes to the other subnets reachable through R2.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route 202.1.0.0/16 gateway 120.190.1.2
ip add route 160.1.5.0/24 gateway 120.190.1.2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! RIP Box Level Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rip start
rip set default-metric 2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! RIP Interface Configuration. Create a RIP interfaces, and set
! their type to (version II, multicast).
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rip add interface to-r41
rip add interface to-r42
rip add interface to-r6
rip set interface to-r41 version 2 type multicast
rip set interface to-r42 version 2 type multicast
rip set interface to-r6 version 2 type multicast
Exporting a Given Static Route to All RIP Interfaces
Router R1 has several static routes, of which one is the default route. We would export this default route over all RIP interfaces.
1.
Create a RIP export destination since we would like to export routes into RIP.
ip-router policy create rip-export-destination ripExpDst
Internet Appliance User Reference Manual 161
Chapter 9: Routing Policy Configuration Guide
162
2.
Create a Static export source since we would like to export static routes.
ip-router policy create static-export-source statExpSrc
As mentioned above, if no export policy is specified, RIP and interface routes are exported into RIP. If any policy is specified, the defaults are overridden; it is necessary to explicitly specify everything that should be exported.
Since we would also like to export/redistribute RIP and direct routes into RIP, we would also create export-sources for those protocols.
3.
Create a RIP export source since we would like to export RIP routes.
ip-router policy create rip-export-source ripExpSrc
4.
Create a Direct export source since we would like to export direct/interface routes.
ip-router policy create direct-export-source directExpSrc
5.
Create the export-policy redistributing the statically created default route, and all
(RIP, Direct) routes into RIP.
ip-router policy export destination ripExpDst source statExpSrc network default ip-router policy export destination ripExpDst source ripExpSrc network all ip-router policy export destination ripExpDst source directExpSrc network all
Exporting a Given Static Route to a Specific RIP Interface
In this case, router R1 would export/redistribute the default route over its interface
140.1.1.1 only.
1.
Create a RIP export destination for interface with address 140.1.1.1, since we intend to change the rip export policy only for interface 140.1.1.1.
ip-router policy create rip-export-destination ripExpDst141 interface 140.1.1.1
2.
Create a static export source since we would like to export static routes.
ip-router policy create static-export-source statExpSrc
3.
Create a RIP export source since we would like to export RIP routes.
ip-router policy create rip-export-source ripExpSrc
Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
4.
Create a Direct export source since we would like to export direct/interface routes.
ip-router policy create direct-export-source directExpSrc
5.
Create the Export-Policy redistributing the statically created default route, and all
(RIP, Direct) routes into RIP.
ip-router policy export destination ripExpDst141 source statExpSrc network default ip-router policy export destination ripExpDst141 source ripExpSrc network all ip-router policy export destination ripExpDst141 source directExpSrc network all
Exporting All Static Routes Reachable Over a Given Interface to a Specific RIP-
Interface
In this case, router R1 would export/redistribute all static routes accessible through its interface 130.1.1.1 to its RIP-interface 140.1.1.1 only.
1.
Create a RIP export destination for interface with address 140.1.1.1, since we intend to change the rip export policy for interface 140.1.1.1
ip-router policy create rip-export-destination ripExpDst141 interface 140.1.1.1
2.
Create a Static export source since we would like to export static routes.
ip-router policy create static-export-source statExpSrc130 interface
130.1.1.1
3.
Create a RIP export source since we would like to export RIP routes.
ip-router policy create rip-export-source ripExpSrc
4.
Create a Direct export source.
ip-router policy create direct-export-source directExpSrc
Internet Appliance User Reference Manual 163
Chapter 9: Routing Policy Configuration Guide
5.
Create the Export-Policy, redistributing all static routes reachable over interface
130.1.1.1 and all (RIP, Direct) routes into RIP.
ip-router policy export destination ripExpDst141 source statExpSrc130 network all ip-router policy export destination ripExpDst141 source ripExpSrc network all ip-router policy export destination ripExpDst141 source directExpSrc network all
Exporting Aggregate-Routes into RIP
In the configuration shown in Figure 18 on page 154 , suppose you decide to run RIP
Version 1 on network 130.1.0.0/16, connecting routers R1 and R3. Router R1 desires to announce the 140.1.1.0/24 and 140.1.2.0/24 networks to router R3. RIP Version 1 does not carry any information about subnet masks in its packets. Thus it would not be possible to announce the subnets (140.1.1.0/24 and 140.1.2.0/24) into RIP Version 1 without aggregating them.
1.
Create an Aggregate-Destination which represents the aggregate/summarized route.
ip-router policy create aggr-gen-dest aggrDst140 network
140.1.0.0/16
2.
Create an Aggregate-Source which qualifies the source of the routes contributing to the aggregate. Since in this case, we do not care about the source of the contributing routes, we would specify the protocol as all. ip-router policy create aggr-gen-source allAggrSrc protocol all
3.
Create the aggregate/summarized route. This command binds the aggregated route with the contributing routes.
ip-router aggr-gen destination aggrDst140 source allAggrSrc network
140.1.1.0/24 ip-router aggr-gen destination aggrDst140 source allAggrSrc network
140.1.2.0/24
4.
Create a RIP export destination for interface with address 130.1.1.1, since we intend to change the rip export policy only for interface 130.1.1.1.
ip-router policy create rip-export-destination ripExpDst130 interface 130.1.1.1
164 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
5.
Create a Aggregate export source since we would to export/redistribute an aggregate/summarized route.
ip-router policy create aggr-export-source aggrExpSrc
6.
Create a RIP export source since we would like to export RIP routes.
ip-router policy create rip-export-source ripExpSrc
7.
Create a Direct export source since we would like to export Direct routes.
ip-router policy create direct-export-source directExpSrc
8.
Create the Export-Policy redistributing all (RIP, Direct) routes and the aggregate route
140.1.0.0/16 into RIP.
ip-router policy export destination ripExpDst130 source aggrExpSrc network 140.1.0.0/16 ip-router policy export destination ripExpDst130 source ripExpSrc network all ip-router policy export destination ripExpDst130 source directExpSrc network all
Example 2: Exporting to OSPF
It is not possible to create OSPF intra- or inter-area routes by exporting routes from the IA routing table into OSPF. It is only possible to export from the IA routing table into OSPF
ASE routes. It is also not possible to control the propagation of OSPF routes within the
OSPF protocol.
There are two types of OSPF ASE routes: type 1 and type 2. The default type is specified by the ospf set ase-defaults type 1/2 command. This may be overridden by a specification in the ip-router policy create ospf-export-destination command.
OSPF ASE routes also have the provision to carry a tag. This is an arbitrary 32-bit number that can be used on OSPF routers to filter routing information. The default tag is specified by the ospf set ase-defaults tag command. This may be overridden by a tag specified with the ip-router policy create ospf-export-destination command.
Interface routes are not automatically exported into OSPF. They have to be explicitly done.
For all examples in this section, refer to the configuration shown in Figure 19 on page 158 .
The following configuration commands for router R1:
• Determine the IP address for each interface
• Specify the static routes configured on the router
Internet Appliance User Reference Manual 165
Chapter 9: Routing Policy Configuration Guide
166
• Determine its OSPF configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Create the various IP interfaces.
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
interface create ip to-r2 address-netmask 120.190.1.1/16 port et.1.2
interface create ip to-r3 address-netmask 130.1.1.1/16 port et.1.3
interface create ip to-r41 address-netmask 140.1.1.1/24 port et.1.4
interface create ip to-r42 address-netmask 140.1.2.1/24 port et.1.5
interface create ip to-r6 address-netmask 140.1.3.1/24 port et.1.6
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! Configure default routes to the other subnets reachable through R2.
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip add route 202.1.0.0/16 gateway 120.1.1.2
ip add route 160.1.5.0/24 gateway 120.1.1.2
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! OSPF Box Level Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ospf start
ospf create area 140.1.0.0
ospf create area backbone
ospf set ase-defaults cost 4
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! OSPF Interface Configuration
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ospf add interface 140.1.1.1 to-area 140.1.0.0
ospf add interface 140.1.2.1 to-area 140.1.0.0
ospf add interface 140.1.3.1 to-area 140.1.0.0
ospf add interface 130.1.1.1 to-area backbone
Exporting All Interface & Static Routes to OSPF
Router R1 has several static routes. We would export these static routes as type-2 OSPF routes. The interface routes would redistributed as type 1 OSPF routes.
1.
Create a OSPF export destination for type-1 routes since we would like to redistribute certain routes into OSPF as type 1 OSPF-ASE routes.
ip-router policy create ospf-export-destination ospfExpDstType1 type 1 metric 1
2.
Create a OSPF export destination for type-2 routes since we would like to redistribute certain routes into OSPF as type 2 OSPF-ASE routes.
ip-router policy create ospf-export-destination ospfExpDstType2 type 2 metric 4
3.
Create a Static export source since we would like to export static routes.
ip-router policy create static-export-source statExpSrc
Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
4.
Create a Direct export source since we would like to export interface/direct routes.
ip-router policy create direct-export-source directExpSrc
5.
Create the Export-Policy for redistributing all interface routes and static routes into
OSPF.
ip-router policy export destination ospfExpDstType1 source directExpSrc network all ip-router policy export destination ospfExpDstType2 source statExpSrc network all
Exporting All RIP, Interface & Static Routes to OSPF
Note: Also export interface, static, RIP, OSPF, and OSPF-ASE routes into RIP.
In the configuration shown in Figure 19 on page 158 , suppose we decide to run RIP
Version 2 on network 120.190.0.0/16, connecting routers R1 and R2.
We would like to redistribute these RIP routes as OSPF type-2 routes, and associate the tag
100 with them. Router R1 would also like to redistribute its static routes as type 2 OSPF routes. The interface routes would redistributed as type 1 OSPF routes.
Router R1 would like to redistribute its OSPF, OSPF-ASE, RIP, Static and Interface/Direct routes into RIP.
1.
Enable RIP on interface 120.190.1.1/16.
rip add interface 120.190.1.1
rip set interface 120.190.1.1 version 2 type multicast
2.
Create a OSPF export destination for type-1 routes.
ip-router policy create ospf-export-destination ospfExpDstType1 type 1 metric 1
3.
Create a OSPF export destination for type-2 routes.
ip-router policy create ospf-export-destination ospfExpDstType2 type 2 metric 4
4.
Create a OSPF export destination for type-2 routes with a tag of 100.
ip-router policy create ospf-export-destination ospfExpDstType2t100 type 2 tag 100 metric 4
Internet Appliance User Reference Manual 167
Chapter 9: Routing Policy Configuration Guide
5.
Create a RIP export source.
ip-router policy export destination ripExpDst source ripExpSrc network all
6.
Create a Static export source.
ip-router policy create static-export-source statExpSrc
7.
Create a Direct export source.
ip-router policy create direct-export-source directExpSrc
8.
Create the Export-Policy for redistributing all interface, RIP and static routes into
OSPF.
ip-router policy export destination ospfExpDstType1 source directExpSrc network all ip-router policy export destination ospfExpDstType2 source statExpSrc network all ip-router policy export destination ospfExpDstType2t100 source ripExpSrc network all
9.
Create a RIP export destination.
ip-router policy create rip-export-destination ripExpDst
10. Create OSPF export source.
ip-router policy create ospf-export-source ospfExpSrc type OSPF
11. Create OSPF-ASE export source.
ip-router policy create ospf-export-source ospfAseExpSrc type OSPF-ASE
168 Internet Appliance User Reference Manual
Chapter 9: Routing Policy Configuration Guide
12. Create the Export-Policy for redistributing all interface, RIP, static, OSPF and OSPF-
ASE routes into RIP.
ip-router policy export destination ripExpDst source statExpSrc network all ip-router policy export destination ripExpDst source ripExpSrc network all ip-router policy export destination ripExpDst source directExpSrc network all ip-router policy export destination ripExpDst source ospfExpSrc network all ip-router policy export destination ripExpDst source ospfAseExpSrc network all
Internet Appliance User Reference Manual 169
Chapter 10
IP Policy-Based
Forwarding
Configuration
Guide
Overview
You can configure the Internet Appliance (IA) to route IP packets according to policies that you define. IP-policy-based routing allows network managers to engineer traffic to make the most efficient use of their network resources.
IP policies forward packets based on Layer-3 or Layer-4 IP header information. You can define IP policies to route packets to a set of next-hop IP addresses based on any combination the following IP header fields:
• IP protocol
• Source IP address
• Destination IP address
• Source Socket
• Destination Socket
• Type of service
Internet Appliance User Reference Manual 171
Chapter 10: IP Policy-Based Forwarding Configuration Guide
For example, you can set up an IP policy to send packets originating from a certain network through a firewall, while letting other packets bypass the firewall. Using IP policies, sites that have multiple Internet service providers can cause user groups to use different ISPs. You can also create IP policies to select service providers based on various traffic types.
Other uses for IP policy routing include transparent web caching, where all HTTP requests are directed to a local cache server, saving WAN access bandwidth and costs. An
ISP can use policy-based routing on an access router to supply high-priority customers with premium levels of service.
Configuring IP Policies
To implement an IP policy, you first create a profile for the packets to be forwarded using an IP policy. For example, you can create a profile defined as all telnet packets going from network 9.1.0.0/16 to network 15.1.0.0/16 . You then associate the profile with an IP policy.
The IP policy specifies what to do with the packets that match the profile. For example, you can create an IP policy that sends packets matching a given profile to next-hop gateway 100.1.1.1.
Configuring an IP policy consists of the following tasks:
• Defining a profile
• Associating the profile with a policy
• Applying the IP policy to an interface
Defining an ACL Profile
An ACL profile specifies the criteria packets must meet to be eligible for IP policy routing.
You define profiles with the acl command. For IP policy routing, the IA uses the packetrelated information from the acl command and ignores the other fields.
For example, the following acl command creates a profile named prof1 for telnet packets going from network 9.1.1.5 to network 15.1.1.2: ia(config)# acl prof1 permit ip 9.1.0.0/16 15.1.0.0/16 any any telnet 0
See the Internet Appliance Command Line Interface Reference for complete syntax information for the acl command.
Note: ACLs for non-IP protocols cannot be used for IP policy routing.
172 Internet Appliance User Reference Manual
Chapter 10: IP Policy-Based Forwarding Configuration Guide
Associating the Profile with an IP Policy
Once you have defined a profile with the acl command, you associate the profile with an
IP policy by entering one or more ip-policy statements. An ip-policy statement specifies the next-hop gateway (or gateways) where packets matching a profile are forwarded. To cause packets matching a defined profile to be forwarded to a next-hop gateway, enter the following command in Configure mode:
Forward packets matching a profile to a next-hop gateway.
ip-policy <name> permit acl <profile> nexthop-list <ip-addr-list>
For example, the following command creates an IP policy named p1 and specifies that packets matching profile prof1 are forwarded to next-hop gateway 10.10.10.10: ia(config)# ip-policy p1 permit acl prof1 next-hop-list 10.10.10.10
You can also set up a policy to prevent packets from being forwarded by an IP policy. To prevent packets matching a defined profile from being forwarded by an IP policy to a next-hop gateway, enter the following command in Configure mode: ip-policy <name> deny acl <profile> Prevent packets matching a profile from being forwarded by an IP policy.
Packets matching the specified profile are forwarded using dynamic routes instead.
For example, the following command creates an IP policy named p2 that prevents packets matching prof1 from being forwarded using an IP policy: ia(config)# ip-policy p2 deny acl prof1
Creating Multi-statement IP Policies
An IP policy can contain more than one ip-policy statement. For example, an IP policy can contain one statement that sends all packets matching a profile to one next-hop gateway, and another statement that sends packets matching a different profile to a different nexthop gateway. If an IP policy has multiple ip-policy statements, you can assign each statement a sequence number that controls the order in which they are evaluated.
Statements are evaluated from lowest sequence number to highest.
To specify the order in which IP policy statements are evaluated by an IP policy, enter the following command in Configure mode:
Specify a sequence number for IP policy statements ip-policy <name> permit|deny acl <profile> sequence <num>
Internet Appliance User Reference Manual 173
Chapter 10: IP Policy-Based Forwarding Configuration Guide
For example, the following commands create an IP policy called p3 , which consists of two
IP policy statements. The ip policy permit statement has a sequence number of 1, which means it is evaluated before the ip policy deny statement, which has a sequence number of 900.
ia(config)# ip-policy p3 permit acl prof1 next-hop-list 10.10.10.10 sequence 1 ia(config)# ip-policy p3 deny acl prof2 sequence 900
Setting Load Distribution for Next-Hop Gateways
You can specify up to four next-hop gateways in an ip-policy statement. If you specify more than one next-hop gateway, you can control how the load is distributed among them. You can cause each new flow to use the first available next-hop gateway in the ip-policy permit statement, or you can cause flows to use all the next-hop gateways in the ip-policy permit statement sequentially.
To set the load distribution for next-hop gateways, enter one of the following commands in Configure mode:
Use the first available next-hop gateway in the ip-policy permit statement for all flows. This is the default.
Sequentially pick the next gateway in the list for each new flow.
Use the source IP, desination IP, or both the source IP and the destination
IP addresses to determine the nexthop gateway to use.
ip-policy <name> set load-policy first-available ip-policy <name> set load-policy round-robin ip-policy <name> set load-policy ip-hash sip|dip|both
Setting the IP Policy Action
You can specify when to apply the IP policy route with respect to dynamic or statically configured routes. The IA can cause packets to use the IP policy route first, then the dynamic route if the next-hop gateway specified in the IP policy is unavailable; use the dynamic route first, then the IP policy route; or drop the packets if the next-hop gateway specified in the IP policy is unavailable.
174 Internet Appliance User Reference Manual
Chapter 10: IP Policy-Based Forwarding Configuration Guide
To set the IP policy action with respect to dynamic or statically configured routes, enter one of the following commands in Configure mode:
Cause packets matching the profile to use the IP policy route first. If the next-hop gateway is not reachable, use the dynamic route instead.
Route packets matching the profile using dynamic routes first. If a dynamic route is not available, then route packets matching the profile using the IP policy gateway.
Cause packets matching the profile to use the IP policy route.
If the next-hop gateway is not reachable, then drop the packets.
Drop packets matching the profile.
Drop packets that do not match any profile.
Do not use policy routing for packets matching this ACL.
Forward using dynamic routes.
ip-policy <name> permit acl <profile> action policy-first ip-policy <name> permit acl <profile> action policy-last ip-policy <name> permit acl <profile> action policy-only ip-policy <name> permit acl <profile> next-hop-list null ip-policy <name> permit everything-else next-hop-list null ip-policy <name> deny acl <profile> ...
Checking the Availability of Next-Hop Gateways
The IA can check the availability of next-hop gateways by querying them with
ICMP_ECHO_REQUESTS. Only gateways that respond to these requests are used for forwarding packets. To configure the IA to do this, enter the following command in
Configure mode:
Periodically check the availability of next-hop gateways.
ip-policy <name> set pinger on
Note: Some hosts may have disabled responding to ICMP_ECHO packets. Make sure each next-hop gateway can respond to ICMP_ECHO packets before using this option.
Internet Appliance User Reference Manual 175
Chapter 10: IP Policy-Based Forwarding Configuration Guide
Applying an IP Policy to an Interface
After you define the IP policy, it must be applied to an inbound IP interface. Once the IP policy is applied to the interface, packets start being forwarded according to the IP policy.
To apply an IP policy to an interface, enter one of the following commands in Configure mode:
Apply a defined IP policy to an IP interface.
Apply a defined IP policy to all IP interfaces on the IA.
ip-policy <name> apply interface <InterfaceName> ip-policy <name> apply interface all
Applying an IP Policy to Locally Generated Packets
You can apply an IP policy to locally generated packets (that is, packets generated by the
IA). To do this, enter the following command in Configure mode:
Cause packets generated by the
IA to be forwarded according to an IP policy.
ip-policy <name> apply local
IP Policy Configuration Examples
This section presents some examples of IP policy configurations. The following uses of IP policies are demonstrated:
• Routing traffic to different ISPs
• Prioritizing service to customers
• Authenticating users through a firewall
• Firewall load balancing
Routing Traffic to Different ISPs
Sites that have multiple Internet service providers can create IP policies that cause different user groups to use different ISPs. You can also create IP policies to select service providers based on various traffic types.
176 Internet Appliance User Reference Manual
Chapter 10: IP Policy-Based Forwarding Configuration Guide
In the sample configuration in Figure 20 , the policy router is configured to divide traffic originating within the corporate network between different ISPs (100.1.1.1 and 200.1.1.1).
ISP1
100.1.1.1
Group user-a
10.50.*.* et.1.1
Policy
Router et.1.2
ISP2
200.1.1.1
Group user-b
11.50.*.*
Figure 20. Using an IP Policy To Route Traffic To Two Different ISPs
HTTP traffic originating from network 10.50.0.0 for destination 207.31.0.0/16 is forwarded to 100.1.1.1. Non-HTTP traffic originating from network 10.50.0.0 for destination
207.31.0.0/16 is forwarded to 200.1.1.1. All other traffic is forwarded to 100.1.1.1.
The following is the IP policy configuration for the Policy Router in Figure 20 : interface create ip user-a address-netmask 10.50.1.1/16 port et.1.1
interface create ip user-b address-netmask 11.50.1.1/16 port et.1.2
acl user-a-http permit ip 10.50.0.0/16 207.31.0.0/16 any http 0 acl user-a permit ip 10.50.0.0/16 207.31.0.0/16 any any 0 acl user-b permit ip 11.50.0.0/16 any any any 0 ip-policy net-a permit acl user-a-http next-hop-list 100.1.1.1 action policy-first sequence 20 ip-policy net-a permit acl user-a next-hop-list 200.1.1.1 action policyonly sequence 25 ip-policy net-a apply interface user-a ip-policy net-b permit acl user-b next-hop-list 200.1.1.1 action policyfirst ip-policy net-b apply interface user-b
Internet Appliance User Reference Manual 177
Chapter 10: IP Policy-Based Forwarding Configuration Guide
Prioritizing Service to Customers
An ISP can use policy-based routing on an access router to supply different customers with different levels of service. The sample configuration in Figure 21 shows an IA using an IP policy to classify customers and route traffic to different networks based on customer type.
ISP
High-Cost, High Availability
Network 100.1.1.1
Premium Customer
10.50.*.* et.1.1
Policy
Router et.1.2
Low-Cost Network
200.1.1.1
Standard Customer
11.50.*.*
Figure 21. Using an IP policy to prioritize service to customers
Traffic from the premium customer is load balanced across two next-hop gateways in the high-cost, high-availability network. If neither of these gateways is available, then packets are forwarded based on dynamic routes learned via routing protocols.
Traffic from the standard customer always uses one gateway (200.1.1.1). If for some reason that gateway is not available, packets from the standard customer are dropped.
178 Internet Appliance User Reference Manual
Chapter 10: IP Policy-Based Forwarding Configuration Guide
The following is the IP policy configuration for the Policy Router in Figure 21 : interface create ip premium-customer address-netmask 10.50.1.1/16 port et.1.1
interface create ip standard-customer address-netmask 11.50.1.1/16 port et.1.2
acl premium-customer permit ip 10.50.0.0/16 any any any 0 acl standard-customer permit ip 11.50.0.0/16 any any any 0 ip-policy p1 permit acl premium-customer next-hop-list "100.1.1.1
100.1.1.2" action policy-first sequence 20 ip-policy apply interface premium-customer ip-policy p2 permit acl standard-customer next-hop-list 200.1.1.1 action policy-only sequence 30 ip-policy apply interface standard-customer
Authenticating Users through a Firewall
You can define an IP policy that authenticates packets from certain users via a firewall before accessing the network. If for some reason the firewall is not responding, the packets to be authenticated are dropped. Figure 22 illustrates this kind of configuration.
Firewall contractors
10.50.1.0/24
11.1.1.1
12.1.1.1
Policy
Router
Router
Rout Servers full-timers
10.50.2.0/24
Figure 22. Using an IP policy To Authenticate Users through a Firewall
Packets from users defined in the contractors group are sent through a firewall. If the firewall cannot be reached, packets from the contractors group are dropped. Packets from users defined in the full-timers group do not have to go through the firewall.
Internet Appliance User Reference Manual 179
Chapter 10: IP Policy-Based Forwarding Configuration Guide
The following is the IP policy configuration for the Policy Router in Figure 22 : interface create ip mls0 address-netmask 10.50.1.1/16 port et.1.1
acl contractors permit ip 10.50.1.0/24 any any any 0 acl full-timers permit ip 10.50.2.0/24 any any any 0 ip-policy access permit acl contractors next-hop-list 11.1.1.1 action policy-only ip-policy access permit acl full-timers next-hop-list 12.1.1.1 action policy-first ip-policy access apply interface mls0
Firewall Load Balancing
The next-hop gateway can be selected by the following information in the IP packet: source IP, destination IP, or both the source and destination IP. Figure 23 illustrates this configuration.
Intranet
Internet
Firewalls mls1
1.1.1.1
1
2.2.2.1
Policy
Router 1
1.1.1.5
et
.1
.1
et.1.
2 et.1.
et
.1
.4
3
1.1.1.2
1.1.1.3
2
3 et.1
2.2.2.2
et.1.2
.1
2.2.2.3
et.1.
3
4 et
.1.
Policy
Router 2 mls2
2.2.2.5
1.1.1.4
4 2.2.2.4
Figure 23. Selecting Next-Hop Gateway from IP Packet Information
One session should always go to a particular firewall for persistence.
180 Internet Appliance User Reference Manual
Chapter 10: IP Policy-Based Forwarding Configuration Guide
The following is the configuration for Policy Router 1 in Figure 23 .
vlan create firewall vlan add ports et.1.(1-5) to firewall interface create ip firewall address-netmask 1.1.1.5/16 vlan firewall acl firewall permit ip any any any 0 ip-policy p1 permit acl firewall next-hop-list “1.1.1.1 1.1.1.2 1.1.1.3
1.1.1.4” action policy-only ip-policy p1 set load-policy ip-hash both ip-policy p1 apply interface mls1
The following is the configuration for Policy Router 2 in Figure 23 .
vlan create firewall vlan add ports et.1.(1-5) to firewall interface create ip firewall address-netmask 2.2.2.5/16 vlan firewall acl firewall permit ip any any any 0 ip-policy p2 permit acl firewall next-hop-list “2.2.2.1 2.2.2.2 2.2.2.3
2.2.2.4” action policy-only ip-policy p2 set load-policy ip-hash both ip-policy p2 apply interface mls2
Monitoring IP Policies
The ip-policy show command reports information about active IP policies, including profile definitions, policy configuration settings, and next-hop gateways. The command also displays statistics about packets that have matched an IP policy statement as well as the number of packets that have been forwarded to each next-hop gateway.
To display IP policy information, enter the following commands in Enable mode.
Display information about all
IP policies.
Display statistics about a specific IP policy.
ip-policy show all ip-policy show policy-name all ip-policy show policy-name <name>
Internet Appliance User Reference Manual 181
Chapter 10: IP Policy-Based Forwarding Configuration Guide
Display information about all
IP policies on a specified interface.
Display information about IP policies that have been applied to all interfaces
Clear statistics gathered for IP policies.
ip-policy show interface <interface> ip-policy show interface all ip-policy clear all | policy-name <name> | all
For example, to display information about an active IP policy named p1 , enter the following command in Enable mode: ia# ip-policy show policy-name p1
--------------------------------------------------------------------------------
IP Policy name : p1
1
Applied Interfaces : int1 2
Load Policy : first available
3
4 5 6 7 8 9 10
ACL Source IP/Mask Dest. IP/Mask SrcPort DstPort TOS Prot
--- -------------- ------------- --------- --------- --- ---prof1 9.1.1.5/32 15.1.1.2 any any 0 IP prof2 2.2.2.2/32 anywhere any any 0 IP everything anywhere anywhere any any 0 IP
Next Hop Information
--------------------
11 12 13 14 15 16 17 18
Seq Rule ACL Cnt Action Next Hop Cnt Last
--- ---- -------- --- ----------- -------- --- ----
10 permit prof1 0 Policy Only 11.1.1.2 0 Dwn
20 permit prof2 0 Policy Last 1.1.1.1 0 Dwn
2.2.2.2 0 Dwn
3.3.3.3 0 Dwn
999 permit everything 0 Policy Only drop N/A N/A
65536 deny deny 0 N/A normal fwd N/A N/A
19
Legend:
1.
The name of the IP policy.
2.
The interface where the IP policy was applied.
3.
The load distribution setting for IP-policy statements that have more than one nexthop gateway; either first available (the default) or round-robin.
4.
The names of the profiles (created with an acl statement) associated with this IP policy.
182 Internet Appliance User Reference Manual
Chapter 10: IP Policy-Based Forwarding Configuration Guide
5.
The source address and filtering mask of this flow.
6.
The destination address and filtering mask of this flow.
7.
For TCP or UDP, the number of the source TCP or UDP port.
8.
For TCP or UDP, the number of the destination TCP or UDP port.
9.
The TOS value in the packet.
10. IP protocol (ICMP, TCP UDP).
11. The sequence in which the statement is evaluated. IP policy statements are listed in the order they are evaluated (lowest sequence number to highest).
12. The rule to apply to the packets matching the profile: either permit or deny
13. The name of the profile (ACL) of the packets to be forwarded using an IP policy.
14. The number of packets that have matched the profile since the IP policy was applied
(or since the ip-policy clear command was last used)
15. The method by which IP policies are applied with respect to dynamic or statically configured routes; possible values are Policy First, Policy Only, or Policy Last.
16. The list of next-hop gateways in effect for the policy statement.
17. The number of packets that have been forwarded to this next-hop gateway.
18. The state of the link the last time an attempt was made to forward a packet; possible values are up, dwn, or N/A.
19. Implicit deny rule that is always evaluated last, causing all packets that do not match one of the profiles to be forwarded normally (with dynamic routes).
Internet Appliance User Reference Manual 183
Chapter 11
Network Address
Translation
Configuration
Guide
Overview
Network Address Translation (NAT) allows an IP address used within one network to be translated into a different IP address used within another network. NAT is often used to map addresses used in a private, local intranet to one or more addresses used in the public, global Internet. NAT provides the following benefits:
• Limits the number of IP addresses used for private intranets that are required to be registered with the Internet Assigned Numbers Authority (IANA).
• Conserves the number of global IP addresses needed by a private intranet (for example, an entity can use a single IP address to communicate on the Internet).
• Maintains privacy of local networks, as internal IP addresses are hidden from public view.
With NAT, the local network is designated the inside network and the global Internet is designated the outside network. In addition, the IA supports Port Address Translation
(PAT) for either static or dynamic address bindings.
Internet Appliance User Reference Manual 185
Chapter 11: Network Address Translation Configuration Guide
The IA allows you to create the following NAT address bindings:
• Static, one-to-one binding of inside, local address or address pool to outside, global address or address pool. A static address binding does not expire until the command that defines the binding is negated. IP addresses defined for static bindings cannot be reassigned. For static address bindings, PAT allows TCP or UDP port numbers to be translated along with the IP addresses.
• Dynamic binding between an address from a pool of local addresses to an address from a pool of outside addresses. With dynamic address binding, you define local and global address pools from which the addresses bindings can be made. IP addresses defined for dynamic binding are reassigned whenever they become free. For dynamic address bindings, PAT allows port address translation if no addresses are available from the global address pool. PAT allows port address translation for each address in the global pool. The ports are dynamically assigned between the range of 1024 to 4999. Hence, you have about 4,000 ports per global IP address.
Dynamic bindings are removed automatically when the flow count goes to zero. At this point, the corresponding port (if PAT enabled) or the global IP address is freed and can be reused the next time. Although there are special cases like FTP where the flows are not installed for the control path, the binding will be removed only by the dynamic binding timeout interval.
Configuring NAT
The following are the steps in configuring NAT on the IA:
1.
Setting the NAT interfaces to be inside or outside .
2.
Setting the NAT rules (static or dynamic).
Setting Inside and Outside Interfaces
When NAT is enabled, address translation is only applied to those interfaces which are defined to NAT as inside or outside interfaces. NAT only translates packets that arrive on a defined inside or outside interface.
To specify an interface as inside (local) or outside (global), enter the following command in Configure mode:
Define an interface as inside or outside for NAT.
nat set interface <InterfaceName> inside|outside
186 Internet Appliance User Reference Manual
Chapter 11: Network Address Translation Configuration Guide
Setting NAT Rules
Static
You create NAT static bindings by entering the following command in Configure mode:
Enable NAT with static address binding.
nat create static protocol ip|tcp|udp local-ip <local-ip-add/address range> global-ip <global-ip-add/address range>
[local-port <tcp/udp local-port> | any]
[global-port <tcp/udp global-port> |any]
Dynamic
You create NAT dynamic bindings by entering the following command in Configure mode:
Enable NAT with dynamic address binding.
nat create dynamic local-acl-pool
[ enable-ip-overload]
<localacl> global-pool <ip-addr/ip-addr-range/ipaddr-list> [matches-interface <interface> ]
For dynamic address bindings, you define the address pools with previously created
ACLs. You can also specify the enable-port-overload parameter to allow PAT.
Managing Dynamic Bindings
As mentioned previously, dynamic address bindings expire only after a period of non-use or when they are manually deleted. The default timeout for dynamic address bindings is
1440 minutes (24 hours). You can manually delete dynamic address bindings for a specific address pool or delete all dynamic address bindings.
To set the timeout for dynamic address bindings, enter the following command in
Configure mode:
Set timeout for dynamic address bindings.
nat set dynamic-binding-timeout <minutes>
| disable
To flush dynamic address bindings, enter the following command in Enable mode:
Flush dynamic address bindings.
nat flush-dynamic-binding all|poolspecified [local-acl-pool <local-acl> ]
[global-pool <ip-addr/address range> ]
Internet Appliance User Reference Manual 187
Chapter 11: Network Address Translation Configuration Guide
NAT and FTP
File Transfer Protocol (FTP) packets require special handling with NAT, because the FTP
PORT command packets contain IP address information within the data portion of the packet. It is therefore important for NAT to know which control port is used for FTP (the default is port 21) and the timeout for the FTP session (the default is 30 minutes). If FTP packets will arrive on a different port number, you need to specify that port to NAT.
To define FTP parameters to NAT, enter the following commands in Configure mode:
Specify the FTP control port.
Specify the FTP session timeout.
nat set ftp-control-port <port number> nat set ftp-session-timeout <minutes>
Monitoring NAT
To display NAT information, enter the following command in Enable mode:
Display NAT information.
nat show [translations all| <type> ]
[timeouts] [statistics]
188 Internet Appliance User Reference Manual
Chapter 11: Network Address Translation Configuration Guide
Configuration Examples
This section shows examples of NAT configurations.
Static Configuration
The example in Figure 24 configures a static address binding for inside address 10.1.1.2 to outside address 192.50.20.2:
Outbound: Translate source 10.1.1.2 to 192.50.20.2
Inbound: Translate destination 192.50.20.2 to 10.1.1.2
Router
IP network 10.1.1.0/24 et.2.1
et.2.2
Global Internet
10.1.1.2
interface 10-net
(10.1.1.1/24) interface 192-net
(192.50.20.1/24)
Figure 24. Static Configuration Example
The first step is to create the interfaces: interface create ip 10-net address-netmask 10.1.1.1/24 port et.2.1
interface create ip 192-net address-netmask 192.50.20.1/24 port et.2.2
Next, define the interfaces to be NAT inside or outside : nat set interface 10-net inside nat set interface 192-net outside
Then, define the NAT static rules: nat create static protocol ip local-ip 10.1.1.2 global-ip 192.50.20.2
Internet Appliance User Reference Manual 189
Chapter 11: Network Address Translation Configuration Guide
Using Static NAT
Static NAT can be used when the local and global IP addresses are to be bound in a fixed manner. These bindings never get removed nor time out until the static NAT command itself is negated. Static binding is recommended when you have a need for a permanent type of binding.
The other use of static NAT is when the out to in traffic is the first to initialize a connection, i.e., the first packet is coming from outside to inside. This could be the case when you have a server in the local network and clients located remotely. Dynamic NAT would not work for this case as bindings are always created when an in to out Internet connection occurs. A typical example is a web server inside the local network, which could be configured as follows: nat create static protocol tcp local-ip 10.1.1.2 global-ip 192.50.20.2 local-port 80 global-port 80
This server, 10.1.1.2, is advertised as 192.50.20.2 to the external network.
Dynamic Configuration
The example in Figure 25 configures a dynamic address binding for inside addresses
10.1.1.0/24 to outside address 192.50.20.0/24:
Outbound: Translate source pool 10.1.1.0/24 to global pool 192.50.20.0/24
10.1.1.4
IP network 10.1.1.0/24
10.1.1.3
10.1.1.2
Router et.2.1
et.2.2
interface 10-net
(10.1.1.1/24) interface 192-net
(192.50.20.1/24)
Global Internet
Figure 25. Dynamic Configuration Example
The first step is to create the interfaces: interface create ip 10-net address-netmask 10.1.1.1/24 port et.2.1
interface create ip 192-net address-netmask 192.50.20.1/24 port et.2.2
190 Internet Appliance User Reference Manual
Chapter 11: Network Address Translation Configuration Guide
Next, define the interfaces to be NAT inside or outside : nat set interface 10-net inside nat set interface 192-net outside
Then, define the NAT dynamic rules by first creating the source ACL pool and then configuring the dynamic bindings: acl lcl permit ip 10.1.1.0/24 nat create dynamic local-acl-pool lcl global-pool 192.50.20.0/24
Using Dynamic NAT
Dynamic NAT can be used when the local network (inside network) is going to initialize the connections. It creates a binding at run time when a packet is sent from a local network, as defined by the NAT dynamic local ACl pool. The network administrator does not have to worry about the way in which the bindings are created; the network administrator just sets the pools and the IA automatically chooses a free global IP from the global pool for the local IP address.
Dynamic bindings are removed when the flow count for that binding goes to zero or the timeout has been reached. The free global IP addresses are used again for the next packet.
A typical problem is that if there are more local IP addresses as compared to global IP addresses in the pools, then packets will be dropped if all the globals are used. A solution to this problem is to use PAT with NAT dynamic. This is only possible with TCP or UDP protocols.
Internet Appliance User Reference Manual 191
Chapter 11: Network Address Translation Configuration Guide
Dynamic NAT with IP Overload (PAT) Configuration
The example in Figure 26 configures a dynamic address binding for inside addresses
10.1.1.0/24 to outside address 192.50.20.0/24:
Outbound: Translate source pool 10.1.1.0/24 to global pool 192.50.20.1-192.50.20.3
10.1.1.4
IP network 10.1.1.0/24
10.1.1.3
10.1.1.2
Router et.2.1
et.2.2
interface 10-net
(10.1.1.1/24) interface 192-net
(192.50.20.1/24)
Global Internet
Figure 26. Dynamic NAT with IP Overload (PAT) Configuration Example
The first step is to create the interfaces: interface create ip 10-net address-netmask 10.1.1.1/24 port et.2.1
interface create ip 192-net address-netmask 192.50.20.1/24 port et.2.2
Next, define the interfaces to be NAT inside or outside : nat set interface 10-net inside nat set interface 192-net outside
Then, define the NAT dynamic rules by first creating the source ACL pool and then configuring the dynamic bindings: acl lcl permit ip 10.1.1.0/24 nat create dynamic local-acl-pool lcl global-pool 192.50.20.1-192.50.20.3
192 Internet Appliance User Reference Manual
Chapter 11: Network Address Translation Configuration Guide
Using Dynamic NAT with IP Overload
Dynamic NAT with IP overload can be used when the local network (inside network) will be initializing the connections using TCP or UDP protocols. It creates a binding at run time when the packet comes from a local network defined in the NAT dynamic local ACL pool. The difference between the dynamic NAT and dynamic NAT with PAT is that PAT uses port (Layer-4) information to do the translation. Hence, each global IP has about 4000 ports that can be translated. NAT on the IA uses the standard BSD range of ports from
1024-4999 which is fixed and cannot be configured by the user. The network administrator does not have to worry about the way in which the bindings are created; he/she just sets the pools and the IA automatically chooses a free global IP from the global pool for the local IP.
Dynamic bindings are removed when the flow count goes to zero or the timeout has been reached. The removal of bindings frees the port for that global and the port is available for reuse. When all the ports for that global are used, then ports are assigned from the next free global. If no more ports and globals are available, the packets will be dropped.
Dynamic NAT with Outside Interface Redundancy
The example in Figure 27 configures a dynamic address binding for inside addresses
10.1.1.0/24 to outside addresses 192.50.20.0/24 on interface 192-net and to outside addresses 201.50.20.0/24 on interface 201-net:
Outbound: Translate source pool 10.1.1.0/24 to global pool 192.50.20.0/24
Translate source pool 10.1.1.0/24 to global pool 201.50.20.0/24 interface 192-net
(192.50.20.0/24)
10.1.1.4
IP network 10.1.1.0/24
10.1.1.3
10.1.1.2
Router et.2.1
et.2.2
et.2.3
interface 10-net
(10.1.1.1/24) interface 201-net
(201.50.20.0/24)
Global Internet
Figure 27. Dynamic NAT with Outside Interface Redundancy Example
Internet Appliance User Reference Manual 193
Chapter 11: Network Address Translation Configuration Guide
The first step is to create the interfaces: interface create ip 10-net address-netmask 10.1.1.1/24 port et.2.1
interface create ip 192-net address-netmask 192.50.20.0/24 port et.2.2
interface create ip 201-net address-netmask 201.50.20.0/24 port et.2.3
Next, define the interfaces to be NAT inside or outside : nat set interface 10-net inside nat set interface 192-net outside nat set interface 201-net outside
Then, define the NAT dynamic rules by first creating the source ACL pool and then configuring the dynamic bindings: acl lcl permit ip 10.1.1.0/24 nat create dynamic local-acl-pool lcl global-pool 192.50.20.0/24 matchingif 192-net nat create dynamic local-acl-pool lcl global-pool 210.50.20.0/24 matchingif 201-net
Using Dynamic NAT with Matching Interface Redundancy
If you have redundant connections to the remote network via two different interfaces, you can use NAT for translating the local address to the different global pool specified for the two connections. This case is possible when you have two ISPs connected on two different interfaces to the Internet. Through a routing protocol, some routes will result in traffic going out of one interface and for others going out on the other interface. NAT will check which interface the packet is going out from before selecting a global pool. Hence, you can specify two different global pools with the same local ACL pool on two different interfaces.
194 Internet Appliance User Reference Manual
Chapter 12
Web Hosting
Configuration
Guide
Overview
Accessing information on Web sites for both work or personal purposes is becoming a normal practice for an increasing number of people. For many companies, fast and efficient Web access is important for both external customers who need to access the company Web sites, as well as for users on the corporate intranet who need to access
Internet Web sites.
The following features on the Internet Appliance (IA) provide ways to improve Web access for external and internal users:
• Load balancing allows incoming HTTP requests to a company’s Web site to be distributed across several physical servers. If one server should fail, other servers can pick up the workload.
• Web caching allows HTTP requests from internal users to Internet sites to be redirected to cached web objects on local servers. Not only is response time faster since requests can be handled locally, but overall WAN bandwidth usage is reduced.
Note: Load balancing and web caching can be performed using application software; however, the IA can perform these functions much faster as the redirection is handled by specialized hardware.
Internet Appliance User Reference Manual 195
Chapter 12: Web Hosting Configuration Guide
Load Balancing
You can use the load balancing feature on the IA to distribute session load across a group of servers. If you configure the IA to provide load balancing, client requests that go through the IA can be redirected to any one of several predefined hosts. With load balancing, clients access servers through a virtual IP. The IA transparently redirects the requests with no change required on the clients or servers; all configuration and redirection is done on the IA.
Configuring Load Balancing
The following are the steps in configuring load balancing on the IA:
1.
Create a logical group of load balancing servers and define a virtual IP for the group.
2.
Define the servers in the group.
3.
Specify optional operating parameters for the group of load balancing servers or for individual servers in the group.
Creating the Server Group
To use load balancing, you create a logical group of load balancing servers and define a virtual IP for the server that the clients will use to access the server pool.
To create the server group and define the virtual IP for the server, enter the following command in Configure mode:
Create group of load balancing servers.
Create a range of load balancing server groups.
load-balance create group-name <group name> virtual-ip <ipaddr> virtual-port
<port number> protocol tcp|udp persistence-level tcp|ssl|vpn|sticky load-balance create vip-range-name <range name> vip-range <range> virtual-port
<port number> protocol tcp|udp persistence-level tcp|ssl|vpn|sticky
196 Internet Appliance User Reference Manual
Chapter 12: Web Hosting Configuration Guide
Adding Servers to the Load Balancing Group
Once a logical server group is created, you specify the servers that can handle client requests. When the IA receives a client request directed to the virtual server address, it redirects the request to the actual server address and port. Server selection is done according to the specified policy.
To add servers to the server group, enter the following command in Configure mode:
Add load balancing servers to a specific server group.
Add range of load balancing servers to a range of server groups.
load-balance add host-to-group
<ipaddr/range> group-name <group name> port <port number> [ weight <weight> ] load-balance add host-to-vip-range <range> vip-range-name <range name> port <port number> [ weight <weight> ]
Optional Group or Server Operating Parameters
There are several commands you can specify that affect the operating parameters of individual servers or the entire group of load balancing servers. In many cases, there are default parameter values and you only need to specify a command if you wish to change the default operation. For example, you can specify the policy to be used for distributing the workload for a group of load balancing servers. By default, the IA assigns sessions to servers in a round-robin (sequential) manner.
Specifying Load Balancing Policy
The default policy for distributing workload among the load balancing servers is roundrobin, where the IA selects the server on a rotating basis without regard to the load on individual servers. Other policies can be chosen for the group, including least loaded, where the server with the fewest number of sessions bound to it is selected to service a new session. The weighted round robin policy is a variation of the round-robin policy, where each server takes on new sessions according to its assigned weight. If you choose the weighted round robin policy, you must assign a weight to each server that you add to the load balancing group.
To specify the load balancing policy, enter the following command in Configure mode:
Specify load balancing policy.
load-balance set policy-for-group <group name> policy <policy>
Note: These policies only affect groups created with the parameter protocol tcp ; groups created with the parameter protocol udp are load-balanced using a fixed IP-hash policy.
Internet Appliance User Reference Manual 197
Chapter 12: Web Hosting Configuration Guide
Specifying a Connection Threshold
By default, there is no limit on the number of sessions that a load balancing server can service. You can configure a maximum number of connections that each server in a group can service.
To specify the connection threshold for servers in the group, enter the following command in Configure mode:
Specify maximum number of connections for all servers in the group.
load-balance set group-conn-threshold
<group name> limit <maximum connections>
Note: This limits the number of connections for each server in the group, not the total number of connections for the group.
Verifying Servers and Applications
The IA automatically performs the following types of verification for the attached loadbalancing servers:
• Verifies the state of the server by sending a ping to the server at 5-second intervals. If the IA does not receive a reply from a server after 4 ping requests, the server is considered to be down .
• Checks that an application session on the server can be established by doing a simple
TCP handshake with the application on the configured physical port of the server at
15-second intervals. If the IA does not receive a reply from the application after 4 tries, the application is considered to be down .
You can change the intervals at which pings or handshakes are attempted and the number of times that the IA retries the ping or handshake before considering the server or application to be down . You can change these parameters for al servers in a load-balancing group or for specific servers.
You can change the ping intervals and the number of retries by entering the following
Configure-mode commands:
Set ping interval for all servers in specified group.
Set ping interval for specific server.
Set number of ping retries for all servers in specified group.
Set number of ping retries for specific server.
load-balance set group-options <group name> ping-int <seconds> load-balance set server-options <ipaddr> ping-int <seconds> port <port number> load-balance set group-options <group name> ping-tries <number> load-balance set server-options <ipaddr> ping-tries <number> port <port number>
198 Internet Appliance User Reference Manual
Chapter 12: Web Hosting Configuration Guide
You can change the handshake intervals and the number of retries by entering the following Configure-mode commands:
Set handshake interval for all servers in specified group.
Set handshake interval for specific server.
Set number of handshake retries for all servers in specified group.
Set number of verification retries for specified server.
load-balance set group-options <group name> app-int <seconds> load-balance set server-options <group name> app-int <seconds> port <port number> load-balance set group-options <group name> app-tries <number> load-balance set server-options <group name> app-tries <number> port <port number>
Verifying Extended Content
You can also have the IA verify the content of an application on one or more loadbalancing servers For this type of verification, you specify the following:
• A string that the IA sends to a single server or to the group of load-balancing servers.
The string can be a simple HTTP command to get a specific HTML page. Or, a string can be a command to execute a user-defined CGI script that tests the operation of the application.
• The reply that the application on each server sends back that the IA will use to validate the content. In the case where a specific HTML page is retrieved, the reply can be a string that appears on the page, such as “OK.” If a CGI scrip is executed on the server, it should return a specific response (for example, “OK”) that the IA can verify.
Note that you can specify this type of verification for a group of load-balancing servers or for a specific server.
Internet Appliance User Reference Manual 199
Chapter 12: Web Hosting Configuration Guide
Application verification, whether a simple TCP handshake or a user-defined actionresponse check, involves opening and closing a connection to a load-balancing server.
Some applications require specific commands for proper closure of the connection. For example, a connection to an SMTP server application should be closed with the quit command. You can configure the IA to send a specific string to close a connection on a server.
Specify application verification for all servers in specified group.
Set verification interval for all servers in specified group.
Set number of verification retries for all servers in specified group.
load-balance set group-options <group name> acv-command <command string> acv-reply <reply string> read-index
<reply string> acv-quit <quit string> load-balance set group-options <group name> app-int <seconds> load-balance set group-options <group name> app-tries <number>
You can verify an application by entering the following Configure-mode commands:
Specify application verification for all servers in specified group.
Set application verification for specified server.
load-balance set server-options <group name> acv-command <command string> acv-reply <reply string> read-till-index
<reply string> [ check-port <port number> ][ acv-quit <quit string> ] load-balance set server-options <ipaddr> port <port number> acv-command <command string> acv-reply <reply string> read-tillindex <reply string> [ check-port <port number> ][ acv-quit <quit string> ]
Setting Server Status
It may become necessary at times to prevent new sessions from being directed to one or more load balancing servers. For example, if you need to perform maintenance tasks on a server system, you might want new sessions to temporarily not be directed to that server.
Setting the status of a server to down prevents new sessions from being directed to that server. The down status does not affect any current sessions on the server. When the server is again ready to accept new sessions, you can set the server status to up .
To set the status of a load balancing server, enter the following command in Enable mode:
Set status of load balancing server.
load-balance set server-status server-ip
<ipaddr range> server-port <port number> group-name <group name> status up|down
200 Internet Appliance User Reference Manual
Chapter 12: Web Hosting Configuration Guide
Load Balancing and FTP
File Transfer Protocol (FTP) packets require special handling with load balancing, because the FTP PORT command packets contain IP address information within the data portion of the packet. If the FTP control port used is not port 21, it is important for the IA to know the port number that is used for FTP.
To define an FTP control port (other than port 21) to the load balancing function, enter the following command in Configure mode:
Specify the FTP control port.
load-balance set ftp-control-port
<port number>
Allowing Access to Load Balancing Servers
Load balancing causes both source and destination addresses to be translated on the IA. It may be undesirable in some cases for a source address to be translated; for example, when data is to be updated on an individual server. Specified hosts can be allowed to directly access servers in the load balancing group without address translation. Note, however, that such hosts cannot use the virtual IP address and port number to access the load balancing group of servers.
To allow specified hosts to access the load balancing servers without address translation, enter the following command in Configure mode:
Specify the hosts that can access servers without address translation.
load-balance allow access-to-servers client-ip <ipaddr/range> group-name
<group name>
Setting Timeouts for Load Balancing Mappings
A mapping between a host (source) and a load-balancing server (destination) times out after a certain period. You can specify the timeout for source-destination load balancing mappings.
To specify the timeout for load balancing mappings, enter the following command in
Configure mode:
Specify the timeout for sourcedestination mappings.
load-balance set mappings-age-timer
<timer>
Internet Appliance User Reference Manual 201
Chapter 12: Web Hosting Configuration Guide
Specifying the VPN Port Number
You can specify the port number to be used for secure key transfer in Virtual Private
Networks (VPN). The default port number for this usage is 500.
To specify a VPN port number, enter the following command in Configure mode:
Specify the port number for secure key transfer in VPNs.
load-balance set vpn-dest-port
<port number>
Displaying Load Balancing Information
To display load balancing information, enter the following commands in Enable mode:
Show the groups of load balancing servers.
Show source-destination bindings.
Show load balancing statistics.
load-balance show virtual-hosts [groupname <group name> ][virtual-ip
<ipaddr> ][virtual-port <port number> ] load-balance show source-mappings
[client-ip <ipaddr range> ][virtual-ip
<ipaddr> ][virtual-port <port number> ][destination-host-ip <ipaddr> ] load-balance show statistics [group-name
<group name> ][virtual-ip
<ipaddr> ][virtual-port <port number> ] load-balance show hash-stats Show load balance hash table statistics.
Show load balance options for verifying the application.
load-balance show acv-options [group-name
<group name> ][destination-host-ip
<virtual ipaddr> ][destination-host-port
<virtual port number> ]
202 Internet Appliance User Reference Manual
Chapter 12: Web Hosting Configuration Guide
Configuration Examples
This section shows examples of load balancing configurations.
Web Hosting with One Virtual Group and Multiple Destination Servers
In Figure 28 , a company Web site is established with a URL of www.ctron.com. The system administrator configures the networks so that the IA forwards Web requests among four separate servers, as shown below.
10.1.1.1
10.1.1.2
10.1.1.3
www.ctron.com
10.1.1.4
Web requests forwarded to one of the servers
Router
Internet
Web requests to www.ctron.com
Virtual IP Address:
207.135.89.16
Figure 28. Web Hosting with One Virtual Group and Multiple Destination Servers
Domain
Name Virtual IP TCP Port www.ctron.com 207.135.89.16
80
Real Server IP TCP Port
10.1.1.1
10.1.1.2
10.1.1.3
10.1.1.4
80
80
80
80
The network shown above can be created with the following load-balance commands: load-balance create group-name ctron-www virtual-ip 207.135.89.16 virtual-port 80 protocol tcp load-balance add host-to-group 10.1.1.1-10.1.1.4 group-name ctron-www port 80
Internet Appliance User Reference Manual 203
Chapter 12: Web Hosting Configuration Guide
The following is an example of how to configure a simple verification check where the IA will issue an HTTP command to retrieve an HTML page and check for the string “OK”: load-balance set group-options ctron-www acv-command “GET /test.html” acv-reply
“OK” read-till-index 25
The read-till-index option is not necessary if the file test.html contains “OK” as the first two characters. The read-till-index option is helpful if the exact index of the acv-reply string in the file is not known to the user. In the above example, the IA will search from the beginning of the file up to the twenty-fifth character for the start of the string “OK.”
Web Hosting with Multiple Virtual Groups and Multiple Destination Servers
In Figure 29 , three different servers are used to provide different services for a site.
10.1.1.1
10.1.1.2
ftp.quick.com
www.quick.com
10.1.1.3
smtp.quick.com
Web requests forwarded to the server
Router
Internet
User Queries: www.quick.com
ftp.quick.com
smtp.quick.com
Figure 29. Web Hosting with Multiple Virtual Groups and
Multiple Destination Servers
Domain Name www.quick.com
ftp.quick.com
smtp.quick.com
Virtual IP TCP Port
207.135.89.16
80
207.135.89.16
21
207.135.89.16
25
Real Server IP TCP Port
10.1.1.1
10.1.1.2
10.1.1.3
80
21
25
204 Internet Appliance User Reference Manual
Chapter 12: Web Hosting Configuration Guide
The network shown above can be created with the following load-balance commands: load-balance create group-name quick-www virtual-ip 207.135.89.16 virtual-port 80 protocol tcp load-balance create group-name quick-ftp virtual-ip 207.135.89.16 virtual-port 21 protocol tcp load-balance create group-name quick-smtp virtual-ip 207.135.89.16 virtual-port
25 protocol tcp load-balance add host-to-group 10.1.1.1 group-name quick-www port 80 load-balance add host-to-group 10.1.1.2 group-name quick-ftp port 21 load-balance add host-to-group 10.1.1.3 group-name quick-smtp port 25
If no application verification options are specified, the IA will do a simple TCP handshake to check that the application is up . Some applications require specific commands for proper closure of the connection. The following command shows an example of how to send a specific string to close a connection on a server: load-balance set group-options quick-smtp acv-quit “quit”
Virtual IP Address Ranges
ISPs who provide Web hosting services for their clients require a large number of virtual
IP addresses (VIPs). The load-balance create vip-range-name and load-balance add hostto-vip-range commands were created specifically for this. An ISP can create a range of
VIPs for up to an entire class C network with the load-balance create vip-range-name command. Once the vip-range is in place, the ISP can then create the corresponding secondary addresses on their destination servers. Once these addresses have been created, the ISP can add these servers to the vip-range with the load-balance add host-to-viprange command. These two commands combined help ISPs take advantage of Web servers like Apache, which serve different Web pages based on the destination address in the http request. Figure 30 illustrates this:
S1
10.1.1.16 www.computers.com
10.1.1.17 www.dvd.com
10.1.1.18 www.vcr.com
...
10.1.1.50 www.toys.com
S2
10.1.2.16 www.computers.com
10.1.2.17 www.dvd.com
10.1.2.18 www.vcr.com
...
10.1.2.50 www.toys.com
Router Internet
Web requests:
207.135.89.16 www.computers.com
207.135.89.17 www.dvd.com
207.135.89.18 www.vcr.com
...
207.135.89.50 www.toys.com
Figure 30. Virtual IP Address Ranges
Internet Appliance User Reference Manual 205
Chapter 12: Web Hosting Configuration Guide
Group Name www.computers.com
www.dvd.com
www.vcr.com
www.toys.com
Virtual IP
207.135.89.16
207.135.89.17
207.135.89.18
207.135.89.50
TCP Port
80
80
80
80
Destination
Server IP
S1: 10.1.1.16
S2: 10.1.2.16
S1: 10.1.1.17
S2: 10.1.2.17
S1: 10.1.1.18
S2: 10.1.2.18
S1: 10.1.1.50
S2: 10.1.2.50
TCP Port
80
80
80
80
The network shown in the previous example can be created with the following loadbalance commands: load-balance create vip-range-name mywwwrange 207.135.89.16-207.135.89.50 virtual-port 80 protocol tcp load-balance add host-to-vip-range 10.1.1.16-10.1.1.50 vip-range-name mywwwrange port 80 load-balance add host-to-vip-range 10.1.2.16-10.1.2.50 vip-range-name mywwwrange port 80
Web Caching
Web caching provides a way to store frequently accessed Web objects on a cache of local servers. Each HTTP request is transparently redirected by the IA to a configured cache server. When a user first accesses a Web object, that object is stored on a cache server. Each subsequent request for the object uses this cached object. Web caching allows multiple users to access Web objects stored on local servers with a much faster response time than accessing the same objects over a WAN connection. This can also result in substantial cost savings by reducing the WAN bandwidth usage.
Note: The IA itself does not act as cache for Web objects. It redirects HTTP requests to local servers on which the Web objects are cached. One or more local servers are needed to work as cache servers with the IA’s web caching function.
206 Internet Appliance User Reference Manual
Chapter 12: Web Hosting Configuration Guide
Configuring Web Caching
The following are the steps in configuring web caching on the IA:
1.
Create the cache group (a list of cache servers) to cache Web objects.
2.
Specify the hosts whose HTTP requests will be redirected to the cache servers. This step is optional; if you do not explicitly define these hosts, then all HTTP requests are redirected.
3.
Apply the caching policy to an outbound interface to redirect HTTP traffic on that interface to the cache servers.
Creating the Cache Group
You can specify either a range of contiguous IP addresses or a list of up to four IP addresses to define the servers when the cache group is created. If you specify multiple servers, load balancing is based on the destination address of the request. If any cache server fails, traffic is redirected to the other active servers.
To create the cache group, enter the following command in Configure mode:
Create the cache group.
web-cache <cache name> create server-list
<server list name> range <ipaddr range> |list
<ipaddr list>
Note: If a range of IP addresses is specified, the range must be contiguous, with a maximum of 256 addresses
Specifying the Client(s) for the Cache Group (Optional)
You can explicitly specify the hosts whose HTTP requests are or are not redirected to the cache servers. If you do not explicitly specify these hosts, then all HTTP requests are redirected to the cache servers.
To specify the clients or non-clients for the cache group, enter the following commands in
Configure mode:
Define hosts whose requests are redirected to cache servers.
Define hosts whose requests are not redirected to cache servers.
web-cache <cache name> permit hosts range
<ipaddr range> |list <ipaddr list>| acl
<acl name> web-cache <cache name> deny hosts range
<ipaddr range> |list <ipaddr list>| acl
<acl name>
Internet Appliance User Reference Manual 207
Chapter 12: Web Hosting Configuration Guide
Redirecting HTTP Traffic on an Interface
To start the redirection of HTTP requests to the cache servers, you need to apply a caching policy to a specific outbound interface. This interface is typically an interface that connects to the Internet.
Note: By default, the IA redirects HTTP requests on port 80. Secure HTTP (https) requests do not run on port 80, therefore these types of requests are not redirected by the IA.
To redirect outbound HTTP traffic to the cache servers, enter the following command in
Configure mode:
Apply caching policy to outbound interface.
web-cache <cache name> apply interface
<interface name>
Configuration Example
In Figure 31 , a cache group of seven local servers is configured to store Web objects for users in the local network:
Cache1 s2 Servers: 186.89.10.51
186.89.10.55
Router ip1
Global Internet s1 Servers: 176.89.10.50
176.89.10.51
176.89.10.52
176.89.10.53
176.89.10.54
Users
Figure 31. Web Caching Configuration Example
208 Internet Appliance User Reference Manual
Chapter 12: Web Hosting Configuration Guide
The following commands configure the cache group cache1 that contains the servers shown in the figure above and applies the caching policy to the interface ip1 : ia(config)# web-cache cache1 create server-list s1 range “176.89.10.50
176.89.10.54” ia(config)# web-cache cache1 create server-list s2 list “186.89.10.51
186.89.10.55” ia(config)# web-cache cache1 apply interface ip1
Note that in this example, HTTP requests from all hosts in the network are redirected as there are no web-cache permit or web-cache deny commands.
Other Configurations
This section discusses other commands that may be useful in configuring web caching in your network.
Bypassing Cache Servers
Some Web sites require source IP address authentication for user access, therefore HTTP requests for these sites cannot be redirected to the cache servers. To specify the sites for which HTTP requests are not redirected to the cache servers, enter the following command in Configure mode:
Define destination sites to which
HTTP requests are sent directly.
web-cache <cache name> create bypass-list range <ipaddr range> | list <ipaddr list> | acl
<acl name>
Proxy Server Redundancy
Some networks use proxy servers that receive HTTP requests on a non-standard port number (i.e., not port 80). When the proxy server is available, all HTTP requests are handled by the proxy server. The IA can provide proxy server redundancy by transparently redirecting HTTP connections to the cache servers should the proxy server fail. To achieve this, the IA must be configured to redirect HTTP requests on the (nonstandard) HTTP port used by the proxy server.
To redirect HTTP requests to a non-standard HTTP port number, enter the following command in Configure mode:
Specify non-standard HTTP port.
web-cache <cache name> set http-port <port number>
Internet Appliance User Reference Manual 209
Distributing Frequently-Accessed Sites Across Cache Servers
The IA uses the destination IP address of the HTTP request to determine which cache server to send the request. However, if there is a Web site that is being accessed very frequently, the cache server serving requests for this destination address may become overloaded with user requests. You can specify that certain destination addresses be distributed across the cache servers in a round-robin manner.
To distribute a specified destination address across cache servers, enter the following command in Configure mode:
Distribute destination address across cache servers.
web-cache <cache name> set round-robin range <ipaddr range> |list <ipaddr list>
Monitoring Web Caching
To display web-caching information, enter the following commands in Enable mode:
Show information for all caching policies and all server lists.
web-cache show all
Show caching policy information.
web-cache show cache-name <cache name> |all
Show cache server information.
web-cache show servers cache
<cache name> |all
Chapter 13
Access Control List
Configuration
Guide
This chapter explains how to configure and use Access Control Lists (ACLs) on the IA.
ACLs are lists of selection criteria for specific types of packets. When used in conjunction with certain IA functions, ACLs allow you to restrict Layer-3/4 traffic going through the router.
This chapter contains the following sections:
• “ACL Basics” on page 212 explains how ACLs are defined and how the IA evaluates them.
• “Creating and Modifying ACLs” on page 216 describes how to edit ACLs, either remotely or by using the IA’s built-in ACL Editor function.
• “Using ACLs” on page 218 describes the different kinds of ACLs: Interface ACLs,
Service ACLs, and Profile ACLs, and gives examples of their usage.
• “Enabling ACL Logging” on page 225 explains how to log information about packets that are permitted or denied because of an ACL.
• “Monitoring ACLs” on page 225 lists the commands you can use to display information about ACLs active on the IA.
Internet Appliance User Reference Manual 211
Chapter 13: Access Control List Configuration Guide
ACL Basics
An ACL consists of one or more rules describing a particular type of IP traffic. ACLs can be simple, consisting of only one rule, or complicated with many rules. Each rule tells the
IA to either permit or deny packets that match selection criteria specified in the rule.
Each ACL is identified by a name. The name can be a meaningful string, such as
“denyftp” or “noweb,” or it can be a number such as 100 or 101 .
For example, the following ACL has a rule that permits all IP packets from subnet
10.2.0.0/16 to go through the IA: acl 101 permit ip 10.2.0.0/16
Defining Selection Criteria in ACL Rules
Selection criteria in the rule describe characteristics about a packet. In the example above, the selection criteria are IP packets from 10.2.0.0/16.
The selection criteria you can specify in an ACL rule depends on the type of ACL you are creating. For IP, TCP, and UDP ACLs, the following selection criteria can be specified:
• Source IP address
• Destination IP address
• Source port number
• Destination port number
• Type of Service (TOS)
These selection criteria are specified as fields of an ACL rule. The following syntax description shows the fields of an IP ACL rule: acl <name> permit|deny ip <SrcAddr/Mask> <DstAddr/Mask> <SrcPort> <DstPort> <tos>
Note: The acl permit|deny ip command restricts traffic for all IP-based protocols, such as TCP, UDP, and ICMP. Variants of the a cl permit|deny ip command exist that allow you to restrict traffic for a specific IP-based protocol; for example, the acl permit|deny tcp command lets you restrict only TCP traffic. These variants have the same syntax and fields as the acl permit|deny ip command.
Each field in an ACL rule is position sensitive. For example, for a rule for TCP traffic, the source address must be followed by the destination address, followed by the source socket and the destination socket, and so on.
212 Internet Appliance User Reference Manual
Chapter 13: Access Control List Configuration Guide
Not all fields of an ACL rule need to be specified. If a particular field is not specified, it is treated as a wildcard or don't-care condition. However, if a field is specified, that particular field will be matched against the packet. Each protocol can have a number of different fields to match. For example, a rule for TCP can use socket port numbers.
Since each field is position sensitive, it may be necessary to skip some fields in order to specify a value for another field. To skip a field, use the keyword any . For example, the following ACL rule denies SMTP traffic between any two hosts: acl nosmtp deny tcp any any smtp smtp
Note that in the above example, the < tos > (Type of Service) field is not specified and is treated as a wildcard. The any keyword is needed only to skip a wildcard field in order to explicitly specify another field that is further down in the rule. If there are no other fields to specify, the any keyword is not necessary. For example, the following ACL permits all
IP traffic to go through: acl yesip permit ip
How ACL Rules are Evaluated
For an ACL with multiple rules, the ordering of the rules is important. When the IA checks a packet against an ACL, it goes through each rule in the ACL sequentially. If a packet matches a rule, it is forwarded or dropped based on the permit or deny keyword in the rule. All subsequent rules are ignored. That is, a first-match algorithm is used. There is no hidden or implied ordering of ACL rules, nor is there precedence attached to each field. The IA simply goes down the list, one rule at a time, until there is a match.
Consequently, rules that are more specific (that is, with more selection criteria) should always be listed ahead of rules that are less specific. For example, the following ACL permits all TCP traffic except those from subnet 10.2.0.0/16: acl 101 deny tcp 10.2.0.0/16 any any any acl 101 permit tcp any any any any
When a TCP packet comes from subnet 10.2.0.0/16, it finds a match with the first rule.
This causes the packet to be dropped. A TCP packet coming from other subnets does not match the first rule. Instead, it matches the second rule, which allows the packet to go through.
Internet Appliance User Reference Manual 213
Chapter 13: Access Control List Configuration Guide
If you were to reverse the order of the two rules: acl 101 permit tcp any any any any acl 101 deny tcp 10.2.0.0/16 any any any all TCP packets would be allowed to go through, including traffic from subnet 10.2.0.0/16.
This is because TCP traffic coming from 10.2.0.0/16 would match the first rule and be allowed to go through. The second rule would not be looked at since the first match determines the action taken on the packet.
Implicit Deny Rule
At the end of each ACL, the system automatically appends an implicit deny rule . This implicit deny rule denies all traffic. For a packet that doesn’t match any of the userspecified rules, the implicit deny rule acts as a catch-all rule. All packets match this rule.
This is done for security reasons. If an ACL is misconfigured, and a packet that should be allowed to go through is blocked because of the implicit deny rule, the worst that could happen is inconvenience. On the other hand, if a packet that should not be allowed to go through is instead sent through, there is now a security breach. Thus, the implicit deny rule serves as a line of defense against accidental misconfiguration of ACLs.
To illustrate how the implicit deny rule is used, consider the following ACL: acl 101 permit ip 1.2.3.4/24 acl 101 permit ip 4.3.2.1/24 any nntp
With the implicit deny rule, this ACL actually has three rules: acl 101 permit ip 1.2.3.4/24 any any any acl 101 permit ip 4.3.2.1/24 any nntp any acl 101 deny any any any any any
If a packet comes in and doesn't match the first two rules, the packet is dropped. This is because the third rule (the implicit deny rule) matches all packets.
Although the implicit deny rule may seem obvious in the above example, this is not always the case. For example, consider the following ACL rule: acl 102 deny ip 10.1.20.0/24 any any any
214 Internet Appliance User Reference Manual
Chapter 13: Access Control List Configuration Guide
If a packet comes in from a network other than 10.1.20.0/24, you might expect the packet to go through because it doesn’t match the first rule. However, that is not the case because of the implicit deny rule. With the implicit deny rule attached, the rule looks like this: acl 102 deny ip 10.1.20.0/24 any any any acl 102 deny any any any any any
A packet coming from 10.1.20.0/24 would not match the first rule, but would match the implicit deny rule. As a result, no packets would be allowed to go through. The first rule is simply a subset of the second rule. To allow packets from subnets other than 10.1.20.0/24 to go through, you would have to explicitly define a rule to permit other packets to go through.
To correct the above example and let packets from other subnets enter the IA, you must add a new rule to permit packets to go through: acl 101 deny ip 10.1.20.0/24 any any any acl 101 permit ip acl 101 deny any any any any any
The second rule forwards all packets that are not denied by the first rule.
Because of the implicit deny rule, an ACL works similarly to a firewall that is elected to deny all traffic. You create ACL rules that punch holes into the firewall to permit specific types of traffic; for example, traffic from a specific subnet or traffic from a specific application.
Allowing External Responses to Established TCP Connections
Typically organizations that are connected to the outside world implement ACLs to deny access to the internal network. If an internal user wishes to connect to the outside world, the request is sent; however any incoming replies may be denied because ACLs prevent them from going through. To allow external responses to internally generated requests, you would have to create an ACL to allow responses from each specific outside host. If the number of outside hosts that internal users need to access is large or changes frequently, this can be difficult to maintain.
To address this problem, the IA can be configured to accept outside TCP responses into the internal network, provided that the TCP connection was initiated internally.
Otherwise, it will be rejected. To do this, enter the following command in Configure
Mode:
Allow TCP responses from external hosts, provided the connection was established internally.
acl <name> permit tcp established
Internet Appliance User Reference Manual 215
Chapter 13: Access Control List Configuration Guide
The following ACL illustrates this feature: acl 101 permit tcp established acl 101 apply interface int1 input
Any incoming TCP packet on interface int1 is examined, and if the packet is in response to an internal request, it is permitted; otherwise, it is rejected. Note that the ACL contains no restriction for outgoing packets on interface int1, since internal hosts are allowed to access the outside world.
Creating and Modifying ACLs
The IA provides two mechanisms for creating and modifying ACLs:
• Editing ACLs on a remote host and uploading them to the IA using TFTP or RCP
• Using the IA’s ACL Editor
The following sections describe these methods.
Editing ACLs Offline
You can create and edit ACLs on a remote host and then upload them to the IA with TFTP or RCP. With this method, you use a text editor on a remote host to edit, delete, replace, or reorder ACL rules in a file. Once the changes are made, you can then upload the ACLs to the IA using TFTP or RCP and make them take effect on the running system. The following example describes how you can use TFTP to help maintain ACLs on the IA.
Suppose the following ACL commands are stored in a file on some hosts: no acl * acl 101 deny tcp 10.11.0.0/16 10.12.0.0/16 acl 101 permit tcp 10.11.0.0 any acl 101 apply interface int12 input
The first command, no acl * , negates all commands that start with the keyword acl . This tells the IA to remove the application and the definition of any ACL. You can be more selective if you want to remove only ACL commands related to, for instance, ACL 101 by entering, no acl 101 * . The negation of all related ACL commands is important because it removes any potential confusion caused by the addition of new ACL rules to existing rules. Basically, the no acl command cleans up the system for the new ACL rules.
Once the negation command is executed, the second and the third commands proceed to redefine ACL 101. The final command applies the ACL to interface int12.
216 Internet Appliance User Reference Manual
Chapter 13: Access Control List Configuration Guide
If the changes are accessible from a TFTP server, you can upload and make the changes take effect by issuing commands like the following: ia# copy tftp://10.1.1.12/config/acl.changes to scratchpad ia# copy scratchpad to active
The first copy command uploads the file acl.changes from a TFTP server and puts the commands into the temporary configuration area, the scratchpad. The administrator can re-examine the changes if necessary before committing the changes to the running system.
The second copy command makes the changes take effect by copying from the scratchpad to the active running system.
If you need to re-order or modify the ACL rules, you must make the changes in the acl.changes file on the remote host, upload the changes, and make them effective again.
Maintaining ACLs Using the ACL Editor
In addition to the traditional method of maintaining ACLs using TFTP or RCP, the IA provides a simpler and more user-friendly mechanism to maintain ACLs: the ACL Editor.
The ACL Editor can only be accessed within Configure mode using the acl-edit command. You edit an ACL by specifying its name together with the acl-edit command. For example, to edit ACL 101, you issue the command acl-edit 101 . The only restriction is that when you edit a particular ACL, you cannot add rules for a different
ACL. You can only add new rules for the ACL that you are currently editing. When the editing session is over, that is, when you are done making changes to the ACL, you can save the changes and make them take effect immediately. Within the ACL editor, you can add new rules ( add command), delete existing rules ( delete command) and re-order the rules ( move command). To save the changes, use the save command or simply exit the
ACL Editor.
If you edit and save changes to an ACL that is currently being used or applied to an interface, the changes will take effect immediately. There is no need to remove the ACL from the interface before making changes and reapply it after changes are made. The process is automatic.
Internet Appliance User Reference Manual 217
Chapter 13: Access Control List Configuration Guide
Using ACLs
It is important to understand that an ACL is simply a definition of packet characteristics specified in a set of rules. An ACL must be enabled in one of the following ways:
• Applying an ACL to an interface, which permits or denies traffic to or from the IA.
ACLs used in this way are known as Interface ACLs .
• Applying an ACL to a service, which permits or denies access to system services provided by the IA. ACLs used in this way are known as Service ACLs .
• Associating an ACL with ip-policy , nat , port mirroring , rate-limit , or web-cache commands, which specifies the criteria that packets, addresses, or flows must meet in order to be relevant to these IA features. ACLs used in this way are known as Profile
ACLs .
These uses of ACLs are described in the following sections.
Applying ACLs to Interfaces
An ACL can be applied to an interface to examine either inbound or outbound traffic.
Inbound traffic is traffic coming into the IA. Outbound traffic is traffic going out of the IA.
For each interface, only one ACL can be applied for the same protocol in the same direction. For example, you cannot apply two or more IP ACLs to the same interface in the inbound direction. You can apply two ACLs to the same interface if one is for inbound traffic and one is for outbound traffic, but not in the same direction. However, this restriction does not prevent you from specifying many rules in an ACL. You just have to put all of these rules into one ACL and apply it to an interface.
When a packet comes into the IA at an interface where an inbound ACL is applied, the IA compares the packet to the rules specified by that ACL. If it is permitted, the packet is allowed into the IA. If not, the packet is dropped. If that packet is to be forwarded to go out of another interface (that is, the packet is to be routed) then a second ACL check is possible. At the output interface, if an outbound ACL is applied, the packet will be compared to the rules specified in this outbound ACL. Consequently, it is possible for a packet to go through two separate checks, once at the inbound interface and once more at the outbound interface.
In general, you should try to apply ACLs at the inbound interfaces instead of the outbound interfaces. If a packet is to be denied, you want to drop the packet as early as possible, at the inbound interface. Otherwise, the IA will have to process the packet, determine where the packet should go only to find out that the packet should be dropped at the outbound interface. In some cases, however, it may not be simple or possible for the administrator to know ahead of time that a packet should be dropped at the inbound interface. Nonetheless, for performance reasons, whenever possible, you should create and apply an ACL to the inbound interface.
218 Internet Appliance User Reference Manual
Chapter 13: Access Control List Configuration Guide
To apply an ACL to an interface, enter the following command in Configure mode:
Apply ACL to an interface.
acl <name> apply interface <interface name> input|output [logging on|off|denyonly|permit-only][policy local|external]
Applying ACLs to Services
ACLs can also be created to permit or deny access to system services provided by the IA; for example, HTTP or Telnet servers. This type of ACL is known as a Service ACL. By definition, a Service ACL is for controlling inbound packets to a service on the router. For example, you can grant Telnet server access from a few specific hosts or deny Web server access from a particular subnet. It is true that you can do the same thing with ordinary
ACLs and apply them to all interfaces. However, the Service ACL is created specifically to control access to some of the services on the IA. As a result, only inbound traffic to the IA is checked. Destination address and port information is ignored; therefore if you are defining a Service ACL, you do not need to specify destination information.
Note: If a service does not have an ACL applied, that service is accessible to everyone.
To control access to a service, an ACL must be used.
To apply an ACL to a service, enter the following command in Configure mode:
Apply ACL to a service.
acl <name> apply service <service name>
[logging [on|off]]
Using ACLs as Profiles
You can use the acl command to define a profile . A profile specifies the criteria that addresses, flows, hosts, or packets must meet to be relevant to certain IA features. Once you have defined an ACL profile, you can use the profile with the configuration command for that feature. For example, the Network Address Translation (NAT) feature on the IA allows you to create address pools for dynamic bindings. You use ACL profiles to represent the appropriate pools of IP addresses.
Internet Appliance User Reference Manual 219
Chapter 13: Access Control List Configuration Guide
Table 3 lists the IA features that use ACL profiles:
Table 3. IA Features and ACL Profile Usage
IA Feature
IP policy
Dynamic NAT
Port mirroring
Rate limiting
Web caching
ACL Profile Usage
Specifies the packets that are subject to the IP routing policy.
Defines local address pools for dynamic bindings.
Defines traffic to be mirrored.
Specifies the incoming traffic flow to which rate limiting is applied.
Specifies which HTTP traffic should always (or never) be redirected to the cache servers.
Specifies characteristics of Web objects that should not be cached.
Note the following about using Profile ACLs:
• Only IP ACLs can be used as Profile ACLs. ACLs for non-IP protocols cannot be used as Profile ACLs.
• The permit / deny keywords, while required in the ACL rule definition, are disregarded in the configuration commands for the above-mentioned features. In other words, the configuration commands will act upon a specified Profile ACL whether or not the
Profile ACL rule contains the permit or deny keyword.
• Unlike with other kinds of ACLs, there is no implicit deny rule for Profile ACLs.
• Only certain ACL rule parameters are relevant for each configuration command. For example, the configuration command to create NAT address pools for dynamic bindings (the nat create dynamic command) only looks at the source IP address in the specified ACL rule. The destination IP address, ports, and TOS parameters, if specified, are ignored.
Specific usage of Profile ACLs is described in more detail in the following sections.
Using Profile ACLs with the IP Policy Facility
The IP policy facility uses a Profile ACL to define criteria that determines which packets should be forwarded according to an IP policy. Packets that meet the criteria defined in the
Profile ACL are forwarded according to the ip-policy command that references the Profile
ACL.
220 Internet Appliance User Reference Manual
Chapter 13: Access Control List Configuration Guide
For example, you can define an IP policy that causes all telnet packets travelling from source network 9.1.1.0/24 to destination network 15.1.1.0/24 to be forwarded to destination address 10.10.10.10. You use a Profile ACL to define the selection criteria (in this case, telnet packets travelling from source network 9.1.1.0/24 to destination network
15.1.1.0/24). Then you use an ip-policy command to specify what happens to packets that match the selection criteria (in this example, forward them to address 10.10.10.10). The following commands illustrate this example.
This command creates a Profile ACL called prof1 that uses as its selection criteria all telnet packets travelling from source network 9.1.1.0/24 to destination network 15.1.1.0/24: ia(config)# acl prof1 permit ip 9.1.1.0/24 15.1.1.0/24 any any telnet 0
This Profile ACL is then used in conjunction with the ip-policy command to cause packets matching prof1’s selection criteria (that is, telnet packets travelling from 9.1.1.0/24 to
15.1.1.0/24) to be forwarded to 10.10.10.10: ia(config)# ip-policy p5 permit profile prof1 next-hop-list 10.10.10.10
See Chapter 10, “IP Policy-Based Forwarding Configuration Guide,” for more information on using the ip-policy command.
Using Profile ACLs with the Traffic Rate Limiting Facility
Traffic rate limiting is a mechanism that allows you to control bandwidth usage of incoming traffic on a per-flow basis. A flow meeting certain criteria can have its packets re-prioritized or dropped if its bandwidth usage exceeds a specified limit.
For example, you can cause packets in flows from source address 1.2.2.2 to be dropped if their bandwidth usage exceeds 10 Mbps. You use a Profile ACL to define the selection criteria (in this case, flows from source address 1.2.2.2). Then you use a rate-limit command to specify what happens to packets that match the selection criteria (in this example, drop them if their bandwidth usage exceeds 10 Mbps). The following commands illustrate this example.
This command creates a Profile ACL called prof2 that uses as its selection criteria all packets originating from source address 1.2.2.2: ia(config)# acl prof2 permit ip 1.2.2.2
The following command creates a rate limit definition that causes flows matching Profile
ACL prof2’s selection criteria (that is, traffic from 1.2.2.2) to be restricted to 10 Mbps for each flow. If this rate limit is exceeded, the packets are dropped.
ia(config)# rate-limit client1 input acl prof2 rate-limit 10000000 exceed-action drop-packets
Internet Appliance User Reference Manual 221
Chapter 13: Access Control List Configuration Guide
When the rate limit definition is applied to an interface (with the rate-limit apply interface command), packets in flows originating from source address 1.2.2.2 are dropped if their bandwidth usage exceeds 10 Mbps.
See “Limiting Traffic Rate” on page 241 for more information on using the rate-limit command.
Using Profile ACLs with Dynamic NAT
Network Address Translation (NAT) allows you to map an IP address used within one network to a different IP address used within another network. NAT is often used to map addresses used in a private, local intranet to one or more addresses used in the public, global Internet.
The IA supports two kinds of NAT: static NAT and dynamic NAT . With dynamic NAT, an IP address within a range of local IP addresses is mapped to an IP address within a range of global IP addresses. For example, you can configure IP addresses on network 10.1.1.0/24 to use an IP address in the range of IP addresses in network 192.50.20.0/24. You can use a
Profile ACL to define the ranges of local IP addresses.
The following command creates a Profile ACL called local . The local profile specifies as its selection criteria the range of IP addresses in network 10.1.1.0/24.
ia(config)# acl local permit ip 10.1.1.0/24
Note: When a Profile ACL is defined for dynamic NAT, only the source IP address field in the acl statement is evaluated. All other fields in the acl statement are ignored.
Once you have defined a Profile ACL, you can then use the nat create dynamic command to bind the range of IP addresses defined in the local profile to a range in network
192.50.20.0/24.
ia(config)# nat create dynamic local-acl-pool local global-pool 192.50.20.10/24
See Chapter 11, “Network Address Translation Configuration Guide,” for more information on using dynamic NAT.
Using Profile ACLs with the Port Mirroring Facility
Port mirroring refers to the IA’s ability to copy traffic on one or more ports to a mirror port, where an external analyzer or probe can be attached. In addition to mirroring traffic on one or more ports, the IA can mirror traffic that matches selection criteria defined in a
Profile ACL.
222 Internet Appliance User Reference Manual
Chapter 13: Access Control List Configuration Guide
For example, you can mirror all IGMP traffic on the IA. You use a Profile ACL to define the selection criteria (in this example, all IGMP traffic). Then you use a port mirroring command to copy packets that match the selection criteria to a specified mirror port. The following commands illustrate this example.
This command creates a Profile ACL called prof3 that uses as its selection criteria all IGMP traffic on the IA: ia(config)# acl prof3 permit igmp
The following command causes packets matching Profile ACL prof3’s selection criteria
(that is, all IGMP traffic) to be copied to mirror port et.1.2.
ia(config)# port mirroring monitor-port et.1.2 target-profile prof3
See “Configuring the IA for Port Mirroring” on page 245 for more information on using the port mirroring command.
Using Profile ACLs with the Web Caching Facility
Web caching is the IA’s ability to direct HTTP requests for frequently accessed Web objects to local cache servers, rather than to the Internet. Since the HTTP requests are handled locally, response time is faster than if the Web objects were retrieved from the Internet.
You can use Profile ACLs with Web caching in two ways:
• Specifying which HTTP traffic should always (or never) be redirected to the cache servers
• Specifying characteristics of Web objects that should not be cached
Redirecting HTTP Traffic to Cache Servers
You can use a Profile ACL to specify which HTTP traffic should always (or never) be redirected to the cache servers. (By default, when Web caching is enabled, all HTTP traffic from all hosts is redirected to the cache servers unless you specify otherwise.)
For example, you can specify that packets with a source address of 10.10.10.10 and a destination address of 1.2.3.4 always are sent to the Internet and never to the cache servers. The following commands illustrate this example.
This command creates a Profile ACL called prof4 that uses as its selection criteria all packets with a source address of 10.10.10.10 and a destination address of 1.2.3.4: ia(config)# acl prof4 permit ip 10.10.10.10 1.2.3.4
Internet Appliance User Reference Manual 223
Chapter 13: Access Control List Configuration Guide
The following command creates a Web caching policy that prevents packets matching
Profile ACL prof4’s selection criteria (that is, packets with a source address of 10.10.10.10 and a destination address of 1.2.3.4) from being redirected to a cache server. Packets that match the profile’s selection criteria are sent to the Internet instead.
ia(config)# web-cache policy1 deny hosts profile prof4
When the Web caching policy is applied to an interface (with the web-cache apply interface command), HTTP traffic with a source address of 10.10.10.10 and a destination address of 1.2.3.4 goes to the Internet instead of to the cache servers.
Preventing Web Objects From Being Cached
You can also use a Profile ACL to prevent certain Web objects from being cached. For example, you can specify that information in packets originating from Internet site 1.2.3.4 and destined for local host 10.10.10.10 not be sent to the cache servers. The following commands illustrate this example.
This command creates a Profile ACL called prof5 that uses as its selection criteria all packets with a source address of 1.2.3.4 and a destination address of 10.10.10.10: ia(config)# acl prof5 permit ip 1.2.3.4 10.10.10.10
To have packets matching Profile ACL prof5’s selection criteria bypass the cache servers, use the following command: ia(config)# web-cache policy1 create bypass-list profile prof5
When the Web caching policy is applied to an interface, information in packets originating from source address 1.2.3.4 and destined for address 10.10.10.10 is not sent to the cache servers.
See “Web Caching” on page 206 for more information on using the web-cache command.
224 Internet Appliance User Reference Manual
Chapter 13: Access Control List Configuration Guide
Enabling ACL Logging
To see whether incoming packets are permitted or denied because of an ACL, you can enable ACL Logging when applying the ACL. When ACL Logging is turned on, the router prints out a message on the console about whether a packet is forwarded or dropped. If you have a Syslog server configured for the IA, the same information will also be sent to the Syslog server.
Before enabling ACL Logging, you should consider its impact on performance. With ACL
Logging enabled, the router prints out a message at the console before the packet is actually forwarded or dropped. Even if the console is connected to the router at a high baud rate, the delay caused by the console message is still significant. This can get worse if the console is connected at a low baud rate, for example, 1200 baud. Furthermore, if a
Syslog server is configured, then a Syslog packet must also be sent to the Syslog server, creating additional delay. Therefore, you should consider the potential performance impact before turning on ACL Logging.
Monitoring ACLs
The IA provides a display of ACL configurations active in the system.
To display ACL information, enter the following commands in Enable mode.
Show all ACLs.
Show a specific ACL.
Show an ACL on a specific interface.
Show ACLs on all IP interfaces.
Show static entry filters.
acl show all acl show aclname <name> | all acl show interface < name > acl show interface all-ip acl show service
Internet Appliance User Reference Manual 225
Chapter 14
Security
Configuration
Guide
Security Overview
The Internet Appliance (IA) provides security features that help control access to the IA.
Access to the IA can be controlled by:
• Enabling RADIUS
• Enabling TACACS
• Enabling TACACS Plus
• Password authentication
Internet Appliance User Reference Manual 227
Chapter 14: Security Configuration Guide
Configuring IA Access Security
This section describes the following methods of controlling access to the IA:
• RADIUS
• TACACS
• TACACS Plus
• Passwords
Configuring RADIUS
You can secure login or Enable mode access to the IA by enabling a Remote
Authentication Dial-In Service (RADIUS) client. A RADIUS server responds to the IA
RADIUS client to provide authentication.
You can configure up to five RADIUS server targets on the IA. A timeout is set to tell the
IA how long to wait for a response from RADIUS servers.
To configure RADIUS security, enter the following commands in Configure mode:
Specify a RADIUS server.
Set the RADIUS time to wait for a
RADIUS server reply.
Determine the IA action if no server responds.
Enable RADIUS.
Cause RADIUS authentication at user login or when user tries to access Enable mode.
Logs specified types of command to RADIUS server.
Logs to RADIUS server when shell is stopped or started on IA.
Logs to RADIUS server SNMP changes to startup or active configuration.
Logs specified type(s) of messages to RADIUS server.
radius set server <hostname or IP-addr> radius set timeout <number> radius set last-resort password|succeed radius enable radius authentication login|enable radius accounting command level < level > radius accounting shell start|stop|all radius accounting snmp active|startup radius accounting system fatal|error|warning|info
228 Internet Appliance User Reference Manual
Chapter 14: Security Configuration Guide
Monitoring RADIUS
You can monitor RADIUS configuration and statistics within the IA.
To monitor RADIUS, enter the following commands in Enable mode:
Show RADIUS server statistics.
Show all RADIUS parameters.
radius show stats radius show all
Configuring TACACS
In addition, Enable mode access to the IA can be made secure by enabling a Terminal
Access Controller Access Control System (TACACS) client. Without TACACS, TACACS
Plus, or RADIUS enabled, only local password authentication is performed on the IA. The
TACACS client provides user name and password authentication for Enable mode. A
TACACS server responds to the IA TACACS client to provide authentication.
You can configure up to five TACACS server targets on the IA. A timeout is set to tell the
IA how long to wait for a response from TACACS servers.
To configure TACACS security, enter the following commands in the Configure mode:
Specify a TACACS server.
Set the TACACS time to wait for a
TACACS server reply.
Determine IA action if no server responds.
Enable TACACS.
tacacs set server <hostname or IP-addr> tacacs set timeout <number> tacacs set last-resort password|succeed tacacs enable
Monitoring TACACS
You can monitor TACACS configuration and statistics within the IA.
To monitor TACACS, enter the following commands in Enable mode:
Show TACACS server statistics.
Show all TACACS parameters.
tacacs show stats tacacs show all
Internet Appliance User Reference Manual 229
Chapter 14: Security Configuration Guide
Configuring TACACS Plus
You can secure login or Enable mode access to the IA by enabling a TACACS Plus client. A
TACACS Plus server responds to the IA TACACS Plus client to provide authentication.
You can configure up to five TACACS Plus server targets on the IA. A timeout is set to tell the IA how long to wait for a response from TACACS Plus servers.
To configure TACACS Plus security, enter the following commands in Configure mode:
Specify a TACACS Plus server.
Set the TACACS Plus time to wait for a TACACS Plus server reply.
Determine the IA action if no server responds.
Enable TACACS Plus.
Cause TACACS Plus authentication at user login or when user tries to access Enable mode.
Cause TACACS Plus authentication at user login or when user tries to access Enable mode.
Logs specified types of command to TACACS Plus server.
Logs to TACACS Plus server when shell is stopped or started on IA.
Logs to TACACS Plus server
SNMP changes to startup or active configuration.
Logs specified type(s) of messages to TACACS Plus server.
tacacs-plus set server <hostname or IP-addr> tacacs-plus set timeout <number> tacacs-plus set last-resort password|succeed tacacs-plus enable tacacs-plus authentication login|enable tacacs-plus authentication login|enable tacacs-plus accounting command level
< level > tacacs-plus accounting shell start|stop|all tacacs-plus accounting snmp active|startup tacacs-plus accounting system fatal|error|warning|info
230 Internet Appliance User Reference Manual
Chapter 14: Security Configuration Guide
Monitoring TACACS Plus
You can monitor TACACS Plus configuration and statistics within the IA.
To monitor TACACS Plus, enter the following commands in Enable mode:
Show TACACS Plus server statistics.
Show all TACACS Plus parameters.
tacacs-plus show stats tacacs-plus show all
Configuring Passwords
The IA provides password authentication for accessing the User and Enable modes. If
TACACS is not enabled on the IA, only local password authentication is performed.
To configure IA passwords, enter the following commands in Configure mode:
Set User mode password.
Set Enable mode password.
system set password login <string> system set password enable <string>
Internet Appliance User Reference Manual 231
Chapter 15
QoS Configuration
Guide
QoS & Layer-2, -3, and -4 Flow Overview
The Internet Appliance (IA) allows network managers to identify traffic and set Quality of
Service (QoS) policies without compromising wire speed performance. The IA can guarantee bandwidth on an application by application basis, thus accommodating highpriority traffic even during peak periods of usage. QoS policies can be broad enough to encompass all the applications in the network, or relate specifically to a single host-to-host application flow.
The IA provides three different features to satisfy QoS requirements:
• Traffic prioritization allows network administrators to identify and segregate missioncritical network traffic into different priority queues from non-critical network traffic.
Once a packet has been identified, it can be assigned into any one of four priorities in order to ensure delivery. Priority can be allocated based on any combination of Layer-2,
Layer-3, or Layer-4 traffic.
• Type of Service (ToS) rewrite provides network administrators access to the ToS octet in an IP packet. The ToS octet is designed to provide feedback to the upper layer application. The administrator can mark packets using the ToS rewrite feature so that the application (a routing protocol, for example) can handle the packet based on a predefined mechanism.
• Traffic rate limiting provides network administrators with tools to manage bandwidth resources. The administrator can create an upper limit for a traffic profile, which is based on Layer-3 or -4 information. Traffic that exceeds the upper limit of the profile can either be dropped or re prioritized into another priority queue.
Internet Appliance User Reference Manual 233
Chapter 15: QoS Configuration Guide
Within the IA, QoS policies are used to classify Layer-2, -3, and -4 traffic into the following priorities:
• Control
• High
• Medium
• Low
By assigning priorities to network traffic, you can ensure that critical traffic will reach its destination even if the exit ports for the traffic are experiencing greater-than-maximum utilization.
Layer-2, -3, and -4 Flow Specification
For Layer-2 traffic, you can define a flow based on the MAC packet headers.
• The MAC fields are source MAC address, destination MAC address and VLAN IDs. A list of incoming ports can also be specified
For Layer-3 (IP) traffic, you can define flows , blueprints , or templates of IP packet headers.
• The IP fields are source IP address, destination IP address, UDP/TCP source port,
UDP/TCP destination port, TOS (Type of Service), transport protocol (TCP or UDP), and a list of incoming interfaces.
The flows specify the contents of these fields. If you do not enter a value for a field, a wildcard value (all values acceptable) is assumed for the field.
Precedence for Layer-3 Flows
A precedence from 1 through 7 is associated with each field in a flow. The IA uses the precedence value associated with the fields to break ties if packets match more than one flow. The highest precedence is 1 and the lowest is 7. Here is the default precedence of the fields:
• IP: destination port (1), destination IP address (2), source port (3), source IP address (4),
TOS (5), interface (6), protocol (7)
Use the qos precedence ip command to change the default precedence.
234 Internet Appliance User Reference Manual
Chapter 15: QoS Configuration Guide
IA Queuing Policies
You can use one of two queuing policies on the IA:
• Strict priority : Assures the higher priorities of throughput but at the expense of lower priorities. For example, during heavy loads, low-priority traffic can be dropped to preserve throughput of control-priority traffic, and so on.
• Weighted fair queuing : Distributes priority throughput among the four priorities
(control, high, medium, and low) based on percentages.
You can set the queuing policy on a per-port basis. The default queuing policy is strict priority.
Traffic Prioritization for Layer-2 Flows
QoS policies applied to Layer-2 flows allow you to assign priorities based on source and destination MAC addresses. A QoS policy set for a Layer-2 flow allows you to classify the priority of traffic from:
• A specific source MAC address to a specific destination MAC address (use only when the port is in flow bridging mode)
• Any source MAC address to a specific destination MAC address
Before applying a QoS policy to a Layer-2 flow, you must first determine whether a port is in address-bridging mode or flow-bridging mode. If a port operates in address-bridging mode (default), you can specify the priority based on the destination MAC address and a
VLAN ID. You can also specify a list of ports to apply the policy.
If a port operates in flow-bridging mode, the user can be more specific and configure priorities for frames that match both a source AND a destination MAC address and a
VLAN ID. You can also specify a list of ports to apply the policy.
The VLAN ID in the QoS configuration must match the VLAN ID assigned to the list of ports to which the QoS policy is applied. In a Layer-2 only configuration, each port has only one VLAN ID associated with it and the QoS policy should have the same VLAN ID.
When different VLANs are assigned to the same port using different protocol VLANs, the
Layer-2 QoS policy must match the VLAN ID of the protocol VLAN.
Note: In flow mode, you can also ignore the source MAC address and configure the priority based on the destination MAC address only.
Internet Appliance User Reference Manual 235
Chapter 15: QoS Configuration Guide
Configuring Layer-2 QoS
When applying QoS to a Layer-2 flow, priority can be assigned as follows:
• The frame gets assigned a priority within the switch. Select low, medium, high or control.
• The frame gets assigned a priority within the switch, AND if the exit ports are trunk ports, the frame is assigned an 802.1Q priority. Select a number from 0 to 7. The mapping of 802.1Q to internal priorities is the following: (0 = low) (1,2,3 =medium)
(4,5,6 = high) (7 = control).
To set a QoS policy on a Layer-2 flow, enter the following command in Configure mode:
Set a Layer-2 QoS policy.
qos set l2 name <name> source-mac <MACaddr> dest-mac <MACaddr> vlan <vlanID> in-port-list <port-list> priority control|high|medium|low| <trunk-priority>
Traffic Prioritization for Layer-3 and -4 Flows
QoS policies applied at Layer-3 and -4 allow you to assign priorities based on specific fields in the IP headers. You can set QoS policies for IP flows based on source IP address, destination IP address, source TCP/UDP port, destination TCP/UDP port, type of service
(TOS) and transport protocol (TCP or UCP). A QoS policy set on an IP flow allows you to classify the priority of traffic based on:
• Layer-3 source-destination flows
• Layer-4 source-destination flows
• Layer-4 application flows
Configuring IP QoS Policies
To configure an IP QoS policy, perform the following tasks:
1.
Identify the Layer-3 or -4 flow and set the IP QoS policy.
2.
Specify the precedence for the fields within an IP flow.
236 Internet Appliance User Reference Manual
Chapter 15: QoS Configuration Guide
Setting an IP QoS Policy
To set a QoS policy on an IP traffic flow, enter the following command in Configure mode:
Set an IP QoS policy.
qos set ip <name> <priority> <srcaddr/mask> |any
<dstaddr/mask> |any <srcport> |any <dstport> |any
<tos> |any <port list> | <interface-list> |any
<protocol> |any <tos-mask> | any <tos-precedencerewrite> | any <tos-rewrite> | any
For example, the following command assigns control priority to any traffic coming from the 10.10.11.0 network: ia(config)# qos set ip xyz control 10.10.11.0/24
Specifying Precedence for an IP QoS Policy
To specify the precedence for an IP QoS policy, enter the following command in Configure mode:
Specify precedence for an
IP QoS policy.
qos precedence ip [sip <num> ] [dip <num> ]
[srcport <num> ] [destport <num> ]
[tos <num> ] [protocol <num> ] [intf
<num> ]
Configuring IA Queueing Policy
The IA queuing policy is set on a system-wide basis. The IA default queuing policy is strict priority. To change the queuing policy to weighted-fair queuing on the IA, enter the following command in Configure mode:
Set queuing policy to weighted-fair.
qos set queuing-policy weighted-fair port
<port list> |all-ports
If you want to revert the IA queuing policy from weighted-fair to strict priority (default), enter the following command in Configure mode:
Revert the IA queuing policy to strict priority.
negate <line within active-configuration containing qos set queuing-policy weighted-fair>
Internet Appliance User Reference Manual 237
Chapter 15: QoS Configuration Guide
Allocating Bandwidth for a Weighted-Fair Queuing Policy
If you enable the weighted-fair queuing policy on the IA, you can allocate bandwidth for the queues on the IA. To allocate bandwidth for each IA queue, enter the following command in Configure mode:
Allocate bandwidth for a weighted-fair queuing policy.
qos set weighted-fair control <percentage> high <percentage> medium <percentage> low <percentage> port <port list> |all-ports
ToS Rewrite
In the Internet, IP packets that use different paths are subject to delays, as there is little inherent knowledge of how to optimize the paths for different packets from different applications or users. The IP protocol actually provides a facility, which has been part of the IP specification since the protocol’s inception, for an application or upper-layer protocol to specify how a packet should be handled. This facility is called the Type of
Service (ToS) octet.
The ToS octet part of the IP specification, however, has not been widely employed in the past. The IETF is looking into using the ToS octet to help resolve IP quality problems.
Some newer routing protocols, like OSPF and IS-IS, are designed to be able to examine the
ToS octet and calculate routes based on the type of service.
The ToS octet in the IP datagram header consists of three fields:
7 6
Precedence
Most Significant Bit
5 4 3
ToS
2 1 0
MBZ
Least Significant Bit
• The three-bit Precedence field is used to indicate the priority of the datagram.
• The four-bit ToS field is used to indicate trade-offs between throughput, delay, reliability, and cost.
• The one-bit must be zero (MBZ) field is not currently used. (In the IA configuration, there is no restriction on this bit and it is included as part of the ToS field.)
For example, setting the ToS field to 0010 specifies that a packet will be routed on the most reliable paths. Setting the ToS field to 1000 specifies that a packet will be routed on the paths with the least delay. (Refer to RFC 1349 for the specification of the ToS field value.)
238 Internet Appliance User Reference Manual
Chapter 15: QoS Configuration Guide
With the ToS rewrite command, you can access the value in the ToS octet (which includes both the Precedence and ToS fields) in each packet. The upper-layer application can then decide how to handle the packet, based on either the Precedence or the ToS field or both fields. For example, you can configure a router to forward packets using different paths, based on the ToS octet. You can also change the path for specific applications and users by changing the Precedence and/or ToS fields.
Note: In RFC 2574, the IETF redefined the ToS octet as the DiffServ byte. You will still be able to use the ToS rewrite feature to implement DiffServ when this standard is deployed.
Configuring ToS Rewrite for IP Packets
The ToS rewrite for IP packets is set with the qos set command in Configure mode. You can define the QoS policy based on any of the following IP fields: source IP address, destination IP address, source port, destination port, ToS, port, or interface.
When an IP packet is received, the ToS field of the packet is ANDed with the <tos-mask> and the resulting value is compared with the ANDed value of <tos> and <tos-mask> of the
QoS policy. If the values are equal, the values of the <tos-rewrite> and <tos-precedencerewrite> parameters will be written into the packet.
The <tos> and <tos-mask> parameters use values ranging from 0 to 255. They are used in conjunction with each other to define which bit in the <tos> field of the packet is significant. The <tos-precedence-rewrite> value ranges from 0 to 7 and is the value that is rewritten in the ToS Precedence field (the first three bits of the ToS octet). The <tos-rewrite> value ranges from 0 to 31 and is the value that is rewritten in the ToS field (the last five bits of the ToS octet, which includes both the ToS field and the MBZ bit).
7 6
Precedence
5 4 3
ToS
2 1 0
MBZ
< tos-precedence-rewrite >
0-7
< tos-rewrite
0-31
>
The ToS byte rewrite is part of the QoS priority classifier group. The entire ToS byte can be rewritten or only the precedence part of the ToS byte can be rewritten. If you specify a value for <tos-precedence-rewrite> , then only the upper three bits of the ToS byte are changed. If you set <tos-precedence-rewrite> to any and specify a value for <tos-rewrite> , then the upper three bits remain unchanged and the lower five bits are rewritten. If you specify values for both <tos-precedence-rewrite> and <tos-rewrite> , then the upper three bits are rewritten to the <tos-precedence-rewrite> value and the lower five bits are rewritten to the <tos-rewrite> value.
Internet Appliance User Reference Manual 239
Chapter 15: QoS Configuration Guide
For example, the following command will rewrite the ToS Precedence field to 7 if the ToS
Precedence field of the incoming packet is 6: ia(config)# qos set ip tosp6to7 low any any any any 222 any any 224 7
In the above example, the <tos> value of 222 (binary value 1101 1110) and the <tos-mask> value of 224 (binary value 1110 0000) are ANDed together to specify the ToS Precedence field value of 6 (binary value 110). Changing the value in the <tos-mask> parameter determines the bit in the ToS octet field that will be examined.
The following example will rewrite the ToS Precedence and the ToS fields to 5 and 30 if the incoming packet is from the 10.10.10.0/24 network with the ToS Precedence field set to 2 and the ToS field set to 7. (In this example, the MBZ bit is included in the ToS field.) The figure below shows how the parameter values are derived.
Incoming Packet: 0 1 0 0 0 1 1 1
< tos > = 71
ToS = 7
Mask (look at all bits):
ToS Precedence = 2
1 1 1 1 1 1 1 1 < tos-mask > = 255
Rewritten ToS byte for 10.10.10.0/24 packet:
1 0 1
ToS Precedence = 5
1 1 1
ToS = 30
1 0 < tos-precedence-rewrite
<tos-rewrite> = 30
> = 5
The < tos-mask > value determines the ToS bit to be examined, which is all eight bits in this example. The following command configures the ToS rewrite for the example: ia(config)# qos set ip tos30to7 low 10.10.10.0/24 any any any 71 any any
255 5 30
240 Internet Appliance User Reference Manual
Chapter 15: QoS Configuration Guide
Monitoring QoS
The IA provides display of QoS statistics and configurations contained in the IA.
To display QoS information, enter the following commands in Enable mode:
Show all IP QoS flows.
Show all Layer-2 QoS flows.
qos show ip qos show l2 all-destination all-flow ports <port-list> vlan <vlanID> source-mac
<MACaddr> dest-mac <MACaddr>
Limiting Traffic Rate
Traffic rate limiting provides the ability to control the usage of a fundamental network resource, bandwidth. It allows you to limit the rate of traffic that flows through the specified interfaces, thus reserving bandwidth for critical applications. Unlike traffic prioritization, traffic rate limiting is a mechanism to control bandwidth usage of incoming traffic on a per flow basis.
A traffic profile is used to define the traffic characteristics before an upper limit is assigned.
The traffic profile is created using one or more ACLs which can utilize any combination of the parameters supported in the IP ACL. A rate limiting profile can then be defined by using the ACL and traffic rate limitations. A single rate limiting profile can have multiple
ACLs to define different traffic profiles and traffic rate limitations. When there are multiple traffic profiles, a sequence number is used to identify the order in which the profiles are applied. You can define the action taken on the traffic that exceeds the upper limit: either drop the packets or reset the priority of the traffic. The rate limiting profile is then applied to a logical IP interface.
To define a rate limit profile and apply the profile to an interface, enter the following commands in Configure mode:
Define a rate limit profile.
Apply a rate limit profile to an interface.
rate-limit <name> input acl <acl list> rate
<rate-limit> exceed-action drop-packets|setpriority-low|set-priority-medium|setpriority-high [sequence <number> ] rate-limit <name> apply interface
<interface> |all
Note: You cannot use non-IP ACLs for rate limit profiles.
Internet Appliance User Reference Manual 241
Chapter 15: QoS Configuration Guide
Example Configuration
Figure 32 presents an example of configuring rate limiting on the IA.
Backbone
1.1.1.1/8 et.1.1
et.1.8
2.2.2.2/8
Router et.1.2
3.3.3.3/8
Figure 32. Configuring Rate Limiting on the IA ipclient1 ipclient2
Traffic from two interfaces, ipclient1 with IP address 1.2.2.2 and ipclient2 with IP address
3.1.1.1, is restricted to 10 Mbps for each flow with the following configuration: vlan create client1 ip vlan create backbone ip vlan create client2 ip vlan add ports et.1.1 to client1 vlan add ports et.1.2 to client2 vlan add ports et.1.8 to backbone interface create ip ipclient1 vlan client1 address-netmask 1.1.1.1/8 interface create ip ipclient2 vlan client2 address-netmask 3.3.3.3/8 interface create ip backbone vlan backbone address-netmask 2.2.2.2/8 acl 100 permit ip 1.2.2.2
acl 200 permit ip 3.1.1.1
rate-limit client1 input acl 100 rate-limit 10000000 exceed-action drop-packets rate-limit client2 input acl 200 rate-limit 10000000 exceed-action drop-packets rate-limit client1 apply interface ipclient1 rate-limit client2 apply interface ipclient2
Displaying Rate Limit Information
To show information about rate limit policies, enter the following command in Enable mode:
Show rate limit policy information.
rate-limit show all| policy-name <name> | interface <interface>
242 Internet Appliance User Reference Manual
Chapter 16
Performance
Monitoring Guide
Performance Monitoring Overview
The Internet Appliance (IA) is a full wire-speed Layer-2, -3 and -4 switching router. As packets enter the IA, Layer-2, -3, and -4 flow tables are populated on each line card. The flow tables contain information on performance statistics and traffic forwarding. Thus the
IA provides the capability to monitor performance at Layer 2, 3, and 4. Layer-2 performance information is accessible to SNMP through MIB-II and can be displayed by using the l2-tables command in the CLI. Layer-3 and 4 performance statistics are accessible to SNMP through RMON/RMON2 and can be displayed by using the statistics show command in the CLI. In addition to the monitoring commands listed, you can find more monitoring commands listed in each chapter of the Internet Appliance Command Line
Interface Reference .
To access statistics on the IA, enter the following commands in Enable mode:
Show all TCP/UDP connections and services.
Show all IP routes.
Show all MAC addresses currently in the L2 tables.
Show info about MACs residing in a port's L2 table.
Show all L2 flows (for ports in flowbridging mode.
ip show connections ip show routes l2-tables show all-macs l2-tables show port-macs <port-list> l2-tables show all-flows
Internet Appliance User Reference Manual 243
Chapter 16: Performance Monitoring Guide
Show information about the master
MAC table.
Show information about a particular MAC address.
Show info about multicasts registered by IGMP.
Show whether IGMP is on or off on a VLAN.
Show info about MACs registered by the system.
Show SNMP statistics.
Show ICMP statistics.
Show IP interface's statistics.
Show unicast routing statistics.
Show multicast statistics.
Show port error statistics.
Show port normal statistics.
Show RMON etherStats statistics.
Show traffic summary statistics.
Show most active tasks.
Show TCP statistics.
Show UDP statistics.
Show TACACS server statistics.
Show broadcast monitoring information for ports.
Show all VLANs.
l2-tables show mac-table-stats l2-tables show mac l2-tables show igmp-mcast-registrations l2-tables show vlan-igmp-status l2-tables show bridge-management snmp show statistics statistics show icmp statistics show ip statistics show ip-routing statistics show multicast statistics show port-errors statistics show port-stats statistics show rmon statistics show summary-stats statistics show top statistics show tcp statistics show udp tacacs show stats port show bmon [config][detail][port
<port list> ][stats] vlan list
244 Internet Appliance User Reference Manual
Chapter 16: Performance Monitoring Guide
Configuring the IA for Port Mirroring
The IA allows you to monitor activity with port mirroring. Port mirroring allows you to monitor the performance and activities of one or more ports on the IA or for traffic defined by an ACL through just a single, separate port. While in Configure mode, you can configure your IA for port mirroring with a simple command line like the following:
Configure Port
Mirroring.
port mirroring monitor-port <port number> targetport <port list> | target-profile <acl name>
Note: • Port mirroring is available for WAN ports. However, you cannot configure port mirroring on a port-by-port basis. (You can only configure port mirroring for the entire WAN card).
•Only IP ACLs can be specified for port mirroring.
Monitoring Broadcast Traffic
The IA allows you to monitor broadcast traffic for one or more ports. You can specify that a port be shut down if its broadcast traffic reaches a certain rate limit for a particular period of time. You can also specify the duration of the port shut down. To specify the monitoring of broadcast traffic and the shut down threshold for one or more ports, enter the following command in Configure mode:
Configure monitoring of broadcast traffic.
port bmon <port list> rate <number> duration
<number> shutdown <number>
Internet Appliance User Reference Manual 245
Chapter 17
RMON
Configuration
Guide
RMON Overview
You can employ Remote Network Monitoring (RMON) in your network to help monitor traffic at remote points on the network. With RMON, data collection and processing is done with a remote probe , namely the Internet Appliance (IA). The IA also includes
RMON agent software that communicates with a network management station via SNMP.
Because information is only transmitted from the IA to the management station when required, SNMP traffic on the network and the management station’s processing load are reduced.
The IA provides support for both RMON 1 and RMON 2 MIBs, as specified in RFCs 1757 and 2021, respectively. While non-RMON SNMP products allow the monitoring and control of specific network devices , RMON 1 returns statistics on network segments at the
MAC layer. RMON 2 collects statistics on network and application layer traffic to show host-to-host connections and the applications and protocols being used. For example, the
RMON 2 network layer matrix MIB group can show protocol-specific traffic between pairs of systems which can help to diagnose protocol problems. Note that RMON 2 is not a superset of RMON 1; on the IA, you can configure both RMON 1 and RMON 2 statistics collection.
Internet Appliance User Reference Manual 247
Chapter 17: RMON Configuration Guide
Configuring and Enabling RMON
By default, RMON is disabled on the IA. To configure and enable RMON on the IA, follow these steps:
1.
Turn on the Lite, Standard, or Professional RMON groups by entering the rmon set lite|standard|professional command. You can also configure default control tables for the Lite, Standard, or Professional RMON groups by including the default-tables yes parameter.
2.
Enable RMON on specified ports with the rmon set ports command.
3.
Optionally, you can configure control tables for the Lite, Standard, or Professional
RMON groups. For example, if you chose not to create default control tables for the
Lite, Standard, or Professional groups, you can configure control table entries for specific ports on the IA.
4.
Use the rmon enable command to enable RMON on the IA.
Example of RMON Configuration Commands
The following are examples of the commands to configure and enable RMON on the IA: ia (config)# show
Running system configuration:
!
! Last modified from Telnet (10.50.89.88) on 1999-04-05 16:52:28
!
1 : port flow-bridging et.5.(3-8) a
!
2 : interface add ip en0 address-netmask 10.50.6.9/16
!
3 : system set contact "usama"
4 : system set location Cabletron Systems, Inc.
5 : system set name "ia"
!
6 : rmon set ports all-ports
7 : rmon set lite default-tables yes
8 : rmon set standard default-tables yes
!
! Set RMON Pro Group with Default Tables ON, cap memory at 4 meg
! Pro: protocolDir, protocolDist, addressMap, al/nl-Matrix, al/nl-Host,
! al/nl-matrixTopN. userHistory, probeConfig.
! Default Tables: one control row per dataSource for protocolDist,
! addressMap, al/nl-Host, al/nl-Matrix.
!
9 : rmon set professional default-tables yes
10 : rmon set memory 4
11 : rmon enable a. To collect Layer-2 matrix information, port must be configured for flow-bridging mode. By default, ports on the IA operate in address-bridging mode.
248 Internet Appliance User Reference Manual
Chapter 17: RMON Configuration Guide
The next sections describe Lite, Standard, and Professional RMON groups and control tables.
RMON Groups
The RMON MIB groups are defined in RFCs 1757 (RMON 1) and 2021 (RMON 2). On the
IA, you can configure one or more levels of RMON support for a set of ports. Each level—
Lite, Standard, or Professional—enables different sets of RMON groups (described later in this section). You need to configure at least one level before you can enable RMON on the
IA.
To specify the support level for RMON groups, use the following CLI command line in
Configure mode:
Specifies Lite, Standard, or
Professional RMON groups.
rmon set lite|standard|professional defaulttables yes|no
To specify the ports on which RMON is to be enabled, use the following CLI command line in Configure mode:
Specifies the ports on which
RMON is enabled.
rmon set ports <port list> |allports
You can configure each level of RMON support independently of each other with default tables on or off. For example, you can configure Lite with default tables on for ports et.1.(1-8) and then configure Standard with no default tables for the same ports. You cannot configure Lite on one set of ports and Standard on another set of ports.
Internet Appliance User Reference Manual 249
Chapter 17: RMON Configuration Guide
Lite RMON Groups
This section describes the RMON groups that are enabled when you specify the Lite support level. The Lite RMON groups are shown in Table 4 .
Table 4. Lite RMON Groups
Group
EtherStats
Event
Alarm
History
Function
Records Ethernet statistics (for example, packets dropped, packets sent, etc.) for specified ports.
Controls event generation and the resulting action (writing a log entry or sending an SNMP trap to the network management station).
Generates an event when specified alarm conditions are met.
Records statistical samples for specified ports.
Standard RMON Groups
This section describes the RMON groups that are enabled when you specify the Standard support level. The Standard RMON groups are shown in Table 5 .
Table 5. Standard RMON Groups
Group
Host
Host Top N
Matrix
Filter
Packet Capture
Function
Records statistics about the hosts discovered on the network.
Gathers the top n hosts, based on a specified rate-based statistic. This group requires the hosts group.
Records statistics for source and destination address pairs.
Specifies the type of packets to be matched and how and where the filtered packets should flow (the channel).
Specifies the capture of filtered packets for a particular channel.
Professional RMON Groups
The Professional RMON groups correspond to the RMON 2 groups defined in RFC 2021.
While RMON 1 groups allow for the monitoring of packets at the MAC layer, RMON 2 groups focus on monitoring traffic at the network and application layers.
250 Internet Appliance User Reference Manual
Chapter 17: RMON Configuration Guide
The Professional RMON groups are shown in Table 6 .
Table 6. Professional RMON Groups
Group
Protocol Directory
Protocol Distribution
Application Layer
Host
Network Layer Host
Application Layer
Matrix (and Top N)
Network Layer Matrix
(and Top N)
Address Map
User History
Function
Contains a list of protocols supported by the IA and monitored by RMON. See the RMON 2 Protocol Directory appendix in the Internet Appliance Command Line Interface
Reference.
Records the packets and octets for specified ports on a per protocol basis.
Monitors traffic at the application layer for protocols defined in the protocol directory.
Monitors traffic at the network layer for protocols defined in the Protocol Directory.
Monitors traffic at the application layer for protocols defined in the Protocol Directory. Top N gathers the top n application layer matrix entries.
Monitors traffic at the network layer for protocols defined in the Protocol Directory. Top N gathers the top n network layer matrix entries.
Records MAC address to network address bindings discovered for specified ports.
Records historical data on user-defined statistics.
Control Tables
Many RMON groups contain both control and data tables. Control tables specify what statistics are to be collected. For example, you can specify the port for which statistics are to be collected and the owner (name, phone, or IP address) for that port. You can change many of the entries in a control table with rmon commands. Data tables contain the collected statistics. You cannot change any of the entries in a data table; you can only view the data.
When you specify the Lite, Standard, or Professional RMON groups, you have the option of creating default control tables. A default control table creates a control table entry for every port on the IA. Creating default control tables essentially configures data collection for every port on the IA for certain RMON groups. If you do not want this, you can choose not to create the default control tables and then configure the appropriate control tables for the data you wish to collect. Even if you use the default control tables, you can always use the rmon commands to modify control table entries.
Internet Appliance User Reference Manual 251
Chapter 17: RMON Configuration Guide
If you choose to create default control tables, entries are created in the control tables for each port on the IA for the following groups:
Lite groups: Etherstats
History
Standard groups:
Professional groups:
Host
Matrix
Protocol Distribution
Address Map
Application Layer/Network Layer Host
Application Layer/Network Layer Matrix
A row in the control table is created for each port on the IA, with the owner set to monitor.
If you want, you can change the owner by using the appropriate rmon command. See
“Configuring RMON Groups” on page 254 for more the command to configure a specific group.
Note: Control tables other than the default control tables must be configured with CLI commands, as described in “Configuring RMON Groups” on page 254 .
Using RMON
RMON on the IA allows you to analyze network traffic patterns, set up alarms to detect potential problems before they turn into real congestive situations, identify heavy network users to assess their possible candidacy for moves to dedicated or higher-speed ports, and analyze traffic patterns to facilitate more long-term network planning.
RMON 1 provides Layer-2 information. Traffic flowing through the IA’s Layer-2 ASIC is collected by RMON 1 groups. RMON 2 in the IA provides Layer-3 traffic information for
IP protocols. Traffic flowing through the IA’s Layer-3 ASIC is collected by RMON 2 groups. The IA’s RMON 2 protocol directory contains over 500 protocols that can be decoded for UDP and TCP ports. You can use RMON to see the kinds of protocol traffic being received on a given port.
252 Internet Appliance User Reference Manual
Chapter 17: RMON Configuration Guide
For example, use the rmon show protocol-distribution command to see the kinds of traffic received on a given port: ia# rmon show protocol-distribution et.5.5
RMON II Protocol Distribution Table
Index: 506, Port: et.1.7, Owner: monitor
Pkts Octets Protocol
---- ------ --------
19 1586 ether2
19 1586 ether2.ip-v4
19 1586 *ether2.ip-v4
2 192 *ether2.ip-v4.icmp
17 1394 *ether2.ip-v4.tcp
17 1394 *ether2.ip-v4.tcp.www-http
In the example output above, only HTTP and ICMP traffic is being received on this port.
To find out which host or user is using these applications/protocols on this port, use the following command: ia# rmon show al-matrix et.5.5
RMON II Application Layer Host Table
Index: 500, Port: et.5.5, Inserts: 4, Deletes: 0, Owner: monitor
SrcAddr DstAddr Packets Octets Protocol
------- ------- ------- ------ --------
10.50.89.88 15.15.15.3 1771 272562 *ether2.ip-v4
10.50.89.88 15.15.15.3 1125 211192 *ether2.ip-v4.tcp
10.50.89.88 15.15.15.3 1122 210967 *ether2.ip-v4.tcp.telnet
10.50.89.88 15.15.15.3 3 225 *ether2.ip-v4.tcp.www-http
Internet Appliance User Reference Manual 253
Chapter 17: RMON Configuration Guide
Configuring RMON Groups
As mentioned previously, control tables in many RMON groups specify the data that is to be collected for the particular RMON group. If the information you want to collect is in the default control tables, then you only need to turn on the default tables when you specify the RMON groups (Lite, Standard, or Professional); you do not need to configure entries in the default tables.
The following table shows the rmon command that you use to configure each RMON group:
To configure the Address
Map group.
To configure the Application
Layer Matrix top n entries.
To configure the Alarm group.
To configure the Packet
Capture group.
To configure the Filter group, you must configure both the
Channel and Filter control tables.
rmon address-map index <index-number> port <port>
[ owner <string> ] [ status enable|disable ] rmon al-matrix-top-n index <index-number> matrixindex <number> ratebase terminal-packets|terminaloctets|all-packets|all-octets duration <number> size
<number> [ owner <string> ] [ status enable|disable ] rmon alarm index <index-number> variable <string>
[ interval <seconds> ] [ falling-event-index <num> ]
[ falling-threshold <num> ] [ owner <string> ] [ risingevent-index <num> ] [ rising-threshold <num> ]
[ startup rising|falling|both ] [ status enable|disable ]
[ type absolute-value|delta-value ] rmon capture index <index-number> channelindex <number> [ full-action lock|wrap ] [ slice-size
<number> ] [ download-slice-size <number> ]
[ download-offset <number> ] [ max-octets <number> ]
[ owner <string> ] [ status enable|disable ] rmon channel index <index-number> port <port>
[ accept-type matched|failed ] [ data-control on|off ]
[ turn-on-event-index <number> ] [ turn-off-eventindex <number> ] [ event-index <number> ] [ channelstatus ready|always-ready ][ description <string> ]
[ owner <string> ] [ status enable|disable ]
To configure the Etherstats group.
rmon filter index <index-number> channel-index
<number> [ data-offset <number> ] [ data <string> ]
[ data-mask <string> ] [ data-not-mask <string> ] [ pktstatus <number> ] [ status-mask <number> ] [ status-notmask <number> ] [ owner <string> ] [ status enable|disable ] rmon etherstats index <index-number> port <port>
[ owner <string> ] [ status enable|disable ]
254 Internet Appliance User Reference Manual
Chapter 17: RMON Configuration Guide
To configure the Event group.
rmon event index <index-number> type none|log|trap|both [ community <string> ]
[ description <string> ] [ owner <string> ] [ status enable|disable ]
To configure the History group.
rmon history index
[ interval <seconds>
<index-number>
] [ owner <string>
<num> ] [ status enable|disable ] port
] [
<port> samples
To configure the Application
Layer and Network Layer
Host groups.
To configure the Application
Layer and Network Layer
Matrix groups.
rmon hl-host index max-entries
[ owner
<number>
<string> ] [
<index-number> port al-max-entries <number> status enable|disable ] rmon hl-matrix index <index-number> port <port> nlmax-entries <number> al-max-entries <number>
[ owner <string> ] [ status enable|disable ]
<port> nl-
To configure the Host group.
rmon host index <index-number> port <port> [ owner
<string> ] [ status enable|disable ]
To configure the Host Top N entries.
rmon host-top-n index
<number> [ base
<index-number>
<statistics> ] [ duration host-index
<time> ] [ size
<size> ] [ owner <string> ] [ status enable|disable ]
To configure the Matrix group.
To configure the Network
Layer Matrix top n entries.
rmon matrix index
[ owner <string> ] [
<index-number> [ port status enable|disable ]
<port> ] rmon nl-matrix-top-n index <index-number> matrixindex <number> ratebase terminal-packets|terminaloctets|all-packets|all-octets duration <number> size
<number> [ owner <string> ] [ status enable|disable ] rmon protocol-distribution index <index-number> port <port> [ owner <string> ] [ status enable|disable ]
To configure the Protocol
Distribution group.
To configure the User History group, you must configure the group of objects to be monitored and apply the objects in the group to the
User History control table.
rmon user-history-control index objects
<oid>
<number>
<number> [ owner samples
<string> rmon user-history-objects type absolute|delta
<number>
] [
[
<index-number> interval
<groupname> status enable|disable variable status enable|disable ]
] rmon user-history-apply <groupname> to <userhistory-index>
Internet Appliance User Reference Manual 255
Chapter 17: RMON Configuration Guide
Configuration Examples
This section shows examples of configuration commands that specify an event that generates an SNMP trap and the alarm condition that triggers the event.
The RMON Alarm group allows the IA to poll itself at user-defined intervals. Alarms that constitute an event are logged into the Event table that can then be polled by the management station. The management station is able to poll more network devices this way, as it only needs to poll the RMON Event table and not the device itself. The management station can also be sent trap information.
The following examples configure the IA to create an event when a module is hot swapped into the chassis or any new IP interface is configured. The managed object ifTableLastChanged from RFC 2233) has an object identifier (OID) of 1.3.6.1.2.1.31.1.5.0 and the IA will poll this OID every 5 minutes (300 seconds).
The command line below is an example of an RMON Event group configuration with the following attributes:
• Index number 15 to identify this entry in the Event control table.
• The event is both logged in the Event table and an SNMP trap generated with the community string “public.”
• Event owner is “help desk.” ia#(config) r mon event index 15 type both community public description
"Interface added or module hot swapped in" owner "help desk"
The command line below is an example of an RMON Alarm group configuration with the following attributes:
• Index number 20 to identify this entry in the Alarm control table.
• The OID 1.3.6.1.2.1.31.1.5.0 identifies the attribute to be monitored.
• Samples taken at 300-second (5-minute) intervals.
• A Startup alarm generation condition instructing the IA to generate an alarm if the sample is greater than or equal to the rising threshold or less than or equal to the falling threshold.
• Compare value at time of sampling (absolute value) to the specified thresholds.
• Rising and falling threshold values are 1.
256 Internet Appliance User Reference Manual
Chapter 17: RMON Configuration Guide
• Rising and falling event index values are 15, which will trigger the previously configured Event.
ia#(config) r mon alarm index 20 variable 1.3.6.1.2.1.31.1.5.0 interval
300 startup both type absolute-value rising-threshold 1 fallingthreshold 1 rising-event-index 15 falling-event-index 15 owner "help desk"
Displaying RMON Information
The CLI rmon show commands allow you to display the same RMON statistics that can be viewed from a management station. To display RMON statistics for the IA, use the following CLI command lines in Enable mode:
To show Ethernet statistics.
To show all events and logs.
To show all alarms.
To show histories and logs.
To show hosts and logs.
To show all Host Top N and logs.
To show matrices and logs.
To show all channels.
To show all filters.
To show all packet captures and logs.
To display the RMON 2
Protocol Directory.
To display the RMON 2
Protocol Distribution.
To display the RMON 2
Address Map table.
To show Network Layer Host logs.
To show Application Layer
Host logs.
rmon show etherstats <port-list> |all-ports rmon show events rmon show alarms rmon show history <port-list>| all-ports rmon show hosts <port-list>| all-ports [summary] rmon show host-top-n rmon show matrix <port-list> |all-ports rmon show channels rmon show filters rmon show packet-capture rmon show protocol-directory rmon show protocol-distribution <port-list> |allports rmon show address-map <port-list> |all-ports rmon show nl-host <port-list> |all-ports [summary] rmon show al-host <port-list> |all-ports [summary]
Internet Appliance User Reference Manual 257
Chapter 17: RMON Configuration Guide
To show Network Layer
Matrix logs.
To show Application Layer
Matrix logs.
To show all Network Layer
Matrix Top N.
To show all Application
Layer Matrix Top N.
rmon show nl-matrix rmon show al-matrix
<port-list> srcdst|dstsrc] [summary]
<port-list> srcdst|dstsrc] [summary] rmon show nl-matrix-top-n rmon show al-matrix-top-n
|all-ports [order-by
|all-ports [order-by
To show all user history logs.
rmon show user-history
To show probe configuration.
rmon show probe-config [basic] [net-config] [trapdest]
RMON CLI Filters
Because a large number of statistics can be collected for certain RMON groups, you can define and use CLI filters to limit the amount of information displayed with the rmon show commands. An RMON CLI filter can only be applied to a current Telnet or Console session.
The following shows Host table output without a CLI filter: ia# rmon show hosts et.5.4
RMON I Host Table
Index: 503, Port: et.5.4, Owner: monitor
Address InPkts InOctets OutPkts OutOctets Bcst Mcst
------- ------ -------- ------- --------- ---- ----
00001D:921086 0 0 102 7140 0 0
00001D:9D8138 1128 75196 885 114387 0 0
00001D:A9815F 0 0 102 7140 0 0
00105A:08B98D 0 0 971 199960 0 0
004005:40A0CD 0 0 51 3264 0 0
006083:D65800 0 0 2190 678372 0 0
0080C8:E0F8F3 0 0 396 89818 0 0
00E063:FDD700 0 0 104 19382 0 0
01000C:CCCCCC 2188 678210 0 0 0 0
01005E:000009 204 14280 0 0 0 0
0180C2:000000 1519 97216 0 0 0 0
030000:000001 168 30927 0 0 0 0
080020:835CAA 885 114387 1128 75196 0 0
980717:280200 0 0 1519 97216 0 0
AB0000:020000 2 162 0 0 0 0
FFFFFF:FFFFFF 1354 281497 0 0 0 0
258 Internet Appliance User Reference Manual
Chapter 17: RMON Configuration Guide
The following shows the same rmon show hosts command with a filter applied so that only hosts with inpkts greater than 500 are displayed: ia# rmon apply cli-filter 4 ia# rmon show hosts et.5.4
RMON I Host Table
Filter: inpkts > 500
Address Port InPkts InOctets OutPkts OutOctets Bcst Mcst
------- ---- ------ -------- ------- --------- ---- ----
00001D:9D8138 et.5.4 1204 80110 941 121129 0 0
01000C:CCCCCC et.5.4 2389 740514 0 0 0 0
0180C2:000000 et.5.4 1540 98560 0 0 0 0
080020:835CAA et.5.4 940 121061 1204 80110 0 0
FFFFFF:FFFFFF et.5.4 1372 285105 0 0
RMON CLI filters can only be used with the following groups:
• Hosts
• Matrix
• Protocol Distribution
• Application Layer Host
• Network Layer Host
• Application Layer Matrix
• Network Layer Matrix
Creating RMON CLI Filters
To create RMON CLI filters, use the following CLI command in Configure mode:
Creates an RMON CLI filter.
rmon set cli-filter <filter-id> <parameter>
Using RMON CLI Filters
To see and use RMON CLI filters, use the following CLI command in User or Enable mode:
Displays RMON CLI filters.
Applies a CLI filter on current
Telnet or Console session.
Clears the currently-selected
CLI filter.
rmon show cli-filters rmon apply cli-filters <filter-id> rmon clear cli-filter
Internet Appliance User Reference Manual 259
Chapter 17: RMON Configuration Guide
Troubleshooting RMON
If you are not seeing the information you expected with an rmon show command, or if the network management station is not collecting the desired statistics, first check that the port is up. Then, use the rmon show status command to check the RMON configuration on the IA.
Check the following fields on the rmon show status command output: ia# rmon show status
RMON Status
-----------
* RMON is ENABLED
1
* RMON initialization successful.
2
+--------------------------+
| RMON Group Status |
+-------+--------+---------+
| Group | Status | Default |
+-------+--------+---------+
| Lite | On | Yes |
+-------+--------+---------+
4
| Std | On | Yes |
+-------+--------+---------+
| Pro | On | Yes |
+-------+--------+---------+
RMON is enabled on: et.5.1, et.5.2, et.5.3, et.5.4, et.5.5, et.5.6, et.5.7, et.5.8
3
RMON Memory Utilization
-----------------------
Total Bytes Available: 48530436
Total Bytes Allocated to RMON: 4000000
Total Bytes Used: 2637872
Total Bytes Free: 1362128
5
1.
Make sure that RMON has been enabled on the IA. When the IA is booted, RMON is off by default. RMON is enabled with the rmon enable command.
2.
Make sure that at least one of the RMON support levels—Lite, Standard, or
Professional—is turned on with the rmon set lite|standard|professional command.
3.
Make sure that RMON is enabled on the port for which you want statistics. Use the rmon set ports command to specify the port on which RMON will be enabled.
260 Internet Appliance User Reference Manual
Chapter 17: RMON Configuration Guide
4.
Make sure that the control table is configured for the report that you want. Depending upon the RMON group, default control tables may be created for all ports on the IA.
Or, if the RMON group is not one for which default control tables can be created, you will need to configure control table entries using the appropriate rmon command.
If you or your application are unable to crate a control table row, check the snmp show status output for errors. Make sure that there is a read-write community string. Verify that you can ping the IA and that no ACLs prevent you from using SNMP to access the
IA.
5.
Make sure that RMON has not run out of memory.
Allocating Memory to RMON
RMON allocates memory depending on the number of ports enabled for RMON, the
RMON groups that have been configured, and whether or not default tables have been turned on or off. Enabling RMON with all groups (Lite, Standard, and Professional) with default tables uses approximately 300 kilobytes per port. If necessary, you can dynamically allocate additional memory to RMON.
To display the amount of memory that is currently allocated to RMON, use the following
CLI command in Enable mode:
Displays the memory allocated to RMON.
rmon show status
Internet Appliance User Reference Manual 261
Chapter 17: RMON Configuration Guide
Any memory allocation failures are reported. The following is an example of the information shown with the rmon show status command: ia# rmon show status
RMON Status
-----------
* RMON is ENABLED
* RMON initialization successful.
+--------------------------+
| RMON Group Status |
+-------+--------+---------+
| Group | Status | Default |
+-------+--------+---------+
| Lite | On | Yes |
+-------+--------+---------+
| Std | On | Yes |
+-------+--------+---------+
| Pro | On | Yes |
+-------+--------+---------+
RMON is enabled on: et.5.1, et.5.2, et.5.3, et.5.4, et.5.5, et.5.6, et.5.7, et.5.8
RMON Memory Utilization
-----------------------
Total Bytes Available: 48530436
Total Bytes Allocated to RMON: 4000000
Total Bytes Used: 2637872
Total Bytes Free: 1362128
To set the amount of memory allocated to RMON, use the following CLI command in
User or Enable mode:
Specifies the total megabytes of memory allocated to
RMON.
rmon set memory <number>
262 Internet Appliance User Reference Manual
Advertisement
Key features
- Compact, all-in-one design
- Easy-to-use interface
- Pre-installed software applications
- Built-in Ethernet port and Wi-Fi connectivity
- Secure and reliable operation
- Affordable price point
