Ubuntu: Interface IP Addressing

Interface addressing includes how to change the ip address of an interface, the default gateway and also the DNS address. You can do temporary or permanent changes. To temporarily change the ip address of an interface, use the following command

sudo ifconfig eth0 A.B.C.D netmask X.X.X.X

A.B.C.D: the new ip address
X.X.X.X: the netmask of the ip address

The example above will change the ip address and the netmask of the eth0 interface. Change eth0 from the command above to other interface based on your need. Verify the changes by using the command "sudo ifconfig eth0" If you change the ip address of an interface, chances are that you also want to configure the default gateway. To do that, use the command

sudo route add default default gw X.X.X.X eth0

X.X.X.X: the ip address of the default gateway

Verify that configuration by using the command "route". The output should display a route to your default gateway.

Next, to make a permanent changes there is a file that has to be edited. The network configuration is kept in "/etc/network/interfaces", open the file and you will see what is inside the file that would look something like this.

There are two interfaces in the example above, l0 and eth0. Now, from the example above, eth0 has been configured to use dhcp. If you want to edit an interface to use dhcp configuration, follow the configuration

auto eth0
iface eth0 inet dhcp

That are the what should be entried in the "etc/network/interfaces" file. After that, you can use the command "sudo ifup eth0" to refresh and initiate the DHCP process. But, if we want to configure the ip address and default gateway statically, edit at the appropriate interface part and add these lines

auto eth0
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1

Change the ip addressing to suit your requirement.

Configuring BGP

BGP configuration is quite different from other routing protocols configuration. There are two kinds of BGP, which are IBGP and EBGP. EBGP is when BGP is configured between routers in a different Autonomous System (AS), IBGP is when BGP is configure between routers within the same AS. EBGP behaves differently from IBGP. We will see what other differences are as we configure BGP in the following topology.

In BGP we have to specify each of our neighbor manually and the network command work differently as with other routing protocol. We will start by configuring every interface and start BGP in each router.

R1

interface FastEthernet1/0
ip address 102.102.0.1 255.255.0.0
no shutdown
interface Serial2/0
ip address 14.10.14.1 255.255.255.252
no shutdown
interface loopback0
ip address 1.1.1.1 255.255.255.255
router bgp 3500

R2

interface FastEthernet1/0
ip address 102.102.0.2 255.255.0.0
no shutdown
interface FastEthernet1/1
ip address 203.203.0.1 255.255.0.0
no shutdown

R3

interface FastEthernet1/0
ip address 203.203.0.2 255.255.0.0
no shutdown
interface Serial2/0
ip address 35.10.35.1 255.255.255.252
no shutdown
interface loopback0
ip address 3.3.3.3 255.255.255.255
router bgp 3500

R4

interface loopback0
ip address 12.10.0.1 255.255.0.0
no shutdown
interface Serial1/0
ip address 14.10.14.2 255.255.255.252
no shutdown
router bgp 2500

R5

interface Serial1/0
ip address 35.10.35.2 255.255.255.252
no shutdown
router bgp 4500

At this point, you can run the "show processes" or only "show processes | include BGP" (the BGP should be in upper case) command to see that BGP processes is running. You can also use the "show processes cpu | include BGP" to see the cpu usage instead of the memory usage.

Now, all interfaces have been configured and BGP processes are running. We can now make them BGP neighbor. There could be two type of BGP neighbor, IBGP or EBGP neighbor. EBGP neighbor is a neighbor of which AS number is different from the AS number of the configured router. First we will configure EBGP peers between R1-R4 and R3-R5. Neighbor in BGP should be configured manually, here is the configuration (enter the configuration at each BGP )

R1

router bgp 3500
neighbor 14.10.14.2 remote-as 2500

R4

router bgp 2500
neighbor 14.10.14.1 remote-as 3500

R3

router bgp 3500
neighbor 35.10.35.2 remote-as 4500

R5

router bgp 4500
neighbor 35.10.35.1 remote-as 3500

At this point, you can verify the BGP neighbor status with "show ip bgp neighbors" or "show bgp summary ". Here's the example of running "show bgp summary " in R1

Now, we will configure IBGP peer between R1-R3. Notice, that I create a loopback interface on R1 and R3, so instead of using a physical interface to make a peer between R1-R3, we will use that loopback interfaces. But, we won't be able to do that before telling each other how to get to peer loopback interface. We can do this by using a static route or a routing protocol. In this case, we will use OSPF. So, let's configure OSPF

R1

router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 102.102.0.0 0.0.255.255 area 0

R2

router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 102.102.0.0 0.0.255.255 area 0
network 203.203.0.0 0.0.255.255 area 0

R3

router ospf 1
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.3 0.0.0.0 area 0
network 203.203.0.0 0.0.255.255 area 0

R1 and R3 should now have known the route to reach each other's loopback interface. We can verify this issuing the "show ip route" command

Now, we can configure IBGP peer for R1-R3, the configuration is quite the same as EBGP neighbor configuration

R1

router bgp 3500
neighbor 3.3.3.3 remote-as 3500
neighbor 3.3.3.3 update-source loopback 0

R3

router bgp 3500
neighbor 1.1.1.1 remote-as 3500
neighbor 1.1.1.1 update-source loopback 0

If we are using loopback interfaces for BGP neighbor, remember the "update-source" and "ebgp-multihop" command. Because loopback interface is not a directly connected interface, we need the "ebgp-multihop" command to make the EBGP neighbor works. For IBGP peer, the "update-source" command is used instead.

Now, the BGP routers have become neighbors but no network is exchanged between them. We will try to advertise a network that is directly connected to R1 to R3 via BGP. For this purpose, we create another loopback interface on R1, and

R1

interface loopback 1
ip address 110.11.11.1 255.255.255.0

Then we use the BGP network command to advertise this network. In BGP, the network command should match exactly the network address and the subnet mask that is to be advertised.

R1

router bgp 3500
network 110.11.11.0 mask 255.255.255.0

At this point, the network won't be advertised not only to R3 but also to R4. You can verify this network being learned by both routers by issuing the command "show bgp".

To avoid advertising this network to R4, we can use a route-map. Here's the configuration on R1

R1

access-list 1 deny 110.11.11.0 0.0.0.255
access-list 1 permit any
route-map filter_r4 permit 10
match ip address 1
router bgp 3500
neighbor 14.10.14.2 route-map filter_r4 out

The idea is to first create an access-list that will deny the route that we do not want to advertise, that is the 110.11.11.0/24 network. Then we will create a route-map that match the access-list, which will deny the unwanted routes. Finally, we apply the route-map to the R4's BGP neighbor command. The out parameter means we want filter outgoing networks to R4. If there's no changes after applying those commands, try to clear bgp process on R1 and R4 by the command "clear ip bgp *".

Next, We will try to advertise network 12.10.0.0/16 from AS 2500 to AS 4500. To achieve this, we must concern the BGP synchronization rule. First, we enter the network command on R4.

R4

network 12.10.0.0 mask 255.255.0.0

At this point, the network should have been advertised to R1 and R3. But in R3, the route won't be installed to the routing table. And also the network won't be advertised to R5 because of the synchronization rule. First we will make the route installed on R3. If we issue the command "show bgp" on R3, there's no best mark for network 12.10.0.0/16.

This is because the next hop address is still pointing to the address of R4's Serial1/0 interface. In BGP, for a route to be chosen as the best route, the receiving router should know how to reach the address of the next hop. And by nature, a route learned via EBGP, won't have the next hop address changed as it is being advertised to another IBGP. To solve this, we add the "" command on R1

R1

router bgp 3500
neighbor 3.3.3.3 next-hop-self

Now, the route should have been chosen as the best route on R3. Next, we will make the 12.10.0.0/24 network to be advertised to R5. To achieve this, we can either turn off synchronization rule or redistribute the 12.10.0.0/24 to a running IGP, that is OSPF. We will try to redistribute the network to OSPF, so that the BGP network comply the synchronization rule.

R1

router ospf 1
redistribute bgp 3500 subnets

Now, if we issue the command "show ip route" on R5, we will see that there's a route to network 12.10.0.0/24 and is learned via BGP.

We also see the 110.11.11.0/24 network advertised to R5, because no route-map is applied to filter this route. Now, the BGP is working and routes have been advertised each other.

Border Gateway Protocol Concepts

Border Gateway Protocol (BGP) is quite different from other routing protocol. BGP is the Internet routing protocol and it is a slow routing protocol which is good for an Internet routing protocol. There are two kinds of BGP, which are Interior BGP and Exterior BGP. IBGP is when BGP is configured between routers within same Autonomous System (AS), while EBGP is when BGP is configured between routers in a different AS. EBGP behaves differently with IBGP. As we know that other Interior Gateway Routing Protocol such as RIP, OSPF or EIGRP will update the next hop address when advertising routes to its neighbor. IBGP doesn't do this.

Neighbor in BGP should be configured manually. Another different concept in BGP is that neighbor in BGP shouldn't always be direct connected. In this topology bellow, R1 and R3 could be a neighbor without having a direct connection to each other.

Instead of having a metric to determine the best path to a network, BGP uses a list of attribute. These attributes have an order of precedence, each attribute of the feasible routes will be evaluated in order and the best path will be chosen when there is an attribute that is better than the others.

There are also two rules in IBGP, which are the synchronization rule and the split-horizon rule.

Synchronization Rule

The synchronization rule says that BGP won't advertised a route to other EBGP peers, if the route has not been learned by an IGP. Consider the following scenario

R4 advertises the network 12.10.0.0/16 to R1, which will then advertise the network to R3, since they are an IBGP peer. But R3 won't advertise the network to R5 if the IGP running in its AS has not learned the 12.10.0.0/16 network. This rule is used to avoid the "blackhole" problem. If R3 ever advertises the network to R5, then R5 will send packets destined to 12.10.0.0/16 network to R3. Then R3 will send the packets to R2, but R2 does not know about that network since it is not running BGP. The packets will be dropped by R2. However, this synchronization rule can be turned off. You can safely turn this off if

• You are not plannig to be a transit AS, that is having traffic from one AS to another AS over your AS.


• All of your router is running BGP.

Split Horizon Rule

The split-horizon rule says that routes learned via IBPG won't be sent ot other IBGP peers. This rule is used to prevent loop in an AS. Consider the following scenario

R1 receives the network 12.10.0.0/16 from R4, which then will advertise the network to R2 and R3. What if then R2 sends the network to R3 and vice-versa. In IGP such as EIGRP and OSPF, the routers could determine the best path to the network, but BGP couldn't. This is because BGP doesn't use the metric like bandwidth or delay to determine the best path, instead it uses some attributes which will not change over IBGP routers in the same AS. So, if R2 and R3 ever send the 12.10.0.0/16 network to each other, they will end up having two routes with the same attribute, and therefore could potentially create a loop in the network. In Cisco routers, you could turn off this rule if you're sure that no potential loop will be created.

Configuring Multicast: Sparse-Dense Mode

There are two modes that we can use in multicast routing. They are sparse mode and dense mode. The dense mode uses the source trees multicast routing technique which is more to broadcast and prune multicast traffic. The sparse mode uses the sharde trees technique, which uses a rendezvous-point to get multicast traffic. But there's another mode which is the sparse-dense mode which quite uses the combination of both modes. We will try to configure multicast routing in sparse-dense mode but we won't get into the detail of the theory of each mode.

Let's say we have this topology.

First of all, we have to turn on multicast routing on all routers. Enter the following command in global configuration level

ip multicast-routing

Then we have to which interfaces will participate in the multicast routing. Go to the interface configuration level and enter the following command (enter the command on all interfaces listed in the above topology):

ip pim sparse-dense-mode

To verify that every interface has been multicast-enabled, enter the following command:

show ip pim interface

At the output of the command, you can see which interfaces are participating and in which mode.

At this point, you should already have multicast connectivity among your routers. But, your routers will be connected in dense mode. We still have to configure the sparse mode. To verify multicast connectivity, we will simulate a multicast server on R1, go to loopback0 interface of R1 and enter the following command:

ip igmp join-group A.B.C.D

A.B.C.D: ip address of the multicast network. You can use one the private multicast address range, which is 239.0.0.0 - 239.127.255.255

Then in any other router, try to ping the multicast address. Here, I use 239.1.1.1 as the multicast address that I joined in. If the router could reach the multicast address, you will see something like "Reply to request 0 from 192.168.2.1, 168 ms", but if the ping failed, you will see a ".".

Next, as in sparse mode, we have to specify at least a rendezvous-point. There are two ways to specify the rendezvous-point, static or auto rendezvous-point. If you configure your rendezvous-point statically, you have to configure it in every router in your network where you want multicast to be supported, that could be tedious if you have many routers. Another way is by using the auto-rp (auto rendezvous-point). This way, you go to the rp router and tells it that it has to announce itself as a rendezvous-point, so that the rest multicast-enabled routers will know it. To configure rp statically, we use the following command:

ip pim rp-address A.B.C.D

A.B.C.D: the ip address of the rp router.

There are some other options to this command. Try putting the question mark and hit enter will list other options such as applying access list so that a specific rp only serves for a group of mutlicast address only.

But, we will use the auto-rp technique. Here, we will configure the rp router to announce itself as a rp for the network. Go to the rp router and in the global configuration level, type in the following command:

ip pim send-rp-announce INTERFACE-TYPE INTERFACE-NUMBER scope NUMBER

INTERFACE-TYPE INTERFACE-NUMBER: the type and number of the interface of which address will be used as the rp address. ex, serial0/1, lo1.

NUMBER: the number of hops the announcement should traverse the network.

It is a good idea to use loopback interface as the address of the rp since a physical interface could be down and it mark the rp as unreachable. So, use a loopback interface and advertise that loopback address by using your routing protocol, so the rest router in the network know how to reach it and do not forget to enable ip pim in the loopback interface. In this example, we will make R3 as the rp. Go to R3 and enter the following command "ip pim send-rp-announce loopback 0 scope 15".

Then configure the mapping agent for your rp router. The mapping agent concept is similar to DR in OSPF. So, your rp will send the announcement to the mapping agent, and then it is the task of the mapping agent to send the mapping to the rest multicast-enabled router in the network. Configure a mapping agent by entering the following command:

ip pim send-rp-discovery scope NUMBER

NUMBER: the number of hops the announcement should traverse the network.

In this example, I make R3 as the mapping agent, so I configure R3 as the mapping agent by entering the command "ip pim send-rp-discovery scope 15" at the global configuration level. Next, we will have to configure other multicast-enabled router to accept auto-rp announcement. To configure this, go to R1, R2 and R4, at the global configuration level enter the following command:

ip pim accept-rp auto-rp

Then, you can also see the multicast routing table created in your router by using the command "show ip mroute". The output of the command would look something similar like this

The next thing to configure is to make your switch support multicasting. This is only one command, but without this command your switches will treat multicast frames just like a broadcast frame. Type in the following command in global configuration level of your switches:

ip igmp snooping

Another optimization that could be done is that if you want to limit your multicast packets from entering a part of your network. Let's say that you don't want to let multicast packet to go off your specific interface of your router. Enter the following command in your interface configuration level:

ip multicast ttl-threshold NUMBER

NUMBER: the number you want to reduce the multicast packet TTL.

Every multicast packet has an TTL. With this command, you can reduce the TTL of multicast packets so it will not go any further beyond the interface where multicast packet is received. To be sure that you reduce the TTL to 0 (or even bellow it), just give the NUMBER parameter a big value such as 255.