Professional Documents
Culture Documents
DRAFT
TODO: Update router conguration proles
Concept:
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 Oce 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 Conguration 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
Concept:
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 Verication Toolkit Some Tools that come with IOS Service Assurance Agent Trac 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
A Conguration Log A.1 Basic IPv4 Conguration A.1.1 Common Conguration - NTP, SNMP, Administrative Access A.1.2 Common Conguration - 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 Conguration 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:
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 Congure Route Reectors Enable IPv6 on Anchor and Dinghy Congure IPv6 Addresses on Ethernet and Loopback Interfaces Create Tunnel between Anchor and Dinghy Congure iBGP between Anchor and Dinghy C.1.2 Congure Cisco Edge Router Enable IPv6 on Edge Router Congure Tunnels Congure BGP on Route Reectors Congure BGP on Cisco Edge Router Test Static Route and Tunnel Check BGP Congure RIPv6 C.1.3 Congure NetBSD/Zebra Edge Router C.2 Conguring DJBDNS D Xyplex MaxServer 1600 D.1 Access Server Administrators Primer D.1.1 Bootstrap Software Image D.1.2 Parameter File D.1.3 Login D.1.4 Conguration 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:
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 Conguring MX1600 To Load Image Via DTFTP D.3 Conguring SYSLOG On Access Servers D.3.1 Congure the Access Server for SYSLOGD D.3.2 *Setting a Priority Number D.3.3 Congure the Unix Host for SYSLOGD Document History
163 164 164 166 168 171 171 171 172 173
iv
Concept:
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 Oce Network - Physical Design Oce 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
Concept:
Tables
3.1 3.2 4.1 4.2 1 Oce Network - Inventory Oce Network - IP Address Assignment Lab Network - Inventory Lab Network - IP Address Assignment Document History 7 8 15 17 173
vi
Concept:
1 Introduction
During the course of my lab sessions I found myself frequently re-cabling boxes and typing basic conguration statements into routers. I thought it would be convenient to have a default laboratory conguration that does support a wide variety of experiments without signicant 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 surng 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 oce network and a laboratory network. Oce 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 oce 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 oce and laboratory network including: Network architecture Network services Devices and device conguration Key software tools used in the network Cheat sheet for common conguration problems Problem and problem resolution log
1.2
Research Resources
Cisco Router Ciscos 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 specic to the Maxserver 1600 was available at the URL http://www.nbase-xyplex.com/support/documentation/product/guide/index.cfm?doc=access
Concept:
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 trac 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 logles 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 Trac Grapher) is a tool to monitor the trac load on network links. MRTG generates HTML pages containing graphical images which provide a live visual representation of this trac. The home page of MRTG (Multi Router Trac 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 trac 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.
Concept:
Introduction
Research Resources
Cricket reads a set of conguration les called a cong tree. The cong 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 cong 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 trac generation test packages. MRT software is in active use providing stress testing of commercial routers, collecting and analyzing Internet routing trac 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 oering, 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 trac 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
Concept:
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 Demetrious 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 specication, 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.
Concept:
11
2 Network Architecture
2.1 Topology Overview
The network has two main components: Oce or production network Laboratory network
2.2
Design Considerations
The network architecture was designed with the following considerations in mind. The oce network shall provide basic services (Internet access, printing) using as little equipment as possible. Services and resources of the oce network, such as Internet access and printing, shall be available to the lab network as well. Services of the oce network must not depend on the lab network or parts of it. Key components of the oce network shall not be used in labs. Reconguration of devices (Internet access router) impacting basic services of the oce 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 conguration modules/procedures that speed up the process of generating congurations for specic 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
Concept:
12
Frame Relay
Frame Relay
Frame Relay
http://www.brest-lab.net
Network Architecture
Et he rn et
h Et er ne t
Laboratory Network
Frame Relay
Concept:
Network Architecture
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 Oce Network
3.1 Physical Design
The oce 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 oce 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 oce 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 oce 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
Concept:
14
Oce Network
Logical Design
3.2
Logical Design
The oce 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 oce 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 oce 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 congured. The next hop interface of the routes is 172.16.254.254. The laboratory router connecting to the production network has this address congured on its Ethernet interface. It has a default route congured 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
3.3
Network Services
Concept:
15
Oce Network
Network Services
3.3.2 DHCP
Router Zerberus provides DHCP service for the oce 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 congured 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 conguration 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.
Head-less means it does not have a graphics controller or monitor attached to it. The machine uses a serial console device.
Concept:
16
Oce Network
Network Services
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
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
Figure 3.1
10
Concept:
17
Oce Network
Network Services
Static Route
Internet
0.0.0.0/0
IP negotiated
Zerberus
172.16.254.1
0.0.0.0/0
172.16.254.2
0.0.0.0/0
IP DHCP
Anchor
Ofce Network
IP: 172.16.254.0/24
DHCP Client
Name server
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
Figure 3.2
11
Concept:
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 dierent 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 conguration 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. Conguration les for basic operation can be found on page 73. With additional IPv6 conguration Anchor serves as IPv6 hub router. Conguration les for IPv6 operation can be found on page 78. Dinghy is a SGI Indy running NetBSD-Core software. In basic conguration 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. Conguration les for basic operation can be found on page 74. With additional IPv6 conguration Dinghy serves as IPv6 hub router. Conguration les for IPv6 operation can be found on page 84. Pagent is a Cisco 4500m router running IOS-Pagent.
12
Concept:
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
Conguration Files
Conguration les are subject to version control. The les are stored in RCS.
13
Concept:
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 conguration 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 conguration Loopback 1 = Version number of module for common conguration 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 conguration Loopback 11 = Version number of a routers MPLS VPN conguration Loopback 20 = Version number of a routers basic IPv6 conguration
On a running router version information can be retrieved by looking at the conguration 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
Some modules are generic while others are specically for a router.
14
Concept:
21
Lab Network
Physical Design
4.1.2 Hardware
Name Core1
Vendor Cisco
Model 2501
OS IOS-MPLS
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
Edge2
Cisco
2503
IOS-Edge
none
15
Concept:
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:
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
Oce 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
17
Concept:
24
Lab Network
Logical Design
4.2.1 MPLS
Unsupported MPLS images on c2500; AYAME code on NetBSD box; TODO: cong principle and examples
18
Concept:
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 specic 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.
Tunneling is encapsulation of IPv6 packets in IPv4 packets so that they can be transported over IPv4-only networks.
19
Concept:
26
Lab Network
Logical Design
Tunnels are congured with link local addresses. Global IPv6 addresses are not congured on pointto-point links because we want to minimize the conguration. 7 On Cisco routers tunnel interfaces are congured 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 reectors for iBGP peering. Route reectors can be either in the forwarding path or dedicated machines. At least two route reectors are recommended for redundancy purposes. Router Anchor and Dinghy are used as route reectors for iBGP. All BGP-speaking edge routers (Edge1, Edge2) peer with both route reectors. 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 oered by Core4 via RIP. Static routes towards this networks are dened 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 reectors to propagate next-hop address of directly attached edge router to other edge routers. Do not use peer groups on route reectors for route reector clients. 9 Use either distance or distribute-list in to prevent learning of routes via RIP.
Remember that the lab shall provide a quick way to build specic 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 reectors can be used in conjunction with peer groups only when the clients of a route reector are fully meshed. The reasoning is as follows: in a normal situation, a router A that learns a prex 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 prex is not reachable via A. This is to prevent a situation where A claims that a prex is reachable via B,
20
Concept:
27
Lab Network
Logical Design
Host Access
IPv6 end systems can be congured either manually or automatically. A major benet of IPv6 is the availability of address auto-conguration for host systems. Automatic host conguration for IPv6 can be done in two ways, using either stateless auto-conguration or DHCPv6. Stateless auto-conguration is used in the IPv6 test network because NetBSD does not support DHCPv6. Stateless auto-conguration requires that a router on a connected network emits periodically ICMPv6 router advertisement messages. These messages contain information such as IPv6 sub-network prex 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-conguration 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 reector situation, a route reector that has learned a prex from one of its clients and is trying to poison that route will end up withdrawing that prex from all the other clients. Because the clients are not talking to each other via BGP, that prex will be lost.
21
Concept:
28
Lab Network
Logical Design
Eth0
DLCI
400
100
Ser1 Phy: DTE Phy: DCE FR: DTE FR: DCE tlp0
back-to-back cable
100
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
100
FR: NNI
200
100
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
Ser1
Eth0
Figure 4.1
22
Concept:
ne2
i386 Core4
ep0
29
s1.200
http://www.brest-lab.net
Concept:
Lab Network
IPv4: 172.16.255.2/24
Area 10.1.1.0 Area 10.2.1.0 Area 10.3.1.0
<int>
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
23
s0.100
eth0
loop0
IPv4: 172.16.0.3/32
DEC AS200
Anchor
NetBSD-Core
Edge2
IOS-Edge 64kbps Frame Relay
loop0
eth0
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
tun1
s1.100
s1.200
s0.300
s0.100
tun0
tun0
Edge1
Edge2
lo0
Concept:
<int>
<int> gif1
<int>
Figure 4.3
IPv6: fefe:d::1/64 Core1 Core4 IPv6: fefe::e3/128
24
Logical Design
31
gif0
http://www.brest-lab.net
Concept:
Lab Network
IPv6: fefe::d/128
tlp0 redistribute
gif0
IPv6: fefe:a::1/64
Route Reector
iBGP
Dinghy
Figure 4.4
IPv6: fefe:d::1/64
iBGP
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
stateless auto-cong
stateless auto-cong
stateless auto-cong
Host
Host
Host
Logical Design
32
Lab Network
IOS-MPLS s1.300
s1.200
http://www.brest-lab.net
Concept:
IPv4: 172.16.255.2/24
IPv4
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
eth0
s1.100 s1.100 c2501 s0.200
loop0
eth0
26
s0.100
Core3
IOS-MPLS
eth0
s1.100
loop0
IPv4: 172.16.0.3/32
Anchor
NetBSD-Core
Edge2
IOS-Edge 64kbps Frame Relay
loop0
eth0
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 conguration example can be found in on page 153.
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. Conguration 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:
34
Network Services
TBD
5.9
28
35
Network Services
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
LER12# Conguring a jitter probe is a bit more complex. A probe must be congured locally and a responder must be congured on the remote router. Conguration 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 Conguration of the responder on router B. rtr responder
29
36
Network Services
A minimum TMS conguration looks like this: ip cef ip cef accounting non-recursive ! interface Multilink1 ip cef accounting non-recursive external You can access trac 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
37
Network Services
Update (merge with) current system configuration Copy to startup configuration Copy to system: file system Copy to tftp: file system
31
Concept:
38
Network Services
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 eective 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 aect 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 conguration so it is not required on subsequent downloads. Pagent tools include: TGN (Trac Generator) is used to dene and send packets on any combination of supported interfaces on a router. The program has predened templates to support the denition of specic packet types. Packet lengths and the data in any header eld can be set to constant, incrementing or random values. Packet denitions can be imported from the PKTS program capture buer. 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 dening packet formats. It adds new packet denitions to the Pagent tool set (TGN and PKTS) at run time and allows TGN trac streams and PKTS lters to be dened using the new formats. It allows the denition of multiple display methods that can be used to decode and display packets. Router Veried Trac (RVT) and Control Veried Trac (CVT) are used together to test bridges and routers. CVT can automatically create numerous trac streams between many Pagent router interfaces, for many dierent LAN media and network protocols. RVT can create modest levels of veried trac where every packet sent through the test network is validated for correct sequence, data integrity, and length. RVT can also create fast-unveried trac. PMOD (Passthru Modify) allows a Pagent router to be inserted into a test network so test trac passes through the router and then allows the trac packets to be modied. Depending on PMOD lters and congurations, 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 trac. The tool provides congurable features that enable a user to emulate various TCP application dialogs between a TCP client and a
32
Concept:
39
Network Services
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 trac. HTTP Session Emulator (HTTPSE) is a tool for generating HTTP trac. It emulates multiple HTTP clients establishing HTTP connections to a HTTP server. It generates all kinds of HTTP trac, 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 trac 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 conguration 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 conguration on the Pagent router has to complement the IP addresses and autonomous system numbers congured 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 congure 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
40
Network Services
This results in the following conguration: 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 conguration is started, the following appears on the console: c4700-p(BGP:OFF,Et1:1-Grp1)#start - ON: BGP Processes Started.
34
41
Network Services
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 conguration 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 conguration on the Pagent router must complement the IP addresses congured on the router under test. The following commands will:
35
Concept:
42
Network Services
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 Congure the OSPF process to advertise 20 networks Turn on basic program messages
These are the commands used to create and congure 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 conguration: 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
43
Network Services
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 conguration 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:
44
Network Services
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 conguration statements create a trac 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 trac ow uses 64 byte, 570 byte, 1518 byte IP packets with 7:4:1 distribution (imix). Create ARP responder on router PAGENT2:
38
45
Network Services
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 trac generation:
39
46
Network Services
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
40
Concept:
47
Network Services
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.0/24
eth0 EDGE2
Trafc 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:
48
Network Services
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
42
Concept:
49
Network Services
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
43
Concept:
50
Network Services
Figure 5.4
44
Concept:
51
Network Services
5.9.5 NRFU
Table of FR PCVs CDP table OSPF table IS-IS table BGP
45
Concept:
52
Network Services
46
Concept:
53
Network Services
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 conguration 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 conguration 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 conguration les can be found on page 104. Example graphs can be found on page 48, 49 and 50.
47
Concept:
54
Network Services
Figure 5.5
Concept:
55
Network Services
Figure 5.6
Concept:
56
Network Services
Figure 5.7
Concept:
57
Network Services
51
Concept:
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 conguration les reside in /usr/pkg/etc/raddb. Example conguration les can be found on page RADIUS is started using daemontools. markus@dinghy.brest.lab# ll /service | grep radiusd lrwxr-xr-x 1 root wheel 20 Oct 1 17:41 radiusd -> /usr/pkg/etc/radiusd markus@dinghy.brest.lab# markus@dinghy.brest.lab# cat /service/radiusd/run #!/bin/sh exec /usr/pkg/sbin/radiusd /usr/pkg/sbin/radiusd -f -s -d /usr/pkg/etc/raddb -p 1812 markus@dinghy.brest.lab# Conguration commands for Cisco routers can be found on page xxx.
52
Concept:
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:
60
A Conguration Log
A.1 Basic IPv4 Conguration
Router conguration les are split into device specic and common les. Device specic les congure mainly the transport and routing aspects. Common les congure generic functions such as NTP, SNMP, and administrative access.
A.1.1
54
61
Conguration Log
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
! ! ! !
55
Concept:
62
Conguration Log
A.1.2
56
63
Conguration Log
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:
64
Conguration Log
A.1.3
58
65
Conguration Log
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
66
Conguration Log
exec-timeout 15 0 login local line vty 0 4 exec-timeout 15 0 login local transport input telnet end
60
Concept:
67
Conguration Log
A.1.4
61
68
Conguration Log
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
69
Conguration Log
! 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:
70
Conguration Log
A.1.5
64
71
Conguration Log
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
72
Conguration Log
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:
73
Conguration Log
A.1.6
67
Concept:
74
Conguration Log
A.1.7
68
75
Conguration Log
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:
76
Conguration Log
A.1.8
70
77
Conguration Log
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:
78
Conguration Log
A.1.9
72
Concept:
79
Conguration Log
73
Concept:
80
Conguration Log
/etc/rc.local root@dinghy.brest.lab# 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
81
Conguration Log
# # # # # # # # #
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 . # # Were 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/ifcong.sq0 root@dinghy.brest.lab# cat /etc/ifconfig.sq0 up 172.16.255.2 netmask 0xffffff00 /etc/syslog.conf root@dinghy.brest.lab# 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 shouldnt go to terminals or publically-readable
75
82
Conguration Log
# files. auth,authpriv.info cron.info ftp.info lpr.info mail.info #uucp.info *.emerg *.notice /etc/newsyslog.conf root@dinghy.brest.lab# 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
root@dinghy.brest.lab# 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 clocks # drift is stored here driftfile /var/db/ntp.drift
# suppress the syslog(3) message for each peer synchronization change logconfig -syncstatus
76
83
Conguration Log
# # # # #
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 root@dinghy.brest.lab# 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 root@dinghy.brest.lab# root@dinghy.brest.lab# cat /service/gated/run #!/bin/sh exec /usr/local/sbin/gated -N -f /etc/gated.conf /var/log/gated.log root@dinghy.brest.lab# root@dinghy.brest.lab# cat /etc/gated.conf ospf yes { backbone { interface sq0; }; }; root@dinghy.brest.lab#
77
Concept:
84
Conguration Log
IPv6 Conguration
A.2
IPv6 Conguration
A.2.1
78
85
Conguration Log
IPv6 Conguration
rtsol_flags="-a" rtadvd_flags="tlp0"
# # 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" root@anchor.brest.lab# /etc/rc.local root@anchor.brest.lab# 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 # # Were 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 & root@anchor.brest.lab#
79
Concept:
86
Conguration Log
IPv6 Conguration
/etc/ifcong.* root@anchor.brest.lab# cat /etc/ifconfig.lo0 inet6 fefe::a prefixlen 128 alias root@anchor.brest.lab# root@anchor.brest.lab# cat /etc/ifconfig.tlp0 up 172.16.254.2 netmask 0xffffff00 media 10baseT inet6 fefe:a::1 prefixlen 64 alias root@anchor.brest.lab# root@anchor.brest.lab# cat /etc/ifconfig.gif0 create tunnel 172.16.254.2 172.16.255.2 inet6 up root@anchor.brest.lab# root@anchor.brest.lab# cat /etc/ifconfig.gif1 create tunnel 172.16.254.2 172.16.0.11 inet6 up root@anchor.brest.lab# root@anchor.brest.lab# cat /etc/ifconfig.gif2 create tunnel 172.16.254.2 172.16.0.12 inet6 up root@anchor.brest.lab# root@anchor.brest.lab# cat /etc/ifconfig.gif3 create tunnel 172.16.254.2 10.3.1.1 inet6 up root@anchor.brest.lab# /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
87
Conguration Log
IPv6 Conguration
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
88
Conguration Log
IPv6 Conguration
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
89
Conguration Log
IPv6 Conguration
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:
90
Conguration Log
IPv6 Conguration
A.2.2
84
91
Conguration Log
IPv6 Conguration
# -> /service/bgpd ip6mode=router ip6sitelocal=YES rtadvd=YES rtadvd_flags="sq0" rtsol=NO rtsol_flags="-a" # for ip6mode=autohost only root@dinghy.brest.lab# /etc/rc.local root@dinghy.brest.lab# 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 # # Were 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 & root@dinghy.brest.lab# /etc/ifcong.* root@dinghy.brest.lab# cat /etc/ifconfig.lo0 inet6 fefe::d prefixlen 128 alias root@dinghy.brest.lab# root@dinghy.brest.lab# cat /etc/ifconfig.sq0 up
85
92
Conguration Log
IPv6 Conguration
172.16.255.2 netmask 0xffffff00 inet6 fefe:d::1 prefixlen 64 alias root@dinghy.brest.lab# root@dinghy.brest.lab# cat /etc/ifconfig.gif0 create tunnel 172.16.255.2 172.16.254.2 inet6 up root@dinghy.brest.lab# root@dinghy.brest.lab# cat /etc/ifconfig.gif1 create tunnel 172.16.255.2 172.16.0.11 inet6 up root@dinghy.brest.lab# root@dinghy.brest.lab# cat /etc/ifconfig.gif2 create tunnel 172.16.255.2 172.16.0.12 inet6 up root@dinghy.brest.lab# /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
93
Conguration Log
IPv6 Conguration
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
94
Conguration Log
IPv6 Conguration
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:
95
Conguration Log
IPv6 Conguration
A.2.3
89
96
Conguration Log
IPv6 Conguration
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:
97
Conguration Log
IPv6 Conguration
A.2.4
91
98
Conguration Log
IPv6 Conguration
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:
99
Conguration Log
IPv6 Conguration
A.2.5
93
100
Conguration Log
IPv6 Conguration
# # # # # #
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" root@core4.brest.lab# /etc/rc.local root@core4.brest.lab# 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
101
Conguration Log
IPv6 Conguration
# Daemons are started via daemontools # -> /service/ayamed # -> /service/ldpd # # Were 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 root@core4.brest.lab# /etc/ifcong.* root@core4.brest.lab# cat /etc/ifconfig.lo0 inet6 fefe::e3 prefixlen 128 alias root@core4.brest.lab# root@core4.brest.lab# cat /etc/ifconfig.rtk0 172.16.3.2 netmask 0xfffffffc media 10baseT root@core4.brest.lab# root@core4.brest.lab# cat /etc/ifconfig.rtk1 172.16.255.4 netmask 0xffffff00 media 10baseT inet6 fefe:d::2 prefixlen 64 alias root@core4.brest.lab# root@core4.brest.lab# cat /etc/ifconfig.ne2 10.3.1.1 netmask 0xffffff00 media autoselect inet6 fefe:e3::1 prefixlen 64 alias root@core4.brest.lab# root@core4.brest.lab# cat /etc/ifconfig.gif0 create tunnel 10.3.1.1 172.16.254.2 inet6 up root@core4.brest.lab# /etc/zebra.conf root@core4.brest.lab# 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
102
Conguration Log
IPv6 Conguration
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
103
Conguration Log
IPv6 Conguration
! 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 ! root@core4.brest.lab# /etc/bgpd.conf root@core4.brest.lab# 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
104
Conguration Log
IPv6 Conguration
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 ! root@core4.brest.lab#
98
Concept:
105
Conguration Log
RADIUS
A.3
RADIUS
The following les congure RADIUS on host Dinghy. /usr/pkg/etc/raddb/clients root@dinghy.brest.lab# 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 root@dinghy.brest.lab# 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. Its 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
106
Conguration 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
root@dinghy.brest.lab# 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:
107
Conguration 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
108
Conguration 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
109
Conguration 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:
110
Conguration 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
104
111
Conguration 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
112
Conguration 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:
113
Conguration 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
114
Conguration Log
Expect
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 }
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
115
Conguration 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
116
Conguration 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 }
########## ########## ########## ########## ########## ########## ########## # # 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
117
Conguration Log
Expect
"" "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
118
Conguration 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:
119
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 <rafal@attbi.com> Datum: Die, 10. Sep. 2002 20:43:00 Europe/Berlin An: Markus Boeing <markus@boeing-online.de> Betreff: Re: Q: Headless Indy, How to go into PROM monitor In message <BFD964B4-C4EA-11D6-92E6-0003939E5310@boeing-online.de>, you write: -> -> -> -> -> -> -> -> Hi Rafal, thanks for your reply. Well, the serial console works ok I think (Im using <Mac modem cable>-<null modem>-<straight Cisco console cable>). I can see messages during the boot up on the terminal. I just dont know how to get the PROM mode, pressing ESC on the serial console doesnt 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 its attempting to do the diagnostics). (All my SGIs are in storage right now, or Id give you better clues 8-)
113
120
Von: Steve Rikli <sr@genyosha.net> Datum: Die, 10. Sep. 2002 21:08:17 Europe/Berlin An: markus@boeing-online.de (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 its _supposed_ to work (in theory ;-) ) is very much like Sun hardware, if youre 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 ">>" -- thats the IRIX PROM. cheers, sr. -|| Steve Rikli || Systems Administrator || || sr@genyosha.net
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:
121
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 dont 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 <rafal@attbi.com> Datum: Mit, 11. Sep. 2002 21:56:20 Europe/Berlin An: Markus Boeing <markus@boeing-online.de> Kopie: port-sgimips@netbsd.org Betreff: Re: Q: Netbooting installation kernel fails on INDY In message <C9E46BCD-C5A1-11D6-8A0F-0003939E5310@boeing-online.de>, 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 thats not the issue here...
115
122
-> -> -> -> -> -> -> -> -> -> ->
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 Indys PROM getting confused by the returned TFTP packets and timing out the transfer. --rafal ---Rafal Boni We are all worms.
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:
123
B.2
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 veried 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.
117
Concept:
124
B.3
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 <markus@boeing-online.de> 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 Zebras 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 Ciscos 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
125
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
119
126
TIA /Markus. +--Markus A. Boeing mailto://markus@boeing-online.de 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 <jasper@ivision.co.uk> 2001-10-05 11:07:02 message RAW] zebra [zebra 10712] RE: Q: OSPF is not establishing adjacency "Frank Dauer" <fdauer@esesix.com> 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 Zebras OSPF up.
120
127
> > 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 dosnt quite understand the way multicats works on the BSDs - 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 dosnt hurt). > Theory: > - I misconfigured Zebra. -Internet Vision 60 Albert Court Prince Consort Road London SW7 2BE List: Subject: From: Date: [Download
Tel: 020 7589 4500 Fax: 020 7589 4522 vision@ivision.co.uk http://www.ivision.co.uk/
zebra [zebra 10726] Re: Q: OSPF is not establishing adjacency fredrik@packetfront.com 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
128
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 dont 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" <daniel.sobral@tcoip.com.br> 2001-10-05 19:45:21 message RAW]
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 didnt want to commit something like this close to code freeze date). -Daniel C. Sobral Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net
(8-DCS)
122
129
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:
130
B.4
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 condent that the congurations (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
131
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
132
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
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:
133
C Activity Log
C.1 How to add IPv6 to the Lab Network
We assume that the static lab is congured correctly for IPv4 already. The following steps will then implement the IPv6 architecture described above.
C.1.1
127
Concept:
134
Activity Log
# Enable IPv6 forwarding sysctl -w net.inet6.ip6.forwarding=1 Dinghy # Enable IPv6 forwarding sysctl -w net.inet6.ip6.forwarding=1
128
Concept:
135
Activity Log
Reboot the machines and check the tunnel. Anchor root@anchor.brest.lab# 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 root@anchor.brest.lab# root@anchor.brest.lab# 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 root@anchor.brest.lab# Dinghy root@dinghy.brest.lab# 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 root@dinghy.brest.lab# root@dinghy.brest.lab# 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 root@dinghy.brest.lab#
129
Concept:
136
Activity Log
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 congured on the tunnel. We are using link local addresses.
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 root@dinghy.brest.lab# Now that the next-hop interface is reachable we can start to congure BGP. Did I already say that zebra was compiled with --enable_multipath=4 on both boxes? Anchor
130
137
Activity Log
root@anchor.brest.lab# 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 ! root@anchor.brest.lab# Dinghy root@dinghy.brest.lab# 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
138
Activity Log
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 ! root@dinghy.brest.lab# Lets see if the conguration works properly. Anchor root@anchor.brest.lab# 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
139
Activity Log
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)# root@anchor.brest.lab# root@anchor.brest.lab# 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
140
Activity Log
--- 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 root@anchor.brest.lab# Looks good to me. Dinghy root@dinghy.brest.lab# 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
141
Activity Log
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)# root@dinghy.brest.lab# root@dinghy.brest.lab# 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 root@dinghy.brest.lab# Looks like we have got BGP working between Anchor and Dinghy. The next step would be adding edge router.
135
Concept:
142
Activity Log
C.1.2
Congure Tunnels
Edit the le /etc/ifconfig.gif1 to congure the tunnel interfaces permanently on Anchor and Dinghy. Use the command ifconfig gif1 to congure the tunnel interfaces on the y. Anchor root@anchor.brest.lab# cat /etc/ifconfig.gif1 create tunnel 172.16.254.2 172.16.0.11 inet6 up root@anchor.brest.lab# Dinghy root@dinghy.brest.lab# cat /etc/ifconfig.gif1 create tunnel 172.16.255.2 172.16.0.11 inet6 up root@dinghy.brest.lab# 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
143
Activity Log
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 conguration to the routers NVRAM. Check if the tunnels are working. Anchor root@anchor.brest.lab# 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 root@anchor.brest.lab# Dinghy root@dinghy.brest.lab# 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 root@dinghy.brest.lab# The DUPs indicate that a tunnel far end is responding and the tunnel is operational. Edge1
ms ms ms ms ms
137
144
Activity Log
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#
138
Concept:
145
Activity Log
Congure BGP, we add another peer group for route reector clients. Anchor root@anchor.brest.lab# 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 ! root@anchor.brest.lab# Dinghy
139
146
Activity Log
root@dinghy.brest.lab# 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 ! root@dinghy.brest.lab#
140
147
Activity Log
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
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 root@anchor.brest.lab# Dinghy root@dinghy.brest.lab# 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
148
Activity Log
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 root@dinghy.brest.lab# 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 root@anchor.brest.lab# 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
149
Activity Log
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
150
Activity Log
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)# root@anchor.brest.lab# Dinghy root@dinghy.brest.lab# 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
151
Activity Log
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
152
Activity Log
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 ?
146
153
Activity Log
root@anchor.brest.lab# 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
154
Activity Log
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
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
155
Activity Log
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
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
156
Activity Log
TblVer 21 21
Congure 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 Dont forget wr mem. Let us see if the conguration 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
157
Activity Log
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 conguration. Router Edge2 can be congured accordingly.
151
Concept:
158
Activity Log
C.1.3
On the hub routers (Anchor and Dinghy) the following steps are required: Congure the interfaces towards the edge router. 11 Congure static IPv6 routes for the loopback interface of the edge router. Congure 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:
159
Activity Log
Conguring DJBDNS
C.2
Conguring 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. markus@anchor.brest.lab> 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 youre 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 youre upgrading from previous version of djbdns.
153
160
Activity Log
Conguring DJBDNS
Homepage: http://cr.yp.to/djbdns.html markus@anchor.brest.lab> markus@anchor.brest.lab> 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 markus@anchor.brest.lab> The following section, which follows Martin Lessers dnscache-HOWTO (http://www.better-com.de/dnscache/howtode/), gives an overview of the conguration. Some stu has been stolen from the Inocial 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 congured with the IP address of the Ethernet interface. tinydns is congured with the IP address of the loopback interface (127.0.0.1). Then dnscache is congured 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. root@dinghy.brest.lab# useradd: Warning: home root@dinghy.brest.lab# useradd: Warning: home root@dinghy.brest.lab# useradd: Warning: home root@dinghy.brest.lab# /sbin/nologin root@dinghy.brest.lab# useradd -g nogroup tinydns directory /home/tinydns doesnt exist, and -m was not specified useradd -g nogroup dnscache directory /home/dnscache doesnt exist, and -m was not specified useradd -g nogroup dnslog directory /home/dnslog doesnt exist, and -m was not specified which nologin chsh tinydns
#Changing user database information for tinydns. <snip> Shell: /sbin/nologin <snip> root@dinghy.brest.lab# chsh dnscache
154
161
Activity Log
Conguring DJBDNS
#Changing user database information for dnscache. <snip> Shell: /sbin/nologin <snip> root@dinghy.brest.lab# chsh dnslog #Changing user database information for dnslog. Login: dnslog <snip> Shell: /sbin/nologin <snip> root@dinghy.brest.lab# Now we are going to congure tinydns. Firstly we create the name server, DNS zone, and reverse lookup zones for the lab network. root@dinghy.brest.lab# tinydns-conf tinydns dnslog /etc/tinydns 127.0.0.1 root@dinghy.brest.lab# root@dinghy.brest.lab# cd /etc/tinydns/root root@dinghy.brest.lab# ls Makefile add-alias6 add-host add-mx data add-alias add-childns add-host6 add-ns root@dinghy.brest.lab# root@dinghy.brest.lab# ./add-ns brest.lab 127.0.0.1 root@dinghy.brest.lab# ./add-ns 16.172.in-addr.arpa 127.0.0.1 root@dinghy.brest.lab# ./add-ns 168.192.in-addr.arpa 127.0.0.1 root@dinghy.brest.lab# ./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. root@dinghy.brest.lab# root@dinghy.brest.lab# root@dinghy.brest.lab# root@dinghy.brest.lab# root@dinghy.brest.lab# root@dinghy.brest.lab# root@dinghy.brest.lab# root@dinghy.brest.lab# Some aliases for lab boxes. root@dinghy.brest.lab# root@dinghy.brest.lab# root@dinghy.brest.lab# root@dinghy.brest.lab# ./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. root@dinghy.brest.lab# ./add-host6 dinghy.ipv6.brest.lab fefe::d root@dinghy.brest.lab# ./add-host anchor.ipv6.brest.lab fefe::a
155
Concept:
162
Activity Log
Conguring DJBDNS
In the second step we congure 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 congured the tinydns program to use the loopback address. root@dinghy.brest.lab# 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 congure 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. root@dinghy.brest.lab# touch /etc/dnscache/root/ip/172.16 root@dinghy.brest.lab# touch /etc/dnscache/root/ip/192.168 root@dinghy.brest.lab# touch /etc/dnscache/root/ip/10 Now we instruct dnscache to consult the local tinydns server to resolve names in the lab zones. root@dinghy.brest.lab# cd /etc/dnscache/root/servers/ root@dinghy.brest.lab# ls @ root@dinghy.brest.lab# echo 127.0.0.1 >brest.lab root@dinghy.brest.lab# echo 127.0.0.1 > 16.172.in-addr.arpa root@dinghy.brest.lab# echo 127.0.0.1 > 168.192.in-addr.arpa root@dinghy.brest.lab# echo 127.0.0.1 > 10.in-addr.arpa root@dinghy.brest.lab# root@dinghy.brest.lab# 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 root@dinghy.brest.lab# root@dinghy.brest.lab# cat brest.lab 127.0.0.1 root@dinghy.brest.lab# root@dinghy.brest.lab# cat 16.172.in-addr.arpa 127.0.0.1 root@dinghy.brest.lab# cat 168.192.in-addr.arpa 127.0.0.1 root@dinghy.brest.lab# cat 10.in-addr.arpa 127.0.0.1 root@dinghy.brest.lab# root@dinghy.brest.lab# 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
163
Activity Log
Conguring DJBDNS
192.36.148.17 198.41.0.10 193.0.14.129 198.32.64.12 202.12.27.33 root@dinghy.brest.lab# Lastly we create entries for dnscache and tinydns in the service directory. This puts the programs under control of the daemontools. root@dinghy.brest.lab# 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 root@dinghy.brest.lab# root@dinghy.brest.lab# ln -s /etc/tinydns /service root@dinghy.brest.lab# ln -s /etc/dnscache /service root@dinghy.brest.lab# root@dinghy.brest.lab# 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 root@dinghy.brest.lab# root@dinghy.brest.lab# 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 root@dinghy.brest.lab# root@dinghy.brest.lab# 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) root@dinghy.brest.lab# Check if the name service is running properly. root@dinghy.brest.lab# dnsipq core1 core1.brest.lab 172.16.0.1 root@dinghy.brest.lab# root@dinghy.brest.lab# dnsip core1.brest.lab 172.16.0.1 root@dinghy.brest.lab# root@dinghy.brest.lab# dnsname 172.16.0.1 core1.brest.lab root@dinghy.brest.lab# That was easy, wasnt it? The conguration on node Anchor is analogous to the example above.
157
Concept:
164
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 servers 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:
165
XMOP Xyplexs 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 Conguration 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 servers 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 units 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 units ethernet address).
159
Concept:
166
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 servers 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 doesnt, 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 servers 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 specic - 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 congure the unit to meet your needs and goals.
D.1.4
Conguration
The parameter database is where the access servers unique prole 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. congure 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:
167
The server has two memory levels, if you will, thus there are two types of commands used during conguration. Level 1 is Active Memory (or operational database) which is the current conguration 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 dierent value, that conguration 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 conguration) 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 aect of the SET command versus DEFINE command after a user logs out: Change the port prompt in the Active Memory conguration: 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 dened 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 conguration: 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 conguring 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:
168
Xyplex>> set server change enable Xyplex>> define server change enable Here is how it is helpful: When you dene 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 conguration would require two commands without a reboot. With CHANGE enabled, when you issued the dene server internet address command, the server would: Update the permanent conguration 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 dene 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 aect 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 features 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 conguration/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:
169
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 specied. The beauty of the initialize command is that it is parameter-database friendly. Provided the parameter/conguration 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.
163
Concept:
170
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 servers 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 prole conguration/parameter les. Once the server is up and running, they can be congured to operate with permanent and temporary settings using the Dene and Set commands at the servers 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 conguring 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 congured to meet many and various needs.
D.1.8
164
Concept:
171
Customers who have purchased one of NBase-Xyplexs various Service Support contract oerings 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 specic to the Access Server, point your browser to: http://www.nbase-xyplex.com/support/documentation/tp/access\_menu.cfm For Manuals and User Guides specic to the Access Server, point your browser to: http://www.nbase-xyplex.com/support/documentation/product/guides/index.cfm?doc=accessserver For Software Updates specic 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:
172
D.2
166
Concept:
173
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 Conguration 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:
174
D.2.1
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
175
(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 dierent 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
176
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
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"
170
Concept:
177
D.3
D.3.1
D.3.2
171
Concept:
178
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
172
Concept:
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:
180
Document History
174
Concept:
180