## Introduction

The purpose of this lab is to investigate the differences and best practices for transit and peering configuration when an AS is connected both to a transit provider, a private peer, and an Internet Exchange Point.

## Lab Topology

The initial lab topology sets up 8 autonomous systems (AS), each with four routers. In each AS, one router is the border router (for connecting to transit providers), one router is the core router (representing the rest of the network operator’s core network), one router is a peering router (for connecting to private peers and IXPs), and one router is the access router (for connecting to customer end-sites). There is also one customer router provided too.

The lab will start simply by configuring each autonomous system, and making sure that transit works via their transit provider. The address plan for the entire network is described in the Address Plan document. The initial set up is shown below.

## Logistics

Each participant will be assigned to a group. Depending on the number of participants, either a single person or a group will be responsible for the configuration of a router. You may be asked to rotate and work on a different router so that you have the opportunity to understand the network from another point of view.

As you go through the exercises, you will see examples of configurations for one or more routers. Make sure to take those examples and adapt them to your own router, network topology and addressing scheme. Use the diagrams to guide you.

Refer to the Lab Access Instructions document for information about logging into the routers that have been assigned to you.

### Address Space Allocation

Refer to the IP Address Plan document for information about the IP address plan for the network infrastructure for these labs.

## Basic Router Configuration

The following configuration examples show the suggested/recommended configuration to be implemented on the routers in each group. Replace the RX in the examples with the router type (either B for Border or C for Core or P for Peering or A for Access or Cust for Customer router) and Group number as appropriate.

### Name the router

    Router> enable
    Router# config terminal
    Router(config)# hostname RX

### Configure Users & Passwords

We will use the username `isplab` for this workshop. It is a role account, note, something that is strongly discouraged on public infrastructure. However, we use it here only for ease of operating the lab, and that we will need to connect to other groups’ routers through the duration of this workshop.

Please do not change the username or password to anything else, or leave the password unconfigured (access to vty ports is not possible if no password is set). It is essential for a smooth operating lab that all participants have access to all routers.

Recent Cisco IOS (and IOS-XE) software is starting to deprecate the type 5 encryption which has been Cisco’s standard since the mid 1990s. Cisco has introduced a new type 9 encryption (using the `scrypt` hashing algorithm1), and we will use that on our switches as they support this. Newer software platforms use type 9 by default.

    username isplab algorithm-type scrypt secret lab-PW
    !
    enable algorithm-type scrypt secret lab-EN
    !
    service password-encryption

The service password-encryption directive tells the router to encrypt all passwords stored in the router’s configuration (apart from enable secret2 which is already encrypted).

### Configure Authentication

The default authentication model used in Cisco’s IOS is from the late 80s and is really very obsolete. We will instead use Cisco’s implementation of AAA, first introduced in around 1995. The code snippet below uses the locally configured username/password pair for standard login, with the locally configured enable secret to go into configuration mode.

    aaa new-model
    aaa authentication login default local
    aaa authentication enable default enable

### Configure console, auxiliary port and VTY access

Stop the router from guessing transports if it does not recognise what was entered in on the command line. This is done for both the VTY (remote access to router) and the Console (what is being used during this lab).

    line vty 0 4
     transport preferred none
    line console 0
     transport preferred none
    line aux 0
     transport preferred none

We will need to change the escape sequence for the console and vtys from the default value of `CTRL ^` because that sequence isn’t transmitted by the web interface we use to access the router consoles. Instead we will use `CTRL C` which is ASCII 3.

    line con 0
     escape-character 3
    line vty 0 4
     escape-character 3
    !

### Configure logging

No logs are sent to the console. Instead they are sent to a log buffer. To access the logs in the log buffer, use the command `show logging`.

    no logging console
    logging buffered 8192 debugging

And we also want to set up improved time-stamping for the log messages as well:

    service timestamps debug datetime msec localtime show-timezone year
    service timestamps log datetime msec localtime show-timezone year

### Disable DNS resolution

There is no DNS resolver at this stage of the lab set up, so we stop the router from trying to do domain name resolution for any encountered addresses.

    no ip domain-lookup

### Set the domain name

Even though there is currently no connectivity to access a DNS resolver, we will still configure the lab’s domain name.

    ip domain name ws.nsrc.org

### Activate IPv6 routing

Turn on IPv6 Routing and activate IPv6 CEF (not on by default in Cisco IOS)

    ipv6 unicast-routing
    ipv6 cef

### Disable source routing for IPv4 and IPv6

    no ip source-route
    no ipv6 source-route

### Path MTU Discovery

Enable Path MTU Discovery on the router - this is not enabled by default for connections to the control plane (but it is enabled by default now for BGP).

    ip tcp path-mtu-discovery

### Login Banners

It is good practice to set informative login banners on all network equipment. We will replace the default banners that come with our environment with one suitable for this lab:

    banner login ^
                 BGP Peering/IXP Workshop
              Network Startup Resource Center
    ^

### Setting up SecureShell

The use of `telnet` is considered obsolete given that everything is set in the clear when communicating with other devices. This includes passwords and other confidential information.

Cisco devices have `telnet` enabled by default. We are going to disable `telnet` and configure the campus devices to use `ssh` instead. We already created the domain name earlier, so we can now generate the SSH key pairs for the device:

    crypto key generate ec keysize 384

This generates an Elliptic Curve key - key sizes available are 256 and 384 bits. (EC keys are much shorter than RSA keys for equivalent strength)

Next we set the SSH version to be version 2:

    ip ssh version 2

Finally we enable SSH access to our device (disabling `telnet` at the same time) by:

    line vty 0 4
     transport input ssh
    !

Note that Cisco devices by default have all incoming transports activated; if you try:

    Switch(config)#line vty 0 4
    Switch(config-line)#transport input ?
      all     All protocols
      none    No protocols
      pad     X.3 PAD
      rlogin  Unix rlogin protocol
      ssh     TCP/IP SSH protocol
      telnet  TCP/IP Telnet protocol

the device will display the options available. By specifying only `ssh`, we disable all other incoming transports.

SSHv2 is now configured on the device, and ready to use in future labs.

### Save!

Exit configuration mode and save - Cisco IOS does not automatically save configurations to NVRAM:

    end
    write memory

## Interface Configuration

### Links to other Devices

Configure your interfaces according to the diagram and the supplied address plan. The examples below show just the Core and Border routers in your AS. You will need to set up configurations for:

- the link from Core router to Border router

- the link from Core router to Peering router

- the link from Core router to Access router

- the link from Access router to Customer router

- the link from the Core router to the Server appliance (SRV)

Note that we follow the convention of addressing the Core router with the low address of the point-to-point link, and the other router with the high address.

On CoreX:

    interface GigabitEthernet0/1
     description P2P Ethernet Link to BX
     ip address 100.68.X.16 255.255.255.254
     no ip directed-broadcast
     no ip redirects
     no ip proxy-arp
     ipv6 address 2001:DB8:X:10::0/127
     ipv6 nd prefix default no-advertise
     ipv6 nd ra suppress all
     no shutdown
    !

On BorderX:

    interface GigabitEthernet0/1
     description P2P Ethernet Link to CX
     ip address 100.68.X.17 255.255.255.254
     no ip redirects
     no ip proxy-arp
     ipv6 address 2001:DB8:X:10::1/127
     ipv6 nd prefix default no-advertise
     ipv6 nd ra suppress all
     no shutdown
    !

### Explanations for some of the commands used

#### no ip proxy-arp

Proxy ARP is the technique in which one host, usually a router, answers ARP requests intended for another machine. By “faking” its identity, the router accepts responsibility for routing packets to the “real” destination. Proxy ARP can help machines on a subnet reach remote subnets without the need to configure routing or a default gateway.

Disadvantages of proxy arp:

- It increases the impact of ARP spoofing, in which a machine claims to be another in order to intercept packets.

- It hides network misconfigurations in hosts

- Hosts will have larger ARP tables

#### no ip redirects

ICMP redirects can be sent to a host when the router knows that another router in the same subnet has a better path to a destination. If a hacker installs a router in the network that causes the legitimate router to learn these ilegitimate paths, the hacker’s router will end up diverting legitimate traffic thanks to ICMP redirects. Thus, we recommend that you disable this feature in all your interfaces.

#### ipv6 nd ra suppress all

IPv6 router advertisements are sent periodically by routers to inform hosts that the router is present, and to allow hosts to autoconfigure themselves using stateless autoconfiguration mechanisms. This is not necessary on point-to-point interfaces.

#### ipv6 nd prefix default no-advertise

This prevents the router from sending any prefixes as part of router advertisements, so the client will not auto-configure itself with a global IPv6 address. This is helpful for IOS versions where you cannot suppress solicited RA messages.

### Loopback interface

Also create the Loopback interface and apply the IPv4 and IPv6 addresses to it - consult the address plan for the addresses used. Here is an example for the Core router in the autonomous system. Remember that the IPv4 address on the Loopback is a /32 and the IPv6 address on the Loopback is /128.

    interface Loopback0
     description Loopback on Core
     ip address 100.68.X.2 255.255.255.255
     ipv6 address 2001:DB8:X::2/128
    !

For the Customer router, we will use the loopback as the anchor point for testing purposes in future labs. Here is how the Loopback might be configured on it:

    interface Loopback0
     description Address anchor for Customer X
     ip address 100.68.X.64 255.255.255.255
     ipv6 address 2001:DB8:X:4000::/128
    !

### Null interface

We also need to modify the configuration of the Null interface to improve our infrastructure security. We will be using the Null interface throughout this lab. Industry best practice today is to route address blocks in use by any autonomous system to the Null interface, so that looping traffic (packet ping-pong) for unreachable destinations within the address block is avoided. So that the Null doesn’t become a target for denial of service attacks, we need to add configuration so that the Null interface does not send any ICMP unreachable messages. Like this:

    interface Null0
     no ip unreachables
     no ipv6 unreachables
    !

This configuration should be added to all five routers being configured in your group.

## Save Configuration

Verify and save the configuration.

    show running-config
    write memory

## Connectivity Testing

Do some PING tests on all four links in your group - here is an example for between Core and Border in Group One:

    C1# ping 100.68.1.17         <- B1
    C1# ping 2001:DB8:1:10::1    <- B1
    C1# ping 100.68.1.19         <- P1
    C1# ping 2001:DB8:1:11::1    <- P1

and then verify the output of the following commands:

    show arp             : Show ARP cache
    show interface       : Show interface state and config
    show ip interface    : Show interface IP state and config
    show ipv6 neighbors  : Show IPv6 neighbours
    show ipv6 interface  : Show interface state and config
    show cdp neighbors   : Show neighbours seen via CDP

1. IOS also supports the PBKDF2 hashing algorithm, better known as SHA256. This would appear in the saved configuration as “type 8” encryption.↩︎

2. For IOS releases prior to 12.3, the username/secret pair was not available, and operators would have had to configure username/password instead. Do NOT use the username/password combination, nor the `enable password` directive - these use type-7 encryption which is not secure at all, whereas the `secret` uses more secure encryption algorithms.↩︎