Config commands

~ ip address show

~ ip route list
default via 65.200.0.1 dev ssh
65.200.0.0/24 dev ssh scope link  src 65.200.0.1
65.200.0.0/24 dev 65-S1 scope link  src 65.200.0.3
158.65.0.0/16 dev ssh scope link  src 158.65.10.6

~ ip address add 65.200.0.1/24 dev 65-S1
~ ip address del 65.200.0.1/24 dev 65-S1
~ ip route add default/24 via 65.200.0.1 dev 65-S1 # add default gateway
~ ip route del default/24 via 65.200.0.1 dev 65-S1 # delete default gateway
~ netstat -t # current default gateway
~ route -n # old school command

Note :

Commands are identical for IPv6
IPv6 routes : ip -6 route
For IPv6, do not delete or change the link local address (the one starting with fe80).

Network Topology

Notes

  • One host is connected to each router (not shown in the figure for clarity).
  • Every router, but the ones at GENE and ZURI, has an external connection to one of your neighboring ASes.

FRRouting

Autocompletion features

When you enter the FRR CLI, you see the following line:

router#

At any time in the CLI, you can type ? to see all the possible commands you can currently type (some of the shown commands are):

router# ?
    clear       Reset functions
    configure   Configuration from vty interface
    exit        Exit current mode and down to previous mode
    no          Negate a command or set its defaults
    ping        Send echo messages
    quit        Exit current mode and down to previous mode
    show        Show running system information
    traceroute  Trace route to destination
    write       Write running configuration to memory, network, or terminal

For example, the command show will print various snapshots of the router state. To see what kind of information can be shown, just type show ?. For example, show running-config will print the running configuration.

The interfaces are not visible in the output at the beginning, but will start appearing as soon as you have configured them.

You can shorten the commands when there is no possible ambiguity. For instance show run is equivalent to show running-config. Similarly to the Linux terminal, you can also use auto-completion by pressing the tabulator key.

Testing connectivity

If you want to test your connectivity, you can use ping or traceroute from the CLI of the routers. However, whenever it is possible, always prefer to run the ping and traceroute from the hosts because they can use DNS whereas the routers cannot.

Switching to configuration mode

To configure your router, you must enter the configuration mode with configure terminal (conf t for the short version). You can verify that you are in the configuration mode by looking for the config prefix in your CLI prompt. Use exit to leave the configuration mode and to go back to the previous mode. Commands that work in configuration mode do not (necessarily) work outside configuration mode and vice versa. Notably, commands starting with show do not work in configuration mode.

Undo a command

If you want to delete parts of the configuration, you can prefix the command you want to remove with no. For example, if you add an IP address to an interface with the command

ip address 1.0.0.1/24

(explained in more detail in the next section of the tutorial), you can simply run

no ip address 1.0.0.1/24

to remove the IP address again.

Note

The interfaces are not visible in the output at the beginning, but will start appearing as soon as you have configured them.
To test connectivity you can use ping or traceroute from the CLI of the routers
To configure your router, you must enter the configuration mode with configure terminal

Interface configs

show interface <interface name>

router# conf t
router(config)# interface INTERFACENAME
router(config-if)# ip address 1.0.0.1/24

Configure static routes

router# conf t
router(config)# ip route 3.0.0.0/24 2.0.0.2
router(config)# ip route 4.0.0.0/24 someinterface
router# show ip route static
S   3.0.0.0/24 [1/0] via 2.0.0.2 inactive

Verification

show run # verify if the config has been updated correctly

router# show ip route connected
C>* 2.0.0.0/24 is directly connected, INTERFACENAME

Note

Do not configure two different IP addresses on one interface at the same time. If you have configured a wrong IP address, first remove the address with the no command and then configure a new IP address:

OSPF

OSPF routers flood IP routes over OSPF adjacencies. FRR routers continuously (and automatically) probe any OSPF-enabled interface to discover new neighbors to establish adjacencies with. By default, FRR router will activate OSPF on any interface whose prefix is covered by a network command under the router ospf part of the configuration. For instance, the following configuration would activate OSPF on any interface whose IP address falls under 1.0.0.0/24 or 2.0.0.0/24:

router# conf t
router(config)# router ospf
router(config)# network 1.0.0.0/24 area 0
router(config)# network 2.0.0.0/24 area 0

OSPF has scalability issues when there is a large number of routers. To make it more scalable, the router topology can be hierarchically divided in what is called “areas”. In this assignment, your network is small and you do not need more than one area: you will only use area 0.

To check the OSPF neighbors of a router, you can use the following command:

router# show ip ospf neighbor
    Neighbor    ID  Pri State Dead Time   Address Interface   RXmtL   RqstL   DBsmL
    1.0.0.2 1   Full/Backup     1.0.0.2 port_BASE:1.0.0.1   0   0   0
    2.0.0.2 1   Full/Backup     2.0.0.2 port_LUGA:2.0.0.1   0   0   0

The Neighbor may be a different IP than you expect since it is an ID that may come from any interface, e.g. also the ssh interface. Do not worry about this.

Here, we see that the router has established two OSPF sessions with two neighbors. The first one is connected via the interface 1.0.0.1 and its IP is 1.0.0.2. The second one is connected via the interface 2.0.0.1 and its IP is 2.0.0.2. Now that you are connected to two routers with OSPF, they can send you information about the topology of the network. Let’s take at look at the routes received by OSPF with the following command.

router# show ip route ospf
O   1.0.0.0/24 [110/10] is directly connected, port_BASE, 07:09:33
O   2.0.0.0/24 [110/10] is directly connected, port_LUGA, 06:14:24
O>* 10.104.0.0/24 [110/20] via 2.0.0.2, port_LUGA, 00:00:10

You can see that our router has learned how to reach the subnet 10.104.0.0/24. The O at the beginning of each line indicates that the router has learned this subnet from OSPF. To reach it, it must send the packets to its neighbor router 2.0.0.2. If you want to have more information about the routers of this OSPF area, you can use show ip ospf database.

With OSPF, each link between two routers has a specific weight, and only the shortest paths are used to forward packets. Below is an example of how you set the weight of a link connected to interface INTERFACENAME to 900:

router# conf t
router(config)# interface INTERFACENAME
router(config-if)# ip ospf cost 900

Use these commands to configure all the OSPF weights in your own network.

BGP

While OSPF is used to provide IP connectivity within an AS, BGP is used to advertise prefixes between different ASes. Unlike OSPF, BGP routers will not automatically establish sessions. Each session needs to be configured individually. The following commands show you how to: start a BGP process and establish two BGP sessions with neighboring routers. The integer following router bgp indicates your AS-number. Here, the local AS-number is 2:

router# conf t
router(config)# router bgp 2
router(config-router)# neighbor 150.0.0.1 remote-as 15
router(config-router)# neighbor 2.0.0.2 remote-as 2

By default, whenever the remote-as is different from the local number (here 2), the BGP session is configured as an external one (i.e., an eBGP session is established). In contrast, when the remote-as is equivalent to the local one, the BGP session is configured as an internal one (iBGP). Here, the first session is an eBGP session, established with a router in another AS 150.0.0.1, while the second one is an internal session, established with a router within your AS 2.0.0.2.

:exclamation: Important for eBGP sessions with FRR v.7.5 (used in this year’s project): When setting up an eBGP session, there is an implicit route-map which denies everything that is automatically configured on the session. Route-maps enable you to express input and output filters on the routes sent and received by a BGP session. We explain them in detail in the next section. To start advertising and receiving prefixes on an eBGP session, you need to override this implicit route-map by explicitly defining a route-map which permits all (or only some) prefixes, and apply it on the corresponding eBGP session. For instance, to advertise and receive all the prefixes, you need to define a route-map that permits everything:

router# conf t
router(config)# route-map ACCEPT_ALL permit 10
router(config-route-map)#

Then, you need to apply this route-map on the BGP session, for both the advertised and received prefixes:

router# conf t
router(config)# router bgp 2
router(config-router)# neighbor 150.0.0.1 route-map ACCEPT_ALL in
router(config-router)# neighbor 150.0.0.1 route-map ACCEPT_ALL out

Now, you should see that our two BGP sessions are up and allow advertising/receiving prefixes. You can check the state of your BGP sessions using the command show ip bgp summary:

router# show ip bgp summary
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.0.0.2        4      2       3       6        0    0    0 00:01:16        0
150.0.0.1      4     15    2009    1979        0    0    0 01:31:42        1

To advertise a prefix on a BGP session, you can just use the following command:

router# conf t
router(config)# router bgp 2
router(config-router)# network 10.104.0.0/24

As soon as you do that, your neighbor 150.0.0.1 receives this advertisement and knows that it can forward to you all the packets with a destination IP in the subnet 10.104.0.0/24. Note that when you advertise a prefix, it generally means you know how to reach this prefix, otherwise you will drop the packets, and your neighbor will not be very happy.

:warning: With some routers (and that is the case for our FRR routers) BGP will not announce a route for a prefix that it does not know how to reach. If you want to announce your /8 prefix, you must then configure a default route to Null, such as the following:

ip route 10.104.0.0/24 Null0

Perhaps one of your BGP neighbor advertises you prefixes as well, let’s check that:

router# sh ip route bgp
B>* 2.101.0.0/24 [20/0] via 2.0.0.2, interface_used, 00:03:17

In this case, we can see that neighbor 2.0.0.2 has advertised one prefix: 2.101.0.0/24. The B at the beginning of the line indicates that the router has learned this prefix from BGP.

BGP update-source for iBGP sessions

By default, when a router establishes an iBGP session with a peer, it uses the IP address of the interface closest to the iBGP peer as source address. This is fine as long as this interface is up. If this interface goes down but the actual router is still running, the iBGP connection will tear down even though the router may be reachable over a different path/interface. In practice, operators therefore often use so called “loopback” interfaces as source of the iBGP connections. Loopback interfaces are virtual interfaces with an IP address which uniquely identifies the router in your network. For example, if you are group 7 and you want to configure an iBGP session from MUNI to MILA, you could use the following commands (on MUNI):

router# conf t
router(config)# router bgp 7
router(config-router)# neighbor 7.158.0.1 remote-as 7
router(config-router)# neighbor 7.158.0.1 update-source lo

7.158.0.1 is the loopback interface IP of MILA. With update-source lo you make sure that the MUNI router is using its loopback interface address as source address.

BGP next-hop-self

The figure below illustrates a possible pitfall when eBGP announcements are distributed over iBGP sessions. If router R1 is advertising its prefix 11.22.33.0/24 towards R2 (over the eBGP session), the next-hop of the advertisement is the IP of the outgoing interface of R1 (10.0.0.2). Router R2 is then distributing this advertisement to all its iBGP neighbors (R3). Per default, the next-hop of the advertisement is not changed and is still 10.0.0.2. That can lead to problems for router R3. In a normal network configuration, the subnets used between two eBGP routers (10.0.0.0/30) are not distributed in the connected ASes, e.g. via OSPF. Router R3 does therefore not know how it can reach the next-hop of the advertised prefix (11.22.33.0/24) and will discard the advertisement. To solve this problem, we can use the BGP next-hop-self command. When properly configured, router R2 is using its own interface IP as next-hop every time it distributes announcements from eBGP sessions to its iBGP neighbors. In this example, R2 would replace the next-hop 10.0.0.2 with its interface IP connected to R3 (20.0.0.1). Router R3 then receives an advertisement for prefix 11.22.33.0/24 with next-hop 20.0.0.1. The 20.0.0.0/30 subnet is distributed via OSPF and R3 does therefore know how to reach the next-hop of the advertisement and can install this prefix in its forwarding table.

To add the next-hop-self command on FRR routers, you can use the following commands (on router R2):

router# conf t
router(config)# router bgp 100
router(config-router)# neighbor 20.0.0.2 remote-as 100
router(config-router)# neighbor 20.0.0.2 next-hop-self