Network static Lab workbook

Published on June 2016 | Categories: Types, Instruction manuals | Downloads: 54 | Comments: 0 | Views: 480

of 181

Content

Logbook Section 1 The Static Laboratory
Version 0.99 November 2002 Markus B¨ing o mailto://[email protected]

DRAFT
TODO: Update router conﬁguration proﬁles

The Brest Laboratory Doosthofer Weg 8 21698 Brest Germany http://www.brest-lab.net

Concept:

November 24, 2002

1

Contents
1 Introduction 1.1 Document Purpose 1.2 Research Resources 2 Network Architecture 2.1 Topology Overview 2.2 Design Considerations 2.3 Design Constraints 3 Oﬃce Network 3.1 Physical Design 3.2 Logical Design 3.3 Network Services 3.3.1 Internet Access 3.3.2 DHCP 3.3.3 DNS 3.3.4 TFTP 3.3.5 Printing 3.3.6 X11 4 Lab Network 4.1 Physical Design 4.1.1 Software IOS-MPLS NetBSD-MPLS IOS-Edge NetBSD-Core IOS-Pagent Conﬁguration Files 4.1.2 Hardware 4.2 Logical Design Zebra OSPFd 4.2.1 MPLS 4.2.2 IPv6 Topology Physical Design Addressing Routing Host Access 5 Network Services 5.1 DNS 5.2 FTP and TFTP 5.3 Logging 5.4 NTP 5.5 Printing 1 1 1 5 5 5 5 7 7 8 8 8 9 9 9 9 9 12 12 13 13 13 13 13 13 13 15 16 16 18 19 19 19 19 20 21 27 27 27 27 27 27

i

Concept:

November 24, 2002

2

5.6 5.7 5.8 5.9 5.9.1

5.9.2

5.9.3 5.9.4 5.9.5 5.9.6 5.9.7 5.9.8 5.9.9 5.10 5.10.1 5.11

netdb (http://www.net.cmu.edu/netreg/) VideoLAN (www.videolan.org) Kismet (www.kismetwireless.net) Network Veriﬁcation Toolkit Some Tools that come with IOS Service Assurance Agent Traﬃc Matrix Statistics Pagent LNE BGP LNE OSPF TGN Expect Ploticus NRFU Cricket and RRDTool MRTG Ethereal (www.ethereal.com) Etherape (etherape.sourceforge.net) Authentication Services RADIUS Security Toolkit

27 27 27 28 28 28 29 32 33 35 38 42 43 45 46 47 51 51 52 52 53 54 54 54 56 58 61 64 67 68 70 72 73 74 78 78 84 89 91 93 99 101 104 107 113 113 113 113

A Conﬁguration Log A.1 Basic IPv4 Conﬁguration A.1.1 Common Conﬁguration - NTP, SNMP, Administrative Access A.1.2 Common Conﬁguration - RADIUS A.1.3 Router Core1 - IPv4 A.1.4 Router Core2 - IPv4 A.1.5 Router Core3 - IPv4 A.1.6 Router Core4 - IPv4 A.1.7 Router Edge1 - IPv4 A.1.8 Router Edge2 - IPv4 A.1.9 Router Zerberus - IPv4 A.1.10 Host Anchor - IPv4 A.1.11 Host Dinghy - IPv4 A.2 IPv6 Conﬁguration A.2.1 Router Anchor - IPv6 A.2.2 Router Dinghy - IPv6 A.2.3 Router Edge1 - IPv6 A.2.4 Router Edge2 - IPv6 A.2.5 Router Core4 - IPv6 A.3 RADIUS A.4 Ploticus A.5 MRTG A.6 Expect B Problem and Resolution Log B.1 2002-09-00 - Installing NetBSD on SGI Indy B.1.1 Status: SOLVED B.1.2 Symptom

ii

Concept:

November 24, 2002

3

B.1.3 Analysis B.1.4 Solution B.1.5 Symptom B.1.6 Analysis B.1.7 Solution B.1.8 Symptom B.1.9 Analysis B.1.10 Solution B.2 2001-10-06 - GateD: No IP forwarding B.2.1 Status: SOLVED B.2.2 Symptom B.2.3 Analysis B.2.4 Solution B.3 2001-10-04 - Zebra OSPFd on NetBSD does not form Adjacency B.3.1 Status: SOLVED B.3.2 Symptom B.3.3 Analysis B.3.4 Solution B.4 2001-03-17 - RADIUS on DEC Alpha running NetBSD B.4.1 Status: OPEN B.4.2 Symptom B.4.3 Analysis B.4.4 Solution C Activity Log C.1 How to add IPv6 to the Lab Network C.1.1 Conﬁgure Route Reﬂectors Enable IPv6 on Anchor and Dinghy Conﬁgure IPv6 Addresses on Ethernet and Loopback Interfaces Create Tunnel between Anchor and Dinghy Conﬁgure iBGP between Anchor and Dinghy C.1.2 Conﬁgure Cisco Edge Router Enable IPv6 on Edge Router Conﬁgure Tunnels Conﬁgure BGP on Route Reﬂectors Conﬁgure BGP on Cisco Edge Router Test Static Route and Tunnel Check BGP Conﬁgure RIPv6 C.1.3 Conﬁgure NetBSD/Zebra Edge Router C.2 Conﬁguring DJBDNS D Xyplex MaxServer 1600 D.1 Access Server Administrator’s Primer D.1.1 Bootstrap Software Image D.1.2 Parameter File D.1.3 Login D.1.4 Conﬁguration D.1.5 Rebooting

113 114 115 115 115 115 115 116 117 117 117 117 117 118 118 118 120 123 124 124 124 124 126 127 127 127 127 128 128 130 136 136 136 138 140 141 142 150 152 153 158 158 158 158 159 160 160 162

iii

Concept:

November 24, 2002

4

D.1.6 Normally NOT Suggested D.1.7 Additional Information D.1.8 Additional Documentation and Resources D.2 Setting An MX-1600, MX-1608 or MX-1450 To Factory Defaults D.2.1 Conﬁguring MX1600 To Load Image Via DTFTP D.3 Conﬁguring SYSLOG On Access Servers D.3.1 Conﬁgure the Access Server for SYSLOGD D.3.2 *Setting a Priority Number D.3.3 Conﬁgure the Unix Host for SYSLOGD Document History

163 164 164 166 168 171 171 171 172 173

iv

Concept:

November 24, 2002

5

Figures
2.1 3.1 3.2 4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 Network Architecture Oﬃce Network - Physical Design Oﬃce Network - Logical Design Lab Network - Physical Design Lab Network - Logical Design Lab Network - IPv6 Logical Design Lab Network - IPv6 Routing Lab Network - MPLS Logical Design Pagent TGN Expect script rtr3 Example of a Ploticus CPU utilization graph Example of a Ploticus memory utilization graph Example of a MRTG CPU utilization graph Example of a MRTG memory utilization graph Example of a MRTG free memory graph 6 10 11 22 23 24 25 26 41 42 43 44 48 49 50

v

Concept:

November 24, 2002

6

Tables
3.1 3.2 4.1 4.2 1 Oﬃce Network - Inventory Oﬃce Network - IP Address Assignment Lab Network - Inventory Lab Network - IP Address Assignment Document History 7 8 15 17 173

vi

Concept:

November 24, 2002

7

1 Introduction
During the course of my lab sessions I found myself frequently re-cabling boxes and typing basic conﬁguration statements into routers. I thought it would be convenient to have a default laboratory conﬁguration that does support a wide variety of experiments without signiﬁcant changes in the physical setup. Also I found myself occasionally in a situation where my wife wanted to so something fancy, such as printing a letter or surﬁng the web, and could not do so because I was using the equipment. To solve my problem I developed a network architecture that is separated in two parts, an oﬃce network and a laboratory network. Oﬃce network (also termed ”production network”) provides a stable environment for tasks that are not directly related to laboratory work such as providing Internet access to my family. However, the services of the oﬃce network are also available to the laboratory network. Laboratory network provides the network engineers playground.

1.1

Document Purpose
Purpose of this document is describing both oﬃce and laboratory network including: • • • • • • Network architecture Network services Devices and device conﬁguration Key software tools used in the network ”Cheat sheet” for common conﬁguration problems Problem and problem resolution log

1.2

Research Resources
Cisco Router Cisco’s web site (http://www.cisco.com/tac/) provides a wealth of information for the network professional ranging from networking basics to in-depth treatment of Cisco products. SNMP Object Navigator http://www.cisco.com/cgi-bin/Support/Mibbrowser/unity.pl Xylan PizzaSwitch Xylan has been aquired by Alcatel (http://www.ind.alcatel.com/). Some of the old PizzaSwitches (at least parts of them) are still alive under the name OmniSwitch. Xyplex Terminal Server iTouch Communications (http://www.itouchcom.com/) has taken over the old Xyplex product line. 1
1

The documentation used to be at the URL http://www.nbase-xyplex.com/support/documentation/ and documentation speciﬁc to the Maxserver 1600 was available at the URL http://www.nbase-xyplex.com/support/documentation/product/guide/index.cfm?doc=access

1

Concept:

November 24, 2002

8

Introduction

Research Resources

Conserver (http://www.conserver.com/) is an application that allows multiple users to watch a serial console at the same time. It can log the data, allows users to take write-access of a console (one at a time), and has a variety of bells and whistles to accentuate that basic functionality. The idea is that conserver will log all your serial traﬃc so you can go back and review why something crashed, look at changes (if done on the console), or tie the console logs into a monitoring system (just watch the logﬁles it creates). With multi-user capabilities you can work on equipment with others, mentor, train, etc. It also does all that client-server stuﬀ so that, assuming you have a network connection, you can interact with any of the equipment from home or wherever. The Greater Scroll of Console Knowledge (http://www.conserver.com/consoles/) provides links to various pages with information regarding serial ports, console servers, and the Conserver program. Stokely Consulting (http://www.stokely.com/) provides Unix serial port and system administrator resources. tcpdump The home page of tcpdump and libpcap can be found at the URL http://www.tcpdump.org/. Ethereal is a network protocol analyzer for Unix and Win32. The home page of Ethereal can be found at the URL http://www.ethereal.com/. Scotty The home page of Scotty can be found at the URL http://wwwhome.cs.utwente.nl/ schoenw/scotty/. Information on Scotty and other network management tools, such as libsmi, can be found at the TU Braunschweig at the URL http://www.ibr.cs.tu-bs.de/projects/nm/. libsmi The home page of the libsmi library can be found at the URL http://www.ibr.cs.tu-bs.de/projects/libsmi/. GxSNMP is a network management application for the GNOME project. The home page of GxSNMP can be found at the URL http://www.gxsnmp.org. http://www.snmplink.org/ This site provides links and information about SNMP/MIB etc. It facilitates a good list of SNMP and network management related tools. MRTG (Multi Router Traﬃc Grapher) is a tool to monitor the traﬃc load on network links. MRTG generates HTML pages containing graphical images which provide a live visual representation of this traﬃc. The home page of MRTG (Multi Router Traﬃc Grapher) can be found at the URL http://ee-staﬀ.ethz.ch/ oetiker/webtools/mrtg/mrtg.html. RRDTool is a system to store and display time-series data such as network bandwidth utilization. It stores the data in a very compact way that will not expand over time, and it presents useful graphs by processing the data to enforce a certain data density. It can be used either via simple wrapper scripts (from shell or Perl) or via frontends that poll network devices and put a friendly user interface on it. If you know MRTG, you can think of RRDtool as a reimplementation of MRTGs graphing and logging features. Magnitudes faster and more ﬂexible than you ever thought possible The home page of RRDTool can be found at the URL http://www.rrdtool.org/. Cricket is a very ﬂexible system for monitoring trends in time-series data. Cricket was expressly developed to help network managers visualize and understand the traﬃc on their networks. It has two components, a collector and a grapher. The collector runs periodically from cron and stores data into a data structure managed by RRDTool. Later, when you want to check on the data you have collected, you can use a web-based interface to view graphs of the data.

2

Concept:

November 24, 2002

9

Introduction

Research Resources

Cricket reads a set of conﬁguration ﬁles called a conﬁg tree. The conﬁg tree expresses everything Cricket needs to know about the types of data to be collected, how to get it, and from which targets it should collect data. The conﬁg tree is designed to minimize redundant information, making it compact and easy to manage, and preventing silly mistakes from occurring due to copy-and-paste errors. The home page of Cricket can be found at the URL http://cricket.sourceforge.net/. OpenNMS is an open-source project dedicated to the creation of an enterprise grade network management platform. The home page of OpenNMS can be found at the URL http://www.opennms.org/. Zebra is free software (distributed under GNU Generic Public License) that manages TCP/IP based routing protocols. The Zebra home page can be found at the URL http://www.zebra.org/. The MRT project is researching routing software architectures, protocols and tools. The MRT (Multithreaded Routing) toolkit has been used to build a wide variety of tools, ranging from production Internet and 6bone routing daemons to BGP fault-injection and traﬃc generation test packages. MRT software is in active use providing stress testing of commercial routers, collecting and analyzing Internet routing traﬃc for researchers, and serving as routing software connecting networks to the Internet and the 6Bone. MRT is no longer actively developed. The MRT home page can be found at the URL http://merit.edu/mrt/. GateD routing software is no longer available to the public. See http://www.gated.org for more details. Nessus is a free, powerful, up-to-date and easy to use remote security scanner. A security scanner is a software which will audit remotely a given network and determine whether bad guys may break into it, or misuse it in some way. The Nessus home page can be found at the URL http://www.nessus.org/. Nmap (Network Mapper) is an open source utility for network exploration or security auditing. It was designed to rapidly scan large networks, although it works ﬁne against single hosts. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services they are oﬀering, what operating system they are running, what type of packet ﬁlters/ﬁrewalls are in use, and dozens of other characteristics. Nmap runs on most types of computers, and both console and graphical versions are available. Nmap is free software, available with full source code under the terms of the GNU GPL. The Nmap home page can be found at the URL http://www.insecure.org/nmap/. ntop is a network traﬃc probe that shows the network usage, similar to what the popular top Unix command does. ntop is based on libpcap and it has been written in a portable way in order to virtually run on every Unix platform and on Win32 as well. ntop comes with two applications: The ”classical” ntop that sports an embedded web server, and intop (interactive ntop) which is basically a network shell based on the ntop engine. The ntop home page can be found at http://www.ntop.org/. NTP SNI PC

3

Concept:

November 24, 2002

10

Introduction

Research Resources

Edimax (http://www.edimax.com/) manufactures the PS-1000A+ print server. http://www.netbsd.org/Ports/alpha/ The NetBSD/alpha site provides a lot of good information on DEC Alpha machines. Chris Demetriou’s Alpha documentation reference list discusses available DEC Alpha documentation. Very good! http://ftp.digital.com/pub/DEC/Alpha/ﬁrmware/ This site provides Alpha systems ﬁrmware updates. ftp://gatekeeper.dec.com/pub/ This is the old public domain software site of DEC. Has still some good (old) stuﬀ on it. http://www.compaq.com/alphaserver/workstations/retired/index.html The site provides information, such as user guides or system speciﬁcation, regarding retired Alpha workstations. Will probably not stay around for long now that HP owns Compaq/DEC. http://www.netbsd.org/Ports/sgimips/faq.html The NetBSD/sgimips site provides a lot of information regarding NetBSD on SGI machines. http://futuretech.mirror.vuurwerk.net/sgi.html This site provides a lot of information regarding SGI and Irix, including a network installation guide for Irix. http://www.reputable.com/indytech.html This site provides a lot of technical information regarding SGI Indy. http://www.sgi.com/ The web site of SGI.

4

Concept:

November 24, 2002

11

2 Network Architecture
2.1 Topology Overview
The network has two main components: • • Oﬃce or production network Laboratory network

2.2

Design Considerations
The network architecture was designed with the following considerations in mind. • • • • • • • • The oﬃce network shall provide basic services (Internet access, printing) using as little equipment as possible. Services and resources of the oﬃce network, such as Internet access and printing, shall be available to the lab network as well. Services of the oﬃce network must not depend on the lab network or parts of it. Key components of the oﬃce network shall not be used in labs. Reconﬁguration of devices (Internet access router) impacting basic services of the oﬃce network should be avoided. The lab network should be ﬂexible enough to allow setting up a variety of network designs without re-cabling the devices. The lab network should provide conﬁguration modules/procedures that speed up the process of generating conﬁgurations for speciﬁc lab set ups. The lab network should provide test procedures to validate correct operation of the baseline network. The lab network should provide a tool chest for common tasks, such as gathering performance data, in various experiments.

2.3

Design Constraints
• • •
2

Lack of time. Lack of money. 2 Lack of space.

Leading to lack of ﬂash memory in my routers.

5

Concept:

November 24, 2002

12

Frame Relay

Frame Relay

Frame Relay

http://www.brest-lab.net

Network Architecture

Et he rn et
h Et er ne t

c4500M Pagent i386 Edge3

Laboratory Network

$Id: static-lab-2-ofﬁce.grafﬂe,v 1.3 2002/08/12 15:24:36 markus Exp $

Frame Relay

Concept:

Network Architecture

November 24, 2002

Static Lab - Interfacing between Laboratory and Production Network

c1603 Zerberus Internet

Production Network
.1 IP 172.16.254.0/24 .2 iBook Fruchtzwerg Aironet 350 Tigerente .254 DEC Alpha Anchor

Figure 2.1

6
c2501 Core2 c2501 Core1 c2501 Core3

c2501 Edge1

c2503 Edge2

Design Constraints

13

3 Oﬃce Network
3.1 Physical Design
The oﬃce network is designed around a 10 MBit/sec Ethernet hub. This are the main components of the network: Zerberus is a Cisco 1603 router providing Internet connectivity and DHCP service. Radio is a Cisco Access Point 350 providing wireless access to the oﬃce network. Fruchtzwerg is a beautiful Apple iBook used as workstation. Printer is a HP Deskjet 520 printer attached to the Ethernet hub using an Edimax PS-1000A+ print server. Anchor is a DEC Alpha Station 200 4/233 providing services such as DNS, NTP, and SYSLOG. Anchor is basically a lab box and not required for operation of the oﬃce network. Zerberus provides T-Online name server addresses to DHCP clients. DNS service on node Anchor is limited to the lab network. Max is a Xyplex MaxServer 1600 terminal server attached to the Ethernet hub providing access to the console ports of lab devices. It is not required for operation of the oﬃce network. Name Zerberus Anchor Fruchtzwerg Radio Max Printer Vendor Cisco DEC Apple Cisco Xyplex Edimax Model 1603 Alpha Station 200 4/233 iBook AP 350 MaxServer 1600 PS-1000A+ OS IOS 12.2(8)T5 IP+ feature set NetBSD 1.6 MacOS 10.1.5 AP 11.21 ? v9.6 ? none none Memory 10 MB DRAM 16 MB Flash 128 MB 256 MB Hard Disk none 9 GB 18 GB CD-RW NIC Ethernet0 BRI0 tlp0 ep0 en0 en1 fec0 awc0 Ethernet0 16 async 10BaseT

Table 3.1 Oﬃce Network - Inventory

7

Concept:

November 24, 2002

14

Oﬃce Network

Logical Design

3.2

Logical Design
The oﬃce network uses the IPv4 protocol 3 with addresses from the RFC 1918 address space 172.16.254.0/24. Router Zerberus has a default route pointing to its Dialer1 interface. Hosts in the oﬃce network have a default route pointing to the Ethernet interface (172.16.254.1) of router Zerberus. The laboratory network can be connected to an Ethernet port of the oﬃce network. Router Zerberus has static routes (192.168.0.0/16, 172.16.0.0/16, 10.0.0.0/8) to the laboratory network conﬁgured. The next hop interface of the routes is 172.16.254.254. The laboratory router connecting to the production network has this address conﬁgured on its Ethernet interface. It has a default route conﬁgured pointing to 172.16.254.1. This default route can be propagated to other routers in the laboratory network. Host Anchor can be connected to the laboratory network using a free LAN card. Name Zerberus Zerberus Anchor Anchor Printer Max Radio Radio Interface Ethernet0 Dialer1 tlp0 ep0 Ethernet Ethernet fec0 awc0 IP Address 172.16.254.1 negotiated 172.16.254.2 DHCP 172.16.254.3 172.16.254.4 172.16.254.5 172.16.254.6 172.16.254.6 172.16.254.7 172.16.254.8 172.16.254.9 172.16.254.10 172.16.254.11 ... 172.16.254.254 Remark Internet router Internet via T-Online Server Interface to lab network unassigned Print Server Console server for lab routers Access point Ethernet Access point radio unassigned unassigned unassigned unassigned Begin of DHCP pool served by Zerberus Interface to the lab network

Table 3.2 Oﬃce Network - IP Address Assignment

3.3

Network Services

3.3.1 Internet Access
Router Zerberus provides Internet access to the oﬃce and lab network. TODO: NAT, dialer list, etc.

3

Zerberus and Anchor run IPv6-enabled software.

8

Concept:

November 24, 2002

15

Oﬃce Network

Network Services

3.3.2 DHCP
Router Zerberus provides DHCP service for the oﬃce network. It provides a requesting node with IP address, default gateway (172.16.254.1), name server (194.25.2.133, 194.25.2.132, 194.25.2.131, 194.125.2.130), and domain name (brest-lab.net) information.

3.3.3 DNS
Node Anchor provides DNS service to the lab network. Please refer to page 27 for a detailed description of the service implementation.

3.3.4 TFTP
Node Anchor provides TFTP boot service. A boot image for the Xyplex terminal server resides in the directory /tftpboot/xyplex. Boot images for SGI Indy resides in the directory /tftpboot/netbsd. Please refer to page 27 for a detailed description of the service implementation.

3.3.5 Printing
Anchor Node Anchor uses CUPS (http://www.cups.org/) as printing system. Please refer to page 27 for a detailed description of the implementation. Fruchtzwerg Printing to the network attached HP Deskjet is conﬁgured according to ”Balthisars Guide to Non-Supported Mac OS X Printing” (http://www.balthisar.com/printing/).

3.3.6 X11
Anchor Despite the fact that node Anchor is a head-less workstation 4 it does have the X11 system installed. Since it does not have a graphics controller or monitor no fancy X11 server conﬁguration is required. Fruchtzwerg Node Fruchtzwerg has the XDarwin X11 server (http://www.xdarwin.org/) and the OroborOSX window manager (http://wrench.et.ic.ac.uk/adrian/) installed. X11 clients on node Anchor can display using the X11 server hosted on node Fruchtzwerg.

4

”Head-less” means it does not have a graphics controller or monitor attached to it. The machine uses a serial console device.

9

Concept:

November 24, 2002

16

Oﬃce Network

Network Services

Ofﬁce Network - Physical Design
IP: DHCP en0 Apple iBook Fruchtzwerg MacOS X 10.1.5 en1 IP: DHCP

IP: 0.0.0.0/0

Internet T-Online

IP: 172.16.254.6/24 awc0 Cisco AP 350 Radio AP S/W 11.21 fec0 IP: 172.16.254.6/24 HP Deskjet 520 Printer

IP: negotiated Dia1 Cisco 1603 Zerberus IOS-Firewall Eth0 IP: 172.16.254.1/24

Print Server IP: 172.16.254.4/24 8-port Ethernet Hub IP: 172.16.254.5/24 Eth0 Xyplex MaxServer 1600 Max v7.? IP: 172.16.254.254/24

IP: 172.16.254.2/24 tlp0 DEC AS200 Anchor NetBSD-Core ep0

Laboratory Network
IP: 10.0.0.0/8 IP: 172.16.0.0/16 IP: 192.168.0.0/16

http://www.brest-lab.net

$Id: ofﬁce-physical-topology.grafﬂe,v 1.5 2002/10/09 15:54:54 markus Exp $

Figure 3.1

Oﬃce Network - Physical Design

10

Concept:

November 24, 2002

17

Oﬃce Network

Network Services

Ofﬁce Network - Logical Design

Static Route

Internet

0.0.0.0/0
IP negotiated

Zerberus
172.16.254.1

NAT DHCP server

0.0.0.0/0
172.16.254.2

0.0.0.0/0
IP DHCP

Anchor

Ofﬁce Network
IP: 172.16.254.0/24

DHCP Client

Name server

10.0.0.0/8 172.16.0.0/16 192.168.0.0/16

172.16.254.254

Lab Router
Lab IP address

Lab Network
IP: 10.0.0.0/8 IP: 172.16.0.0/16 IP: 192.168.0.0/16

http://www.brest-lab.net

$Id: ofﬁce-logical-design.grafﬂe,v 1.2 2002/08/13 13:26:59 markus Exp $

Figure 3.2

Oﬃce Network - Logical Design

11

Concept:

November 24, 2002

18

4 Lab Network
4.1 Physical Design
The static lab network consists mainly of ﬁve Cisco 2500 series routers. The routers are daisy-chained via their serial interfaces using back-to-back cables. Core routers act as Frame Relay switches thus providing the capability to implement a variety of diﬀerent logical topologies. Per convention interface Serial0 will always provide clocking. A diagram of the physical design can be found on page 22. This are the main components of the static lab network: Core1 is a Cisco 2501 router running IOS-MPLS software. Core2 is a Cisco 2501 router running IOS-MPLS software. Core3 is a Cisco 2501 router running IOS-MPLS software. Core4 is a i386 PC running NetBSD-MPLS software. Edge1 is a Cisco 2501 router running IOS-Edge software. Edge2 is a Cisco 2503 router running IOS-Edge software. Anchor is a DEC Alpha Station 200 running NetBSD-Core software. In basic conﬁguration Anchor serves as IPv4 host. It provides ftp, tftp and syslog services for lab routers. It participates in NTP peering with all lab routers and node Dinghy. Anchor also participates in OSPF routing. Conﬁguration ﬁles for basic operation can be found on page 73. With additional IPv6 conﬁguration Anchor serves as IPv6 hub router. Conﬁguration ﬁles for IPv6 operation can be found on page 78. Dinghy is a SGI Indy running NetBSD-Core software. In basic conﬁguration Dinghy serves as IPv4 host. It provides ftp, tftp and syslog services for lab routers. It participates in NTP peering with all lab routers and NTP server Anchor. Dinghy also participates in OSPF routing. Conﬁguration ﬁles for basic operation can be found on page 74. With additional IPv6 conﬁguration Dinghy serves as IPv6 hub router. Conﬁguration ﬁles for IPv6 operation can be found on page 84. Pagent is a Cisco 4500m router running IOS-Pagent.

12

Concept:

November 24, 2002

19

Lab Network

Physical Design

4.1.1 Software
The following software versions are used in the lab.

IOS-MPLS
Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-P-L), Experimental Version 12.0(20011017:155337) [rraszukNew_reorg_oct17 109] Copyright (c) 1986-2001 by cisco Systems, Inc. Compiled Sat 20-Oct-01 04:12 by rraszuk

NetBSD-MPLS
NetBSD 1.5.2/i386 AYAME 0.3 Zebra-AYAME 0.93b

IOS-Edge
Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.2(11)T, TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Thu 01-Aug-02 18:38 by ccai RELEASE SOFTWARE (fc1)

NetBSD-Core
NetBSD 1.6/alpha NetBSD 1.6/sgimips Zebra 0.93b GateD 3.6/public

IOS-Pagent
Cisco Internetwork Operating System Software IOS (tm) 4500 Software (C4500-TSPGEN-M), Experimental Version 12.2(20020815:031451) [nkalyanbuild 126] Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Thu 15-Aug-02 03:22 by nkalyan Pagent version 3.7.0

Conﬁguration Files
Conﬁguration ﬁles are subject to version control. The ﬁles are stored in RCS.

13

Concept:

November 24, 2002

20

Lab Network

Physical Design

In case of a Cisco router the following convention will be used. Revision information will be put into the description of a routers loopback interface. This way version information can be retrieved easily from a running router. Since a routers conﬁguration can be composed from multiple modules 5 a number of loopback interfaces are used. The following mapping will be used for the static lab: • • • • • • • Loopback 0 = Version number of a routers basic IPv4 conﬁguration Loopback 1 = Version number of module for common conﬁguration commands Loopback 2 = Version number of module RADIUS authentication Loopback 3 = Version number of module TACACS authentication Loopback 10 = Version number of a routers basic MPLS conﬁguration Loopback 11 = Version number of a routers MPLS VPN conﬁguration Loopback 20 = Version number of a routers basic IPv6 conﬁguration

On a running router version information can be retrieved by looking at the conﬁguration ﬁle: Core1#write terminal <snip> interface Loopback0 description $Id: core1-confg,v 1.3 2002/10/19 15:49:11 markus Exp $ ip address 172.16.0.1 255.255.255.255 no ip directed-broadcast ! interface Loopback1 description $Id: common-confg,v 1.2 2002/10/25 14:15:13 markus Exp $ no ip address no ip directed-broadcast ! interface Loopback10 description $Id: core1-mpls-confg,v 1.3 2002/10/24 14:26:21 markus Exp $ no ip address no ip directed-broadcast <snip> Another way of retrieving version information is looking at the interface description: Core3#show interfaces loopback 0 description Interface Status Protocol Lo0 up up Core3#show interfaces loopback 1 description Interface Status Protocol Lo1 up up Core3#show interfaces loopback 10 description Interface Status Protocol Lo10 up up Core3#
5

Description $Id: core3-confg,v 1.3 2002/10/12 14:30:02 markus Exp

Description $Id: common-confg,v 1.2 2002/10/25 14:15:13 markus Exp

Description $Id: core3-mpls-confg,v 1.3 2002/10/24 14:26:34 markus

Some modules are generic while others are speciﬁcally for a router.

14

Concept:

November 24, 2002

21

Lab Network

Physical Design

4.1.2 Hardware

Name Core1

Vendor Cisco

Model 2501

OS IOS-MPLS

Memory 16 MB DRAM 8 MB Flash 16 MB DRAM 8 MB Flash 16 MB DRAM 8 MB Flash 48 MB DRAM

Hard Disk none

NIC Ethernet0 Serial0 Serial1 Ethernet0 Serial0 Serial1 Ethernet0 Serial0 Serial1 rtk0 rtk1 ne2 Ethernet0 Serial0 Serial1 Ethernet0 Serial0 Serial1 BRI0 Ethernet0 Ethernet1 tlp0 ep0 sq0 Ethernet0 Ethernet1 Serial0 Serial1 BRI0 BRI1 BRI2 BRI3

Core2

Cisco

2501

IOS-MPLS

none

Core3

Cisco

2501

IOS-MPLS

none

Core4

SNI

Pro C5

NetBSD-MPLS

4 GB 4 GB none

Edge1

Cisco

2501

IOS-Edge

16 MB DRAM 16 MB Flash 16 MB DRAM 16 MB Flash

Edge2

Cisco

2503

IOS-Edge

none

Cisco Anchor Dinghy Pagent DEC SGI Cisco

Pix 501 Alpha Station 200 Indy 4500m

PIX 6.1(2) NetBSD-Core NetBSD-Core IOS-Pagent

16 MB DRAM 128 MB DRAM 64 MB DRAM 32 MB DRAM 16 MB Flash 8 MB Bootﬂash

none 9 GB CD-ROM 2 GB none

Table 4.1 Lab Network - Inventory

15

Concept:

November 24, 2002

22

Lab Network

Logical Design

4.2

Logical Design
The static laboratory network uses IPv4 addresses from the RFC 1918 address space. The static lab uses OSPF as routing protocol for IPv4. All interfaces are in area 0 except the Ethernet interfaces of edge routers, which are each in its own area.

Zebra OSPFd
Zebra was compiled with the options --enable-snmp, --enable-tcp-zebra, --enable-nssa, -enable-opaque-lsa, --enable-ospf-te, and --enable-multipath=4. Please note that Zebras OSPF daemon on a NetBSD system requires static routes for the multicast addresses 224.0.0.5 and 224.0.0.6 in order to establish adjacency with peer routers.

16

Concept:

November 24, 2002

23

Lab Network

Logical Design

Name Core1

Interface Loopback0 Serial0.100 Serial1.100 Serial0.200 Ethernet0 Loopback0 Serial1.100 Serial1.200 Serial0.100 Serial1.300 Ethernet0 Loopback0 Serial0.100 Serial0.200 Serial1.100 Ethernet0 rtk0 rtk1 ne2 Loopback0 Serial1.100 Serial1.200 Ethernet0 Loopback0 Serial0.300 Serial0.100 Ethernet0 Loopback0 Ethernet0 Ethernet1

IP Address 172.16.0.1/32 ip unnumbered loopback0 ip unnumbered loopback0 ip unnumbered loopback0 172.16.255.1/24 172.16.0.2/32 ip unnumbered loopback0 ip unnumbered loopback0 ip unnumbered loopback0 ip unnumbered loopback0 172.16.254.254/24 172.16.0.3/32 ip unnumbered loopback0 ip unnumbered loopback0 ip unnumbered loopback0 172.16.3.1/30 172.16.3.2/30 172.16.3.6/30 10.3.1.1/24 172.16.0.11/32 ip unnumbered loopback0 ip unnumbered loopback0 10.1.1.1/24 172.16.0.12/32 ip unnumbered loopback0 ip unnumbered loopback0 10.2.1.1/24 172.16.255.254/24 10.3.1.254/24

Remark PVC to Core2 (Trunk) PVC to Core3 (Trunk) PVC to Edge1 (Access) Trunk link to Core4, Dinghy PVC PVC PVC PVC to to to to Core1 (Trunk) Core3 (Trunk) Edge1 (Access) Edge2 (Access)

Core2

Oﬃce LAN, Trunk link to Anchor PVC to Core1 (Trunk) PVC to Core2 (Trunk) PVC to Edge2 (Access) Trunk link to Core4 Access link to Core2 Access link to Core3 Core4 LAN PVC to Core2 (Access) PVC to Core1 (Access) Edge1 LAN PVC to Core2 (Access) PVC to Core3 (Access) Edge2 LAN Core1, Core4, Dinghy Core4

Core3

Core4

Edge1

Edge2

Pagent

Table 4.2 Lab Network - IP Address Assignment

17

Concept:

November 24, 2002

24

Lab Network

Logical Design

4.2.1 MPLS
Unsupported MPLS images on c2500; AYAME code on NetBSD box; TODO: conﬁg principle and examples

18

Concept:

November 24, 2002

25

Lab Network

Logical Design

4.2.2 IPv6
The IPv6 network shall provide robust IPv6 transport service for whole networks. Solutions targeting individual host systems or infrequently communicating systems, such as tunnel broker or automatic tunnels, are not being implemented.

Topology
The IPv6 overlay network uses a partly-meshed, hierarchical design. Hierarchical network design separates a topology into discrete layers with each layer focusing on a speciﬁc set of functions. Typical layers found in hierarchical networks are core layer, distribution layer, and access layer. The lab networks uses a two layer hierarchy. All edge routers are connected to two IPv6 core routers (Anchor and Dinghy). Figure 4.3 on page 24 shows an overview of the network.

Physical Design
The IPv6 test network uses Cisco routers and routers based on NetBSD and Zebra software. Today Cisco has probably the most comprehensive IPv6 solution. Since Cisco routers are widely deployed it can be assumed that they will play a dominant role in future IPv6 networks as well. Zebra (http://www.zebra.org) is the only routing software that is freely available today and actively developed. GateD routing software (http://www.gated.org) is no longer available to the public and it does not support IPv6. MRT routing software (http://www.merit.edu/mrt) does support IPv6 but is no longer actively developed. Therefore Zebra routing software is used in the IPv6 test network. NetBSD (http://www.netbsd.org) was chosen as platform because it includes the IPv6 implementation of the KAME project (http://www.kame.net) in its default distribution. A mixture of both tunneling 6 and IPv6-enabled data links are used to create the network. The following routers are used in the IPv6 network: • Core routers: − Anchor − Dinghy • Edge routers: − Edge1 − Edge2 − Core4 (IPv4 core router)

Addressing
The laboratory network uses IPv6 addresses from the “site local” address space. Site local addresses are functionally equivalent to RFC 1918 addresses in the IPv4 world.

6

Tunneling is encapsulation of IPv6 packets in IPv4 packets so that they can be transported over IPv4-only networks.

19

Concept:

November 24, 2002

26

Lab Network

Logical Design

Tunnels are conﬁgured with “link local” addresses. Global IPv6 addresses are not conﬁgured on pointto-point links because we want to minimize the conﬁguration. 7 On Cisco routers tunnel interfaces are conﬁgured with ip unnumbered loopback 0 to allow IPv6 ping from a router.

Routing
A dynamic routing protocol is used to propagate IPv6 routing information. An architecture based entirely on static routing is only appropriate for small networks that change infrequently. However, static routes are used for special cases, such as loopback interfaces of next-hop routers, or stub networks connected via a single link. Cisco IOS software supports static routing, RIP, ISIS and multi-protocol BGP (MP-BGP) for IPv6 routing. Zebra routing software supports static routing, RIP, OSPF and multi-protocol BGP for IPv6 routing. 8 RIP is the only IGP (Interior Gateway Protocol) Cisco IOS and Zebra routing software have in common. Since RIP is not suitable for use in wide area networks the only dynamic IPv6 routing protocol available is multi-protocol BGP. Therefore the IPv6 network uses multi-protocol BGP for propagation of IPv6 routing information. Private AS 65000 is used for iBGP. Multi-protocol BGP routes will be redistributed into RIP at the edge and advertised to local area networks by RIP. IPv6 routes are not learned via RIP and RIP derived routes are not redistributed into MP-BGP. IPv6 routers in the lab use internal BGP (iBGP) to exchange routing information. iBGP requires a full-mesh between all iBGP speakers, which limits network scalability (n 2 problem). A solution is using route reﬂectors for iBGP peering. Route reﬂectors can be either in the forwarding path or dedicated machines. At least two route reﬂectors are recommended for redundancy purposes. Router Anchor and Dinghy are used as route reﬂectors for iBGP. All BGP-speaking edge routers (Edge1, Edge2) peer with both route reﬂectors. Since IPv6 edge router Core4 shares an Ethernet with router Dinghy, RIPv6 is used between them instead of iBGP. Please note that Dinghy does not learn IPv6 networks oﬀered by Core4 via RIP. Static routes towards this networks are deﬁned on Dinghy and redistributed into BGP. That way the other routers (Anchor, Edge1, Edge2) learn the networks attached to Core4. On Dinghy BGP derived routes are redistributed into RIP and thus made available to router Core4. Figure 4.4 on page 25 shows an overview of the routing architecture. Please bear in mind the following: • • •
7

Use redistribute static on route reﬂectors to propagate next-hop address of directly attached edge router to other edge routers. Do not use peer groups on route reﬂectors for route reﬂector clients. 9 Use either distance or distribute-list in to prevent learning of routes via RIP.

8

9

Remember that the lab shall provide a quick way to build speciﬁc test environments. Adding IPv6 addresses to unnumbered links is easier then removing old addresses prior to adding new ones. The same reason dictates use of ip unnumbered on IPv4 point-to-point links. There is an ISISd project (http://isisd.sourceforge.net/) which has been started in May 2001. The project aims to implement ISIS on the Zebra platform. Currently ISISd is not integrated in Zebra, it is available as patch against Zebra source code. Stolen from Halabis BGP book: “Route reﬂectors can be used in conjunction with peer groups only when the clients of a route reﬂector are fully meshed. The reasoning is as follows: in a normal situation, a router A that learns a preﬁx from router B will send a WITHDRAW message back to that router to poison that route. In other words, router A is telling B that this preﬁx is not reachable via A. This is to prevent a situation where A claims that a preﬁx is reachable via B,

20

Concept:

November 24, 2002

27

Lab Network

Logical Design

Host Access
IPv6 end systems can be conﬁgured either manually or automatically. A major beneﬁt of IPv6 is the availability of address auto-conﬁguration for host systems. Automatic host conﬁguration for IPv6 can be done in two ways, using either stateless auto-conﬁguration or DHCPv6. Stateless auto-conﬁguration is used in the IPv6 test network because NetBSD does not support DHCPv6. Stateless auto-conﬁguration requires that a router on a connected network emits periodically ICMPv6 “router advertisement” messages. These messages contain information such as IPv6 sub-network preﬁx and default router. An end system listens to router advertisement messages to get its global IPv6 address and the default router. Hosts can also trigger router advertisements by sending an ICPMv6 “router solicitation” message. Stateless auto-conﬁguration is used in the IPv6 lab network.

and B claims it is reachable via A. In a peer group the same UPDATE or WITHDRAW message is sent to all members of the group. In a peer group/route reﬂector situation, a route reﬂector that has learned a preﬁx from one of its clients and is trying to poison that route will end up withdrawing that preﬁx from all the other clients. Because the clients are not talking to each other via BGP, that preﬁx will be lost.”

21

Concept:

November 24, 2002

28

Lab Network

Logical Design

Static Laboratory Network - Physical Design
DLCI

Ser0 c2501 Edge1
16MB Flash 16 MB DRAM

Frame Relay PVC

Eth0

DLCI

400

100

Ser1 Phy: DTE Phy: DCE FR: DTE FR: DCE tlp0
back-to-back cable

100

Ser0 Eth0 c2501 Core2
8MB Flash 16MB DRAM

128MB DRAM 9GB HDD

300

200

100

Ser1 Phy: DTE Phy: DCE FR: NNI FR: NNI SGI Indy Dinghy
64MB DRAM 2GB HDD

back-to-back cable

400

100

Ser0 Eth0 c2501 Core1
8MB Flash 16MB DRAM

100

Ser1 Phy: DTE Phy: DCE FR: NNI
back-to-back cable

48MB DRAM 4GB HDD

FR: NNI

200

100

Ser0 Eth0 c2501 Core3
8MB Flash 16MB DRAM

100

Ser1 Phy: DTE Phy: DCE FR: DCE FR: DTE Eth1 c4500m Pagent
32MB DRAM 16MB Flash

back-to-back cable

300
http://www.brest-lab.net

100
Eth0

Ser0 c2503 Edge2
16MB Flash 16MB DRAM

Ser1

Eth0

$Id: static-lab-physical-design.grafﬂe,v 1.7 2002/10/19 15:53:39 markus Exp $

Figure 4.1

Lab Network - Physical Design

22

Concept:

November 24, 2002

ne2

i386 Core4

ep0

DEC AS200 Anchor

sq0 rtk1 rtk0

29

IOS-MPLS s1.300 s1.100

s1.200

http://www.brest-lab.net

Concept:

Lab Network

Static Laboratory Network - IPv4 Logical Design
IPv4: 172.16.255.1/24 IPv4: 172.16.0.1/32
loop0 <int> c2501 SGI Indy s0.400 <int>

IPv4: 172.16.255.2/24
Area 10.1.1.0 Area 10.2.1.0 Area 10.3.1.0
<int>

November 24, 2002

IPv4: 172.16.255.4/24

<int>

Area 0

eth0
i386

sq0

rtk1

Core1
IOS-MPLS s1.100 NetBSD-Core NetBSD-MPLS

Dinghy Core4

IPv4: 172.16.0.11/32
s0.100 s1.400

loop0

ne2

rtk0

Figure 4.2
IPv4: 172.16.3.2/30 IPv4: 10.3.1.1/24 IPv4: 172.16.0.2/32
s1.100 s1.100 c2501 s0.200 c2501

c2501

Edge1

IOS-Edge

IPv4: 172.16.3.1/30
s0.100

eth0 loop0 eth0

Lab Network - Logical Design

23
s0.100

IPv4: 10.1.1.1/24 Core2 Core3
IOS-MPLS

eth0

loop0

IPv4: 172.16.254.2/24 IPv4: 172.16.254.254/24
tlp0
s0.300 c2503 s0.100

IPv4: 172.16.0.3/32

DEC AS200

Anchor

NetBSD-Core

Frame Relay PVC use "ip unnumbered"

Edge2
IOS-Edge 64kbps Frame Relay

loop0

eth0

IPv4: 172.16.0.12/32 IPv4: 10.2.1.1/24
$Id: static-lab-logical-design.grafﬂe,v 1.9 2002/10/19 15:59:33 markus Exp $

256kbps Frame Relay 10mbps Ethernet

Logical Design

30

Lab Network

gif0

tlp0

gif3

IPv6: fefe:bb:d::1/126
sq0

gif2

rtk0

s1.100

s0.100

loop0

s0.200

ne2

loop0
s1.100 s1.200 s0.100

eth0 loop0

IPv6: fefe:e3::1/64

s0.200

eth0

Core2
s1.300 s1.100

Core3

s0.100

tun1

eth0

loop0

eth0

loop0

http://www.brest-lab.net

Link local addresses are used on tunnel interfaces. IPv6: fefe::e1/128 IPv6: fefe:e1::1/64

IPv6: fefe::e2/128 IPv6: fefe:e2::1/64

$Id: static-lab-logical-design-inet6.grafﬂe,v 1.10 2002/10/24 13:16:41 markus Exp $

tun1

Lab Network - IPv6 Logical Design

s1.100

s1.200

s0.300

s0.100

tun0

tun0

Edge1

Edge2

lo0

Concept:

Static Laboratory Network - IPv6 Logical Design
IPv6: fefe::a/128
lo0 gif0

<int>

IPv4 only IPv6: fefe::d/128 IPv6: fefe:bb::1/126
lo0

November 24, 2002

<int> gif1

IPv4 and IPv6 IPv6: fefe:bb::2/126 Dinghy
gif1

<int>

IPv6 only Anchor
gif2

IPv6: fefe:d::2/64 IPv6: fefe:a::1/64
eth0 rtk1

Figure 4.3
IPv6: fefe:d::1/64 Core1 Core4 IPv6: fefe::e3/128

24

Logical Design

31

Route Reﬂector gif1 gif2 gif1 gif2 sq0

gif0

http://www.brest-lab.net

Concept:

Lab Network

Static Laboratory Network - IPv6 Routing
IPv6: fefe::a/128
lo0 lo0

November 24, 2002

IPv6: fefe::d/128

tlp0 redistribute

gif0

IPv6: fefe:a::1/64
Route Reﬂector

Anchor AS 65000 is used for iBGP.

iBGP
Dinghy

Link local addresses are used on tunnel interfaces.

Figure 4.4
IPv6: fefe:d::1/64

iBGP iBGP RIPv6

iBGP

Lab Network - IPv6 Routing

25
tun0 redistribute RR Client loop0 eth0 tun1 redistribute

IPv6: fefe:d::2/64
rtk1

tun0

tun1

Edge1

Edge2

RR Client

Core4
lo0 ne2

loop0

eth0

IPv6: fefe::e1/128 IPv6: fefe:e1::1/64

IPv6: fefe::e2/128 IPv6: fefe:e2::1/64

IPv6: fefe::e3/128 IPv6: fefe:e3::1/64

stateless auto-conﬁg

stateless auto-conﬁg

stateless auto-conﬁg

stateless auto-conﬁg RIPv6

Host

Host

Host

iBGP $Id: static-lab-logical-design-inet6-routing.grafﬂe,v 1.6 2002/10/21 09:31:31 markus Exp $

Logical Design

32

Lab Network

IOS-MPLS s1.300

s1.200

http://www.brest-lab.net

Concept:

Static Laboratory Network - MPLS Logical Design
IPv4: 172.16.255.1/24 IPv4: 172.16.0.1/32
loop0 c2501 SGI Indy i386 <int>

IPv4: 172.16.255.2/24
IPv4

November 24, 2002

IPv4: 172.16.255.4/24

<int>

MPLS

eth0

sq0

rtk1

s0.200

Core1
IOS-MPLS s1.100 NetBSD-Core NetBSD-MPLS

Dinghy Core4

IPv4: 172.16.0.11/32
s0.100 s1.200

Figure 4.5
ne2 rtk0

loop0
c2501

IPv4: 172.16.3.2/30 Edge1
IOS-Edge

IPv4: 10.3.1.1/24 IPv4: 172.16.0.2/32 IPv4: 172.16.3.1/30
s0.100 c2501

eth0
s1.100 s1.100 c2501 s0.200

loop0

eth0

Lab Network - MPLS Logical Design

26
s0.100

IPv4: 10.1.1.1/24 Core2

Core3
IOS-MPLS

eth0

s1.100

loop0

IPv4: 172.16.254.2/24 IPv4: 172.16.254.254/24
tlp0
DEC AS200 s0.300 c2503 s0.100

IPv4: 172.16.0.3/32

Anchor
NetBSD-Core

Frame Relay PVC use "ip unnumbered"

Edge2
IOS-Edge 64kbps Frame Relay

loop0

eth0

IPv4: 172.16.0.12/32 IPv4: 10.2.1.1/24
$Id: static-lab-logical-design-mpls.grafﬂe,v 1.1 2002/10/11 21:00:02 markus Exp $

256kbps Frame Relay 10mbps Ethernet

Logical Design

33

5 Network Services
5.1 DNS
Hosts Anchor an Dinghy provide name service for IPv4 and IPv6 systems in the lab network. Both machines use DJBDNS instead of BIND. An conﬁguration example can be found in on page 153ﬀ.

5.2 FTP and TFTP
TBD

5.3

Logging
TBD

5.4

NTP
Host Anchor play the role of the labs NTP servers using. All lab routers peer with each other and hosts Dinghy and Anchor. Conﬁguration commands can be found pages 54 (router), 73 (Anchor), and 74 (Dinghy).

5.5

Printing
TBD

5.6

netdb (http://www.net.cmu.edu/netreg/)
TBD

5.7

VideoLAN (www.videolan.org)
TBD -¿ Probably interesting for multicast labs.

5.8

Kismet (www.kismetwireless.net)

27

Concept:

November 24, 2002

34

Network Services

Network Veriﬁcation Toolkit

TBD

5.9

Network Veriﬁcation Toolkit
The following sections describe tools that can be used to verify correct operation of lab networks.

5.9.1 Some Tools that come with IOS

Service Assurance Agent
Service Assurance Agent (SAA) is a new name for the Response Time Reporter (RTR) feature that was introduced in Cisco IOS release 11.2. The feature allows monitoring network performance by measuring key Service Level Agreement (SLA) metrics such as response time, network resources, availability, jitter, connect time, packet loss and application performance. The following example shows an implementation of ping probes on a router. No conﬁguration is required on the remote routers. LER12#wr t Building configuration... <snip> rtr 11 type echo protocol ipIcmpEcho 172.16.0.11 rtr schedule 11 life forever start-time now ! rtr 12 type echo protocol ipIcmpEcho 172.16.0.12 rtr schedule 12 life forever start-time now ! rtr 13 type echo protocol ipIcmpEcho 172.16.0.13 rtr schedule 13 life forever start-time now ! rtr 14 type echo protocol ipIcmpEcho 172.16.0.14 rtr schedule 14 life forever start-time now <snip> The following output shows maximum (TMax) and minimum (TMin) round-trip times. LER12#sho rtr distributions-statistics Captured Statistics Entry = Entry Number StartT = Start Time of Entry (hundredths of seconds) Pth = Path Index

28

Concept: November 24, 2002

35

Network Services

Network Veriﬁcation Toolkit

Hop Dst Comps OvrTh SumCmp SumCmp2L SumCmp2H TMax TMin Entry 11 12 13 14

= = = = = = = = =

Hop in Path Index Time Distribution Index Operations Completed Operations Completed Over Thresholds Sum of Completion Times (milliseconds) Sum of Completion Times Squared Low 32 Bits (milliseconds) Sum of Completion Times Squared High 32 Bits (milliseconds) Completion Time Maximum (milliseconds) Completion Time Minimum (milliseconds) Pth 1 1 1 1 Hop 1 1 1 1 Dst 1 1 1 1 Comps 60 61 60 61 OvrTh 0 0 0 0 SumCmp 668 1268 603 719 SumCmp2L 8580 28944 8523 11559 SumCmp2H 0 0 0 0 TMax 24 52 32 36 TMin 1 8 1 1

StartT 2822284 2819228 2819415 2819590

LER12# Conﬁguring a jitter probe is a bit more complex. A probe must be conﬁgured locally and a responder must be conﬁgured on the remote router. Conﬁguration of the jitter probe on router A. rtr 11 type jitter dest-ipaddr 172.16.0.11 dest-port 2011 num-packets 20 interval 300 rtr schedule 11 life forever start-time now Conﬁguration of the responder on router B. rtr responder

Traﬃc Matrix Statistics
Traﬃc matrix statistics (TMS) is an IOS feature that enables capturing and analyzing traﬃc data entering a backbone. By enabling a backbone router to gather traﬃc matrix statistics, you can determine the amount of traﬃc that enters the backbone from sites outside of the backbone. You can also determine the amount of traﬃc that is generated within the backbone. The traﬃc matrix statistics help you optimize and manage traﬃc across the backbone. You can determine the amount of traﬃc the backbone handles by enabling a backbone router to track the number of packets and bytes that travel through it. You can separate the traﬃc into the categories “internal” (within scope of interest) and “external” (outside scope of interest). You separate the traﬃc by designating incoming interfaces on the backbone router as internal or external. TMS data is counted during packet forwarding by CEF nonrecursive accounting, which is conﬁgured as described below. • • • Enable CEF on the router. Enable non-recursive accounting on the router. Set incoming interfaces to collect internal or external traﬃc. By default all interfaces are set as internal.

29

Concept: November 24, 2002

36

Network Services

Network Veriﬁcation Toolkit

A minimum TMS conﬁguration looks like this: ip cef ip cef accounting non-recursive ! interface Multilink1 ip cef accounting non-recursive external You can access traﬃc matrix data either by using CLI or by reading the virtual ﬁles residing on the router. LER12#show ip cef 10.25.0.0 10.25.0.0/24, version 71, per-destination sharing 0 packets, 0 bytes tag information set local tag: 39 via 172.16.0.3, Serial3/0, 0 dependencies next hop 172.16.0.3, Serial3/0 valid adjacency tag rewrite with Se3/0, point2point, tags imposed: {29} 218016 packets, 153301502 bytes switched through the prefix tmstats: external 0 packets, 0 bytes internal 218016 packets, 153301502 bytes 30 second output rate 46 Kbits/sec LER12# TMS data is stored in two ﬁles, tmstats_ascii (human readable format) and tmstats_binary (binary format). LER12#dir system:/vfiles Directory of system:/vfiles/ 11 9 10 -r--r--r-0 0 0 <no date> <no date> <no date> tmasinfo tmstats_ascii tmstats_binary

No space information available LER12#more system:/vfiles/tmstats_ascii VERSION 1|ADDR 172.16.0.12|AGGREGATION TrafficMatrix.ascii|SYSUPTIME 39659|routerUTC 3246068423|NTP s p|172.16.1.23/32|9384|418|29163|0|0 p|172.16.254.0/24|9384|0|0|0|0 p|172.16.254.11/32|9384|0|0|0|0 p|172.16.254.100/32|9384|5040|254024|0|0 <snip> You can export TMS data from a router using the copy command. LER12#copy system:/vfiles/tmstats_ascii ? ftp: Copy to ftp: file system null: Copy to null: file system nvram: Copy to nvram: file system rcp: Copy to rcp: file system

30

Concept: November 24, 2002

37

Network Services

Network Veriﬁcation Toolkit

running-config startup-config system: tftp:

Update (merge with) current system configuration Copy to startup configuration Copy to system: file system Copy to tftp: file system

31

Concept:

November 24, 2002

38

Network Services

Network Veriﬁcation Toolkit

5.9.2 Pagent
TODO: LNE templates for OSPF, BGP, and TGN Pagent is a set of test tools, based on the Cisco IOS (Internetwork Operating System), and developed within Cisco. The test tools are included in special IOS Pagent images. The primary function of the Pagent tool set is to provide cost eﬀective test tools to the Cisco community. Since the tools are based on production hardware and the IOS operating system, the tools are not able to test the datalink level. They cannot aﬀect frame checksums, preambles, inter frame gap times, or inject hardware failures. There are limitations to the rates that Pagent tools can transmit and receive packets. Due to the processing power of the main CPU, not all IOS based devices are able to transmit packets at full media rates. The Pagent programs are best used for testing layer 3 protocols and above. That is, emulating routing protocols, multicast, TCP sessions, HTTP sessions. Pagent images have a security scheme to prevent illegal distribution outside Cisco. When an router is loaded with a Pagent image for the ﬁrst time, it presents a machine Id that must be converted to a license key. Once the license key is entered in the router, it is saved in the conﬁguration so it is not required on subsequent downloads. Pagent tools include: • TGN (Traﬃc Generator) is used to deﬁne and send packets on any combination of supported interfaces on a router. The program has predeﬁned templates to support the deﬁnition of speciﬁc packet types. Packet lengths and the data in any header ﬁeld can be set to constant, incrementing or random values. Packet deﬁnitions can be imported from the PKTS program capture buﬀer. PKTS (Packet Count and Capture) can capture and display incoming and/or outgoing packets from any combination of interfaces on a router. It can fast-count packets, that is, it can count and discard packets at higher rates than IOS counters can support. PKTS supports the creation of ﬁlters that allow selective counting, capture or display Template Compiler provides a convenient high-level language for deﬁning packet formats. It adds new packet deﬁnitions to the Pagent tool set (TGN and PKTS) at run time and allows TGN traﬃc streams and PKTS ﬁlters to be deﬁned using the new formats. It allows the deﬁnition of multiple display methods that can be used to decode and display packets. Router Veriﬁed Traﬃc (RVT) and Control Veriﬁed Traﬃc (CVT) are used together to test bridges and routers. CVT can automatically create numerous traﬃc streams between many Pagent router interfaces, for many diﬀerent LAN media and network protocols. RVT can create modest levels of veriﬁed traﬃc where every packet sent through the test network is validated for correct sequence, data integrity, and length. RVT can also create fast-unveriﬁed traﬃc. PMOD (Passthru Modify) allows a Pagent router to be inserted into a test network so test traﬃc passes through the router and then allows the traﬃc packets to be modiﬁed. Depending on PMOD ﬁlters and conﬁgurations, the tool can selectively drop, alter, delay or timestamp packets. It also allows test packets to act as triggers and can recalculate test packet IP, TCP and UDP checksums. TCP Session Emulator (TCPSE) is a tool for generating TCP traﬃc. The tool provides conﬁgurable features that enable a user to emulate various TCP application dialogs between a TCP client and a

•

•

•

•

•

32

Concept:

November 24, 2002

39

Network Services

Network Veriﬁcation Toolkit

TCP server. It emulates multiple hosts establishing thousands of TCP connections. All these TCP sessions are short-lived, which is very typical for web or email traﬃc. • HTTP Session Emulator (HTTPSE) is a tool for generating HTTP traﬃc. It emulates multiple HTTP clients establishing HTTP connections to a HTTP server. It generates all kinds of HTTP traﬃc, including all kinds of HTTP requests and HTTP responses. FTP Session Emulator (FTPSE) is a TCP application for transferring ﬁles. The FTPSE Client Emulator generates real FTP traﬃc and emulates FTP client sessions, which must talk to a real FTP server. Currently FTPSE only supports the client side in passive mode. Large Network Emulators (LNE) is comprised of six programs to support six routing protocols: BGP, OSPF, ISIS, EIGPR, IGRP and RIP. LNE is used to emulate routers that advertise large router networks. It can emulate hundreds of routers to emulate multiple peers to a router under test. To stress the router under test, LNE can ﬂap entire LNE routers, routes advertised by the LNE routers or route attributes.

•

•

LNE BGP
The following is a simple example of a BGP conﬁguration on a Cisco router in a test network. interface ethernet 0 ip address 173.200.14.10 255.255.255.0 router bgp 100 network 173.200.0.0 neighbor 173.200.14.101 remote-as 101 The BGP process conﬁguration on the Pagent router has to complement the IP addresses and autonomous system numbers conﬁgured on the router under test. The following commands will: • • • • • Assign an IP address to the BGP process Identify the IP address of the destination router Assign an autonomous system number to the BGP process Identify the autonomous system number of the remote or destination router Add a group of networks to advertise

By default, a group advertises 100 networks or routes to networks. For this example, The value will be lowered to 10 networks. These are the commands used to create and conﬁgure this BGP process: c4700-pagent#lne bgp c4700-p(BGP:OFF,Et0:none)#ethernet1 c4700-p(BGP:OFF,Et1:none)#add bgp c4700-p(BGP:OFF,Et1:1)#ip source 173.200.14.101 c4700-p(BGP:OFF,Et1:1)#ip destination 173.200.14.10 c4700-p(BGP:OFF,Et1:1)#autonomous-system 101 c4700-p(BGP:OFF,Et1:1)#remote-as 100 c4700-p(BGP:OFF,Et1:1)#add group c4700-p(BGP:OFF,Et1:1-Grp1)#advert 10

33

Concept: November 24, 2002

40

Network Services

Network Veriﬁcation Toolkit

This results in the following conﬁguration: c4700-p(BGP:OFF,Et1:1-Grp1)#sh BGP Process 1 of 1 with 1 group(s) advertising 10 networks name "" on datalink lne-defined ip source 173.200.14.101 ip destination 173.200.14.10 autonomous-system 101 remote-as 100 ! random-as-range 200 to 65535 disallow duplicate-as on disallow own-as on ! router-flap off router-flap duration on 600 to 1200 seconds router-flap duration off 300 to 600 seconds verbose on flapping on header-definition off ! group 1 group name "" advertise 10 networks network start 34.1.1.0 network subnetmask 255.255.255.0 network per-nlri 10 next-hop ip-source origin EGP Flap off AS_SEQ 3 to 7 Flap off AS_SET 0 to 3 Flap off MED 1000 to 3000 Flap off Pref 10000 to 100000 Flap off withdraw Flap off define AS_SEQ off define AS_SET off atomic-aggregate off aggregator off community attribute off originator-id off cluster-list attribute off freeform attribute off With the verbose on command, the process posts activity messages when BGP packets are sent or received. When this LNE BGP conﬁguration is started, the following appears on the console: c4700-p(BGP:OFF,Et1:1-Grp1)#start - ON: BGP Processes Started.

34

Concept: November 24, 2002

41

Network Services

Network Veriﬁcation Toolkit

c4700-p(BGP:ON,Et1:1-Grp1)# BGP 173.200.14.101: Starting process #1 on Ethernet1. BGP 173.200.14.101: Send Arp Request. BGP 173.200.14.101: Send TCP SYN. BGP 173.200.14.101: Send TCP SYN. BGP 173.200.14.101: Send BGP Open. BGP 173.200.14.101: Recv BGP Open from 173.200.14.10 BGP 173.200.14.101: Send Group 1 Updates. BGP 173.200.14.101: Recv BGP Update from 173.200.14.10 If you enter the command show ip route bgp at the console of the router under test, you should see the 10 routes or subnets that were advertised by the LNE BGP process. For example: Edge1#show ip route bgp 34.0.0.0/24 is subnetted, 10 subnets B 34.1.3.0 [20/2311] via 173.200.14.101, 00:00:03 B 34.1.2.0 [20/2311] via 173.200.14.101, 00:00:03 B 34.1.1.0 [20/2311] via 173.200.14.101, 00:00:03 B 34.1.7.0 [20/2311] via 173.200.14.101, 00:00:03 B 34.1.6.0 [20/2311] via 173.200.14.101, 00:00:03 B 34.1.5.0 [20/2311] via 173.200.14.101, 00:00:03 B 34.1.4.0 [20/2311] via 173.200.14.101, 00:00:03 B 34.1.10.0 [20/2311] via 173.200.14.101, 00:00:03 B 34.1.9.0 [20/2311] via 173.200.14.101, 00:00:04 B 34.1.8.0 [20/2311] via 173.200.14.101, 00:00:04 Edge1# These are the console messages when the program is stopped: c4700-p(BGP:ON,Et1:1-Grp1)#stop --- Please wait until all BGP TCP circuits are closed. BGP 173.200.14.101: Send TCP FIN #1. BGP 173.200.14.101: Recv TCP Close from 173.200.14.10 - OFF: BGP Processes Stopped. c4700-p(BGP:OFF,Et1:1-Grp1)#

LNE OSPF
The following is a simple example of an OSPF conﬁguration on a Cisco router in a test network. Setting SPF (shortest path ﬁrst) timers to stress test the router under test is optional. interface Ethernet2 ip address 192.21.2.2 255.255.255.0 no shutdown ! router ospf 700 timers spf 0 0 network 192.21.2.0 0.0.0.255 area 0 The OSPF process conﬁguration on the Pagent router must complement the IP addresses conﬁgured on the router under test. The following commands will:

35

Concept:

November 24, 2002

42

Network Services

Network Veriﬁcation Toolkit

• • • • • •

Select the LNE OSPF program command prompt Select the Ethernet2 interface Create an OSPF EASY process Assign an IP address to the process that is in the same subnet as the interface of the RUT Conﬁgure the OSPF process to advertise 20 networks Turn on basic program messages

These are the commands used to create and conﬁgure the OSPF process: a4700a-pagent#lne ospf a4700a-(OSPF:OFF,Et0:none)#et2 a4700a-(OSPF:OFF,Et2:none)#add ez-ospf a4700a-(OSPF:OFF,Et2:1/1)#ip source 192.21.2.5 a4700a-(OSPF:OFF,Et2:1/1)#advertise 20 a4700a-(OSPF:OFF,Et2:1/1)#verb on a4700a-(OSPF:OFF,Et2:1/1)# This results in the following conﬁguration: a4700a-(OSPF:OFF,Et2:1/1)#sho OSPF Process 1 of 1 ! This is an OSPF-EASY process ! name "" on ! datalink lne-defined ip source 192.21.2.5 id 1.1.1.1 subnet-mask 255.255.255.0 area 0.0.0.0 ! hello-interval 10 dead-interval 40 network-type broadcast ! advertise 20 network start 193.0.0.0 network subnetmask 255.255.255.0 ! interface-metric 10 to 10 cluster-link-type broadcast authentication off traffic-eng off ! summary-links quantity 0 !

36

Concept: November 24, 2002

43

Network Services

Network Veriﬁcation Toolkit

external-links quantity 0 ! nssa-links quantity 0 ! withdraw-flap off withdraw-flap 1 2 link-flap off link-flap 0 2 ! convergence-test off convergence-test destination 0.0.0.0 convergence-test packet-interval 10 convergence-test delay-next 1 convergence-test verbose off ! verify-test off verify-test current-table verify-test batch-size 100 verify-test batch-interval 100 verify-test max-timeout 60 verify-test verbose off ! router-flap off router-flap duration on 600 to 1200 seconds router-flap duration off 300 to 600 seconds update rate 50 pps update interval 1800 seconds verbose on header-definition off With the verbose on command, the process posts activity messages when OSPF packets are sent or received. When this LNE OSPF conﬁguration is started, the following appears on the console: a4700a-(OSPF:OFF,Et2:1/1)#start *** OSPF 192.21.2.5 now looking for designated routers. - ON: OSPF Processes Started. a4700a-(OSPF:ON,Et2:1/1)# OSPF Found Designated Router 192.21.2.2, ID 192.21.0.2 on Ethernet2. OSPF 192.21.2.5 Starting. OSPF 192.21.2.5 send OSPF Database Description, Router:0. OSPF 192.21.2.5 send OSPF Database Description, Router:1. OSPF 192.21.2.5 send OSPF Database Description, Router:2. OSPF 192.21.2.5 send OSPF Database Description, Router:3. OSPF 192.21.2.5 send OSPF Database Description, Router:4. OSPF 192.21.2.5 send OSPF Database Description, Router:5. OSPF 192.21.2.5 send OSPF Database Description, Router:6. OSPF 192.21.2.5 send OSPF Database Description, Router:7. OSPF 192.21.2.5 send OSPF Database Description, Router:8. OSPF 192.21.2.5 database exchange complete a4700a-(OSPF:ON,Et2:1/1)#

37

Concept:

November 24, 2002

44

Network Services

Network Veriﬁcation Toolkit

On the console of the router under test you should see an OSPF adjacency change message. If you enter the command show ip ospf neighbor at the router, you should see one neighbor in the FULL state, which is the LNE OSPF process. If you enter the command show ip route ospf at the router under test, you should see the 20 routes or networks that were advertised by the LNE OSPF process. For example: b4700a-pagent# 2w6d: %OSPF-5-ADJCHG: Process 700, Nbr 1.1.1.1 on Ethernet2 from LOADING to FULL, Loading Done b4700a-pagent#sho ip ospf neighbour Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 0 FULL/DROTHER 00:00:35 192.21.2.5 Ethernet2 b4700a-pagent# b4700a-pagent#sho ip route ospf O 193.0.13.0/24 [110/50] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.12.0/24 [110/50] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.15.0/24 [110/50] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.14.0/24 [110/60] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.9.0/24 [110/40] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.8.0/24 [110/40] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.11.0/24 [110/50] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.10.0/24 [110/40] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.5.0/24 [110/50] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.4.0/24 [110/40] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.7.0/24 [110/30] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.6.0/24 [110/40] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.1.0/24 [110/30] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.16.0/24 [110/40] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.17.0/24 [110/50] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.0.0/24 [110/20] via 192.21.2.5, 00:01:52, Ethernet2 O 193.0.3.0/24 [110/40] via 192.21.2.5, 00:01:53, Ethernet2 O 193.0.18.0/24 [110/50] via 192.21.2.5, 00:01:53, Ethernet2 O 193.0.19.0/24 [110/50] via 192.21.2.5, 00:01:53, Ethernet2 O 193.0.2.0/24 [110/30] via 192.21.2.5, 00:01:53, Ethernet2 These are the console messages when the program is stopped: a4700a-(OSPF:ON,Et2:1/1)#stop - OFF: OSPF Processes Stopped. a4700a-(OSPF:OFF,Et2:1/1)#

TGN
The following conﬁguration statements create a traﬃc stream from router PAGENT1 to dummy nodes in EDGE2-LAN. Router PAGENT2 acts as ARP responder providing MAC addresses for ARP requests to dummy nodes. Please see also ﬁgure on page XXX. The traﬃc ﬂow uses 64 byte, 570 byte, 1518 byte IP packets with 7:4:1 distribution (imix). Create ARP responder on router PAGENT2:

38

Concept: November 24, 2002

45

Network Services

Network Veriﬁcation Toolkit

eth <interface> add arp responder name "EDGE2-LAN" ip-address 10.22.0.2 to 10.22.0.253 mac-address <MAC-PAGENT2> Create 64 byte ﬂow on router PAGENT1: eth <interface> add ip name "PAGENT1-to-EDGE2-64byte" rate 70 length 64 l2-encapsulation arpa l2-dest-addr <MAC-EDGE1> l2-src-addr <MAC-PAGENT1> l2-protocol 0x0800 l3-tos random 0x00 to 0x07 l3-dest-addr random 10.22.0.2 to 10.22.0.253 l3-src-addr random 10.21.0.2 to 10.21.0.253 Create 570 byte ﬂow on router PAGENT1: eth <interface> add ip name "PAGENT1-to-EDGE2-570byte" rate 40 length 570 l2-encapsulation arpa l2-dest-addr <MAC-EDGE1> l2-src-addr <MAC-PAGENT1> l2-protocol 0x0800 l3-tos random 0x00 to 0x07 l3-dest-addr random 10.22.0.2 to 10.22.0.253 l3-src-addr random 10.21.0.2 to 10.21.0.253 Create 1518 byte ﬂow on router PAGENT1: eth <interface> add ip name "PAGENT1-to-EDGE2-1518byte" rate 10 length 1518 l2-encapsulation arpa l2-dest-addr <MAC-EDGE1> l2-src-addr <MAC-PAGENT1> l2-protocol 0x0800 l3-tos random 0x00 to 0x07 l3-dest-addr random 10.22.0.2 to 10.22.0.253 l3-src-addr random 10.21.0.2 to 10.21.0.253 Check traﬃc generation:

39

Concept: November 24, 2002

46

Network Services

Network Veriﬁcation Toolkit

PAGENT1(TGN:ON,Et1/0:4/4)#show ip Summary of IP traffic streams on Ethernet1/0 ts# tos len id frag ttl protocol chksm 2 IP 00 20 0000 0000 60 0 6AB8 3 IP 00 20 0000 0000 60 0 6AB8 4 IP 00 20 0000 0000 60 0 6AB8 PAGENT1(TGN:ON,Et1/0:4/4)# PAGENT1(TGN:ON,Et1/0:4/4)#show rate The rates are since traffic generation was started. Summary of traffic stream rates on Ethernet1/0 ts# template state repeat 2 IP on 1 3 IP on 1 4 IP on 1 Totals for Ethernet1/0 PAGENT1(TGN:ON,Et1/0:4/4)# interval/rate 70 pps 40 pps 10 pps measured interval/rate 3.216 3.216 3.216 9.649 packets_sent 134071 134068 134067 402206

source 10.21.0.2 10.21.0.2 10.21.0.2

destination 10.22.0.2 10.22.0.2 10.22.0.2

40

Concept:

November 24, 2002

47

Network Services

Network Veriﬁcation Toolkit

eth 0 add arp responder name "EDGE2-LAN" ip-address 10.22.0.2 to 10.22.0.253 mac-address <MAC-PAGENT2>

PAGENT2 eth0
<MAC-PAGENT2> IP: 10.22.0.1

IP: 10.22.0.254 <MAC-EDGE2>

IP: 10.22.0.0/24

eth0 EDGE2

Trafﬁc Stream

EDGE1 eth0
<MAC-EDGE1> IP: 10.21.0.1

IP:10.21.0.254 <MAC-PAGENT1>

IP: 10.21.0.0/24

eth0 PAGENT1

eth 0 add ip name "PAGENT1-to-EDGE2-64byte" rate 70 length 64 l2-encapsulation arpa l2-dest-addr <MAC-EDGE1> l2-src-addr <MAC-PAGENT1> l2-protocol 0x0800 l3-tos random 0x00 to 0x07 l3-dest-addr random 10.22.0.2 to 10.22.0.253 l3-src-addr random 10.21.0.2 to 10.21.0.253

Figure 5.1

Pagent TGN

41

Concept:

November 24, 2002

48

Network Services

Network Veriﬁcation Toolkit

5.9.3 Expect
Expect script rtr3 can be used to execute commands on a router. The script can be found on page 107.

Figure 5.2

Expect script rtr3

42

Concept:

November 24, 2002

49

Network Services

Network Veriﬁcation Toolkit

5.9.4 Ploticus
Sometimes it is interesting to monitor CPU and memory utilization during an experiment. The following procedure allows creating CPU and memory graphs covering a time period of a few hours. The procedure involves gathering router data using cron and an Expect script (rtr3). The data is graphed using the Ploticus software (http://ploticus.sourceforge.net/). zerberus.sh is a shell script that is executed by cron every ﬁve minutes. The script invokes rtr3 to collect data from a router and store it a log ﬁle. It can be found on page 101ﬀ. cpu.pl is a Ploticus script that generates a CPU graph from the log ﬁle. It can be found on page 101ﬀ. mem.pl is a Ploticus script that generates a memory graph from the log ﬁle. It can be found on page 101ﬀ. Example graphs can be found on page 43 and 44.

Figure 5.3

Example of a Ploticus CPU utilization graph

43

Concept:

November 24, 2002

50

Network Services

Network Veriﬁcation Toolkit

Figure 5.4

Example of a Ploticus memory utilization graph

44

Concept:

November 24, 2002

51

Network Services

Network Veriﬁcation Toolkit

5.9.5 NRFU
• • • • • Table of FR PCVs CDP table OSPF table IS-IS table BGP

45

Concept:

November 24, 2002

52

Network Services

Network Veriﬁcation Toolkit

5.9.6 Cricket and RRDTool
TBD

46

Concept:

November 24, 2002

53

Network Services

Network Veriﬁcation Toolkit

5.9.7 MRTG
MRTG (http://www.mrtg.org) has been deployed as another method of monitoring CPU and memory utilization during an experiment. MRTG is installed on node Dinghy (from NetBSD pkgsource). MRTG conﬁguration ﬁles are placed in the directory /home/mrtg. MRTG generated ﬁles are placed in subdirectories of /home/mrtg/public_html. They can be access via the URL http://dinghy.brest.lab. Templates for CPU and memory conﬁguration ﬁles are stored in a RCS repository in /home/mrtg. Monitoring a new router requires the following steps: • • • • • Check out the ﬁles router_name-cpu_mrtg.conf and router_name-memory_mrtg.conf Individualize and rename the ﬁles router_name-cpu_mrtg.conf and router_name-memory_mrtg.conf Add the ﬁles <ROUTER_SHORT_NAME>-cpu_mrtg.conf and <ROUTER_SHORT_NAME>-memory_mrtg.conf to mrtg.conf Create the directory /home/mrtg/public_html/<ROUTER_SHORT_NAME> Start or restart MRTG

Example conﬁguration ﬁles can be found on page 104. Example graphs can be found on page 48, 49 and 50.

47

Concept:

November 24, 2002

54

Network Services

Network Veriﬁcation Toolkit

Figure 5.5

Example of a MRTG CPU utilization graph 48

Concept:

November 24, 2002

55

Network Services

Network Veriﬁcation Toolkit

Figure 5.6

Example of a MRTG memory utilization graph 49

Concept:

November 24, 2002

56

Network Services

Network Veriﬁcation Toolkit

Figure 5.7

Example of a MRTG free memory graph 50

Concept:

November 24, 2002

57

Network Services

Network Veriﬁcation Toolkit

5.9.8 Ethereal (www.ethereal.com)
TBD

5.9.9 Etherape (etherape.sourceforge.net)
TBD

51

Concept:

November 24, 2002

58

Network Services

Authentication Services

5.10

Authentication Services

5.10.1 RADIUS
Host Dinghy provides RADIUS authentication service for lab routers. It runs the Cistron RADIUS daemon (radiusd-cistron-1.6.6), which was installed from NetBSD package source. RADIUS conﬁguration ﬁles reside in /usr/pkg/etc/raddb. Example conﬁguration ﬁles can be found on page RADIUS is started using daemontools. [email protected]# ll /service | grep radiusd lrwxr-xr-x 1 root wheel 20 Oct 1 17:41 radiusd -> /usr/pkg/etc/radiusd [email protected]# [email protected]# cat /service/radiusd/run #!/bin/sh exec /usr/pkg/sbin/radiusd /usr/pkg/sbin/radiusd -f -s -d /usr/pkg/etc/raddb -p 1812 [email protected]# Conﬁguration commands for Cisco routers can be found on page xxx.

52

Concept:

November 24, 2002

59

Network Services

Security Toolkit

5.11

Security Toolkit
• • • • • Portsentry and Logcheck Nessus (www.nessus.org) Snort and Logsnorter (www.snort.org) Analysis Console for Intrusion Databases (ACID) (www.cert.org/kb/acid) nmap

53

Concept:

November 24, 2002

60

A Conﬁguration Log
A.1 Basic IPv4 Conﬁguration
Router conﬁguration ﬁles are split into device speciﬁc and common ﬁles. Device speciﬁc ﬁles conﬁgure mainly the transport and routing aspects. Common ﬁles conﬁgure generic functions such as NTP, SNMP, and administrative access.

A.1.1

Common Conﬁguration - NTP, SNMP, Administrative Access
! $Id: common-confg,v 1.2 2002/10/25 14:15:13 markus Exp $ ! ! Generic commands, administrative access etc. ! interface loopback1 description $Id: common-confg,v 1.2 2002/10/25 14:15:13 markus Exp $ ! ip telnet source-interface Loopback0 ip tftp source-interface Loopback0 ip ftp source-interface Loopback0 ! ip domain-name brest.lab ip name-server 172.16.254.2 172.16.255.2 ! logging trap debugging logging facility local4 logging source-interface Loopback0 logging 172.16.255.2 ! access-list 1 remark Hosts in this list are allowed telnet/SNMP access access-list 1 permit 172.16.0.0 0.0.0.255 access-list 1 permit 172.16.254.0 0.0.0.255 access-list 1 permit 172.16.255.0 0.0.0.255 ! snmp-server community Brest-Lab RO 1 ! line vty 0 4 access-class 1 in transport input telnet ! ntp peer 172.16.0.1 source Loopback0 ! Core1 ntp peer 172.16.0.2 source Loopback0 ! Core2 ntp peer 172.16.0.3 source Loopback0 ! Core3 ntp peer 172.16.0.11 source Loopback0 ! Edge1

54

Concept: November 24, 2002

61

Conﬁguration Log

Basic IPv4 Conﬁguration

ntp ntp ntp ntp

peer 172.16.0.12 source Loopback0 peer 172.16.3.2 source Loopback0 peer 172.16.255.2 source Loopback0 server 172.16.254.2 source Loopback0 prefer

! ! ! !

Edge2 Edge3 Dinghy Anchor

55

Concept:

November 24, 2002

62

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.2

Common Conﬁguration - RADIUS
Two conﬁguration ﬁles are provided here because IOS 12.0 is conﬁgured diﬀerently from IOS 12.2. ! $Id: common-radius-confg,v 1.2 2002/10/25 14:16:26 markus Exp $ ! RADIUS IOS 12.2 ! interface loopback2 description $Id: common-radius-confg,v 1.2 2002/10/25 14:16:26 markus Exp $ ! aaa new-model aaa authentication login LOCAL_AUTH local aaa authentication login RADIUS_AUTH group radius local aaa authentication enable default group radius enable aaa accounting send stop-record authentication failure aaa accounting exec default wait-start group radius ip radius source-interface loopback0 ! enable secret q1w2e3r4 username admin password 1q2w3e4r ! radius-server host 172.16.255.2 auth-port 1812 acct-port 1813 radius-server key Brest-Lab ! line con 0 exec-timeout 0 0 login authentication LOCAL_AUTH transport input none line aux 0 exec-timeout 15 0 login authentication LOCAL_AUTH line vty 0 4 exec-timeout 15 0 login authentication RADIUS_AUTH This is the IOS 12.0 conﬁguration: ! $Id: common-radius-oldstyle-confg,v 1.2 2002/10/25 14:17:39 markus Exp $ ! RADIUS IOS 12.0 -> no "group radius" ! interface loopback 2 description $Id: common-radius-oldstyle-confg,v 1.2 2002/10/25 14:17:39 markus Exp $ ! aaa new-model aaa authentication login LOCAL_AUTH local aaa authentication login RADIUS_AUTH radius local aaa authentication enable default radius enable aaa accounting send stop-record authentication failure aaa accounting exec default wait-start radius

56

Concept: November 24, 2002

63

Conﬁguration Log

Basic IPv4 Conﬁguration

ip radius source-interface loopback0 ! enable secret q1w2e3r4 username admin password 1q2w3e4r ! radius-server host 172.16.255.2 auth-port 1812 acct-port 1813 radius-server key Brest-Lab ! line con 0 exec-timeout 0 0 login authentication LOCAL_AUTH transport input none line aux 0 exec-timeout 15 0 login authentication LOCAL_AUTH line vty 0 4 exec-timeout 15 0 login authentication RADIUS_AUTH

57

Concept:

November 24, 2002

64

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.3

Router Core1 - IPv4
! $Id: core1-confg,v 1.3 2002/10/19 15:49:11 markus Exp $ ! version 12.0 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname Core1 ! enable secret q1w2e3r4 username admin password 1q2w3e4r username system password manager username markus password 1q2w3e4r ! ip subnet-zero ip cef ! frame-relay switching ! interface Loopback0 description $Id: core1-confg,v 1.3 2002/10/19 15:49:11 markus Exp $ ip address 172.16.0.1 255.255.255.255 no ip directed-broadcast ! interface Ethernet0 description Core1 LAN -> Dinghy ip address 172.16.255.1 255.255.255.0 no ip directed-broadcast ! interface Serial0 description Trunk link Core1 to Core2 bandwidth 2000 no ip address no ip directed-broadcast encapsulation frame-relay no fair-queue clockrate 2000000 frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay intf-type nni frame-relay route 200 interface Serial1 200 frame-relay route 300 interface Serial1 300 ! interface Serial0.100 point-to-point description Link Core1 to Core2 bandwidth 256 ip unnumbered Loopback0

58

Concept: November 24, 2002

65

Conﬁguration Log

Basic IPv4 Conﬁguration

no ip directed-broadcast frame-relay class 256KBPS frame-relay interface-dlci 100 ! interface Serial0.400 point-to-point description Link Core1 to Edge1 bandwidth 64 ip unnumbered Loopback0 no ip directed-broadcast frame-relay class 64KBPS frame-relay interface-dlci 400 ! interface Serial1 description Trunk link Core1 to Core3 bandwidth 2000 no ip address no ip directed-broadcast encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay intf-type nni frame-relay route 200 interface Serial0 200 frame-relay route 300 interface Serial0 300 ! interface Serial1.100 point-to-point description Link Core1 to Core3 bandwidth 256 ip unnumbered Loopback0 no ip directed-broadcast frame-relay class 256KBPS frame-relay interface-dlci 100 ! router ospf 65000 log-adjacency-changes network 172.16.0.0 0.0.0.255 area 0 network 172.16.255.0 0.0.0.255 area 0 ! ip classless no ip pim bidir-enable ! map-class frame-relay 256KBPS frame-relay traffic-rate 256000 512000 frame-relay adaptive-shaping becn ! line con 0 exec-timeout 0 0 login local line aux 0

59

Concept: November 24, 2002

66

Conﬁguration Log

Basic IPv4 Conﬁguration

exec-timeout 15 0 login local line vty 0 4 exec-timeout 15 0 login local transport input telnet end

60

Concept:

November 24, 2002

67

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.4

Router Core2 - IPv4
! $Id: core2-confg,v 1.3 2002/10/19 15:49:17 markus Exp $ ! version 12.0 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname Core2 ! enable secret q1w2e3r4 username admin password 1q2w3e4r username system password manager username markus password 1q2w3e4r ip subnet-zero ip cef ! frame-relay switching ! interface Loopback0 description $Id: core2-confg,v 1.3 2002/10/19 15:49:17 markus Exp $ ip address 172.16.0.2 255.255.255.255 no ip directed-broadcast ! interface Ethernet0 description Office LAN -> Anchor ip address 172.16.254.254 255.255.255.0 no ip directed-broadcast ! interface Serial0 description Access link Core2 to Edge1 bandwidth 2000 no ip address no ip directed-broadcast encapsulation frame-relay no fair-queue clockrate 2000000 frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay intf-type dce frame-relay route 400 interface Serial1 400 ! interface Serial0.100 point-to-point description Access link Core2 to Edge1 bandwidth 64 ip unnumbered Loopback0 no ip directed-broadcast frame-relay class 64KBPS

61

Concept: November 24, 2002

68

Conﬁguration Log

Basic IPv4 Conﬁguration

frame-relay interface-dlci 100 ! interface Serial1 description Trunk link Core2 to Core1 bandwidth 2000 no ip address no ip directed-broadcast encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay intf-type nni frame-relay route 400 interface Serial0 400 ! interface Serial1.100 point-to-point description Trunk link Core2 to Core1 bandwidth 256 ip unnumbered Loopback0 no ip directed-broadcast frame-relay class 256KBPS frame-relay interface-dlci 100 ! interface Serial1.200 point-to-point description Trunk link Core2 to Core3 bandwidth 256 ip unnumbered Loopback0 no ip directed-broadcast frame-relay class 256KBPS frame-relay interface-dlci 200 ! interface Serial1.300 point-to-point description Access link Core2 to Edge2 bandwidth 64 ip unnumbered Loopback0 no ip directed-broadcast frame-relay class 64KBPS frame-relay interface-dlci 300 ! router ospf 65000 log-adjacency-changes network 172.16.0.0 0.0.0.255 area 0 network 172.16.254.0 0.0.0.255 area 0 ! ip classless no ip pim bidir-enable ! map-class frame-relay 256KBPS frame-relay traffic-rate 256000 512000 frame-relay adaptive-shaping becn

62

Concept: November 24, 2002

69

Conﬁguration Log

Basic IPv4 Conﬁguration

! map-class frame-relay 64KBPS frame-relay traffic-rate 64000 128000 frame-relay adaptive-shaping becn ! line con 0 exec-timeout 0 0 login local line aux 0 exec-timeout 15 0 login local line vty 0 4 exec-timeout 15 0 login local transport input telnet end

63

Concept:

November 24, 2002

70

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.5

Router Core3 - IPv4
! $Id: core3-confg,v 1.3 2002/10/12 14:30:02 markus Exp $ ! version 12.0 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname Core3 ! enable secret q1w2e3r4 username admin password 1q2w3e4r username system password manager username markus password 1q2w3e4r ip subnet-zero ip cef ! frame-relay switching ! interface Loopback0 description $Id: core3-confg,v 1.3 2002/10/12 14:30:02 markus Exp $ ip address 172.16.0.3 255.255.255.255 no ip directed-broadcast ! interface Ethernet0 description Trunk link Core3 to Core4 ip address 172.16.3.1 255.255.255.252 no ip directed-broadcast ! interface Serial0 description Trunk link Core3 to Core1 bandwidth 2000 no ip address no ip directed-broadcast encapsulation frame-relay no fair-queue clockrate 2000000 frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay intf-type nni frame-relay route 300 interface Serial1 300 ! interface Serial0.100 point-to-point description Trunk link Core3 to Core1 bandwidth 256 ip unnumbered Loopback0 no ip directed-broadcast frame-relay class 256KBPS

64

Concept: November 24, 2002

71

Conﬁguration Log

Basic IPv4 Conﬁguration

frame-relay interface-dlci 100 ! interface Serial0.200 point-to-point description Trunk link Core3 to Core2 bandwidth 256 ip unnumbered Loopback0 no ip directed-broadcast frame-relay class 256KBPS frame-relay interface-dlci 200 ! interface Serial1 description Access link Core3 to Edge2 bandwidth 2000 no ip address no ip directed-broadcast encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi frame-relay intf-type dce frame-relay route 300 interface Serial0 300 ! interface Serial1.100 point-to-point description Access link Core3 to Edge2 bandwidth 64 ip unnumbered Loopback0 no ip directed-broadcast frame-relay class 64KBPS frame-relay interface-dlci 100 ! router ospf 65000 log-adjacency-changes network 172.16.0.0 0.0.0.255 area 0 network 172.16.3.0 0.0.0.255 area 0 ! ip classless no ip pim bidir-enable ! map-class frame-relay 256KBPS frame-relay traffic-rate 256000 512000 frame-relay adaptive-shaping becn ! map-class frame-relay 64KBPS frame-relay traffic-rate 64000 128000 frame-relay adaptive-shaping becn ! line con 0 exec-timeout 0 0 login local

65

Concept: November 24, 2002

72

Conﬁguration Log

Basic IPv4 Conﬁguration

line aux 0 exec-timeout 15 0 login local line vty 0 4 exec-timeout 15 0 login local transport input telnet end

66

Concept:

November 24, 2002

73

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.6

Router Core4 - IPv4
[file 910-Configuration-Log/core4-confg does not exist]

67

Concept:

November 24, 2002

74

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.7

Router Edge1 - IPv4
! $Id: edge1-confg,v 1.4 2002/10/19 15:49:02 markus Exp $ ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname Edge1 ! enable secret q1w2e3r4 username admin password 1q2w3e4r username system password manager username markus password 1q2w3e4r ! ip subnet-zero ip cef ! interface Loopback0 description $Id: edge1-confg,v 1.4 2002/10/19 15:49:02 markus Exp $ ip address 172.16.0.11 255.255.255.255 ! interface Ethernet0 description Edge1 LAN (to CPE) ip address 10.1.1.1 255.255.255.0 ! interface Serial0 description *** unused *** no ip address shutdown ! interface Serial1 description Access link Edge1 to Core2 bandwidth 2000 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ! interface Serial1.100 point-to-point description Access link Edge1 to Core2 bandwidth 64 ip unnumbered Loopback0 frame-relay class 64KBPS frame-relay interface-dlci 100 ! interface Serial1.400 point-to-point

68

Concept: November 24, 2002

75

Conﬁguration Log

Basic IPv4 Conﬁguration

description Access link Edge1 to Core1 bandwidth 64 ip unnumbered Loopback0 frame-relay class 64KBPS frame-relay interface-dlci 400 ! router ospf 65000 log-adjacency-changes network 10.1.1.0 0.0.0.255 area 10.1.1.0 network 172.16.0.0 0.0.0.255 area 0 ! ip classless no ip http server ip pim bidir-enable ! map-class frame-relay 64KBPS frame-relay traffic-rate 64000 128000 frame-relay adaptive-shaping becn ! line con 0 exec-timeout 0 0 login local line aux 0 exec-timeout 15 0 login local line vty 0 4 exec-timeout 15 0 login local transport input telnet end

69

Concept:

November 24, 2002

76

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.8

Router Edge2 - IPv4
! $Id: edge2-confg,v 1.2 2002/09/28 18:50:32 markus Exp $ ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! hostname Edge2 ! enable secret q1w2e3r4 username admin password 1q2w3e4r username system password manager username markus password 1q2w3e4r ! ip subnet-zero ip cef ! interface Loopback0 description $Id: edge2-confg,v 1.2 2002/09/28 18:50:32 markus Exp $ ip address 172.16.0.12 255.255.255.255 ! interface Ethernet0 description Edge2 LAN (to CPE) ip address 10.2.1.1 255.255.255.0 ! interface Serial0 description Access link Edge2 to Core3 bandwidth 2000 no ip address encapsulation frame-relay no fair-queue clockrate 2000000 frame-relay traffic-shaping frame-relay lmi-type ansi ! interface Serial0.100 point-to-point description Access link Edge2 to Core3 bandwidth 64 ip unnumbered Loopback0 frame-relay class 64KBPS frame-relay interface-dlci 100 ! interface Serial0.300 point-to-point description Access link Edge2 to Core2 bandwidth 64 ip unnumbered Loopback0 frame-relay class 64KBPS

70

Concept: November 24, 2002

77

Conﬁguration Log

Basic IPv4 Conﬁguration

frame-relay interface-dlci 300 ! interface Serial1 description *** unused *** no ip address shutdown ! interface BRI0 no ip address shutdown ! router ospf 65000 log-adjacency-changes network 10.2.1.0 0.0.0.255 area 10.2.1.0 network 172.16.0.0 0.0.0.255 area 0 ! ip classless no ip http server no ip pim bidir-enable ! map-class frame-relay 64KBPS frame-relay traffic-rate 64000 128000 frame-relay adaptive-shaping becn ! line con 0 exec-timeout 0 0 login local line aux 0 exec-timeout 15 0 login local line vty 0 4 exec-timeout 15 0 login local transport input telnet end

71

Concept:

November 24, 2002

78

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.9

Router Zerberus - IPv4
[file 910-Configuration-Log/zerberus-confg does not exist]

72

Concept:

November 24, 2002

79

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.10 Host Anchor - IPv4
[file 910-Configuration-Log/anchor-confg does not exist]

73

Concept:

November 24, 2002

80

Conﬁguration Log

Basic IPv4 Conﬁguration

A.1.11 Host Dinghy - IPv4
/etc/rc.conf [email protected]# cat /etc/rc.conf # $NetBSD: rc.conf,v 1.96 2000/10/14 17:01:29 wiz Exp $ # # see rc.conf(5) for more information. # # Use program=YES to enable program, NO to disable it. program_flags are # passed to the program on the command line. # # Load the defaults in from /etc/defaults/rc.conf (if it’s readable). # These can be overridden below. # if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf fi # If this is not set to YES, the system will drop into single-user mode. # rc_configured=YES # # Add local overrides below # # Web server thttpd=YES # Logging syslogd=YES syslogd_flags="" # Allow remote boxes to use syslogd newsyslog=YES newsyslog_flags="" # Trim log files # NTP ntpd=YES # # # # # IPv4 routing IPv4 forwarding is enabled in /etc/rc.local -> sysctl -w net.inet.ip.forwarding=1 Routing daemons are started via daemontools -> /service/gated

/etc/rc.local [email protected]# cat /etc/rc.local # $NetBSD: rc.local,v 1.29 2000/10/07 00:22:44 hubertf Exp $ # originally from: @(#)rc.local 8.3 (Berkeley) 4/28/94

74

Concept: November 24, 2002

81

Conﬁguration Log

Basic IPv4 Conﬁguration

# # # # # # # # #

This file is (nearly) the last thing invoked by /etc/rc during a normal boot, via /etc/rc.d/local. It is intended to be edited locally to add site-specific boot-time actions, such as starting locally installed daemons. An alternative option is to create site-specific /etc/rc.d scripts.

echo -n ’starting local daemons:’ # Add your local daemons here. # # Enable ip forwarding sysctl -w net.inet.ip.forwarding=1 sysctl -w net.inet6.ip6.forwarding=1 #if [ -f /usr/pkg/etc/rc.d/apache ]; then # /usr/pkg/etc/rc.d/apache start #fi echo ’.’ # # We’re using Daemontools to manage local services - starting svscan # env - PATH=/usr/local/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/sbin:/usr/bin:/bin csh cf ’svscan /service &’ /etc/ifconﬁg.sq0 [email protected]# cat /etc/ifconfig.sq0 up 172.16.255.2 netmask 0xffffff00 /etc/syslog.conf [email protected]# cat /etc/syslog.conf # $NetBSD: syslog.conf,v 1.7 2001/02/12 06:08:31 mycroft Exp $ local4.* *.err;kern.*;auth.notice;authpriv.none;mail.crit *.info;auth,authpriv,cron,ftp,kern,lpr,mail.none kern.debug /var/log/router.log /dev/console /var/log/messages /var/log/messages

# The authpriv log file should be restricted access; these # messages shouldn’t go to terminals or publically-readable

75

Concept: November 24, 2002

82

Conﬁguration Log

Basic IPv4 Conﬁguration

# files. auth,authpriv.info cron.info ftp.info lpr.info mail.info #uucp.info *.emerg *.notice /etc/newsyslog.conf [email protected]# cat /etc/newsyslog.conf # $NetBSD: newsyslog.conf,v 1.15 2002/03/29 # # Configuration file for newsyslog(8). # # logfilename [owner:group] mode ngen # /var/cron/log root:wheel 600 3 /var/log/aculog uucp:dialer 640 7 /var/log/authlog 600 5 /var/log/kerberos.log 640 7 /var/log/lpd-errs 640 7 /var/log/maillog 600 7 /var/log/messages 644 5 /var/log/wtmp 644 7 /var/log/xferlog 640 7 /var/log/gated.log 644 5 /var/log/router.log 644 5 /etc/ntp.conf

/var/log/authlog /var/cron/log /var/log/xferlog /var/log/lpd-errs /var/log/maillog /var/spool/uucp/ERRORS * root

02:47:26 heinz Exp $

size when flags [/pidfile] [sigtype] 10 * 30 * 10 * 30 * 250 30 30 * 24 * 24 * 24 * 168 * * * Z Z Z ZN Z Z Z ZBN Z Z Z

[email protected]# cat /etc/ntp.conf # $Id$ # Network Time Protocol (NTP) configuration file for ntpd # Process ID file, so that the daemon can be signalled from scripts pidfile /var/run/ntpd.pid

# The correction calculated by ntpd(8) for the local system clock’s # drift is stored here driftfile /var/db/ntp.drift

# suppress the syslog(3) message for each peer synchronization change logconfig -syncstatus

76

Concept: November 24, 2002

83

Conﬁguration Log

Basic IPv4 Conﬁguration

# # # # #

Hereafter should be "server" or "peer" statements to configure other hosts to exchange NTP packets with. Ideally, you should select at least three other systems to talk NTP with, for an "what I tell you three times is true" effect.

server anchor.brest.lab peer core1.brest.lab peer core2.brest.lab peer core2.brest.lab peer edge1.brest.lab peer edge2.brest.lab peer edge3.brest.lab /etc/gated.conf [email protected]# ll /service/ total 0 lrwxr-xr-x 1 root wheel 21 Oct 1 14:09 gated -> /usr/local/etc/gated/ lrwxr-xr-x 1 root wheel 19 Sep 17 11:33 thttpd -> /usr/pkg/etc/thttpd lrwxr-xr-x 1 root wheel 18 Sep 30 16:25 zebra -> /usr/pkg/etc/zebra [email protected]# [email protected]# cat /service/gated/run #!/bin/sh exec /usr/local/sbin/gated -N -f /etc/gated.conf /var/log/gated.log [email protected]# [email protected]# cat /etc/gated.conf ospf yes { backbone { interface sq0; }; }; [email protected]#

77

Concept:

November 24, 2002

84

Conﬁguration Log

IPv6 Conﬁguration

A.2

IPv6 Conﬁguration

A.2.1

Router Anchor - IPv6
Anchor serves as IPv6 hub router and route reﬂector. /etc/rc.conf [email protected]# cat /etc/rc.conf # $NetBSD: rc.conf,v 1.96 2000/10/14 17:01:29 wiz Exp $ # # see rc.conf(5) for more information. # # Use program=YES to enable program, NO to disable it. program_flags are # passed to the program on the command line. # # Load the defaults in from /etc/defaults/rc.conf (if it’s readable). # These can be overridden below. # if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf fi # If this is not set to YES, the system will drop into single-user mode. # rc_configured=YES # Add local overrides below # # Logging syslogd=YES syslogd_flags="" # Allow remote boxes to use syslogd newsyslog=YES newsyslog_flags="" # Trim log files # NTP ntpd=YES # # # # # # # # # IPv4 routing IPv4 forwarding is enabled in /etc/rc.local -> sysctl -w net.inet.ip.forwarding=1 Routing daemons are started via daemontools -> /service/ospfd IPv6 routing IPv6 forwarding is enabled in /etc/rc.local -> sysctl -w net.inet6.ip.forwarding=1 Routing daemons are started via daemontools

78

Concept: November 24, 2002

85

Conﬁguration Log

IPv6 Conﬁguration

# -> /service/zebra # -> /service/bgpd ip6mode=router ip6sitelocal=YES rtsol=NO rtadvd=YES

rtsol_flags="-a" rtadvd_flags="tlp0"

# host, autohost or router # IPv6 sitelocal addrs # for ip6mode=autohost only

# # NFS server => netboot the Indy # # rpcbind=YES rpcbind_flags="-l" # nfs_server=YES # lockd=YES # statd=YES # # DHCPd => netboot the Indy # dhcpd=YES dhcpd_flags="-q tlp0" [email protected]# /etc/rc.local [email protected]# cat /etc/rc.local # $NetBSD: rc.local,v 1.29 2000/10/07 00:22:44 hubertf Exp $ # originally from: @(#)rc.local 8.3 (Berkeley) 4/28/94 # # This file is (nearly) the last thing invoked by /etc/rc during a # normal boot, via /etc/rc.d/local. # # It is intended to be edited locally to add site-specific boot-time # actions, such as starting locally installed daemons. # # An alternative option is to create site-specific /etc/rc.d scripts. # echo -n ’starting local daemons:’ # Add your local daemons here. # # Enable ip forwarding sysctl -w net.inet.ip.forwarding=1 sysctl -w net.inet6.ip6.forwarding=1 # # We’re using Daemontools to start local services - starting svscan now # env - PATH=/usr/local/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/sbin:/usr/bin:/bin csh cf ’svscan /service &’ [email protected]#

79

Concept:

November 24, 2002

86

Conﬁguration Log

IPv6 Conﬁguration

/etc/ifconﬁg.* [email protected]# cat /etc/ifconfig.lo0 inet6 fefe::a prefixlen 128 alias [email protected]# [email protected]# cat /etc/ifconfig.tlp0 up 172.16.254.2 netmask 0xffffff00 media 10baseT inet6 fefe:a::1 prefixlen 64 alias [email protected]# [email protected]# cat /etc/ifconfig.gif0 create tunnel 172.16.254.2 172.16.255.2 inet6 up [email protected]# [email protected]# cat /etc/ifconfig.gif1 create tunnel 172.16.254.2 172.16.0.11 inet6 up [email protected]# [email protected]# cat /etc/ifconfig.gif2 create tunnel 172.16.254.2 172.16.0.12 inet6 up [email protected]# [email protected]# cat /etc/ifconfig.gif3 create tunnel 172.16.254.2 10.3.1.1 inet6 up [email protected]# /etc/zebra.conf ! ! $Id: anchor-ipv6-zebra.conf,v 1.2 2002/10/23 18:18:55 markus Exp $ ! hostname Anchor(zebra) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/zebra.log ! interface tlp0 description Office LAN ipv6 address fefe:a::1/64 ipv6 nd suppress-ra ! interface ep0 description ***unused*** ipv6 nd suppress-ra !

80

Concept: November 24, 2002

87

Conﬁguration Log

IPv6 Conﬁguration

interface lo0 description $Id: anchor-ipv6-zebra.conf,v 1.2 2002/10/23 18:18:55 markus Exp $ ipv6 address fefe::a/128 ! interface ppp0 description ***unused*** ipv6 nd suppress-ra ! interface ppp1 description ***unused*** ipv6 nd suppress-ra ! interface ppp2 description ***unused*** ipv6 nd suppress-ra ! interface ppp3 description ***unused*** ipv6 nd suppress-ra ! interface sl0 description ***unused*** ipv6 nd suppress-ra ! interface sl1 description ***unused*** ipv6 nd suppress-ra ! interface sl2 description ***unused*** ipv6 nd suppress-ra ! interface sl3 description ***unused*** ipv6 nd suppress-ra ! interface gif0 description IPv6 tunnel to router Dinghy ipv6 nd suppress-ra ! interface gif1 description IPv6 tunnel to router Edge1 ipv6 nd suppress-ra ! interface gif2 description IPv6 tunnel to router Edge2 ipv6 nd suppress-ra ! interface gif3

81

Concept: November 24, 2002

88

Conﬁguration Log

IPv6 Conﬁguration

description ***unused*** ipv6 nd suppress-ra ! ip route 224.0.0.5/32 127.0.0.1 ip route 224.0.0.6/32 127.0.0.1 ipv6 route fefe::d/128 gif0 ipv6 route fefe::e1/128 gif1 253 ipv6 route fefe::e2/128 gif2 253 ! ! line vty ! /etc/bgpd.conf ! ! $Id: anchor-ipv6-bgpd.conf,v 1.1 2002/10/23 15:55:26 markus Exp $ ! hostname Anchor(bgpd) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/bgpd.log ! router bgp 65000 bgp deterministic-med neighbor MESH peer-group neighbor MESH remote-as 65000 neighbor MESH description Fellow route reflectors neighbor MESH update-source lo0 no neighbor MESH activate !*! Edge1 neighbor fefe::e1 remote-as 65000 neighbor fefe::e1 update-source lo0 no neighbor fefe::e1 activate !*! Edge2 neighbor fefe::e2 remote-as 65000 neighbor fefe::e2 update-source lo0 no neighbor fefe::e2 activate ! address-family ipv6 redistribute connected redistribute static neighbor MESH activate neighbor MESH next-hop-self neighbor MESH route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out !*! Edge1 neighbor fefe::d peer-group MESH neighbor fefe::e1 activate neighbor fefe::e1 route-reflector-client neighbor fefe::e1 next-hop-self

82

Concept: November 24, 2002

89

Conﬁguration Log

IPv6 Conﬁguration

neighbor fefe::e1 route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out !*! Edge2 neighbor fefe::e2 activate neighbor fefe::e2 route-reflector-client neighbor fefe::e2 next-hop-self neighbor fefe::e2 route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 set ipv6 next-hop global fefe::a ! line vty !

83

Concept:

November 24, 2002

90

Conﬁguration Log

IPv6 Conﬁguration

A.2.2

Router Dinghy - IPv6
Dinghy serves as IPv6 hub router and route reﬂector. /etc/rc.conf [email protected]# cat /etc/rc.conf # $NetBSD: rc.conf,v 1.96 2000/10/14 17:01:29 wiz Exp $ # # see rc.conf(5) for more information. # # Use program=YES to enable program, NO to disable it. program_flags are # passed to the program on the command line. # # Load the defaults in from /etc/defaults/rc.conf (if it’s readable). # These can be overridden below. # if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf fi # If this is not set to YES, the system will drop into single-user mode. # rc_configured=YES # # Add local overrides below # thttpd=YES # Logging syslogd=YES syslogd_flags="" # Allow remote boxes to use syslogd newsyslog=YES newsyslog_flags="" # Trim log files # NTP ntpd=YES # # # # # # # # # # IPv4 routing IPv4 forwarding is enabled in /etc/rc.local -> sysctl -w net.inet.ip.forwarding=1 Routing daemons are started via daemontools -> /service/gated IPv6 routing IPv6 forwarding is enabled in /etc/rc.local -> sysctl -w net.inet6.ip6.forwarding=1 Routing daemons are started via daemontools -> /service/zebra

84

Concept: November 24, 2002

91

Conﬁguration Log

IPv6 Conﬁguration

# -> /service/bgpd ip6mode=router ip6sitelocal=YES rtadvd=YES rtadvd_flags="sq0" rtsol=NO rtsol_flags="-a" # for ip6mode=autohost only [email protected]# /etc/rc.local [email protected]# cat /etc/rc.local # $NetBSD: rc.local,v 1.29 2000/10/07 00:22:44 hubertf Exp $ # originally from: @(#)rc.local 8.3 (Berkeley) 4/28/94 # # This file is (nearly) the last thing invoked by /etc/rc during a # normal boot, via /etc/rc.d/local. # # It is intended to be edited locally to add site-specific boot-time # actions, such as starting locally installed daemons. # # An alternative option is to create site-specific /etc/rc.d scripts. # echo -n ’starting local daemons:’ # Add your local daemons here. # # RADIUS #if [ -f /usr/pkg/etc/rc.d/radiusd ]; then # /usr/pkg/etc/rc.d/radiusd start #fi #echo ’-> radiusd’ # Enable ip forwarding sysctl -w net.inet.ip.forwarding=1 sysctl -w net.inet6.ip6.forwarding=1 # # We’re using Daemontools to manage local services - starting svscan # env - PATH=/usr/local/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/sbin:/usr/bin:/bin csh cf ’svscan /service &’ [email protected]# /etc/ifconﬁg.* [email protected]# cat /etc/ifconfig.lo0 inet6 fefe::d prefixlen 128 alias [email protected]# [email protected]# cat /etc/ifconfig.sq0 up

85

Concept: November 24, 2002

92

Conﬁguration Log

IPv6 Conﬁguration

172.16.255.2 netmask 0xffffff00 inet6 fefe:d::1 prefixlen 64 alias [email protected]# [email protected]# cat /etc/ifconfig.gif0 create tunnel 172.16.255.2 172.16.254.2 inet6 up [email protected]# [email protected]# cat /etc/ifconfig.gif1 create tunnel 172.16.255.2 172.16.0.11 inet6 up [email protected]# [email protected]# cat /etc/ifconfig.gif2 create tunnel 172.16.255.2 172.16.0.12 inet6 up [email protected]# /etc/zebra.conf ! ! $Id: dinghy-ipv6-zebra.conf,v 1.1 2002/10/23 16:00:32 markus Exp $ ! hostname Dinghy(zebra) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/zebra.log ! interface sq0 description To routers Core4 (IPv4, IPv6) and Core1 (IPv4) ipv6 address fefe:d::1/64 ipv6 nd suppress-ra ! interface lo0 description $Id: dinghy-ipv6-zebra.conf,v 1.1 2002/10/23 16:00:32 markus Exp $ ipv6 address fefe::d/128 ! interface ppp0 description ***unused*** ipv6 nd suppress-ra ! interface ppp1 description ***unused*** ipv6 nd suppress-ra ! interface sl0 description ***unused*** ipv6 nd suppress-ra !

86

Concept: November 24, 2002

93

Conﬁguration Log

IPv6 Conﬁguration

interface sl1 description ***unused*** ipv6 nd suppress-ra ! interface strip0 description ***unused*** ipv6 nd suppress-ra ! interface strip1 description ***unused*** ipv6 nd suppress-ra ! interface gif0 description IPv6 tunnel to router Anchor ipv6 nd suppress-ra ! interface gif1 description IPv6 tunnel to router Edge1 ipv6 nd suppress-ra ! interface gif2 description IPv6 tunnel to router Edge2 ipv6 address fefe:bb:d::5/126 ipv6 nd suppress-ra ! ip route 224.0.0.5/32 127.0.0.1 ip route 224.0.0.6/32 127.0.0.1 ipv6 route fefe::a/128 gif0 ipv6 route fefe::e1/128 gif1 253 ipv6 route fefe::e2/128 gif2 253 ipv6 route fefe::e3/128 fefe:d::2 253 ! ! line vty ! /etc/bgpd.conf ! ! $Id: dinghy-ipv6-bgpd.conf,v 1.1 2002/10/23 16:00:40 markus Exp $ ! hostname Dinghy(bgpd) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/bgpd.log ! router bgp 65000 bgp deterministic-med neighbor MESH peer-group neighbor MESH remote-as 65000

87

Concept: November 24, 2002

94

Conﬁguration Log

IPv6 Conﬁguration

neighbor MESH description Fellow route reflectors neighbor MESH update-source lo0 no neighbor MESH activate !*! Edge1 neighbor fefe::e1 remote-as 65000 neighbor fefe::e1 update-source lo0 no neighbor fefe::e1 activate !*! Edge2 neighbor fefe::e2 remote-as 65000 neighbor fefe::e2 update-source lo0 no neighbor fefe::e2 activate !*! Edge3 (Core4) neighbor fefe::e3 remote-as 65000 neighbor fefe::e3 update-source lo0 no neighbor fefe::e3 activate ! address-family ipv6 redistribute connected redistribute static neighbor MESH activate neighbor MESH next-hop-self neighbor MESH route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor fefe::a peer-group MESH !*! Edge1 neighbor fefe::e1 activate neighbor fefe::e1 route-reflector-client neighbor fefe::e1 next-hop-self neighbor fefe::e1 route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out !*! Edge2 neighbor fefe::e2 activate neighbor fefe::e2 route-reflector-client neighbor fefe::e2 next-hop-self neighbor fefe::e2 route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out !*! Edge3 neighbor fefe::e3 activate neighbor fefe::e3 route-reflector-client neighbor fefe::e3 next-hop-self neighbor fefe::e3 route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 set ipv6 next-hop global fefe::d ! line vty !

88

Concept:

November 24, 2002

95

Conﬁguration Log

IPv6 Conﬁguration

A.2.3

Router Edge1 - IPv6
The following commands add IPv6 to the base IPv4 conﬁguration of the router. ! $Id: edge1-ipv6-confg,v 1.12 2002/10/25 14:20:23 markus Exp $ ! ! Add IPv6 to the IPv4 configuration of router Edge1 ! ipv6 unicast-routing ! ! Configure interfaces ! interface loopback 0 ipv6 address fefe::e1/128 exit ! interface loopback 20 description $Id: edge1-ipv6-confg,v 1.12 2002/10/25 14:20:23 markus Exp $ ! interface ethernet 0 ipv6 address fefe:e1::1/64 exit ! interface tunnel 0 description IPv6 tunnel to router Anchor ipv6 unnumbered loopback 0 ipv6 enable tunnel source loopback 0 tunnel destination 172.16.254.2 tunnel mode ipv6ip exit ! interface tunnel 1 description IPv6 tunnel to router Dinghy ipv6 unnumbered loopback 0 ipv6 enable tunnel source loopback 0 tunnel destination 172.16.255.2 tunnel mode ipv6ip exit ! ! Configure BGP Routing ! ipv6 route fefe::a/128 Tunnel0 ipv6 route fefe::d/128 Tunnel1 ! router bgp 65000 no synchronization bgp log-neighbor-changes

89

Concept: November 24, 2002

96

Conﬁguration Log

IPv6 Conﬁguration

bgp deterministic-med neighbor ROUTE-REFLECTORS peer-group neighbor ROUTE-REFLECTORS remote-as 65000 neighbor ROUTE-REFLECTORS description Upstream route reflector servers neighbor ROUTE-REFLECTORS update-source Loopback0 no neighbor ROUTE-REFLECTORS activate no auto-summary ! address-family ipv6 neighbor ROUTE-REFLECTORS activate neighbor ROUTE-REFLECTORS next-hop-self neighbor ROUTE-REFLECTORS send-community neighbor ROUTE-REFLECTORS route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor fefe::a peer-group ROUTE-REFLECTORS neighbor fefe::d peer-group ROUTE-REFLECTORS no synchronization redistribute connected exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 description Set next hop to global IPv6 addr; default is using link local IPv6 addr set ipv6 next-hop fefe::e1 ! ! Configure RIPv6 Routing ! ipv6 router rip EDGE-LAN distance 254 redistribute bgp 65000 metric 10 distribute-list prefix-list DENY_ALL in ! ipv6 prefix-list DENY_ALL seq 5 deny ::/0 ! interface Ethernet0 ipv6 rip EDGE-LAN enable ! ! End of module IPv6-Edge1

90

Concept:

November 24, 2002

97

Conﬁguration Log

IPv6 Conﬁguration

A.2.4

Router Edge2 - IPv6
The following commands add IPv6 to the base IPv4 conﬁguration of the router. ! $Id: edge2-ipv6-confg,v 1.14 2002/10/25 14:21:15 markus Exp $ ! ! Add IPv6 to the IPv4 configuration of router Edge2 ! ipv6 unicast-routing ! ! Configure interfaces ! interface loopback 0 ipv6 address fefe::e2/128 exit ! interface loopback 20 description $Id: edge2-ipv6-confg,v 1.14 2002/10/25 14:21:15 markus Exp $ ! interface ethernet 0 ipv6 address fefe:e2::1/64 exit ! interface tunnel 0 description IPv6 tunnel to router Anchor ipv6 unnumbered loopback 0 ipv6 enable tunnel source loopback 0 tunnel destination 172.16.254.2 tunnel mode ipv6ip exit ! interface tunnel 1 description IPv6 tunnel to router Dinghy ipv6 unnumbered loopback 0 ipv6 enable tunnel source loopback 0 tunnel destination 172.16.255.2 tunnel mode ipv6ip exit ! ! Configure BGP Routing ! ipv6 route fefe::a/128 Tunnel0 ipv6 route fefe::d/128 Tunnel1 ! router bgp 65000 no synchronization bgp log-neighbor-changes

91

Concept: November 24, 2002

98

Conﬁguration Log

IPv6 Conﬁguration

bgp deterministic-med neighbor ROUTE-REFLECTORS peer-group neighbor ROUTE-REFLECTORS remote-as 65000 neighbor ROUTE-REFLECTORS description Upstream route reflector servers neighbor ROUTE-REFLECTORS update-source Loopback0 no neighbor ROUTE-REFLECTORS activate no auto-summary ! address-family ipv6 neighbor ROUTE-REFLECTORS activate neighbor ROUTE-REFLECTORS next-hop-self neighbor ROUTE-REFLECTORS send-community neighbor ROUTE-REFLECTORS route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor fefe::a peer-group ROUTE-REFLECTORS neighbor fefe::d peer-group ROUTE-REFLECTORS no synchronization redistribute connected exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 description Set next hop to global IPv6 addr; default is using link local IPv6 addr set ipv6 next-hop fefe::e2 ! ! Configure RIPv6 Routing ! ipv6 router rip EDGE-LAN distance 254 redistribute bgp 65000 metric 10 distribute-list prefix-list DENY_ALL in ! ipv6 prefix-list DENY_ALL seq 5 deny ::/0 ! interface Ethernet0 ipv6 rip EDGE-LAN enable ! ! End of module IPv6-Edge2

92

Concept:

November 24, 2002

99

Conﬁguration Log

IPv6 Conﬁguration

A.2.5

Router Core4 - IPv6
/etc/rc.conf [email protected]# cat /etc/rc.conf # $NetBSD: rc.conf,v 1.85.2.9 2001/04/24 22:42:44 he Exp $ # # see rc.conf(5) for more information. # # Use program=YES to enable program, NO to disable it. program_flags are # passed to the program on the command line. # # Load the defaults in from /etc/defaults/rc.conf (if it’s readable). # These can be overridden below. # if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf fi # If this is not set to YES, the system will drop into single-user mode. # rc_configured=YES # Add local overrides below # # Console wscons=YES # Logging newsyslog=YES newsyslog_flags="" # Trim log files # NTP ntpd=YES # MPLS - AYAME # Interface options are set in rc.local # -> /usr/ayame/sbin/ifconfig lo0 mtu 1500 # -> /usr/ayame/sbin/ifconfig lo0 mpls 0:0 # Multicast route is set in rc.local # -> route add -net 224.0.0.0 -netmask 255.0.0.0 127.0.0.1 # Kernel options are set in rc.local # -> /usr/ayame/sbin/sysctl -w net.mpls.mapttl_ip=0 # Daemons are started via daemontools # -> /service/ayamed # -> /service/ldpd mpls=YES

93

Concept: November 24, 2002

100

Conﬁguration Log

IPv6 Conﬁguration

# # # # # #

IPv4 routing IPv4 forwarding is enabled in /etc/rc.local -> sysctl -w net.inet.ip.forwarding=1 Routing daemons are started via daemontools -> /service/zebra -> /service/ospfd

# IPv6 routing # IPv6 forwarding is enabled in /etc/rc.local # -> sysctl -w net.inet6.ip.forwarding=1 # Routing daemons are started via daemontools # -> /service/zebra # -> /service/bgpd ip6mode=router # host, autohost or router #ip6sitelocal=YES # IPv6 sitelocal addrs -> NetBSD 1.6 rtsol=NO rtsol_flags="-a" # for ip6mode=autohost only rtadvd=YES rtadvd_flags="ne2" [email protected]# /etc/rc.local [email protected]# cat /etc/rc.local # $NetBSD: rc.local,v 1.25.10.2 2000/10/07 20:21:35 hubertf Exp $ # originally from: @(#)rc.local 8.3 (Berkeley) 4/28/94 # # This file is (nearly) the last thing invoked by /etc/rc during a # normal boot, via /etc/rc.d/local. # # It is intended to be edited locally to add site-specific boot-time # actions, such as starting locally installed daemons. # # An alternative option is to create site-specific /etc/rc.d scripts. # echo -n ’starting local daemons:’ # Add your local daemons here. # # Enable ip forwarding sysctl -w net.inet.ip.forwarding=1 sysctl -w net.inet6.ip6.forwarding=1 # MPLS - AYAME # Interface options /usr/ayame/sbin/ifconfig lo0 mtu 1500 /usr/ayame/sbin/ifconfig lo0 mpls 0:0 # Multicast route route add -net 224.0.0.0 -netmask 255.0.0.0 127.0.0.1 # Kernel options /usr/ayame/sbin/sysctl -w net.mpls.mapttl_ip=0

94

Concept: November 24, 2002

101

Conﬁguration Log

IPv6 Conﬁguration

# Daemons are started via daemontools # -> /service/ayamed # -> /service/ldpd # # We’re using Daemontools to start local services - starting svscan now # env - PATH=/usr/local/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/sbin:/usr/bin:/bin csh cf ’svscan /service &’ # German keyboard wsconsctl -k -w encoding=de [email protected]# /etc/ifconﬁg.* [email protected]# cat /etc/ifconfig.lo0 inet6 fefe::e3 prefixlen 128 alias [email protected]# [email protected]# cat /etc/ifconfig.rtk0 172.16.3.2 netmask 0xfffffffc media 10baseT [email protected]# [email protected]# cat /etc/ifconfig.rtk1 172.16.255.4 netmask 0xffffff00 media 10baseT inet6 fefe:d::2 prefixlen 64 alias [email protected]# [email protected]# cat /etc/ifconfig.ne2 10.3.1.1 netmask 0xffffff00 media autoselect inet6 fefe:e3::1 prefixlen 64 alias [email protected]# [email protected]# cat /etc/ifconfig.gif0 create tunnel 10.3.1.1 172.16.254.2 inet6 up [email protected]# /etc/zebra.conf [email protected]# cat /etc/zebra.conf ! ! Zebra configuration saved from vty ! 2002/10/12 20:04:09 ! hostname Core4(zebra) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/zebra.log ! debug zebra events ! interface ne2

95

Concept: November 24, 2002

102

Conﬁguration Log

IPv6 Conﬁguration

description Edge LAN ipv6 nd suppress-ra ! interface rtk0 description IPv4-only link to Core3 ipv6 nd suppress-ra ! interface rtk1 description IPv4/IPv6 link to Core1 and Dinghy ipv6 nd suppress-ra ! interface lo0 description Loopback for BGP peering (IPv6) ! interface ppp0 ipv6 nd suppress-ra ! interface ppp1 ipv6 nd suppress-ra ! interface sl0 ipv6 nd suppress-ra ! interface sl1 ipv6 nd suppress-ra ! interface strip0 ipv6 nd suppress-ra ! interface strip1 ipv6 nd suppress-ra ! interface tun0 ipv6 nd suppress-ra ! interface tun1 ipv6 nd suppress-ra ! interface gre0 ipv6 nd suppress-ra ! interface gre1 ipv6 nd suppress-ra ! interface ipip0 ipv6 nd suppress-ra ! interface ipip1 ipv6 nd suppress-ra

96

Concept: November 24, 2002

103

Conﬁguration Log

IPv6 Conﬁguration

! interface gif0 description IPv6 tunnel to router Anchor ipv6 nd suppress-ra ! interface gif1 description IPv6 tunnel to router Dinghy ipv6 nd suppress-ra ! interface gif2 ipv6 nd suppress-ra ! interface gif3 ipv6 nd suppress-ra ! ip route 224.0.0.5/32 127.0.0.1 ip route 224.0.0.6/32 127.0.0.1 ipv6 route fefe::a/128 gif0 ipv6 route fefe::d/128 fefe:d::1 ! ! line vty ! [email protected]# /etc/bgpd.conf [email protected]# cat /etc/bgpd.conf ! ! Zebra configuration saved from vty ! 2002/10/12 20:11:10 ! hostname Core4(bgpd) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/bgpd.log ! router bgp 65000 bgp deterministic-med neighbor ROUTE-REFLECTORS peer-group neighbor ROUTE-REFLECTORS remote-as 65000 neighbor ROUTE-REFLECTORS description Upstream route reflector servers neighbor ROUTE-REFLECTORS update-source Loopback0 no neighbor ROUTE-REFLECTORS activate ! address-family ipv6 redistribute connected neighbor ROUTE-REFLECTORS activate neighbor ROUTE-REFLECTORS next-hop-self neighbor ROUTE-REFLECTORS route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out

97

Concept: November 24, 2002

104

Conﬁguration Log

IPv6 Conﬁguration

neighbor fefe::a peer-group ROUTE-REFLECTORS neighbor fefe::d peer-group ROUTE-REFLECTORS exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 set ipv6 next-hop global fefe::e3 ! line vty ! [email protected]#

98

Concept:

November 24, 2002

105

Conﬁguration Log

RADIUS

A.3

RADIUS
The following ﬁles conﬁgure RADIUS on host Dinghy. /usr/pkg/etc/raddb/clients [email protected]# cat /usr/pkg/etc/raddb/clients # # clients This file contains a list of clients which are allowed to # make authentication requests and their encryption key. # # Description of the fields: # # * The first field is a valid hostname or IP address # for the client. # * The second field (seperated by blanks or tabs) is the # encryption key. # Client Name #---------------core1.brest.lab core2.brest.lab core3.brest.lab edge1.brest.lab edge2.brest.lab edge3.brest.lab /usr/pkg/etc/raddb/naslist [email protected]# cat /usr/pkg/etc/raddb/naslist # # naslist This file contains a list of NASes (Network Access Servers, # also known as terminal servers) which we know. # # Description of the fields: # # * The first field is a valid hostname or IP address # for the client. It’s matched against the NAS-IP-Address # sent in the radius packets by the client. # * The second field (seperated by blanks or tabs) is the # short name we use in the logfiles for this NAS. # This means /var/log/radacct/<shortname>/detail, # and Sxx:<shortname> in the radwtmp file. # * The third field defines what type of device it is. Valid # values are "livingston", "cisco", etc etc. # This is used to find out how to detect simultaneous logins. # Please read doc/README.simul for further information. # # You can use DEFAULT as a catch-all. # Key ---------Brest-Lab Brest-Lab Brest-Lab Brest-Lab Brest-Lab Brest-Lab

99

Concept: November 24, 2002

106

Conﬁguration Log

RADIUS

# NAS Name #---------------core1.brest.lab core2.brest.lab core3.brest.lab edge1.brest.lab edge2.brest.lab edge3.brest.lab DEFAULT /usr/pkg/etc/raddb/users

Short Name ---------core1 core2 core3 edge1 edge2 edge3 default

Type ---cisco cisco cisco cisco cisco other other

[email protected]# cat /usr/pkg/etc/raddb/users # # This file contains security and configuration information # for each user. # # # This is the enable password used for all of our routers. # $enab15$ Auth-Type = Local, Password = "q1w2e3r4" Service-Type = Administrative-User # # All accounts are checked against the UNIX /etc/passwd # unless a password was already given earlier in this file. # DEFAULT Auth-Type = System Fall-Through = 1 #

100

Concept:

November 24, 2002

107

Conﬁguration Log

Ploticus

A.4

Ploticus
zerberus.sh # $Id: zerberus.sh,v 1.1 2002/08/22 19:21:39 markus Exp $ date +"%Y%m%d %H:%M" >> /home/markus/log/zerberus-cpu.log rtr2 zerberus show proc cpu | grep CPU >> /home/markus/log/zerberus-cpu.log date +"%Y%m%d %H:%M" >> /home/markus/log/zerberus-memory.log rtr2 zerberus show proc mem | grep Total: >> /home/markus/log/zerberus-memory.log cpu.pl // $Id: cpu.pl,v 1.1 2002/08/22 19:21:13 markus Exp $ #proc getdata file: ../log/zerberus-cpu.log delim: space fieldnames: datestamp timestamp CPU utilization for five seconds: crap one minute: cpu1 five minutes: cpu-5 showresults: yes #proc areadef areaname: standard title: CPU Utilization (5 Minute Moving Average) titledetails: align=C size=12 style=B adjust=0,0.2 rectangle: 1 1 7.5 4 xscaletype: time hh:mm //xautorange: datafield=timestamp xrange: 17:00 20:00 yscaletype: linear yrange: 0 100 frame: yes #proc xaxis grid: color=oceanblue gridskip: minmax label: Time labeldetails: size=10 style=B adjust=0,-0.4 stubs: incremental 5 stubformat: hh:mm stubvert: yes #proc yaxis grid: color=oceanblue gridskip: minmax label: Percent labeldetails: size=10 style=B stubs: incremental 10

101

Concept: November 24, 2002

108

Conﬁguration Log

Ploticus

#proc lineplot xfield: timestamp yfield: cpu-5 stairstep: yes // gapmissing: yes // Documented on the web site but not available in my ploticus numbers: yes linedetails: width=2 color=green //fill: green legendlabel: Moving average over 5 minutes read from router //#proc curvefit // curvetype: movingavg // xfield: timestamp // yfield: cpu-5 // order: 12 // linedetails: color=red // legendlabel: Moving average over 60 min //#proc legend // location: min+1 min-0.5 // format: singleline mem.pl // $Id: mem.pl,v 1.1 2002/08/22 19:21:22 markus Exp $ #proc getdata file: ../log/zerberus-memory.log delim: space fieldnames: datestamp timestamp Total: total-mem Used: used-mem Free: free-mem showresults: yes #proc areadef areaname: standard title: Processor Memory Utilization (5 Minute) titledetails: align=C size=12 style=B adjust=0,0.2 rectangle: 1 1 7.5 4 xscaletype: time hh:mm //xautorange: datafield=timestamp xrange: 17:00 20:00 yscaletype: linear yrange: 0 16384000 // Adopt this to the processor memory in the router; // Zerberus has 16MB, 14MB are processor memory frame: yes #proc xaxis grid: color=oceanblue gridskip: minmax label: Time labeldetails: size=10 style=B

102

Concept: November 24, 2002

109

Conﬁguration Log

Ploticus

labeldistance: 0.65 stubs: incremental 5 stubformat: hh:mm stubvert: yes #proc yaxis grid: color=oceanblue gridskip: minmax label: Byte labeldetails: size=10 style=B labeldistance: 0.75 stubs: incremental 1000000 //1048576 stubformat: %3.0f #proc lineplot xfield: timestamp yfield: total-mem stairstep: yes //gapmissing: yes // Documented on the web site but not available in my ploticus linedetails: width=2 color=blue legendlabel: Total memory #proc lineplot xfield: timestamp yfield: used-mem stairstep: yes //gapmissing: yes // Documented on the web site but my ploticus complains linedetails: width=2 color=red legendlabel: Used memory #proc lineplot xfield: timestamp yfield: free-mem stairstep: yes //gapmissing: yes // Documented on the web site but not available in my ploticus linedetails: width=2 color=green legendlabel: Free memory #proc legend location: min+0.75 min-0.65 format: singleline

103

Concept:

November 24, 2002

110

Conﬁguration Log

MRTG

A.5

MRTG
mrtg.conf # # $Id: mrtg.conf,v 1.1 2002/09/23 18:09:46 mrtg Exp $ # # # Set global options # WorkDir: /home/mrtg/public_html RunAsDaemon:Yes Refresh: 300 Interval: 5 WriteExpires: Yes #Language: german # # Load per-router configuration files # Include: edge1-cpu_mrtg.conf Include: edge1-memory_mrtg.conf Include: edge2-cpu_mrtg.conf Include: edge2-memory_mrtg.conf Include: hub1-cpu_mrtg.conf Include: hub1-memory_mrtg.conf router name-cpu mrtg.conf # # # # # # # # # # # # # # # $Id: router_name-cpu_mrtg.conf,v 1.2 2002/09/25 12:58:08 root Exp $ Graph CPU load of a Cisco router OID avgBusy5 1.3.6.1.4.1.9.2.1.58.0 5 minute exponentially-decayed moving average of the CPU busy percentage. avgBusy1 1.3.6.1.4.1.9.2.1.57.0 1 minute exponentially-decayed moving average of the CPU busy percentage.

OID

Replace this variables to individalize this template: <ROUTER_NAME> <ROUTER_SHORT_NAME> <SNMP_COMMUNITY>

104

Concept: November 24, 2002

111

Conﬁguration Log

MRTG

Target[cpu-<ROUTER_SHORT_NAME>]: 1.3.6.1.4.1.9.2.1.58.0&1.3.6.1.4.1.9.2.1.57.0:<SNMP_COMMUNITY>@<ROUT RouterUptime[cpu-<ROUTER_SHORT_NAME>]: <SNMP_COMMUNITY>@<ROUTER_NAME> Supress[cpu-<ROUTER_SHORT_NAME>]: wmy PageTop[cpu-<ROUTER_SHORT_NAME>]: <H1>CPU Statistics for Router <ROUTER_SHORT_NAME></H1> Title[cpu-<ROUTER_SHORT_NAME>]: CPU Statistics for Router <ROUTER_SHORT_NAME> PageFoot[cpu-<ROUTER_SHORT_NAME>]: <P>Data for OIDs "avgBusy5" and "avgBusy1" is collected in 5 minut MaxBytes[cpu-<ROUTER_SHORT_NAME>]: 100 Directory[cpu-<ROUTER_SHORT_NAME>]: <ROUTER_SHORT_NAME> Options[cpu-<ROUTER_SHORT_NAME>]: gauge, growright, unknaszero, nobanner Colours[cpu-<ROUTER_SHORT_NAME>]: RED#ff0000,BLUE#1000ff,GREEN#006600,VIOLET#ff00ff YLegend[cpu-<ROUTER_SHORT_NAME>]: Percent ShortLegend[cpu-<ROUTER_SHORT_NAME>]: % Legend1[cpu-<ROUTER_SHORT_NAME>]: 5 minute average of CPU busy Legend2[cpu-<ROUTER_SHORT_NAME>]: 1 minute average of CPU busy LegendI[cpu-<ROUTER_SHORT_NAME>]:  5min: LegendO[cpu-<ROUTER_SHORT_NAME>]:  1min: router name-memory mrtg.conf # # # # # # # # # # # # # # # # # # # # # # # # $Id: router_name-memory_mrtg.conf,v 1.2 2002/09/25 13:40:06 root Exp $ Graph memory utilization of a Cisco router OID ciscoMemoryPoolUsed 1.3.6.1.4.1.9.9.48.1.1.1.5.0 Indicates the number of bytes from the memory pool that are currently in use by applications on the managed device. ciscoMemoryPoolFree 1.3.6.1.4.1.9.9.48.1.1.1.6.0 Indicates the number of bytes from the memory pool that are currently unused on the managed device. Note that the sum of ciscoMemoryPoolUsed and ciscoMemoryPoolFree is the total amount of memory in the pool ciscoMemoryPoolLargestFree 1.3.6.1.4.1.9.9.48.1.1.1.7.0 Indicates the largest number of contiguous bytes from the memory pool that are currently unused on the managed device.

OID

OID

Replace this variables to individalize this template: <ROUTER_NAME> <ROUTER_SHORT_NAME> <SNMP_COMMUNITY> <PHYSICAL_MEMORY> Amount of DRAM (in MB) present in the router. <PROCESSOR_MEMORY> Use the value from the "show version display" (in byte)

Target[mem-<ROUTER_SHORT_NAME>]: 1.3.6.1.4.1.9.9.48.1.1.1.5.0&1.3.6.1.4.1.9.9.48.1.1.1.6.0:<SNMP_COMM RouterUptime[mem-<ROUTER_SHORT_NAME>]: <SNMP_COMMUNITY>@<ROUTER_NAME> Supress[mem-<ROUTER_SHORT_NAME>]: wmy PageTop[mem-<ROUTER_SHORT_NAME>]: <H1>Memory Statistics for Router <ROUTER_SHORT_NAME></H1> <P>Router has <PHYSICAL_MEMORY> MB of DRAM installed.

105

Concept: November 24, 2002

112

Conﬁguration Log

MRTG

<PROCESSOR_MEMORY> Byte are used as processor memory.</P> Title[mem-<ROUTER_SHORT_NAME>]: Memory Statistics for Router <ROUTER_SHORT_NAME> PageFoot[mem-<ROUTER_SHORT_NAME>]: <P>Data for OIDs is collected in 5 minute intervals.</P> <P>The sum of ciscoMemoryPoolUsed and ciscoMemoryPoolFree is the total amount of memory in the pool.</P> MaxBytes[mem-<ROUTER_SHORT_NAME>]: <PROCESSOR_MEMORY> Unscaled[mem-<ROUTER_SHORT_NAME>]: d Directory[mem-<ROUTER_SHORT_NAME>]: <ROUTER_SHORT_NAME> Options[mem-<ROUTER_SHORT_NAME>]: gauge, integer, growright, unknaszero, nobanner Colours[mem-<ROUTER_SHORT_NAME>]: RED#ff0000,BLUE#1000ff,GREEN#006600,VIOLET#ff00ff YLegend[mem-<ROUTER_SHORT_NAME>]: Bytes ShortLegend[mem-<ROUTER_SHORT_NAME>]: byte Legend1[mem-<ROUTER_SHORT_NAME>]: Bytes from the memory pool that are used Legend2[mem-<ROUTER_SHORT_NAME>]: Bytes from the memory pool that are unused LegendI[mem-<ROUTER_SHORT_NAME>]:  usedBytes: LegendO[mem-<ROUTER_SHORT_NAME>]:  freeBytes:

Target[memfree-<ROUTER_SHORT_NAME>]: 1.3.6.1.4.1.9.9.48.1.1.1.6.0&1.3.6.1.4.1.9.9.48.1.1.1.7.0:<SNMP_ RouterUptime[memfree-<ROUTER_SHORT_NAME>]: <SNMP_COMMUNITY>@<ROUTER_SHORT_NAME> Supress[memfree-<ROUTER_SHORT_NAME>]: wmy PageTop[memfree-<ROUTER_SHORT_NAME>]: <H1>Free Memory Statistics for Router <ROUTER_SHORT_NAME></H1> <P>Router has <PHYSICAL_MEMORY> MB of DRAM installed. <PROCESSOR_MEMORY> Byte are used as processor memory.</P> Title[memfree-<ROUTER_SHORT_NAME>]: Free Memory Statistics for Router <ROUTER_SHORT_NAME> PageFoot[memfree-<ROUTER_SHORT_NAME>]: <P>Data for OIDs is collected in 5 minute intervals.</P> <P>Do we have fragmented memory?</P> MaxBytes[memfree-<ROUTER_SHORT_NAME>]: <PROCESSOR_MEMORY> Unscaled[memfree-<ROUTER_SHORT_NAME>]: d Directory[memfree-<ROUTER_SHORT_NAME>]: <ROUTER_SHORT_NAME> Options[memfree-<ROUTER_SHORT_NAME>]: gauge, integer, growright, unknaszero, nobanner Colours[memfree-<ROUTER_SHORT_NAME>]: RED#ff0000,BLUE#1000ff,GREEN#006600,VIOLET#ff00ff YLegend[memfree-<ROUTER_SHORT_NAME>]: Bytes ShortLegend[memfree-<ROUTER_SHORT_NAME>]: byte Legend1[memfree-<ROUTER_SHORT_NAME>]: Bytes from the memory pool that are unused Legend2[memfree-<ROUTER_SHORT_NAME>]: Largest block (contigious bytes) of free memory LegendI[memfree-<ROUTER_SHORT_NAME>]:  freeBytes: LegendO[memfree-<ROUTER_SHORT_NAME>]:  largestBlock:

106

Concept:

November 24, 2002

113

Conﬁguration Log

Expect

A.6

Expect
rtr3 #!/usr/pkg/bin/expect -# # $Id: rtr3,v 1.3 2002/09/30 18:21:50 markus Exp $ # # Connect to a Cisco/Zebra/Unix box and execute one or multiple commands # Cisco: A box prompting "Username:" is considered a Cisco router. # Logon uses username/password/enable_password # Zebra: A box prompting "Password:" is considered a Zebra router # or a Cisco router without username. # Logon uses password/enable_password # Unix: A box prompting "login:" is considered a Unix machine. # Login uses username/password/root_password # # Syntax: rtr3 <router> [<cli_command> [: <cli_command>]] # # Implicit: username/password tupel for any router is defined in this script # empty command string connects to the router interactively # # Caveats: (1) Passing command flags to Unix boxes does not work. # (2) Script does not work with pre-authenticated access such as Kerberos. # (3) Script requires prompts containing the character > in # unpriviledged mode and prompts containing the character # in # priviledged mode. # Set default values set cisco_username admin set cisco_password geheim set cisco_enable_password strenggeheim set unix_username admin set unix_password geheim set unix_root_password strenggeheim set zebra_password geheim set zebra_enable_password strenggeheim # Redefine defaults with user specific values if [file exists ~/.rtr3] { source ~/.rtr3 } else { puts "ERROR: ~/.rtr3 does not exist" puts "Default username and passwords are most likely not suitable for your network." puts "" puts "~/.rtr3 format:" puts "set cisco_username <username>" puts "set cisco_password <password>" puts "set cisco_enable_password <password>"

107

Concept: November 24, 2002

114

Conﬁguration Log

Expect

puts puts puts puts puts exit }

"set "set "set "set "set 1

unix_username <username>" unix_password <password>" unix_root_password <password>" zebra_password <password>" zebra_enable_password <password>"

# # Procedure execute_command # proc execute_command {command_string remote_box} { if {$command_string == "INTERACTIVE"} { interact exit 0 } else { # Give a command up to 5 min. to complete set timeout 300 switch -- $remote_box "CISCO" { send "term expect "#" } "ZEBRA" { send "term expect "#" } default {} } { leng 0\r" {} default { puts "Error. Giving up."; exit 1 }

leng 0\r" {} default { puts "Error. Giving up."; exit 1 }

foreach element $command_string { if {$element == ":"} { send \r expect "#" {} default { puts "Error. Giving up."; exit 1 } } else { send "$element " } ;# closes if } ;# closes foreach send \r; expect "#" {} default { puts "Error. Giving up."; exit 1 } exit 0 } } # # End of procedure execute_command #

108

Concept: November 24, 2002

115

Conﬁguration Log

Expect

# # Procedure logon_cisco # # Telnet returned a "Username:" prompt => assuming remote box is Cisco proc logon_cisco {username password enable_password command remote_box} { send "$username\r" expect "Password:" {} default { puts "Error. Giving up."; exit 1 } send "$password\r" expect { ">" {} "% Authentication failed." { exit 1 } default { puts "Error. Giving up."; exit 1 } } send "enable\r" expect "Password:" {} default { puts "Error. Giving up."; exit 1 } send "$enable_password\r" expect { "#" {execute_command $command $remote_box; return} "Access denied" {exit 1} default { puts "Error. Giving up."; exit 1 } } } # # End of procedure logon_cisco # # # Procedure logon_zebra # # Telnet returned a "Password:" prompt => assuming remote box is Zebra proc logon_zebra {password enable_password command remote_box} { send "$password\r" expect { ">" {} "Authentication failed" { exit 1 } default { puts "Error. Giving up."; exit 1 } } send "enable\r" expect "Password:" {} default { exit 1 } send "$enable_password\r" expect { "#" {execute_command $command $remote_box; return} "Access denied" {exit 1} default { puts "Error. Giving up."; exit 1 } } } #

109

Concept: November 24, 2002

116

Conﬁguration Log

Expect

# End of procedure logon_zebra # # # Procedure logon_unix # # Telnet returned a "login:" prompt => assuming remote box is NetBSD proc logon_unix {username password root_password command remote_box} { send "$username\r" expect "Password:" {} default { exit send "$password\r" expect { ">" {} "Login incorrect" { exit 1 } default { puts "Error. Giving } send "su -\r" expect "Password:" {} default { puts send "$root_password\r" expect { "#" {execute_command $command "Sorry" {exit 1} default { puts "Error. Giving } } # # End of procedure logon_unix #

1 }

up."; exit 1 }

"Error. Giving up."; exit 1 }

$remote_box; return} up."; exit 1 }

########## ########## ########## ########## ########## ########## ########## # # Main procedure # # check arguments if {[llength $argv] == 0} { puts "Connect to a Cisco/Zebra/Unix box and execute one or multiple commands" puts " " puts "Syntax: rtr3 \<router\> \[\<command string\> \[ : \<command string\>\]\]" puts "" puts "Example:" puts "rtr3 zebrabox:2604 show ip ospf neigh : show ip ospf database" puts "rtr3 ciscobox conf t : int eth 0 : shutdown" puts "rtr3 unixbox ifconfig de0 : ifconfig ep1 : cat /etc/gated.conf" puts "" puts "Implicit:" puts "Username/password/enable_password of targets must be defined in ~/.rtr3" puts "Empty command string connects to the router interactively"

110

Concept: November 24, 2002

117

Conﬁguration Log

Expect

puts puts puts puts puts puts puts exit }

"" "Caveats:" "(1) Passing command flags to Unix boxes does not work." "(2) Script does not work with pre-authenticated access such as Kerberos." "(3) Script requires prompts containing the character > in" " unpriviledged mode and prompts containing the character # in" " priviledged mode." 1

# If we reach this point an argument was passed to the script. # Lets see what we have. set i 0 set j 0 set router "" set command "" set element "" set remote_box "UNKNOWN" foreach element $argv { incr i if {$i == 1} { set j [string first ":" $element] if {$j == -1} { # no port number given set router $element } else { # port number given regsub ":" $element " " router } } else { set command "$command$element " } } if {$command == ""} { set command "INTERACTIVE" } # The variables $router and $command store now the router name and command string # $command contains INTERACTIVE if no command string was specified # Login to the router and switch to enable mode set timeout 10 spawn /bin/sh -c "exec telnet $router"

expect { "Username:" { set remote_box "CISCO" logon_cisco $cisco_username $cisco_password $cisco_enable_password $co

111

Concept: November 24, 2002

118

Conﬁguration Log

Expect

} "Password:" { set remote_box "ZEBRA" logon_zebra $zebra_password $zebra_enable_password $command $remote_bo } "login:" { set remote_box "UNIX" logon_unix $unix_username $unix_password $unix_root_password $command } default { puts "Error telnetting to $router. Giving up." exit 1 } } exit 0 # # End of main procedure # ########## ########## ########## ########## ########## ########## ##########

112

Concept:

November 24, 2002

119

B Problem and Resolution Log
B.1 2002-09-00 - Installing NetBSD on SGI Indy

B.1.1

Status: SOLVED

B.1.2

Symptom
On a head-less Indy pressing the Escape key does not bring the machine into PROM mode.

B.1.3

Analysis
Von: Rafal Boni <[email protected]> Datum: Die, 10. Sep. 2002 20:43:00 Europe/Berlin An: Markus Boeing <[email protected]> Betreff: Re: Q: Headless Indy, How to go into PROM monitor In message <[email protected]>, you write: -> -> -> -> -> -> -> -> Hi Rafal, thanks for your reply. Well, the serial console works ok I think (I’m using <Mac modem cable>-<null modem>-<straight Cisco console cable>). I can see messages during the boot up on the terminal. I just don’t know how to get the PROM mode, pressing ESC on the serial console doesn’t help.

First, if your keyboard plugged in? If so, unplug it.... You should then at least get messages on the serial console about the KB being unavailable and it falling back to serial console... Second of all, I think you should be able to press any key to interrupt the boot if you hit it in the right period of a couple of seconds. If you *are* getting messages on the console, it might be interesting to paste (or paraphrase) what you see... There are cases (ie, a bad SCSI disk, etc.) where the PROM can hang for quite a while and not respond to input *before* it offers you a choice of doing anything (esp. if it’s attempting to do the diagnostics). (All my SGI’s are in storage right now, or I’d give you better clues 8-)

113

Concept: November 24, 2002

120

Problem and Resolution Log

2002-09-00 - Installing NetBSD on SGI Indy

--rafal ---Rafal Boni We are all worms.

But I do believe I am a glowworm.

[email protected] -- Winston Churchill

Von: Steve Rikli <[email protected]> Datum: Die, 10. Sep. 2002 21:08:17 Europe/Berlin An: [email protected] (Markus Boeing) Betreff: Re: Q: Headless Indy, How to go into PROM monitor =?ISO-8859-1?Q?Markus_B=F6ing?= wrote: > >may I ask a very basic question regarding SGI Indy operation? > >I recently acquired an Indy w/o monitor that I would like to use with >NetBSD as a lab server. My problem is that I am running the box headless >and I cannot get it into PROM mode. I can see the request to press ESC >during boot up but it seems that I cannot force the box into PROM from the >serial console. Any ideas how to do that? BTW I cannot access the box once >it booted up. It responds neither to serial console nor to telnet. Most >probably the operating system is screwed up badly. Possibly a serial cable pinout problem? E.g. maybe you have the "TX" and "RX" pins talking to the corresponding "TX" and "RX" rather than visa versa? (ie. pins 2 and 3 are flipped the wrong way?) The way it’s _supposed_ to work (in theory ;-) ) is very much like Sun hardware, if you’re familiar at all with that. That is, unplug the keyboard, plug in the serial console cable (should be a round "din-8" connector on Indy) and hit <esc> to interrupt the bootup. After that you should see a prompt which looks like ">>" -- that’s the IRIX PROM. cheers, sr. -|| Steve Rikli || Systems Administrator || || [email protected]

||| ||| ||| |||

When I was younger, I made it a rule || never to take strong drink before lunch.|| It is now my rule never to do so before || breakfast. - Winston Churchill ||

B.1.4

Solution
Replaced console cable. I am using [Indy serial port 1]-[Mac modem cable (DB25)]-[null modem]-[Cisco DB25-to-RJ45 plug (Terminal)]-[Cisco RJ45-to-RJ45 console cable (roll-over cable)]-[DEC VT510].

114

Concept:

November 24, 2002

121

Problem and Resolution Log

2002-09-00 - Installing NetBSD on SGI Indy

B.1.5

Symptom
Using PROM to boot a kernel from a TFTP server produces ”wrong magic number” error messages but does not boot the kernel.

B.1.6

Analysis
Symptom is described in in the NetBSD/sgimips FAQ (http://www.netbsd.org/Ports/sgimips/faq.html): “Another old PROM issue – old PROMs don’t understand ELF, so you may need an ECOFF kernel.”

B.1.7

Solution
Booting an uncompressed ECOFF kernel ﬁxed the problem (booting a gzipped ECOFF kernel produced the same ”wrong magic number” messages).

B.1.8

Symptom
Using PROM to boot a kernel from a TFTP server starts but then times out with error message ”no such device”.

B.1.9

Analysis
Von: Rafal Boni <[email protected]> Datum: Mit, 11. Sep. 2002 21:56:20 Europe/Berlin An: Markus Boeing <[email protected]> Kopie: [email protected] Betreff: Re: Q: Netbooting installation kernel fails on INDY In message <[email protected]>, you write: -> -> -> -> -> -> -> -> -> -> Ladies and Gents, I have yet another question regarding NetBSD installation on Indy: I am using the files from the 200209080000 directory on releng.netbsd.org. I have set up a server (NetBSD/alpha with DHCP client entry for the Indy, TFTP enabled and boot kernel in /tftpboot/netbsd) with kernel netbsd-INDY_INSTALL.ecoff. The Indy root directory holds the contents of installation/netboot/diskimage.gz.

Your Indy probably should be fine with the ELF version, but that’s not the issue here...

115

Concept: November 24, 2002

122

Problem and Resolution Log

2002-09-00 - Installing NetBSD on SGI Indy

-> -> -> -> -> -> -> -> -> -> ->

I am booting the Indy from PROM: >>boot -f bootp():/netbsd/netbsd-INDY_INSTALL.ecoff Setting $netaddr to 172.16.254.20 (from server 172.16.254.2) Obtaining /netbsd/netbsd-INDY_INSTALL.ecoff from server 172.16.254.2 5876528 Cannot load bootp():/netbsd/netbsd-INDY_INSTALL.ecoff. Error reading text section: cnt=0xc0, expected 0x59ab30. Unable to load bootp():/netbsd/netbsd-INDY_INSTALL.ecoff: no such device. The whole process takes a couple of minutes.

Please check the FAQ (at http://www.netbsd.org/Ports/sgimips/faq.html), esp. the following link: http://www.netbsd.org/Ports/sgimips/faq.html#prom-tftp-clientfailing The problem is most likely the Indy’s PROM getting confused by the returned TFTP packets and timing out the transfer. --rafal ---Rafal Boni We are all worms.

But I do believe I am a glowworm.

[email protected] -- Winston Churchill

B.1.10 Solution
Modifying the TFTP setting on the server (NetBSD/alpha) ﬁxed the problem (sysctl -w net.inet.ip.anonportmin=20000, sysctl -w net.inet.ip.anonportmax=32767).

116

Concept:

November 24, 2002

123

Problem and Resolution Log

2001-10-06 - GateD: No IP forwarding

B.2

2001-10-06 - GateD: No IP forwarding

B.2.1

Status: SOLVED

B.2.2

Symptom
GateD complains about missing support for IP forwarding during startup. This happens under NetBSD v1.5/i386 and NetBSD v1.5.2/Alpha.

B.2.3

Analysis
The GENERIC kernel of NetBSD does no have IP forwarding enabled be default. This could be veriﬁed using the command sysctl net.inet.ip.forwarding. In oder to use routing software on a NetBSD machine IP forwarding must be enabled.

B.2.4 Solution
There are two options to solve the problem: • • Compile a new kernel with IP forwarding enabled by default. Add the statement sysctl -w net.inet.ip.forwarding=1 to the ﬁle /etc/rc.local.

The second approach has been implemented.

117

Concept:

November 24, 2002

124

Problem and Resolution Log

2001-10-04 - Zebra OSPFd on NetBSD does not form Adjacency

B.3

2001-10-04 - Zebra OSPFd on NetBSD does not form Adjacency

B.3.1

Status: SOLVED

B.3.2

Symptom
List: Subject: From: Date: [Download zebra [zebra 10698] Q: OSPF is not establishing adjacency Markus Boeing <[email protected]> 2001-10-04 18:49:19 message RAW]

Ladies and Gents, may I ask for your help regarding Zebra and OSPF? I am setting up a small lab using Cisco routers, GateD and Zebra. So far I was unable to get Zebra’s OSPF up. I am using Zebra v0.91a on NetBSD 1.5/i386 (installed from package distribution) but I could observe the same behavior with Zebra v0.92a compiled from source. The lab topology is pretty simple, two Cisco routers and the Zebra box share a LAN (IPv4: 192.168.16.0/27; .1 and .2 are Cisco boxes; .3 is Zebra). BTW The Zebra box has only one interface but that is ok. I want to use it as BGP route reflector server later on. What happens now is that the Zebra box receives Hellos from the Cisco’s but itself is not sending Hellos. Therefor bidirectional communication cannot be established and an adjacency will not be formed. The Cisco boxes use their LAN interface for router id (=> They are in a connected network, no routing is involved to get to it.). The configuration of the Cisco boxes should be fine because they play nicely with each other and GateD/OSPF. Observation: - Debug on the Cisco boxes does not show Hello packets emitted from the Zebra box. - Debug on the Zebra box shows incoming Hello packets (HelloRecived, 1-WayReceived) and "sendto in ospf_write failed with No route to host". Theory: - I misconfigured Zebra.

118

Concept: November 24, 2002

125

Problem and Resolution Log

2001-10-04 - Zebra OSPFd on NetBSD does not form Adjacency

Here is my ospfd.conf +--hostname Gamma(ospfd) password 1q2w3e4r enable password 1q2w3e4r ! interface ne2 ip ospf network broadcast ! router ospf network 192.168.16.3/27 area 0 ! mask should match "ifconfig netmask" ospf router-id 192.168.16.3 ospf abr-type cisco ! probably useless area 0 range 192.168.16.0/24 ! log file /var/log/zebra/ospfd.log +--+--root@gamma# ifconfig ne2 ne2: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 media: Ethernet autoselect (10baseT) inet 192.168.16.3 netmask 0xffffffe0 broadcast 192.168.16.31 inet6 fe80::2e0:7dff:fe95:9450%ne2 prefixlen 64 scopeid 0x1 root@gamma# +--Here is some output +--2001/10/04 19:33:10 2001/10/04 19:33:10 2001/10/04 19:33:10 2001/10/04 19:33:17 2001/10/04 19:33:17 host 2001/10/04 19:33:20 *|*|-|-|-|-|E|* 2001/10/04 19:33:20 2001/10/04 19:33:20 2001/10/04 19:33:20 2001/10/04 19:33:27 2001/10/04 19:33:27 host 2001/10/04 19:33:30 *|*|-|-|-|-|E|* +--from debug on Zebra: OSPF: OSPF: OSPF: OSPF: OSPF: NSM[ne2:192.168.16.2]: Init (HelloReceived) NSM[ne2:192.168.16.2]: nsm_ignore called NSM[ne2:192.168.16.2]: Init (1-WayReceived) make_hello: options: 2, int: ne2 *** sendto in ospf_write failed with No route to

OSPF: Packet 192.168.16.2 [Hello:RECV]: Options OSPF: OSPF: OSPF: OSPF: OSPF: NSM[ne2:192.168.16.2]: Init (HelloReceived) NSM[ne2:192.168.16.2]: nsm_ignore called NSM[ne2:192.168.16.2]: Init (1-WayReceived) make_hello: options: 2, int: ne2 *** sendto in ospf_write failed with No route to

OSPF: Packet 192.168.16.2 [Hello:RECV]: Options

Help and comments are greatly appreciated.

119

Concept: November 24, 2002

126

Problem and Resolution Log

2001-10-04 - Zebra OSPFd on NetBSD does not form Adjacency

TIA /Markus. +--Markus A. Boeing mailto://[email protected] http://www.boeing-online.de +--"Fr den Mann, der nicht wei, wohin es ihn treibt, gibt es keinen gnstigen Wind." Seneca

B.3.3

Analysis
List: Subject: From: Date: [Download Hello, > - Debug on the Zebra box shows incoming Hello packets (HelloRecived, > 1-WayReceived) and "sendto in ospf_write failed with No > route to host". The ospfd does not know where to send his (multicast) packets to. A friend of mine has had a similar problem with FreeBSD. Try adding a loopback route for 224. (i.e., route add 224 127.0.0.1). Bye, Frank List: Subject: From: Date: [Download zebra [zebra 10719] Re: Q: OSPF is not establishing adjacency Jasper Wallace <[email protected]> 2001-10-05 11:07:02 message RAW] zebra [zebra 10712] RE: Q: OSPF is not establishing adjacency "Frank Dauer" <[email protected]> 2001-10-05 8:20:27 message RAW]

On Thu, 4 Oct 2001, Markus Bing wrote: > > > > > > Ladies and Gents, may I ask for your help regarding Zebra and OSPF? I am setting up a small lab using Cisco routers, GateD and Zebra. So far I was unable to get Zebra’s OSPF up.

120

Concept: November 24, 2002

127

Problem and Resolution Log

2001-10-04 - Zebra OSPFd on NetBSD does not form Adjacency

> > I am using Zebra v0.91a on NetBSD 1.5/i386 (installed from package > distribution) but I could observe the same behavior with Zebra v0.92a > compiled from source. 0.92a is in the latest version of pkgsrc. > > > > > Observation: - Debug on the Cisco boxes does not show Hello packets emitted from the Zebra box. - Debug on the Zebra box shows incoming Hello packets (HelloRecived, 1-WayReceived) and "sendto in ospf_write failed with No route to host".

zebra dosn’t quite understand the way multicats works on the BSD’s - you need to add something like: ! ip route 224.0.0.5/32 127.0.0.1 ip route 224.0.0.6/32 127.0.0.1 ip route 224.0.0.9/32 127.0.0.1 ! near the end of zebra.conf. (ok, so the last one is for RIP, but it dosn’t hurt). > Theory: > - I misconfigured Zebra. -Internet Vision 60 Albert Court Prince Consort Road London SW7 2BE List: Subject: From: Date: [Download

Internet Consultancy & Web development

Tel: 020 7589 4500 Fax: 020 7589 4522 [email protected] http://www.ivision.co.uk/

zebra [zebra 10726] Re: Q: OSPF is not establishing adjacency [email protected] 2001-10-05 16:28:34 message RAW]

On 4 Oct 2001 at 20:49, Markus Bing wrote: > > > > > Observation: - Debug on the Cisco boxes does not show Hello packets emitted from the Zebra box. - Debug on the Zebra box shows incoming Hello packets (HelloRecived, 1-WayReceived) and "sendto in ospf_write failed with No route to host".

This is a bug in Zebra and/or BSD. The kernel in BSD tries to do a route lookup on the multicast destination 224.0.0.5 (AllSPFROuters), which

121

Concept: November 24, 2002

128

Problem and Resolution Log

2001-10-04 - Zebra OSPFd on NetBSD does not form Adjacency

fails if there is no default-route or other route to a prefix covering that address. I believe old gated installs the needed dummy route in order to avoid this problem, which Zebra also should do IMHO. I recently saw a suggested modification to FreeBSD kernel - if the output interface is indicated and the packet type is multicast in the call to ip_output() then just send the packet and ignore the routing table - in order to avoid this and similar multicast-related problems when the system lacks a default route. I don’t know it if has been implemented for future FreeBSD kernels, but even if it has it will take some time I guess before all flavors of BSD supports it and has been upgraded out there. Which means that we are back to a Zebra modification. So far I dont know if any of the Zebra people has responded to this issue and if it is a planned modification? -Fredrik Nyman PacketFront Sweden AB http://www.packetfront.com/ List: Subject: From: Date: [Download zebra [zebra 10733] Re: Q: OSPF is not establishing adjacency "Daniel C. Sobral" <[email protected]> 2001-10-05 19:45:21 message RAW]

[email protected] wrote: > > > > >

This is a bug in Zebra and/or BSD. The kernel in BSD tries to do a route lookup on the multicast destination 224.0.0.5 (AllSPFROuters), which fails if there is no default-route or other route to a prefix covering that address.

According to the Multicast RFC, the bug is in the BSD kernel. Alas, afaik all ip stacks out there had this problem at some point. It was just BSD taking longer to fix this. Alas, the patch was in for FreeBSD-current for quite a while, and I have just committed it on FreeBSD-stable (I was waiting 4.4 to come out, as I didn’t want to commit something like this close to code freeze date). -Daniel C. Sobral [email protected] [email protected] [email protected] [email protected]

(8-DCS)

122

Concept: November 24, 2002

129

Problem and Resolution Log

2001-10-04 - Zebra OSPFd on NetBSD does not form Adjacency

TRUTHFUL: Dumb and illiterate.

B.3.4

Solution
Added static routes for the multicast addresses 224.0.0.5 (AllSPFRouters) and 224.0.0.6 (AllDRouters) to zebra.conf.

123

Concept:

November 24, 2002

130

Problem and Resolution Log

2001-03-17 - RADIUS on DEC Alpha running NetBSD

B.4

2001-03-17 - RADIUS on DEC Alpha running NetBSD

B.4.1

Status: OPEN

B.4.2

Symptom
During the course of this endeavor I acquired a new machine (Tigerente). Tigerente is a DEC AlphaStation 200 running the NetBSD 1.5/alpha operating system. My intent was/is to use this machine to provide all network-centric servcies such as DNS, NTP, FTP, HTTP and others. As of today 10 Tigerente is the primary provider of DNS, NTP, FTP, TFTP and HTTP services. My attempt to provide AAA services through node Tigerente has not yet been successful. I installed Cistron RADIUS v1.6.4 (build from source) but could not get it working. I de-installed Cistron and installed Merit AAA v3.6B (NetBSD 1.5-alpha package) instead but could not get it working either. I installed TACACS (NetBSD 1.5-alpha package) but to my surprise it would work as well as the two RADIUSes. In every case authentication failed with messages complaining about mismatching keys. I am pretty conﬁdent that the conﬁgurations (and the keys) are correct. I have not even a vague idea about the cause of this. Further research is required. :) For the moment node Fruchtzwerg (iMac running MacOS X) is providing RADIUS services.

B.4.3

Analysis
Merit AAA: output from ”debug radius” on the router and the ”-x” output from radiusd This is a login attemt to the router using an account/password tuple in /etc/passwd: Beta#deb radius Radius protocol debugging is Beta#term moni Beta#! This is using account Jun 24 14:12:37.007: RADIUS: Jun 24 14:12:37.011: Radius: Jun 24 14:12:37.019: RADIUS: Request, len 80 Jun 24 14:12:37.019: Jun 24 14:12:37.023: Jun 24 14:12:37.023: Jun 24 14:12:37.027: Jun 24 14:12:37.027: Jun 24 14:12:37.031: Jun 24 14:12:37.071: RADIUS: Jun 24 14:12:37.075: Jun 24 14:12:37.075:
10

on markus, should be using /etc/passwd ustruct sharecount=1 radius_port_info() success=1 radius_nas_port=1 Initial Transmit tty3 id 3 192.168.16.201:1812, AccessAttribute 4 6 C0A82002 Attribute 5 6 00000003 Attribute 61 6 00000005 Attribute 1 8 6D61726B Attribute 31 16 3139322E Attribute 2 18 7932B486 Received from id 3 192.168.16.201:1812, Access-Reject, len 135 Attribute 4 6 C0A82002 Attribute 5 6 00000003

17-March-2001

124

Concept: November 24, 2002

131

Problem and Resolution Log

2001-03-17 - RADIUS on DEC Alpha running NetBSD

Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun

24 24 24 24 24 24 24 24 24 24

14:12:37.079: Attribute 61 6 00000005 14:12:37.079: Attribute 1 8 6D61726B 14:12:37.083: Attribute 31 16 3139322E 14:12:37.083: Attribute 2 18 7932B486 14:12:37.087: Attribute 222 8 6D61726B 14:12:37.087: Attribute 32 16 62657461 14:12:37.091: Attribute 11 7 756E6C69 14:12:37.091: Attribute 18 24 41757468 14:12:37.095: RADIUS: Response (3) failed decrypt 14:12:37.099: RADIUS: Reply for 3 fails decrypt

And this is what radius.debug thinks about it: Program = radiusd NAS-IP-Address = 192.168.32.2 [flags = 0x00004500] NAS-Port = 3 [flags = 0x00004500] NAS-Port-Type = Virtual [flags = 0x00004500] User-Name = "markus" [flags = 0x00004500] Calling-Station-Id = "192.168.16.200" [flags = 0x00004500] User-Password = "y2\0xb4\0x86\n~xS\0xc5h\0x1f;\0xd3\0x8f\0xdd\0xdd" [flags = 0x00004500] get_radrequest: Request from c0a82002 (beta.brest.lab[1645]) access, id = 3, len = 80 unix_pass: ID = ’markus’ unix_pass: encrypted passwords do not match NAS-IP-Address = 192.168.32.2 [flags = 0x00004500] NAS-Port = 3 [flags = 0x00004500] NAS-Port-Type = Virtual [flags = 0x00004500] User-Name = "markus" [flags = 0x00004500] Calling-Station-Id = "192.168.16.200" [flags = 0x00004500] User-Password = "y2\0xb4\0x86\n~xS\0xc5h\0x1f;\0xd3\0x8f\0xdd\0xdd" [flags = 0x00004500] User-Id = "markus" [flags = 0x00000400] NAS-Identifier = "beta.brest.lab" [flags = 0x00004500] Filter-Id = "unlim" [flags = 0x00004400] Reply-Message = "Authentication failure" [flags = 0x00004000] send_reply: Authentication: 3/0 ’markus’ from beta.brest.lab port 3 This is a login attempt to the router using an account/password tuple in ”users”: Beta# Beta#! This is using Beta# Jun 24 14:19:30.744: Jun 24 14:19:30.744: Jun 24 14:19:30.752: Request, len 80 Jun 24 14:19:30.756: Jun 24 14:19:30.756: Jun 24 14:19:30.760: Jun 24 14:19:30.760: Jun 24 14:19:30.764: Jun 24 14:19:30.764: Jun 24 14:19:30.777: account labdog - should be using password from the file users RADIUS: ustruct sharecount=1 Radius: radius_port_info() success=1 radius_nas_port=1 RADIUS: Initial Transmit tty3 id 4 192.168.16.201:1812, AccessAttribute 4 6 C0A82002 Attribute 5 6 00000003 Attribute 61 6 00000005 Attribute 1 8 6C616264 Attribute 31 16 3139322E Attribute 2 18 520EB2B4 RADIUS: Received from id 4 192.168.16.201:1812, Access-Reject, len 135

125

Concept: November 24, 2002

132

Problem and Resolution Log

2001-03-17 - RADIUS on DEC Alpha running NetBSD

Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun

24 24 24 24 24 24 24 24 24 24 24 24

14:19:30.781: Attribute 4 6 C0A82002 14:19:30.781: Attribute 5 6 00000003 14:19:30.785: Attribute 61 6 00000005 14:19:30.785: Attribute 1 8 6C616264 14:19:30.789: Attribute 31 16 3139322E 14:19:30.789: Attribute 2 18 520EB2B4 14:19:30.793: Attribute 222 8 6C616264 14:19:30.793: Attribute 32 16 62657461 14:19:30.797: Attribute 11 7 756E6C69 14:19:30.797: Attribute 18 24 41757468 14:19:30.801: RADIUS: Response (4) failed decrypt 14:19:30.805: RADIUS: Reply for 4 fails decrypt

And here is radius.debug again:

NAS-IP-Address = 192.168.32.2 [flags = 0x00004500] NAS-Port = 3 [flags = 0x00004500] NAS-Port-Type = Virtual [flags = 0x00004500] User-Name = "labdog" [flags = 0x00004500] Calling-Station-Id = "192.168.16.200" [flags = 0x00004500] User-Password = "R\0x0e\0xb2\0xb4\0x82\0xd42&\0x0b-\0x1a\0x9c\0xb6\0x01R\0xc7" [flags = 0x0000 get_radrequest: Request from c0a82002 (beta.brest.lab[1645]) access, id = 4, len = 80 NAS-IP-Address = 192.168.32.2 [flags = 0x00004500] NAS-Port = 3 [flags = 0x00004500] NAS-Port-Type = Virtual [flags = 0x00004500] User-Name = "labdog" [flags = 0x00004500] Calling-Station-Id = "192.168.16.200" [flags = 0x00004500] User-Password = "R\0x0e\0xb2\0xb4\0x82\0xd42&\0x0b-\0x1a\0x9c\0xb6\0x01R\0xc7" [flags = 0x0000 User-Id = "labdog" [flags = 0x00000400] NAS-Identifier = "beta.brest.lab" [flags = 0x00004500] Filter-Id = "unlim" [flags = 0x00004400] Reply-Message = "Authentication failure" [flags = 0x00004000] send_reply: Authentication: 4/1 ’labdog’ from beta.brest.lab port 3

B.4.4

Solution
None.

126

Concept:

November 24, 2002

133

C Activity Log
C.1 How to add IPv6 to the Lab Network
We assume that the static lab is conﬁgured correctly for IPv4 already. The following steps will then implement the IPv6 architecture described above.

C.1.1

Conﬁgure Route Reﬂectors
In the ﬁrst step we conﬁgure Anchor and Dinghy as BGP route reﬂectors.

Enable IPv6 on Anchor and Dinghy
Add the following lines to /etc/rc.conf to enable IPv6 on Anchor (NetBSD/alpha 1.6) and Dinghy (NetBSD/sgimips 1.6). Anchor # IPv6 routing # IPv6 forwarding is enabled in /etc/rc.local # -> sysctl -w net.inet6.ip.forwarding=1 # Routing daemons are started via daemontools # -> /service/zebra # -> /service/bgpd ip6mode=router # host, autohost or router ip6sitelocal=YES # IPv6 sitelocal addrs rtadvd=YES rtadvd_flags="tlp0" rtsol=NO rtsol_flags="-a" # for ip6mode=autohost only Dinghy # IPv6 routing # IPv6 forwarding is enabled in /etc/rc.local # -> sysctl -w net.inet6.ip6.forwarding=1 # Routing daemons are started via daemontools # -> /service/zebra # -> /service/bgpd ip6mode=router # host, autohost or router ip6sitelocal=YES # IPv6 sitelocal addrs rtadvd=YES rtadvd_flags="sq0" rtsol=NO rtsol_flags="-a" # for ip6mode=autohost only Add the following lines to /etc/rc.local to enable IPv6 forwarding on Anchor and Dinghy. Anchor

127

Concept:

November 24, 2002

134

Activity Log

How to add IPv6 to the Lab Network

# Enable IPv6 forwarding sysctl -w net.inet6.ip6.forwarding=1 Dinghy # Enable IPv6 forwarding sysctl -w net.inet6.ip6.forwarding=1

Conﬁgure IPv6 Addresses on Ethernet and Loopback Interfaces
Edit the ﬁle /etc/ifconfig.<interface> to conﬁgure an interface permanently on NetBSD. Anchor [email protected]# cat /etc/ifconfig.lo0 inet6 fefe::a prefixlen 128 alias [email protected]# [email protected]# cat /etc/ifconfig.tlp0 up 172.16.254.2 netmask 0xffffff00 media 10baseT inet6 fefe:a::1 prefixlen 64 alias [email protected]# Dinghy [email protected]# cat /etc/ifconfig.lo0 inet6 fefe::d prefixlen 128 alias [email protected]# [email protected]# cat /etc/ifconfig.sq0 up 172.16.255.2 netmask 0xffffff00 inet6 fefe:d::1 prefixlen 64 alias [email protected]#

Create Tunnel between Anchor and Dinghy
Create the following ﬁles to conﬁgure the tunnel between Anchor and Dinghy. Anchor [email protected]# cat ifconfig.gif0 create tunnel 172.16.254.2 172.16.255.2 inet6 fefe:bb::1 prefixlen 126 alias [email protected]# Dinghy [email protected]# cat /etc/ifconfig.gif0 create tunnel 172.16.255.2 172.16.254.2 inet6 fefe:bb::2 prefixlen 126 alias [email protected]#

128

Concept:

November 24, 2002

135

Activity Log

How to add IPv6 to the Lab Network

Reboot the machines and check the tunnel. Anchor [email protected]# ifconfig gif0 gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 tunnel inet 172.16.254.2 --> 172.16.255.2 inet6 fe80::200:f8ff:fe20:5a6e%gif0 -> :: prefixlen 64 scopeid 0xc [email protected]# [email protected]# ping6 -c 5 ff02::1%gif0 PING6(64=40+8+16 bytes) fe80::200:f8ff:fe20:5a6e%gif0 --> ff02::1%gif0 24 bytes from fe80::200:f8ff:fe20:5a6e%gif0, icmp_seq=0 hlim=64 time=1.234 24 bytes from fe80::a00:69ff:fe06:d6ce%gif0, icmp_seq=0 hlim=64 time=9.155 24 bytes from fe80::200:f8ff:fe20:5a6e%gif0, icmp_seq=1 hlim=64 time=0.782 24 bytes from fe80::a00:69ff:fe06:d6ce%gif0, icmp_seq=1 hlim=64 time=8.779 24 bytes from fe80::200:f8ff:fe20:5a6e%gif0, icmp_seq=2 hlim=64 time=1.212 24 bytes from fe80::a00:69ff:fe06:d6ce%gif0, icmp_seq=2 hlim=64 time=9.161 24 bytes from fe80::200:f8ff:fe20:5a6e%gif0, icmp_seq=3 hlim=64 time=0.726 24 bytes from fe80::a00:69ff:fe06:d6ce%gif0, icmp_seq=3 hlim=64 time=8.785 24 bytes from fe80::200:f8ff:fe20:5a6e%gif0, icmp_seq=4 hlim=64 time=0.726 --- ff02::1%gif0 ping6 statistics --5 packets transmitted, 5 packets received, +4 duplicates, 0% packet loss round-trip min/avg/max/std-dev = 0.726/4.507/9.161/3.998 ms [email protected]# Dinghy [email protected]# ifconfig gif0 gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 tunnel inet 172.16.255.2 --> 172.16.254.2 inet6 fe80::a00:69ff:fe06:d6ce%gif0 -> :: prefixlen 64 scopeid 0x9 [email protected]# [email protected]# ping6 -c5 ff02::1%gif0 PING6(56=40+8+8 bytes) fe80::a00:69ff:fe06:d6ce%gif0 --> ff02::1%gif0 16 bytes from fe80::a00:69ff:fe06:d6ce%gif0, icmp_seq=0 hlim=64 time=1.16 ms 16 bytes from fe80::200:f8ff:fe20:5a6e%gif0, icmp_seq=0 hlim=64 time=10.059 ms(DUP!) 16 bytes from fe80::a00:69ff:fe06:d6ce%gif0, icmp_seq=1 hlim=64 time=0.91 ms 16 bytes from fe80::200:f8ff:fe20:5a6e%gif0, icmp_seq=1 hlim=64 time=8.667 ms(DUP!) 16 bytes from fe80::a00:69ff:fe06:d6ce%gif0, icmp_seq=2 hlim=64 time=0.921 ms 16 bytes from fe80::200:f8ff:fe20:5a6e%gif0, icmp_seq=2 hlim=64 time=8.335 ms(DUP!) 16 bytes from fe80::a00:69ff:fe06:d6ce%gif0, icmp_seq=3 hlim=64 time=0.926 ms 16 bytes from fe80::200:f8ff:fe20:5a6e%gif0, icmp_seq=3 hlim=64 time=8.489 ms(DUP!) 16 bytes from fe80::a00:69ff:fe06:d6ce%gif0, icmp_seq=4 hlim=64 time=0.92 ms --- ff02::1%gif0 ping6 statistics --5 packets transmitted, 5 packets received, +4 duplicates, 0% packet loss round-trip min/avg/max/std-dev = 0.910/4.487/10.059/3.963 ms [email protected]#

ms ms(DUP!) ms ms(DUP!) ms ms(DUP!) ms ms(DUP!) ms

129

Concept:

November 24, 2002

136

Activity Log

How to add IPv6 to the Lab Network

See the DUPs? Thats good news because it shows us that the other end of the tunnel is responding as well. Which implies that the tunnel is up and running. Please note that we do not have IPv6 addresses explicitly conﬁgured on the tunnel. We are using ‘link local addresses’.

Conﬁgure iBGP between Anchor and Dinghy
We use loopback addresses for BGP peering purposes. In order to make these addresses reachable to the remote node we must add static routes to /etc/zebra.conf. Anchor [email protected]# cat /etc/zebra.conf | grep "ipv6 route" ipv6 route fefe::d/128 gif0 [email protected]# [email protected]# ping6 -c5 fefe::d PING6(64=40+8+16 bytes) fefe::a --> fefe::d 24 bytes from fefe::d, icmp_seq=0 hlim=64 time=9.053 ms 24 bytes from fefe::d, icmp_seq=1 hlim=64 time=8.439 ms 24 bytes from fefe::d, icmp_seq=2 hlim=64 time=8.495 ms 24 bytes from fefe::d, icmp_seq=3 hlim=64 time=14.207 ms 24 bytes from fefe::d, icmp_seq=4 hlim=64 time=8.51 ms --- fefe::d ping6 statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/std-dev = 8.439/9.741/14.207/2.244 ms [email protected]# Dinghy [email protected]# ipv6 route fefe::a/128 [email protected]# [email protected]# PING6(56=40+8+8 bytes) 16 bytes from fefe::a, 16 bytes from fefe::a, 16 bytes from fefe::a, 16 bytes from fefe::a, 16 bytes from fefe::a, cat /etc/zebra.conf | grep "ipv6 route" gif0 ping6 -c 5 fefe::a fefe::d --> fefe::a icmp_seq=0 hlim=64 time=9.642 icmp_seq=1 hlim=64 time=8.435 icmp_seq=2 hlim=64 time=8.281 icmp_seq=3 hlim=64 time=8.319 icmp_seq=4 hlim=64 time=8.285

ms ms ms ms ms

--- fefe::a ping6 statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/std-dev = 8.281/8.592/9.642/0.528 ms [email protected]# Now that the next-hop interface is reachable we can start to conﬁgure BGP. Did I already say that zebra was compiled with --enable_multipath=4 on both boxes? Anchor

130

Concept: November 24, 2002

137

Activity Log

How to add IPv6 to the Lab Network

[email protected]# cat /etc/bgpd.conf ! ! Zebra configuration saved from vty ! 2002/10/09 16:31:43 ! hostname Anchor(bgpd) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/bgpd.log ! router bgp 65000 bgp deterministic-med neighbor MESH peer-group neighbor MESH remote-as 65000 neighbor MESH description Fellow route reflectors neighbor MESH update-source lo0 no neighbor MESH activate ! address-family ipv6 redistribute connected neighbor MESH activate neighbor MESH next-hop-self neighbor MESH route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor fefe::d peer-group MESH exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 set ipv6 next-hop global fefe::a ! line vty ! [email protected]# Dinghy [email protected]# cat /etc/bgpd.conf ! ! Zebra configuration saved from vty ! 2002/10/10 11:41:53 ! hostname Dinghy(bgpd) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/bgpd.log ! router bgp 65000 bgp deterministic-med neighbor MESH peer-group neighbor MESH remote-as 65000 neighbor MESH description Fellow route reflectors

131

Concept: November 24, 2002

138

Activity Log

How to add IPv6 to the Lab Network

neighbor MESH update-source lo0 no neighbor MESH activate ! address-family ipv6 redistribute connected neighbor MESH activate neighbor MESH next-hop-self neighbor MESH route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor fefe::a peer-group MESH exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 set ipv6 next-hop global fefe::d ! line vty ! [email protected]# Lets see if the conﬁguration works properly. Anchor [email protected]# rtr3 anchor:2605 show ip bgp scan : show ip bgp neig : show ipv6 bgp spawn /bin/sh -c exec telnet anchor 2605 Trying 172.16.254.2... Connected to anchor.brest.lab. Escape character is ’^]’. Hello, this is zebra (version 0.93b). Copyright 1996-2002 Kunihiro Ishiguro. User Access Verification Password: Anchor(bgpd)> enable Password: Anchor(bgpd)# term leng 0 Anchor(bgpd)# show ip bgp scan BGP scan is running BGP scan interval is 60 Current BGP nexthop cache: fefe::d valid [IGP metric 0] BGP connected route: 172.16.254.0/24 fefe:a::/64 Anchor(bgpd)# show ip bgp neig BGP neighbor is fefe::d, remote AS 65000, local AS 65000, internal link Member of peer-group MESH for session parameters BGP version 4, remote router ID 172.16.255.2 BGP state = Established, up for 00:05:17

132

Concept: November 24, 2002

139

Activity Log

How to add IPv6 to the Lab Network

Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received (old and new) Address family IPv6 Unicast: advertised and received Received 9 messages, 0 notifications, 0 in queue Sent 10 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 5 seconds Update source is lo0 For address family: IPv6 Unicast MESH peer-group member NEXT_HOP is always this router Community attribute sent to this neighbor (both) Outbound path policy configured Route map for outgoing advertisements is *SET_NEXT_HOP_TO_GLOBAL_IP6 2 accepted prefixes Connections established 1; dropped 0 Local host: fefe::a, Local port: 49157 Foreign host: fefe::d, Foreign port: 179 Nexthop: 172.16.254.2 Nexthop global: fefe::a Nexthop local: :: BGP connection: non shared network Read thread: on Write thread: off Anchor(bgpd)# show ipv6 bgp BGP table version is 0, local router ID is 172.16.254.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *> fefe::a/128 *>ifefe::d/128 *> fefe:a::/64 *>ifefe:d::/64 Next Hop :: fefe::d :: fefe::d Metric LocPrf Weight Path 0 32768 ? 0 100 0 ? 0 32768 ? 0 100 0 ?

Total number of prefixes 4 Anchor(bgpd)# [email protected]# [email protected]# ping6 -c5 fefe:d::1 PING6(64=40+8+16 bytes) fefe:a::1 --> fefe:d::1 24 bytes from fefe:d::1, icmp_seq=0 hlim=64 time=8.975 24 bytes from fefe:d::1, icmp_seq=1 hlim=64 time=8.586 24 bytes from fefe:d::1, icmp_seq=2 hlim=64 time=8.338 24 bytes from fefe:d::1, icmp_seq=3 hlim=64 time=8.322 24 bytes from fefe:d::1, icmp_seq=4 hlim=64 time=8.705

ms ms ms ms ms

133

Concept: November 24, 2002

140

Activity Log

How to add IPv6 to the Lab Network

--- fefe:d::1 ping6 statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/std-dev = 8.322/8.585/8.975/0.244 ms [email protected]# Looks good to me. Dinghy [email protected]# rtr3 dinghy:2605 show ip bgp scan : show ip bgp neig : show ipv6 bgp spawn /bin/sh -c exec telnet dinghy 2605 Trying 172.16.255.2... Connected to dinghy.brest.lab. Escape character is ’^]’. Hello, this is zebra (version 0.93b). Copyright 1996-2002 Kunihiro Ishiguro. User Access Verification Password: Dinghy(bgpd)> enable Password: Dinghy(bgpd)# term leng 0 Dinghy(bgpd)# show ip bgp scan BGP scan is running BGP scan interval is 60 Current BGP nexthop cache: fefe::a valid [IGP metric 0] BGP connected route: 172.16.255.0/24 fefe:d::/64 Dinghy(bgpd)# show ip bgp neig BGP neighbor is fefe::a, remote AS 65000, local AS 65000, internal link Member of peer-group MESH for session parameters BGP version 4, remote router ID 172.16.254.2 BGP state = Established, up for 00:07:38 Last read 00:00:38, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received (old and new) Address family IPv6 Unicast: advertised and received Received 31 messages, 0 notifications, 0 in queue Sent 31 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 5 seconds Update source is lo0 For address family: IPv6 Unicast MESH peer-group member NEXT_HOP is always this router

134

Concept: November 24, 2002

141

Activity Log

How to add IPv6 to the Lab Network

Community attribute sent to this neighbor (both) Outbound path policy configured Route map for outgoing advertisements is *SET_NEXT_HOP_TO_GLOBAL_IP6 2 accepted prefixes Connections established 2; dropped 1 Local host: fefe::d, Local port: 179 Foreign host: fefe::a, Foreign port: 49157 Nexthop: 172.16.255.2 Nexthop global: fefe::d Nexthop local: :: BGP connection: non shared network Read thread: on Write thread: off Dinghy(bgpd)# show ipv6 bgp BGP table version is 0, local router ID is 172.16.255.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>ifefe::a/128 *> fefe::d/128 *>ifefe:a::/64 *> fefe:d::/64 Next Hop fefe::a :: fefe::a :: Metric LocPrf Weight Path 0 100 0 ? 0 32768 ? 0 100 0 ? 0 32768 ?

Total number of prefixes 4 Dinghy(bgpd)# [email protected]# [email protected]# ping6 -c5 fefe:a::1 PING6(56=40+8+8 bytes) fefe:d::1 --> fefe:a::1 16 bytes from fefe:a::1, icmp_seq=0 hlim=64 time=9.523 ms 16 bytes from fefe:a::1, icmp_seq=1 hlim=64 time=15.738 ms 16 bytes from fefe:a::1, icmp_seq=2 hlim=64 time=8.398 ms 16 bytes from fefe:a::1, icmp_seq=3 hlim=64 time=15.604 ms 16 bytes from fefe:a::1, icmp_seq=4 hlim=64 time=8.226 ms --- fefe:a::1 ping6 statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/std-dev = 8.226/11.498/15.738/3.437 ms [email protected]# Looks like we have got BGP working between Anchor and Dinghy. The next step would be adding edge router.

135

Concept:

November 24, 2002

142

Activity Log

How to add IPv6 to the Lab Network

C.1.2

Conﬁgure Cisco Edge Router
As a second step we will add an IPv6 edge router to our hub routers.

Enable IPv6 on Edge Router
Edge1 Edge1(config)#ipv6 unicast-routing Edge1(config)# Edge1(config)#interface loopback 0 Edge1(config-if)#ipv6 address fefe::e1/128 Edge1(config-if)#exit Edge1(config)# Edge1(config)#interface ethernet 0 Edge1(config-if)#ipv6 address fefe:e1::1/64 Edge1(config-if)#exit

Conﬁgure Tunnels
Edit the ﬁle /etc/ifconfig.gif1 to conﬁgure the tunnel interfaces permanently on Anchor and Dinghy. Use the command ifconfig gif1 to conﬁgure the tunnel interfaces on the ﬂy. Anchor [email protected]# cat /etc/ifconfig.gif1 create tunnel 172.16.254.2 172.16.0.11 inet6 up [email protected]# Dinghy [email protected]# cat /etc/ifconfig.gif1 create tunnel 172.16.255.2 172.16.0.11 inet6 up [email protected]# Edge1 Edge1(config)#interface tunnel 0 Edge1(config-if)#description IPv6 tunnel to router Anchor Edge1(config-if)#ipv6 enable Edge1(config-if)#tunnel source loopback 0 Edge1(config-if)#tunnel destination 172.16.254.2 Edge1(config-if)#tunnel mode ipv6ip Edge1(config-if)#exit Edge1(config)# Edge1(config)#interface tunnel 1

136

Concept: November 24, 2002

143

Activity Log

How to add IPv6 to the Lab Network

Edge1(config-if)#description IPv6 tunnel to router Dinghy Edge1(config-if)#ipv6 enable Edge1(config-if)#tunnel source loopback 0 Edge1(config-if)#tunnel destination 172.16.255.2 Edge1(config-if)#tunnel mode ipv6ip Edge1(config-if)#exit Issue a wr mem command to save the conﬁguration to the routers NVRAM. Check if the tunnels are working. Anchor [email protected]# ping6 -c5 ff02::1%gif1 PING6(64=40+8+16 bytes) fe80::200:f8ff:fe20:5a6e%gif1 --> ff02::1%gif1 24 bytes from fe80::200:f8ff:fe20:5a6e%gif1, icmp_seq=0 hlim=64 time=1.3 ms 24 bytes from fe80::ac10:b%gif1, icmp_seq=0 hlim=64 time=7.116 ms(DUP!) 24 bytes from fe80::200:f8ff:fe20:5a6e%gif1, icmp_seq=1 hlim=64 time=0.688 ms 24 bytes from fe80::ac10:b%gif1, icmp_seq=1 hlim=64 time=6.541 ms(DUP!) 24 bytes from fe80::200:f8ff:fe20:5a6e%gif1, icmp_seq=2 hlim=64 time=0.718 ms 24 bytes from fe80::ac10:b%gif1, icmp_seq=2 hlim=64 time=6.741 ms(DUP!) 24 bytes from fe80::200:f8ff:fe20:5a6e%gif1, icmp_seq=3 hlim=64 time=0.648 ms 24 bytes from fe80::ac10:b%gif1, icmp_seq=3 hlim=64 time=6.641 ms(DUP!) 24 bytes from fe80::200:f8ff:fe20:5a6e%gif1, icmp_seq=4 hlim=64 time=0.687 ms --- ff02::1%gif1 ping6 statistics --5 packets transmitted, 5 packets received, +4 duplicates, 0% packet loss round-trip min/avg/max/std-dev = 0.648/3.453/7.116/2.967 ms [email protected]# Dinghy [email protected]# ping6 -c5 ff02::1%gif1 PING6(56=40+8+8 bytes) fe80::a00:69ff:fe06:d6ce%gif1 --> ff02::1%gif1 16 bytes from fe80::a00:69ff:fe06:d6ce%gif1, icmp_seq=0 hlim=64 time=1.182 16 bytes from fe80::ac10:b%gif1, icmp_seq=0 hlim=64 time=11.309 ms(DUP!) 16 bytes from fe80::a00:69ff:fe06:d6ce%gif1, icmp_seq=1 hlim=64 time=0.898 16 bytes from fe80::ac10:b%gif1, icmp_seq=1 hlim=64 time=7.95 ms(DUP!) 16 bytes from fe80::a00:69ff:fe06:d6ce%gif1, icmp_seq=2 hlim=64 time=0.883 16 bytes from fe80::ac10:b%gif1, icmp_seq=2 hlim=64 time=7.638 ms(DUP!) 16 bytes from fe80::a00:69ff:fe06:d6ce%gif1, icmp_seq=3 hlim=64 time=0.926 16 bytes from fe80::ac10:b%gif1, icmp_seq=3 hlim=64 time=7.866 ms(DUP!) 16 bytes from fe80::a00:69ff:fe06:d6ce%gif1, icmp_seq=4 hlim=64 time=0.895 --- ff02::1%gif1 ping6 statistics --5 packets transmitted, 5 packets received, +4 duplicates, 0% packet loss round-trip min/avg/max/std-dev = 0.883/4.394/11.309/3.975 ms [email protected]# The DUPs indicate that a tunnel far end is responding and the tunnel is operational. Edge1

ms ms ms ms ms

137

Concept: November 24, 2002

144

Activity Log

How to add IPv6 to the Lab Network

Edge1#show ipv6 int tun 0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::AC10:B Description: IPv6 tunnel to router Anchor No global unicast address is configured Joined group address(es): FF02::1 FF02::2 FF02::1:FF10:B MTU is 1480 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. Edge1# Edge1#show ipv6 int tun 1 Tunnel1 is up, line protocol is up IPv6 is enabled, link-local address is FE80::AC10:B Description: IPv6 tunnel to router Dinghy No global unicast address is configured Joined group address(es): FF02::1 FF02::2 FF02::1:FF10:B MTU is 1480 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. Edge1#

Conﬁgure BGP on Route Reﬂectors
Add static routes the loopback interface of router Edge1. Anchor [email protected]# cat /etc/zebra.conf | grep "ipv6 route" ipv6 route fefe::d/128 gif0 ipv6 route fefe::e1/128 gif1 [email protected]# Dinghy [email protected]# cat /etc/zebra.conf | grep "ipv6 route" ipv6 route fefe::a/128 gif0 ipv6 route fefe::e1/128 gif1 [email protected]#

138

Concept:

November 24, 2002

145

Activity Log

How to add IPv6 to the Lab Network

Conﬁgure BGP, we add another peer group for route reﬂector clients. Anchor [email protected]# cat /etc/bgpd.conf ! ! Zebra configuration saved from vty ! 2002/10/09 23:42:47 ! hostname Anchor(bgpd) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/bgpd.log ! router bgp 65000 bgp deterministic-med neighbor CLIENTS peer-group neighbor CLIENTS remote-as 65000 neighbor CLIENTS description Route reflector clients neighbor CLIENTS update-source lo0 no neighbor CLIENTS activate neighbor MESH peer-group neighbor MESH remote-as 65000 neighbor MESH description Fellow route reflectors neighbor MESH update-source lo0 no neighbor MESH activate ! address-family ipv6 redistribute connected neighbor CLIENTS activate neighbor CLIENTS route-reflector-client neighbor CLIENTS next-hop-self neighbor CLIENTS route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor MESH activate neighbor MESH next-hop-self neighbor MESH route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor fefe::d peer-group MESH neighbor fefe::e1 peer-group CLIENTS exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 set ipv6 next-hop global fefe::a ! line vty ! [email protected]# Dinghy

139

Concept: November 24, 2002

146

Activity Log

How to add IPv6 to the Lab Network

[email protected]# cat /etc/bgpd.conf ! ! Zebra configuration saved from vty ! 2002/10/10 18:51:24 ! hostname Dinghy(bgpd) password 1q2w3e4r enable password q1w2e3r4 log file /var/log/zebra/bgpd.log ! router bgp 65000 bgp deterministic-med neighbor CLIENTS peer-group neighbor CLIENTS remote-as 65000 neighbor CLIENTS description Route reflector clients neighbor CLIENTS update-source lo0 no neighbor CLIENTS activate neighbor MESH peer-group neighbor MESH remote-as 65000 neighbor MESH description Fellow route reflectors neighbor MESH update-source lo0 no neighbor MESH activate ! address-family ipv6 redistribute connected neighbor CLIENTS activate neighbor CLIENTS route-reflector-client neighbor CLIENTS next-hop-self neighbor CLIENTS route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor MESH activate neighbor MESH next-hop-self neighbor MESH route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor fefe::a peer-group MESH neighbor fefe::e1 peer-group CLIENTS exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 set ipv6 next-hop global fefe::d ! line vty ! [email protected]#

Conﬁgure BGP on Cisco Edge Router
Edge1 router bgp 65000 no synchronization bgp log-neighbor-changes

140

Concept: November 24, 2002

147

Activity Log

How to add IPv6 to the Lab Network

bgp deterministic-med neighbor ROUTE-REFLECTORS peer-group neighbor ROUTE-REFLECTORS remote-as 65000 neighbor ROUTE-REFLECTORS description Upstream route reflector servers neighbor ROUTE-REFLECTORS update-source Loopback0 no neighbor ROUTE-REFLECTORS activate no auto-summary ! address-family ipv6 neighbor ROUTE-REFLECTORS activate neighbor ROUTE-REFLECTORS next-hop-self neighbor ROUTE-REFLECTORS send-community neighbor ROUTE-REFLECTORS route-map SET_NEXT_HOP_TO_GLOBAL_IP6 out neighbor fefe::a peer-group ROUTE-REFLECTORS neighbor fefe::d peer-group ROUTE-REFLECTORS no synchronization redistribute connected exit-address-family ! route-map SET_NEXT_HOP_TO_GLOBAL_IP6 permit 10 description Set next hop to global IPv6 addr; default is using link local IPv6 addr set ipv6 next-hop fefe::e1 ! ipv6 route fefe::a/128 Tunnel0 ipv6 route fefe::d/128 Tunnel1

Test Static Route and Tunnel
Anchor [email protected]# ping6 -c5 fefe::e1 PING6(64=40+8+16 bytes) fefe::a --> fefe::e1 24 bytes from fefe::e1, icmp_seq=0 hlim=64 time=12.081 24 bytes from fefe::e1, icmp_seq=1 hlim=64 time=11.709 24 bytes from fefe::e1, icmp_seq=2 hlim=64 time=12.496 24 bytes from fefe::e1, icmp_seq=3 hlim=64 time=11.671 24 bytes from fefe::e1, icmp_seq=4 hlim=64 time=12.852

ms ms ms ms ms

--- fefe::e1 ping6 statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/std-dev = 11.671/12.162/12.852/0.456 ms [email protected]# Dinghy [email protected]# ping6 -c5 fefe::e1 PING6(56=40+8+8 bytes) fefe::d --> fefe::e1 16 bytes from fefe::e1, icmp_seq=0 hlim=64 time=8.727 ms 16 bytes from fefe::e1, icmp_seq=1 hlim=64 time=8.33 ms 16 bytes from fefe::e1, icmp_seq=2 hlim=64 time=8.438 ms

141

Concept: November 24, 2002

148

Activity Log

How to add IPv6 to the Lab Network

16 bytes from fefe::e1, icmp_seq=3 hlim=64 time=8.398 ms 16 bytes from fefe::e1, icmp_seq=4 hlim=64 time=8.379 ms --- fefe::e1 ping6 statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/std-dev = 8.330/8.454/8.727/0.141 ms [email protected]# Edge1 Edge1#ping fefe::a Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FEFE::A, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/14/36 ms Edge1# Edge1#ping fefe::d Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FEFE::D, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms Edge1#

Check BGP
Anchor [email protected]# rtr3 anchor:2605 show ip bgp scan : show ip bgp neig : show ipv6 bgp spawn /bin/sh -c exec telnet anchor 2605 Trying 172.16.254.2... Connected to anchor.brest.lab. Escape character is ’^]’. Hello, this is zebra (version 0.93b). Copyright 1996-2002 Kunihiro Ishiguro. User Access Verification Password: Anchor(bgpd)> enable Password: Anchor(bgpd)# term leng 0 Anchor(bgpd)# show ip bgp scan BGP scan is running BGP scan interval is 60 Current BGP nexthop cache: fefe::d valid [IGP metric 0] fefe::e1 valid [IGP metric 0]

142

Concept: November 24, 2002

149

Activity Log

How to add IPv6 to the Lab Network

BGP connected route: 172.16.254.0/24 fefe:a::/64 Anchor(bgpd)# show ip bgp neig BGP neighbor is fefe::d, remote AS 65000, local AS 65000, internal link Member of peer-group MESH for session parameters BGP version 4, remote router ID 172.16.255.2 BGP state = Established, up for 00:09:00 Last read 00:01:00, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received (old and new) Address family IPv6 Unicast: advertised and received Received 14 messages, 0 notifications, 0 in queue Sent 15 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 5 seconds Update source is lo0 For address family: IPv6 Unicast MESH peer-group member NEXT_HOP is always this router Community attribute sent to this neighbor (both) Outbound path policy configured Route map for outgoing advertisements is *SET_NEXT_HOP_TO_GLOBAL_IP6 4 accepted prefixes Connections established 1; dropped 0 Local host: fefe::a, Local port: 49153 Foreign host: fefe::d, Foreign port: 179 Nexthop: 172.16.254.2 Nexthop global: fefe::a Nexthop local: :: BGP connection: non shared network Read thread: on Write thread: off BGP neighbor is fefe::e1, remote AS 65000, local AS 65000, internal link Member of peer-group CLIENTS for session parameters BGP version 4, remote router ID 172.16.0.11 BGP state = Established, up for 00:09:17 Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received (old and new) Address family IPv6 Unicast: advertised and received Received 13 messages, 0 notifications, 0 in queue Sent 16 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 5 seconds Update source is lo0

143

Concept: November 24, 2002

150

Activity Log

How to add IPv6 to the Lab Network

For address family: IPv6 Unicast CLIENTS peer-group member Route-Reflector Client NEXT_HOP is always this router Community attribute sent to this neighbor (both) Outbound path policy configured Route map for outgoing advertisements is *SET_NEXT_HOP_TO_GLOBAL_IP6 2 accepted prefixes Connections established 1; dropped 0 Local host: fefe::a, Local port: 49154 Foreign host: fefe::e1, Foreign port: 179 Nexthop: 172.16.254.2 Nexthop global: fefe::a Nexthop local: :: BGP connection: non shared network Read thread: on Write thread: off Anchor(bgpd)# show ipv6 bgp BGP table version is 0, local router ID is 172.16.254.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *> fefe::a/128 *>ifefe::d/128 * ifefe::e1/128 *>i *> fefe:a::/64 *>ifefe:d::/64 * ifefe:e1::/64 *>i Next Hop :: fefe::d fefe::e1 fefe::e1 :: fefe::d fefe::e1 fefe::e1 Metric LocPrf Weight Path 0 32768 ? 0 100 0 ? 100 0 ? 100 0 ? 0 32768 ? 0 100 0 ? 100 0 ? 100 0 ?

Total number of prefixes 6 Anchor(bgpd)# [email protected]# Dinghy [email protected]# rtr3 dinghy:2605 show ip bgp scan : show ip bgp neig : show ipv6 bgp spawn /bin/sh -c exec telnet dinghy 2605 Trying 172.16.255.2... Connected to dinghy.brest.lab. Escape character is ’^]’. Hello, this is zebra (version 0.93b). Copyright 1996-2002 Kunihiro Ishiguro. User Access Verification

144

Concept: November 24, 2002

151

Activity Log

How to add IPv6 to the Lab Network

Password: Dinghy(bgpd)> enable Password: Dinghy(bgpd)# term leng 0 Dinghy(bgpd)# show ip bgp scan BGP scan is running BGP scan interval is 60 Current BGP nexthop cache: fefe::a valid [IGP metric 0] fefe::e1 valid [IGP metric 0] BGP connected route: 172.16.255.0/24 fefe:d::/64 Dinghy(bgpd)# show ip bgp neig BGP neighbor is fefe::a, remote AS 65000, local AS 65000, internal link Member of peer-group MESH for session parameters BGP version 4, remote router ID 172.16.254.2 BGP state = Established, up for 00:07:01 Last read 00:00:01, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received (old and new) Address family IPv6 Unicast: advertised and received Received 12 messages, 0 notifications, 0 in queue Sent 15 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 5 seconds Update source is lo0 For address family: IPv6 Unicast MESH peer-group member NEXT_HOP is always this router Community attribute sent to this neighbor (both) Outbound path policy configured Route map for outgoing advertisements is *SET_NEXT_HOP_TO_GLOBAL_IP6 4 accepted prefixes Connections established 1; dropped 0 Local host: fefe::d, Local port: 179 Foreign host: fefe::a, Foreign port: 49153 Nexthop: 172.16.255.2 Nexthop global: fefe::d Nexthop local: :: BGP connection: non shared network Read thread: on Write thread: off BGP neighbor is fefe::e1, remote AS 65000, local AS 65000, internal link Member of peer-group CLIENTS for session parameters BGP version 4, remote router ID 172.16.0.11 BGP state = Established, up for 00:07:01

145

Concept: November 24, 2002

152

Activity Log

How to add IPv6 to the Lab Network

Last read 00:00:01, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received (old and new) Address family IPv6 Unicast: advertised and received Received 11 messages, 0 notifications, 0 in queue Sent 14 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 5 seconds Update source is lo0 For address family: IPv6 Unicast CLIENTS peer-group member Route-Reflector Client NEXT_HOP is always this router Community attribute sent to this neighbor (both) Outbound path policy configured Route map for outgoing advertisements is *SET_NEXT_HOP_TO_GLOBAL_IP6 2 accepted prefixes Connections established 1; dropped 0 Local host: fefe::d, Local port: 49154 Foreign host: fefe::e1, Foreign port: 179 Nexthop: 172.16.255.2 Nexthop global: fefe::d Nexthop local: :: BGP connection: non shared network Read thread: on Write thread: off Dinghy(bgpd)# show ipv6 bgp BGP table version is 0, local router ID is 172.16.255.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network *>ifefe::a/128 *> fefe::d/128 * ifefe::e1/128 *>i *>ifefe:a::/64 *> fefe:d::/64 * ifefe:e1::/64 *>i Next Hop fefe::a :: fefe::e1 fefe::e1 fefe::a :: fefe::e1 fefe::e1 Metric LocPrf Weight Path 0 100 0 ? 0 32768 ? 100 0 ? 100 0 ? 0 100 0 ? 0 32768 ? 100 0 ? 100 0 ?

Total number of prefixes 6 Dinghy(bgpd)# [email protected]# Edge1

146

Concept: November 24, 2002

153

Activity Log

How to add IPv6 to the Lab Network

[email protected]# rtr3 edge1 show ip bgp neig : show bgp ipv6 : show bgp ipv6 summary spawn /bin/sh -c exec telnet edge1 Trying 172.16.0.11... Connected to edge1.brest.lab. Escape character is ’^]’. User Access Verification Username: Kerberos: No default realm defined for Kerberos! markus Password: Edge1>enable Password: Edge1#term leng 0 Edge1#show ip bgp neig BGP neighbor is FEFE::A, remote AS 65000, internal link Member of peer-group ROUTE-REFLECTORS for session parameters BGP version 4, remote router ID 172.16.254.2 BGP state = Established, up for 00:13:31 Last read 00:00:31, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(old & new) Address family IPv6 Unicast: advertised and received Received 65 messages, 0 notifications, 0 in queue Sent 58 messages, 0 notifications, 0 in queue Default minimum time between advertisement runs is 5 seconds For address family: IPv6 Unicast BGP table version 21, neighbor version 21 Index 1, Offset 0, Mask 0x2 ROUTE-REFLECTORS peer-group member NEXT_HOP is always this router Community attribute sent to this neighbor Route refresh request: received 0, sent 0 Outbound path policy configured Route map for outgoing advertisements is SET_NEXT_HOP_TO_GLOBAL_IP6 4 accepted prefixes consume 272 bytes Prefix advertised 4, suppressed 0, withdrawn 0 Connections established 2; dropped 1 Last reset 00:13:34, due to Peer closed the session Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: FEFE::E1, Local port: 179 Foreign host: FEFE::A, Foreign port: 49154 Enqueued packets for retransmit: 0, input: 0 Event Timers (current time is 0x37FE98): Timer Starts Wakeups mis-ordered: 0 (0 bytes)

Next

147

Concept: November 24, 2002

154

Activity Log

How to add IPv6 to the Lab Network

Retrans TimeWait AckHold SendWnd KeepAlive GiveUp PmtuAger DeadWait iss: 1416768829 irs: 926894319

18 0 20 0 0 0 0 0

0 0 5 0 0 0 0 0

0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 sndnxt: 1416769266 rcvwnd: 16232 sndwnd: delrcvwnd: 16384 152

snduna: 1416769266 rcvnxt: 926895002

SRTT: 273 ms, RTTO: 499 ms, RTV: 226 ms, KRTT: 0 ms minRTT: 12 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: passive open, nagle, gen tcbs Datagrams (max data segment is 516 bytes): Rcvd: 37 (out of order: 0), with data: 20, total data bytes: 682 Sent: 24 (retransmit: 0, fastretransmit: 0), with data: 24, total data bytes: 1404 BGP neighbor is FEFE::D, remote AS 65000, internal link Member of peer-group ROUTE-REFLECTORS for session parameters BGP version 4, remote router ID 172.16.255.2 BGP state = Established, up for 00:13:14 Last read 00:00:14, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(old & new) Address family IPv6 Unicast: advertised and received Received 34 messages, 0 notifications, 0 in queue Sent 31 messages, 0 notifications, 0 in queue Default minimum time between advertisement runs is 5 seconds For address family: IPv6 Unicast BGP table version 21, neighbor version 21 Index 1, Offset 0, Mask 0x2 ROUTE-REFLECTORS peer-group member NEXT_HOP is always this router Community attribute sent to this neighbor Route refresh request: received 0, sent 0 Outbound path policy configured Route map for outgoing advertisements is SET_NEXT_HOP_TO_GLOBAL_IP6 4 accepted prefixes consume 272 bytes Prefix advertised 4, suppressed 0, withdrawn 0 Connections established 2; dropped 1 Last reset 00:13:18, due to Peer closed the session Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: FEFE::E1, Local port: 179 Foreign host: FEFE::D, Foreign port: 49154

148

Concept: November 24, 2002

155

Activity Log

How to add IPv6 to the Lab Network

Enqueued packets for retransmit: 0, input: 0 Event Timers (current time is 0x37FFC8): Timer Starts Wakeups Retrans 18 0 TimeWait 0 0 AckHold 20 7 SendWnd 0 0 KeepAlive 0 0 GiveUp 0 0 PmtuAger 0 0 DeadWait 0 0 iss: 3977539705 irs: 1456148508 snduna: 3977540142 rcvnxt: 1456149191

mis-ordered: 0 (0 bytes)

Next 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 sndwnd: delrcvwnd: 16384 152

sndnxt: 3977540142 rcvwnd: 16232

SRTT: 273 ms, RTTO: 499 ms, RTV: 226 ms, KRTT: 0 ms minRTT: 8 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: passive open, nagle, gen tcbs Datagrams (max data segment is 516 bytes): Rcvd: 34 (out of order: 0), with data: 20, total data bytes: 682 Sent: 26 (retransmit: 0, fastretransmit: 0), with data: 26, total data bytes: 1484 Edge1#show bgp ipv6 BGP table version is 21, local router ID is 172.16.0.11 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>iFEFE::A/128 FEFE::A 0 100 0 ? * i FEFE::A 0 100 0 ? *>iFEFE::D/128 FEFE::D 0 100 0 ? * i FEFE::D 0 100 0 ? *> FEFE::E1/128 :: 32768 ? *>iFEFE:A::/64 FEFE::A 0 100 0 ? * i FEFE::A 0 100 0 ? *>iFEFE:D::/64 FEFE::D 0 100 0 ? * i FEFE::D 0 100 0 ? *> FEFE:E1::/64 :: 32768 ? Edge1#show bgp ipv6 summary BGP router identifier 172.16.0.11, local AS number 65000 BGP table version is 21, main routing table version 21 6 network entries and 10 paths using 1454 bytes of memory 2 BGP path attribute entries using 120 bytes of memory 2 BGP rrinfo entries using 48 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP activity 8/50 prefixes, 20/10 paths, scan interval 60 secs

149

Concept: November 24, 2002

156

Activity Log

How to add IPv6 to the Lab Network

Neighbor V AS MsgRcvd MsgSent FEFE::A 4 65000 65 58 FEFE::D 4 65000 34 31 Edge1# [email protected]#

TblVer 21 21

InQ OutQ Up/Down State/PfxRcd 0 0 00:13:32 4 0 0 00:13:15 4

Conﬁgure RIPv6
RIPv6 is used to propagate IPv6 router to the local area networks. Since we do not want to learn routes via RIP we block all incoming route advertisements. Edge1 Edge1(config)#ipv6 router rip EDGE-LAN Edge1(config-rtr)#distance 254 Edge1(config-rtr)#redistribute bgp 65000 metric 10 Edge1(config-rtr)#distribute-list prefix-list DENY_ALL in Edge1(config-rtr)#exit Edge1(config)# Edge1(config)#ipv6 prefix-list DENY_ALL deny ::/0 Edge1(config)# Edge1(config)#interface ethernet 0 Edge1(config-if)#ipv6 router rip EDGE-LAN Edge1(config-rtr)#exit Don’t forget wr mem. Let us see if the conﬁguration is working. Edge1 Edge1#show ipv6 rip RIP process "EDGE-LAN", port 521, multicast-group FF02::9, pid 76 Administrative distance is 120. Routing table is 0 Updates every 30 seconds, expire after 180 Holddown lasts 180 seconds, garbage collect after 120 Split horizon is on; poison reverse is off Default routes are not generated Periodic updates 8, trigger updates 0 Edge1# Edge1#term moni Edge1#debug ipv6 rip RIP Routing Protocol debugging is on Edge1# Oct 9 22:03:13.100: RIPng: Sending multicast update on Ethernet0 for EDGE-LAN Oct 9 22:03:13.104: src=FE80::200:CFF:FE4A:A1D1 Oct 9 22:03:13.104: dst=FF02::9 (Ethernet0) Oct 9 22:03:13.108: sport=521, dport=521, length=72 Oct 9 22:03:13.112: command=2, version=1, mbz=0, #rte=3 Oct 9 22:03:13.112: tag=0, metric=10, prefix=FEFE:A::/64 Oct 9 22:03:13.116: tag=0, metric=10, prefix=FEFE:D::/64 Oct 9 22:03:13.116: tag=0, metric=1, prefix=FEFE:E1::/64 Oct 9 22:03:39.688: RIPng: Sending multicast update on Ethernet0 for EDGE-LAN

150

Concept: November 24, 2002

157

Activity Log

How to add IPv6 to the Lab Network

Oct 9 22:03:39.692: src=FE80::200:CFF:FE4A:A1D1 Oct 9 22:03:39.692: dst=FF02::9 (Ethernet0) Oct 9 22:03:39.696: sport=521, dport=521, length=72 Oct 9 22:03:39.700: command=2, version=1, mbz=0, #rte=3 Oct 9 22:03:39.700: tag=0, metric=10, prefix=FEFE:A::/64 Oct 9 22:03:39.704: tag=0, metric=10, prefix=FEFE:D::/64 Oct 9 22:03:39.704: tag=0, metric=1, prefix=FEFE:E1::/64 Oct 9 22:04:06.496: RIPng: Sending multicast update on Ethernet0 for EDGE-LAN Oct 9 22:04:06.500: src=FE80::200:CFF:FE4A:A1D1 Oct 9 22:04:06.504: dst=FF02::9 (Ethernet0) Oct 9 22:04:06.504: sport=521, dport=521, length=72 Oct 9 22:04:06.508: command=2, version=1, mbz=0, #rte=3 Oct 9 22:04:06.508: tag=0, metric=10, prefix=FEFE:A::/64 Oct 9 22:04:06.512: tag=0, metric=10, prefix=FEFE:D::/64 Oct 9 22:04:06.516: tag=0, metric=1, prefix=FEFE:E1::/64 Edge1# Edge1#un all All possible debugging has been turned off Edge1# Edge1#debug ipv6 icmp ICMP packet debugging is on Edge1# Oct 9 22:07:08.405: ICMPv6-ND: Sending RA to FF02::1 on Ethernet0 Oct 9 22:07:08.409: ICMPv6-ND: prefix = FEFE:E1::/64 onlink autoconfig Edge1# Looks like we have a working conﬁguration. Router Edge2 can be conﬁgured accordingly.

151

Concept:

November 24, 2002

158

Activity Log

How to add IPv6 to the Lab Network

C.1.3

Conﬁgure NetBSD/Zebra Edge Router
Well, by now you should already have a good understanding of how to conﬁgure a NetBSD edge router for IPv6. Basically the following steps are required on an edge router: • • • • • Edit /etc/rc.conf and /etc/rc.local. Check the section regarding conﬁguration of route reﬂectors. Conﬁgure interfaces for IPv6 (including gif, loopback, and Ethernet). Conﬁgure static IPv6 routes for the loopback interfaces of the peering routers. Conﬁgure BGP analogous to an Cisco edge router. Conﬁgure RIPv6 to redistribute IPv6 route on edge networks.

On the hub routers (Anchor and Dinghy) the following steps are required: • • • Conﬁgure the interfaces towards the edge router. 11 Conﬁgure static IPv6 routes for the loopback interface of the edge router. Conﬁgure BGP like for an Cisco edge router.

11

In the case of router Core4 this is a gif interface on Anchor. Dinghy is attached via a local area network

152

Concept:

November 24, 2002

159

Activity Log

Conﬁguring DJBDNS

C.2

Conﬁguring DJBDNS
Anchor and Dinghy provide name service for the lab network. In order to provide the service both machines have djbdns (http://cr.yp.to/djbdns.html) and daemontools (http://cr.yp.to/daemontools.html) installed. [email protected]> pkg_info djbdns Information for djbdns-1.05: Comment: Collection of secure and reliable DNS tools by Dan Bernstein Description: DJBDNS is a collection of Domain Name System tools. It includes several components: * The dnscache program is a local DNS cache. It accepts recursive DNS queries from local clients such as web browsers. It collects responses from remote DNS servers. * The tinydns program is a fast, UDP-only DNS server. It makes local DNS information available to the Internet. * The pickdns program is a load-balancing DNS server. It points clients to a dynamic selection of IP addresses. * The walldns program is a reverse DNS wall. It provides matching reverse and forward records while hiding local host information. * The dns library handles outgoing and incoming DNS packets. It can be used by clients such as web browsers to look up host addresses, host names, MX records, etc. It supports asynchronous resolution. * The dnsfilter program is a parallel IP-address-to-host-name converter. * The dnsip, dnsip6, dnsipq, dnsname, dnstxt, and dnsmx programs are simple command-line interfaces to DNS. * The dnsq and dnstrace programs are DNS debugging tools. You * * * may also want to use: pkgsrc/net/ucspi-tcp, if you’re going to use axfrdns or axfr-get tinydns logfile formatter, installed under ${PREFIX}/bin/tinydns-log dnscache logfile formatter, installed under ${PREFIX}/bin/dnscache-log (formatters are taken from http://tinydns.org, they need perl to run] * tai64nlocal (pkgsrc/sysutils/daemontools) -- to convert timestamps printed out by these two formatters to human readable form

This package includes IPv6 patches written by Fefe, see http://www.fefe.de/dns/ for more details. Please read http://cr.yp.to/djbdns/upgrade.html if you’re upgrading from previous version of djbdns.

153

Concept: November 24, 2002

160

Activity Log

Conﬁguring DJBDNS

Homepage: http://cr.yp.to/djbdns.html [email protected]> [email protected]> pkg_info daemontools Information for daemontools-0.70: Comment: Service monitoring and logging utilities by djb Description: Daemontools is a small set of /very/ useful utilities, from Dan Bernstein. They are mainly used for controlling processes, and maintaining logfiles. Homepage: http://cr.yp.to/daemontools.html [email protected]> The following section, which follows Martin Lessers dnscache-HOWTO (http://www.better-com.de/dnscache/howtode/), gives an overview of the conﬁguration. Some stuﬀ has been stolen from the ‘Inoﬃcial djbdns FAQ’ (http://www.fefe.de/djbdns/), which is also a very useful resource. Two machines are used to provide naming service for the lab. Unlike bind djbdns does not use a concept of primary and secondary name servers. Both name servers are equal. There are no zone transfers required with djbdns. Synchronization of the two databases can be done using utilities such as rsync. The name service on a single machine is implemented by two programs, dnscache and tinydns. It is not possible to use the same IP address for both programs. dnscache is conﬁgured with the IP address of the Ethernet interface. tinydns is conﬁgured with the IP address of the loopback interface (127.0.0.1). Then dnscache is conﬁgured to ask the local instance of tinydns. Firstly we create the required user accounts. Please note that the accounts do not require a home directory. Login shell is set to /sbin/nologin for security reasons. [email protected]# useradd: Warning: home [email protected]# useradd: Warning: home [email protected]# useradd: Warning: home [email protected]# /sbin/nologin [email protected]# useradd -g nogroup tinydns directory ‘/home/tinydns’ doesn’t exist, and -m was not specified useradd -g nogroup dnscache directory ‘/home/dnscache’ doesn’t exist, and -m was not specified useradd -g nogroup dnslog directory ‘/home/dnslog’ doesn’t exist, and -m was not specified which nologin chsh tinydns

#Changing user database information for tinydns. <snip> Shell: /sbin/nologin <snip> [email protected]# chsh dnscache

154

Concept: November 24, 2002

161

Activity Log

Conﬁguring DJBDNS

#Changing user database information for dnscache. <snip> Shell: /sbin/nologin <snip> [email protected]# chsh dnslog #Changing user database information for dnslog. Login: dnslog <snip> Shell: /sbin/nologin <snip> [email protected]# Now we are going to conﬁgure tinydns. Firstly we create the name server, DNS zone, and reverse lookup zones for the lab network. [email protected]# tinydns-conf tinydns dnslog /etc/tinydns 127.0.0.1 [email protected]# [email protected]# cd /etc/tinydns/root [email protected]# ls Makefile add-alias6 add-host add-mx data add-alias add-childns add-host6 add-ns [email protected]# [email protected]# ./add-ns brest.lab 127.0.0.1 [email protected]# ./add-ns 16.172.in-addr.arpa 127.0.0.1 [email protected]# ./add-ns 168.192.in-addr.arpa 127.0.0.1 [email protected]# ./add-ns 10.in-addr.arpa 127.0.0.1 Now we populate the zone with name to address mappings. Reverse lookup zones will be populated automagically. [email protected]# [email protected]# [email protected]# [email protected]# [email protected]# [email protected]# [email protected]# [email protected]# Some aliases for lab boxes. [email protected]# [email protected]# [email protected]# [email protected]# ./add-alias ./add-alias ./add-alias ./add-alias www.brest.lab 172.16.254.2 mrtg.brest.lab 172.16.255.2 ns1.brest.lab 172.16.254.2 ns2.brest.lab 172.16.255.2 ./add-host ./add-host ./add-host ./add-host ./add-host ./add-host ./add-host ./add-host dinghy.brest.lab 172.16.255.2 anchor.brest.lab 172.16.254.2 core1.brest.lab 172.16.0.1 core2.brest.lab 172.16.0.2 core3.brest.lab 172.16.0.3 edge1.brest.lab 172.16.0.11 edge2.brest.lab 172.16.0.12 edge3.brest.lab 172.16.0.13

Since NetBSDs djbdns package includes IPv6 patches written by Felix von Leitner (http://www.fefe.de/dns/) we do have IPv6 naming service out of the box. [email protected]# ./add-host6 dinghy.ipv6.brest.lab fefe::d [email protected]# ./add-host anchor.ipv6.brest.lab fefe::a

155

Concept:

November 24, 2002

162

Activity Log

Conﬁguring DJBDNS

In the second step we conﬁgure the dnscache program. Firstly we create the cache. Please note that we bind the dnscache program to the IP address of the Ethernet interface. Above we conﬁgured the tinydns program to use the loopback address. [email protected]# dnscache-conf dnscache dnslog /etc/dnscache 172.16.255.2 By default dnscache will only answer to requests initiated from the hosting machine. Now we conﬁgure it to accept requests from all machines in the lab network. The ﬁle /etc/dnscache/root/ip/10 instructs dnscache to accept requests from IPv4 addresses in the range 10.0.0.0/16. [email protected]# touch /etc/dnscache/root/ip/172.16 [email protected]# touch /etc/dnscache/root/ip/192.168 [email protected]# touch /etc/dnscache/root/ip/10 Now we instruct dnscache to consult the local tinydns server to resolve names in the lab zones. [email protected]# cd /etc/dnscache/root/servers/ [email protected]# ls @ [email protected]# echo ’127.0.0.1’ >brest.lab [email protected]# echo ’127.0.0.1’ > 16.172.in-addr.arpa [email protected]# echo ’127.0.0.1’ > 168.192.in-addr.arpa [email protected]# echo ’127.0.0.1’ > 10.in-addr.arpa [email protected]# [email protected]# ll total 5 -rw-r--r-- 1 root wheel 10 Oct 4 18:08 10.in-addr.arpa -rw-r--r-- 1 root wheel 10 Oct 4 18:08 16.172.in-addr.arpa -rw-r--r-- 1 root wheel 10 Oct 4 18:08 168.192.in-addr.arpa -rw-r--r-- 1 root wheel 164 Oct 4 18:04 @ -rw-r--r-- 1 root wheel 10 Oct 4 18:07 brest.lab [email protected]# [email protected]# cat brest.lab 127.0.0.1 [email protected]# [email protected]# cat 16.172.in-addr.arpa 127.0.0.1 [email protected]# cat 168.192.in-addr.arpa 127.0.0.1 [email protected]# cat 10.in-addr.arpa 127.0.0.1 [email protected]# [email protected]# cat @ 198.41.0.4 128.9.0.107 192.33.4.12 128.8.10.90 192.203.230.10 192.5.5.241 192.112.36.4 128.63.2.53

156

Concept: November 24, 2002

163

Activity Log

Conﬁguring DJBDNS

192.36.148.17 198.41.0.10 193.0.14.129 198.32.64.12 202.12.27.33 [email protected]# Lastly we create entries for dnscache and tinydns in the service directory. This puts the programs under control of the daemontools. [email protected]# ll /service total 0 lrwxr-xr-x 1 root wheel 21 Oct 1 14:09 gated -> /usr/local/etc/gated/ lrwxr-xr-x 1 root wheel 18 Sep 30 16:25 zebra -> /usr/pkg/etc/zebra [email protected]# [email protected]# ln -s /etc/tinydns /service [email protected]# ln -s /etc/dnscache /service [email protected]# [email protected]# ll /service total 0 lrwxr-xr-x 1 root wheel 13 Oct 4 18:13 dnscache -> /etc/dnscache lrwxr-xr-x 1 root wheel 21 Oct 1 14:09 gated -> /usr/local/etc/gated/ lrwxr-xr-x 1 root wheel 12 Oct 4 18:12 tinydns -> /etc/tinydns lrwxr-xr-x 1 root wheel 18 Sep 30 16:25 zebra -> /usr/pkg/etc/zebra [email protected]# [email protected]# ps -aux | grep tinydns tinydns 28740 0.0 0.8 164 492 ?? S 6:12PM 0:00.22 /usr/pkg/bin/tinydns root 28732 0.0 0.7 36 464 ?? S 6:12PM 0:00.09 supervise tinydns root 29719 0.0 0.9 204 588 p1 S+ 6:13PM 0:00.06 grep tinydns [email protected]# [email protected]# ps -aux | grep dnscache dnscache 28957 0.0 2.7 1388 1796 ?? S 6:13PM 0:00.35 /usr/pkg/bin/dnscache root 28952 0.0 0.7 36 464 ?? S 6:13PM 0:00.09 supervise dnscache root 29896 0.0 2.6 1424 1708 p1 RV 6:13PM 0:00.00 grep dnscache (tcsh) [email protected]# Check if the name service is running properly. [email protected]# dnsipq core1 core1.brest.lab 172.16.0.1 [email protected]# [email protected]# dnsip core1.brest.lab 172.16.0.1 [email protected]# [email protected]# dnsname 172.16.0.1 core1.brest.lab [email protected]# That was easy, wasn’t it? The conﬁguration on node Anchor is analogous to the example above.

157

Concept:

November 24, 2002

164

D Xyplex MaxServer 1600
iTouch Communications (http://www.itouchcom.com/) has taken over the old Xyplex terminal server product line. Transfering the documentation section from the Nbase/Xyplex web site to the iTouch web site was lossy. I included documentation from the iTouch web site so that this document is now self contained.

D.1 Access Server Administrator’s Primer
The NBase-Xyplex Access Server is a multi-protocol terminal server which supports direct Asyncronous connections for most Serial peripherals. These devices can be either terminals, printers, async modems for remote access, console ports for UNIX workstations, management port on switches, hand-held scanners, and a variety of other data-collecting serial devices. The access server can concurrently support users who are logged into IP and VMS systems, dial-in and dial-out with interactive, SLIP or PPP sessions, network printing, and provide network access to serial Management Ports on other network devices. The purpose of this document is to provide an overview on the initial key issues you should be aware of when ﬁrst working with the unit. These key issues include: the server’s loading process, user interface concepts, server and port conﬁgurations, and safe methods for rebooting the server after it has been conﬁgured.

D.1.1

Bootstrap
The access server REQUIRES that it be connected to a 10 mbps Ethernet LAN before it will start the normal loading sequence. The unit does not support 100 mbps fast ethernet. During the loading process, if a LAN connection is not seen by the unit, then it will not load and the following message will be displayed on an attached terminal: Searching for a Functional Standard Ethernet Network. To resolve this problem, verify the cabling between the LAN and the ethernet port on the access server. For 10baseT connections, a straight-thru ethernet cable is required between the access server and a DCE device (such as an ethernet hub or switch), and a cross-over ethernet cable is required for connections to a DTE device (such as a bridge/router). Once the LAN is detected, the unit will complete a hardware self test and begin to load. To complete the loading process and become fully functional, the server requires two ﬁles: the software image or runtime code AND the parameter ﬁle. The access server will ﬁrst load the runtime image, then load and implement the parameter database. The server’s boot ROMs are designed to load both ﬁles using several loading protocols.

Software Image
The Access Server defaults to load the runtime image using protocols in the following order: CARD For loading from a local FLASH memory card that is inserted in the unit.

158

Concept:

November 24, 2002

165

Xyplex MaxServer 1600

Access Server Administrator’s Primer

XMOP Xyplex’s proprietary load protocol where one Xyplex device will act as a load server for another Xyplex device. MOP The unit will send DEC MOP load broadcasts across the LAN searching for a VAX load server. BOOTP The unit will send a bootp broadcast, searching for a bootp server to gain an ip-address to use so it can tftp download the image runtime code from a tftp host. If an router is between the Xyplex device and the bootp server, you will need to ensure the router will forward bootp packets on to the bootp server. Bootp is not routable. CISCO calls this a helper IP. RARP The unit will send a rarp broadcast looking for a response from a rarp server to provide an ip-address to use so it can tftp download the image runtime code from a tftp host. Once the access server has downloaded the image ﬁle, it will then decompress and implement the runtime code it received.

D.1.2

Parameter File
Once the server has processed the runtime image, it will then download and implement the parameter database. The parameter ﬁle contains all of the server and port settings. Should this ﬁle be incomplete or corrupted, the access server will either complete the bootstrap process using the default parameter set, or it will not completely boot/reboot, instead displaying a ﬂashing LED error code on the front panel. To correct this situation, please reference the ”Getting Started” manual and follow the process to gain access to the ROM Conﬁguration Menu in order to default the server and port settings. There is also a Technical Paper available on the NBase-Xyplex web page that outlines this process in detail: http://www.nbase-xyplex.com/support/documentation/tp/default2.cfm The process will require a directly attached terminal to any single async port on the server. The server’s default parameter load protocols are in the order below (this order may vary depending on the access server hardware type you are working with): NVS Non-Volatile Storage located within the unit on the motherboard. This is the default for all NBase-Xyplex access servers except the N9-720 which has no NVS on board. CARD The only NBase-Xyplex access server that can retrieve its parameter ﬁle from an on-board ﬂash memory card would be the N9-720 server. No other server can support this function directly. XMOP Using the Xyplex proprietary protocol, the server will broadcast a load request to get a copy of its parameter ﬁle from another Xyplex device which has stored its parameter ﬁle. The responding Xyplex device must have a local ﬂash memory card (where it stores the parameter ﬁles for other units) and have ”Manager Load” and ”Parameter Service” as enabled functions. MOP The unit will send DEC MOP load broadcasts across the LAN searching for a VAX load server that is running the Xyplex software process ”xyp manager” and has an NCP entry for that access server as well as a copy of its parameter ﬁle. NOTE: ”xyp manager” is not supported on OpenVMS version 6.2 or higher. BOOTP Same process as for the image loading, but the unit will look for a ﬁle named ”x012345.prm” from the tftp server (where 012345 represents the last 6 digits of the unit’s ethernet address). RARP Same process as for the image loading, but the unit will look for a ﬁle named ”x012345.prm” from the tftp server (where 012345 represents the last 6 digits of the unit’s ethernet address).

159

Concept:

November 24, 2002

166

Xyplex MaxServer 1600

Access Server Administrator’s Primer

D.1.3

Login
Once the server is fully booted, the RUN and LAN lights will ﬂash about once per second. At this time, press the or key on the terminal keyboard several times. This will allow the access server’s port to autobaud to the speed your terminal is set to. Terminal parameters should be set to VT100 emulation, character size 8, parity none, stop bits 1, and XON/XOFF (software) ﬂow control. As you press the return key, the LED in the front panel that corresponds to the port your terminal is connected to, should ﬂash. If it doesn’t, there could be a communications issue between the port and your terminal. You should verify your terminal settings and cabling between the two. Reference the ”Getting Started” manual for DTE pinouts and cabling requirements. There is also a Technical Paper available on the NBase-Xyplex web page that provides this information as well: http://www.nbase-xyplex.com/support/documentation/tp/as\_cabling.cfm Once the port and the terminal are communicating properly, you will see the server’s default welcome message and be prompted to log into the server: Welcome to the Xyplex Terminal Server. Enter username> At this point, the server is just looking for any name or character sting to be entered. It is not looking for something speciﬁc - whatever you enter is not important. The ”string” you provide will appear on certain ”show port” screens as a visual reference to indicate who is logged in there, for user and administrator convenience only. Enter username> enter_some_string After entering any alpha or numeric string, you are presented with the default port prompt: Xyplex> At this point you are logged into and talking to an active and functional access server port. The next step is to conﬁgure the unit to meet your needs and goals.

D.1.4

Conﬁguration
The parameter database is where the access server’s unique proﬁle and port settings are stored, and from where they are reloaded each time the server is rebooted. The parameter ﬁle is where all the changes you make to the server and each port are saved. This ﬁle needs to be protected so that it does not get corrupted during a reboot. In order to make changes to the parameter ﬁle (i.e. conﬁgure the unit), you must be in privileged (priv) mode. The sequence is as follows (please note the user command and the default privilege password): Xyplex> set priv Password: system Xyplex>> The port prompt has changed to include a double greater-than symbol. You may shorten this sequence by the single command string set priv system, but this is software version dependent.

160

Concept:

November 24, 2002

167

Xyplex MaxServer 1600

Access Server Administrator’s Primer

The server has two memory levels, if you will, thus there are two types of commands used during conﬁguration. Level 1 is Active Memory (or operational database) which is the current conﬁguration the server and ports are working with while the unit is in operation. Should you issue a SET command to change a parameter to a diﬀerent value, that conﬁguration change would be lost when the port is logged out (for port settings) or if the server was rebooted. The SET command allows for a temporary change to the active working parameter set. If the SET command was used to change a port setting, that setting will revert back to the original setting when the port resets for any reason (including a simple logout by the user on that port; or if someone in privileged mode logs that port out; or if the server is rebooted). Level 2 memory is Permanent Memory (or stored conﬁguration) which is recalled upon a reboot or port logout. Should you want to make a change to the server and port settings that needed to be recalled after a reboot of the server or after a port is logged out, a DEFINE command would be required. The SET commands can be used by both privileged and non-privileged users. The DEFINE commands are limited to the privileged user only. The following examples will illustrate the aﬀect of the SET command versus DEFINE command after a user logs out: Change the port prompt in the Active Memory conﬁguration: Xyplex> set port prompt "Port_3" The yield of the above command: Port_3> logout After the user logs out, the port will reset and go back to the values as deﬁned in the Permanent memory database. Note the port prompt once the user logs back into the port: Xyplex> Change the port prompt in the Level 2 Permanent Memory conﬁguration: Xyplex>> define port prompt "Port_3" The yield of the above command: Xyplex>> logout After the user logs out of the port, it will reset and read the settings stored in the permanent database, implementing the new setting. Notice the port prompt once the user logs back into the port: Port_3> When conﬁguring the access server, there is an parameter feature called ”CHANGE” that, when enabled, will automatically execute the SET command whenever you issue a DEFINE command, thus eliminating the need for typing in the second command line. To enable the CHANGE feature, execute:

161

Concept:

November 24, 2002

168

Xyplex MaxServer 1600

Access Server Administrator’s Primer

Xyplex>> set server change enable Xyplex>> define server change enable Here is how it is helpful: When you deﬁne an internet address to the server using Xyplexdefine server internet address 10.10.10.3, the ip-address is written to permanent memory, which would then require either the SET command to also be issued or a reboot of the entire server in order for the value to become active. If you only issued a SET command with Xyplexset server internet address 10.10.10.3, the ip-address would become active immediately, but lost when the server was rebooted unless the DEFINE was also performed. This example illustrates that changing both the temporary and permanent conﬁguration would require two commands without a reboot. With CHANGE enabled, when you issued the deﬁne server internet address command, the server would: • • Update the permanent conﬁguration database, Automatically execute the SET command so the ip-address would become active right away without requiring a reboot.

Please Note: NOT all server or port parameters can be changed with the SET command. When the CHANGE feature is enabled, at some point you will deﬁne some parameter and be prompted with a warning or informational message: Xyplex -729- Parameter cannot be modified by a SET command. Some of the commands cannot be ”set” because the change could aﬀect any users that may be logged into that particular server/port(s). The message is also displayed when enabling certain server-wide features and protocols (such as LPD, Radius, IPX, etc), because memory resources will need to be allocated for the feature’s use. These features will also display the message Xyplex -705- Change leaves approximately \# bytes free. If you see this message after making a parameter change to a port, you will need to reset the port for the change to become active/operational immediately. To do this, you simply need to issue the command logout port \# (which, in addition to ”set”-ting the parameter, will also disconnect any user who may be connected to it): Xyplex>> logout port # (where "#" is the physical port number you made the change to) If you see this message after issuing a command to change a server-wide parameter, or enable a feature, then you will need to reboot the server at some point for the new parameter to be implemented. Follow the instructions on safe reboot methods in the next section of this paper.

D.1.5

Rebooting
Important: To reboot the server, it is strongly recommended you use the conﬁguration/parameter friendly reboot command initialize: Xyplex>> initialize This is a command where the server will, by default, wait for one minute before it automatically reboots using the process boot/load sequences discussed earlier. You can also modify the time to reboot by providing a time argument:

162

Concept:

November 24, 2002

169

Xyplex MaxServer 1600

Access Server Administrator’s Primer

Xyplex>> initialize delay # (where "#" is the variable in minutes before the unit will reboot) If the time argument is ”0” the unit will reboot immediately. If the time argument is greater than ”0”, the server will reboot in that number of minutes speciﬁed. The beauty of the initialize command is that it is parameter-database friendly. Provided the parameter/conﬁguration ﬁle is current and up-to-date and in an idle state (see the show parameter server screen), the server will terminate all processes and proceed through a normal bootstrap process. If the server is still writing the parameter changes to permanent memory, it will not prematurely terminate the write process so as to prevent corruption of the parameter database. The server will instead give you a warning message: Xyplex -198- WARNING - changed configuration has not been saved. After you issue the last define command, the server waits a period of time to make sure there are no more defines to follow, then it writes the ”lump sum” of your commands all at once to the parameter storage locations (i.e. ﬂashcard, NVS, host). All of this takes approximately 30-40 seconds from the moment you issued the last define command. If the unit is forced to reboot while writing parameters, then the ﬁle will get corrupted. The initialize command will not force a reboot, and therefor, if it has not yet saved the changes, it will display the above message. Should this happen, give the Xyplex device another minute or so in order to complete the process of writing the parameter database to memory, then try issuing the initialize command again.

D.1.6 Normally NOT Suggested
There are three methods of rebooting the access server that are not sensitive to the storing status of the parameters. It is not suggested you execute either of them unless you verify the parameters are saved and current beforehand. The server command to check on the status of the parameter ﬁle storage state is: Xyplex>> show parameter server Check for the status, version, and storage state of the parameter servers. The storage state needs to be ”Idle”, the status should be ”current”, and the versions at each location should be the same as the value listed next to ”Last Update Version” in the ﬁrst column. Again, the parameter database health is your responsibility should you do any of the next three processes. • There is a server command CRASH. This command will reboot the server, but the process is as gentle as the word itself reﬂects. When you use this command, the server will immediately attempt to dump its core memory to a dump server. CRASH is not sensitive to the state of the parameter set. If the server is writing parameters to permanent memory, this command will terminate the write process immediately and there is a 100 Another reboot process that is NOT sensitive to the parameter set is a power cycle of the unit. In other words, pulling the power cord. All processes are terminated immediately including all the rules related to checking for a complete and valid parameter set. Defaulting the unit will be in order if the parameter database gets corrupted. The third reboot process, again not suggested, is using the reset switch. Pressing the reset switch with a paperclip two quick times will force the server to reboot. This process is also NOT parameter

•

•

163

Concept:

November 24, 2002

170

Xyplex MaxServer 1600

Access Server Administrator’s Primer

database sensitive. Should the server be writing parameters to memory, the write and verify process is terminated regardless of whether or not the process had been completed. If the unit displays a ﬂash error code on a reboot, you will have to default the server parameters and start anew as well. On a positive note: It is possible that, if the parameter ﬁle is current and in an idle state, and you happen to reboot using these last three mechanisms, you could be in luck and not have a problem. These reboot methods do work, but there is a high level of risk when used. It is best to always reboot using the initialize command whenever it is possible to access the server’s command line interface (CLI).

D.1.7

Additional Information
The NBase-Xyplex Access Servers are a reliable network device. They support several network protocols for loading its runtime code and server proﬁle conﬁguration/parameter ﬁles. Once the server is up and running, they can be conﬁgured to operate with permanent and temporary settings using the Deﬁne and Set commands at the server’s command line interface, i.e. port prompt. The Access Server provides a help utility to solve command line syntax errors. It will always highlight or note the command or argument that are not known and will provide you with a list of valid commands or verbs it was expecting to see. The Access Server also provides informational and warning messages when certain conditions are met to assist you when working with and conﬁguring the server. You are able to reboot the server from local or remote locations using the Initialize command knowing it will validate the status of the parameter ﬁle ﬁrst. A key element when working with devices attached to physical ports on the server is the wiring between the ports and third party devices. The manual NBase-Xyplex provides with each unit, will list the expected DTE and DCE pinouts and cable to use. The server supports various show port screens to display the port status and port counters, not discussed above, that can be used in troubleshooting communications issues. The Access Server also allows you to view port characteristics, alternate characteristics, and telnet characteristics to look at various port settings. These and many more commands are described and discussed in the documentation Commands Reference Guide. This and other manuals are on the NBase-Xyplex Web page as well as on CD-ROM. The intent of this document was to give a brief overview of a few key issues the System Administrator should know when working with the Access Server. The Access Server is a ﬂexible device that can be conﬁgured to meet many and various needs.

D.1.8

Additional Documentation and Resources
NBase-Xyplex has available on our web site numerous detailed command line help ﬁles to assist you in conﬁguring the access server and its ports. Help ﬁles are also available that outline the process to use certain Host applications and features which interact with the access server’s functionality (ex. CSPORTD printing, etc); as well as some unique conﬁgurations other customers have implemented. The web URL below brings you to the main page of the Customer Support area. For conﬁguration and troubleshooting assistance, there are links here to our Technical Papers, Technical Tips, FAQ Finder, Manuals and User Guides, Software Downloads, and more. http://www.nbase-xyplex.com/support/index.cfm

164

Concept:

November 24, 2002

171

Xyplex MaxServer 1600

Access Server Administrator’s Primer

Customers who have purchased one of NBase-Xyplex’s various Service Support contract oﬀerings will have access to a password-protected area where they can download the latest software updates from the web URL below: http://www.nbase-xyplex.com/support/software/index.cfm For Technical Papers speciﬁc to the Access Server, point your browser to: http://www.nbase-xyplex.com/support/documentation/tp/access\_menu.cfm For Manuals and User Guides speciﬁc to the Access Server, point your browser to: http://www.nbase-xyplex.com/support/documentation/product/guides/index.cfm?doc=accessserver For Software Updates speciﬁc to the Access Server, point your browser to: http://www.nbase-xyplex.com/support/contract/software/index.cfm?query=access Copyright 2001 iTouch Communications, Inc.

165

Concept:

November 24, 2002

172

Xyplex MaxServer 1600

Setting An MX-1600, MX-1608 or MX-1450 To Factory Defaults

D.2

Setting An MX-1600, MX-1608 or MX-1450 To Factory Defaults
• • Straighten a paper clip and press into the pin-size hole next to console LED on the front panel of the unit. All LEDs on the front of the unit will light up. Press the paper clip in again and hold it in for 3-5 seconds. The LEDs will light up in a sweeping fashion from right to left, then left to right. When this sweeping stops, there will be 2 or 3 LEDS to the right lit, at this point release the paper clip. The LEDs will light up in a countdown pattern to 1 (diagnostic test pattern). Then they will all go out and the RUN light will be ﬂashing very fast. You should have a terminal attached to one of the serial ports on the back of the unit. Press the ENTER key several times for the port to autobaud. You will see a text display similar to this: Terminal Server, Type 97, Rev G.00.00 Ethernet address 08-00-87-05-A1-16, port 2 Configuration in progress. Please wait • Type the password access (there is no password prompt and it will not display the characters you type) and then press ENTER on your keyboard. The menu below will display. Please select the menu options and answer the questions as detailed below to default your unit. To Default The Server Load/Dump Parameters: Welcome to the Configuration Menu. Terminal Server Configuration/Maintenance Menu 1. Display unit configuration 2. Modify unit configuration 3. Initialize server and port parameters 4. Revert to stored configuration S. Exit saving configuration changes X. Exit without saving configuration changes Enter menu selection [X]: 2 Initialize configuration to defaults (Y,N) [N]? Y (Type any key to continue) Press ENTER on your keyboard at this time... • To Default The Server And Port Parameters: Terminal Server Configuration/Maintenance Menu 1. 2. 3. 4. S. Display unit configuration Modify unit configuration Initialize server and port parameters Revert to stored configuration Exit saving configuration changes

•

•

166

Concept:

November 24, 2002

173

Xyplex MaxServer 1600

Setting An MX-1600, MX-1608 or MX-1450 To Factory Defaults

X. Exit without saving configuration changes Enter menu selection [X]: 3 When the software has been loaded, should default server and port parameters be used (Y,N) [N]? Y • Save Conﬁguration Changes And Reboot The Server: Terminal Server Configuration/Maintenance Menu 1. Display unit configuration 2. Modify unit configuration 3. Initialize server and port parameters 4. Revert to stored configuration S. Exit saving configuration changes X. Exit without saving configuration changes Enter menu selection [X]: S Save changes and exit (Y,N) [Y]? Y The access server will now reboot using factory settings. Copyright 2001 iTouch Communications, Inc.

167

Concept:

November 24, 2002

174

Xyplex MaxServer 1600

Setting An MX-1600, MX-1608 or MX-1450 To Factory Defaults

D.2.1

Conﬁguring MX1600 To Load Image Via DTFTP
• Push a straightened paper clip into the pin-size hole on the far left side of front panel (N9-720) or the pin-size hole next to the CONSOLE LED for the MX16xx series (insertion time is 1 second). All the LEDs will light up. Push paper clip in again and hold in for about 3-4 seconds. The LEDs will light up in a sweeping fashion from right to left, then left to right. When this pattern stops and LEDs 14,15,16 are lit, remove the paper clip. The LEDs will light up in a countdown pattern to 1, which is the diagnostic test. After they all go out, the RUN light will blink very fast. You should have a terminal or PC attached to one of the RJ-45 ports on the back of the server. Press the ENTER key on your keyboard several times to autobaud your terminal to the port speed. You will see text displayed similar to this: Terminal Server, Type 97, Rev G.00.00 Ethernet address 08-00-87-0A-B9-BB Configuration in progress. Please wait. Please type the login password access at this time (there is no password prompt and it will not display the characters you type). Welcome to the Initialization Configuration Menu. Terminal Server Configuration Menu 1. Display unit configuration 2. Modify unit configuration 3. Initialize server and port parameters 4. Revert to stored configuration X. Exit saving configuration changes S. Exit without saving configuration changes Enter menu selection [X]: 1 Stored Configuration Status: Enabled New Configuration Enabled CARD XMOP MOP BOOTP RARP NVS XMOP MOP BOOTP RARP XMOP MOP BOOTP RARP XPCS00S 0.0.0.0 N/A N/A N/A Enabled Automatic 4 Megabytes

•

•

Image load method: CARD XMOP MOP BOOTP RARP Parameter load method: NVS XMOP MOP BOOTP RARP Dump method: XMOP MOP BOOTP RARP CARD/XMOP/MOP filename: XPCS00S Default unit IP addr: 0.0.0.0 DTFTP host IP addr: N/A DTFTP gateway IP addr: N/A DTFTP filename: N/A Load status messages: Enabled Network interface: Automatic Memory size expected 4 Megabytes (Found 4 Megabytes)

168

Concept: November 24, 2002

175

Xyplex MaxServer 1600

Setting An MX-1600, MX-1608 or MX-1450 To Factory Defaults

(Type any key to continue) Terminal Server Configuration Menu 1. 2. 3. 4. S. X. Display unit configuration Modify unit configuration Initialize server and port parameters Revert to stored configuration Exit saving configuration changes Exit without saving configuration changes

Enter menu selection [X]: 2 Set Initialization record #1 to defaults (Y,N) [N]? N Enable initialization record #1 (Y,N) [Y]? Y Enable ALL methods for image loading (Y,N) [N]? N Toggle (CARD,DTFTP,XMOP,MOP,BOOTP,RARP) load methods [C,X,M,B,R]: D Toggle (CARD,DTFTP,XMOP,MOP,BOOTP,RARP) load methods [C,D,X,M,B,R]: (hit ENTER) Enable ALL methods for parameter loading (Y,N) [Y]? (hit ENTER to accept defaults) Enable ALL methods for dumping (Y,N) [Y]? (hit ENTER to accept defaults) CARD/XMOP/MOP image filename (16 characters max) [XPCSRV20]: (hit ENTER) Enter unit IP address [0.0.0.0]: enter IP address of access server Enter host IP address [0.0.0.0]: enter IP address of the load host

Enter gateway IP address [0.0.0.0]: enter IP address of router Enter TFTP image filename (64 characters max.) : xpcs00s.sys Note: Some UNIX hosts do not use /tftpboot as the tftp home directory. If your host uses a diﬀerent path, please enter as part of the image ﬁlename. Example: Enter TFTP image filename (64 characters max.) : /usr/tftp/xpcs00s.sys (Type any key to continue) Terminal Server Configuration Menu 1. 2. 3. 4. Display unit configuration Modify unit configuration Initialize server and port parameters Revert to stored configuration

169

Concept: November 24, 2002

176

Xyplex MaxServer 1600

Setting An MX-1600, MX-1608 or MX-1450 To Factory Defaults

S. Exit saving configuration changes X. Exit without saving configuration changes Enter menu selection [X]: S Save changes and exit (Y,N) [Y]? Y Changes saved. \end{Verbatim} } The access server will now reboot using the DTFTP information entered above. \stopitemize To enable DTFTP on a running server using the Xyplex Command Language Interface: \starttyping Xyplex>> DEFINE Xyplex>> DEFINE Xyplex>> DEFINE Xyplex>> DEFINE Xyplex>> DEFINE

SERVER SERVER SERVER SERVER SERVER

IMAGE LOAD PROTOCOL DTFTP ENABLED INTERNET ADDRESS x.x.x.x (server address) INTERNET LOAD HOST x.x.x.x (host address) INTERNET LOAD GATEWAY x.x.x.x (1st hop router) INTERNET LOAD FILE "xpcs00s..sys"

Copyright 2002 iTouch Communications, Inc.

170

Concept:

November 24, 2002

177

Xyplex MaxServer 1600

Conﬁguring SYSLOG On Access Servers

D.3

Conﬁguring SYSLOG On Access Servers
Many Customers are having problems conﬁguring SYSLOG on their Access Server and their UNIX Hosts. The procedure is two fold. The Access Server needs to have SYSLOGD enabled and pointed to a UNIX Host. And the UNIX host needs to be conﬁgured to be running SYSLOG and have a deﬁnition for where the syslog information from the Access server should be stored.

D.3.1

Conﬁgure the Access Server for SYSLOGD
Xyplex >> define server accounting entries 1000 This will enable the accounting feature, by deﬁning the maximum number of accounting entries. Xyplex >> define server daemon syslogd enabled 192.9.200.1 This will enable the syslogd on the Access server and also point it to the UNIX host with ip-address 192.9.200.1. Xyplex>> init delay 0 This will re-initialize the Access server for the changes to take eﬀect. Xyplex >> set server verbose accounting enabled This will enable the VERBOSE accounting on the Access Server.

D.3.2

*Setting a Priority Number
There are several priority levels that deﬁne what type of information will be stored to the SYSLOG host. The priorities are: − LOG EMERG, 0, A severe condition. − LOG ALERT, 1, A condition the system manager needs to correct immediately. − LOG CRIT, 2, A critical condition such as a hard device error. − LOG ERR, 3, A software error condition. − LOG WARNING, 4, A warning message. − LOG NOTICE, 5, Conditions that may require speciﬁc procedures to adjust them. − LOG INFO, 6, Normal condition. Informational messages. − LOG DEBUG, 7, Messages with information useful for test situations only. The Priority chosen on the Access server will match with the one deﬁned on the UNIX host. To specify the priority number on the Access Server:

171

Concept:

November 24, 2002

178

Xyplex MaxServer 1600

Conﬁguring SYSLOG On Access Servers

Xyplex >> set server verbose priority 7 This will set the priority to 7. NOTE: Level 7 will get all message from priorities lower than 7 also. Xyplex >> clear server accounting This will clear the accounting log, so that the ﬁrst information will be the newest. Xyplex >> show server accounting This will display the accounting information stored locally on the Access Server. 720-console> show server account ACCOUNTING SUMMARY/SYSTEM LOG (ENTRIES WILL LOG AT OR BELOW PRIORITY LEVEL: 7) 02 May 1996 14:48:27 Accounting Summary/System Log Cleared by Port 15 02 May 1996 14:49:26 source:08-00-87-06-52-34 dest:140.179.240.14 port:0 user: (Remote) type:Rtelm 02 May 1996 14:49:31 Port: 00 User: wilbur User Login.

D.3.3

Conﬁgure the Unix Host for SYSLOGD
Well, we don’t need that, do we? Again, the stuﬀ is Copyright by iTouch Communications, Inc.

172

Concept:

November 24, 2002

179

Document History
Datum 24-Nov-2002 dd-mmm-yyyy dd-mmm-yyyy dd-mmm-yyyy Version 0.99 Status Draft Remark Migrated from old ‘Testbed and Tools’ format ... ... ... Document History

Table 1

173

Concept:

November 24, 2002

180

Document History

174

Concept:

November 24, 2002

180

Network static Lab workbook

Comments

Content

Sponsor Documents

Recommended