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.

OSPF: Authentication over a Virtual Link

In OSPF, we can have an area that is not directly connected to the backbone area by using the virtual link feature. If somehow, OSPF authentication is enabled in area 0. Routers that is connected through a virtual link must have the authentication configured too. This is because the router believe that it is directly connected to the area 0, and since routers in area 0 authenticate themselves for communicating, the virtual-linked router would no longer able to communicate with the routers in area 0.

The command to configure authentication on a virtual-link is:

area NUMBER virtual-link A.B.C.D message-digest-key NUMBER2 md5 WORD

NUMBER: the area number where both virtual-linked routers reside.

A.B.C.D: the router-id of the peer router.
NUMBER2: the id number of the digest key.
WORD: the authentication password used.

So, let's say that we have this topology

We have an md5 authentication configured in area 0 with password of "cisco". To configure this authentication for area 0, go to all router in area 0, which in this case are R1 and R2 and type the following command (assume that you are from the global configuration level and the OSPF process id is 1):

router ospf 1
area 0 authentication message-digest
interface fastethernet1/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 cisco

Now, since authentication is in place for area 0, in order for area 2 to have connectivity with the rest of OSPF network, the authentication should be configured on the virtual-linked routers too, which in this case are R2 and R3. We first go to R2 and go to its OSPF process 1 configuration level and enter the following command

area 1 virtual-link 3.3.3.3 message-digest-key 1 md5 cisco

Next we go to R3, go to the OSPF process 1 configuration level and enter the command:

area 1 virtual-link 2.2.2.2 message-digest-key 1 md5 cisco
area 0 authentication message-digest

We need to configure the command "area 0 authentication message-digest" on R3 to avoid authentication type mismatch error (Type 0 - Null authentication on R3, and Type 2 - Message Digest authentication on R2). This is because a virtual-link is a tunnel that makes as if R3 is directly connected to area 0, and since area 0 is configured with message-digest authentication, therefore R3 should be configured to use message-digest authentication too on area 0.

PPP Multilink Connection

PPP Multilink connection adds load-balancing and to your PPP connection. PPP multilink sends packet in fragments spread

To configure PPP Multilink connection is first go to your serial interfaces that will participate in your PPP link perform no-shutdown and change the encapsulation to PPP.

no shutdown
encapsulation ppp

Then configure the logical multilink interface. You create the multilink interface, give it an IP address, and specify the encapsulation for it. On global configuration level, type this command

interface multilink NUMBER

NUMBER: this could be any unique number you want to identifiy the multilink interface.

ip addresss A.B.C.D NETMASK

A.B.C.D: IPv4 address for this interface

NETMASK: the subnet mask for the IPv4 address.

encapsulation ppp

Next, you want to configure something that can link your logical multilink interface to your physical serial PPP interfaces. This something is done with the multilink-group command. Type the following command at your multilink and physical serial interface configuration level.

ppp multilink-group NUMBER

NUMBER: the number of the multilink group.

The number configured should be the same at the multilink interface and the physical serial interfaces.

By this time, you should be able to ping your PPP peer. You can verify your multilink interface with the command "show ip interface brief" and "show ppp multilink". Here is the output of the show ppp multilink command:

OSPF: Configuring NBMA Network Type

There are 5 network tpyes in OSPF. They are: NBMA (Non-Broadcast MultiAccess), Point-to-Multipoint which are RFC standard and Broadcast, Point-to-Point, Point-to-Multipoint (static) which are Cisco proprietary. The default network type for interfaces in OSPF for multipoint network or when you are configuring Frame-Relay on physical interfaces is NBMA.

The characteristics of NBMA network type are there will be DR/BDR elections, what has to be noted here is that DR and BDR should have direct connectivity with the rest OSPF router in the network. In NBMA network there will be no broadcast, so that we have to define our OSPF neighbor statically. We only have to specify the neighbors statically at one router (one-way), and the peer router will respond and the neighborship will be formed. Usually, the static neighbor configuration is done at the hub-router.

We will try to configure OSPF in NBMA network type based on this topology

First, configure the serial1/0 interface, give an ip address, set the encapsulation to frame-relay and perform no shutdown

ip address 10.10.10.1 255.255.255.0
encapsulation frame-relay
no shutdown
ip ospf priority 255

Remember that in an NBMA network, there is a DR/BDR election. DR/BDR routers should have direct connectivity with the rest of the routers in the segment. So here, we want to make sure that R1 becomes the DR router. Therefore we set the OSPF priority of the interface to 255. You can go to R2 and R3 and configure the same configuration at the serial1/0 interface

R2:

ip address 10.10.10.2 255.255.255.0
encapsulation frame-relay
no shutdown
ip ospf priority 0

R3:

ip address 10.10.10.3 255.255.255.0
encapsulation frame-relay
no shutdown
ip ospf priority 0

R2 and R3 have no direct connectivity, therefore both of them couldn't be the BDR. We specify the OSPF interface priority of R2 and R3 serial1/0 to 0, making them inelligible for DR/BDR election.

I also configure a loopback0 interface on R1 for OSPF connectivity purpose, so if later after OSPF has been configured, we can see at least a route learned from OSPF on R2 and R3 in its routing table. On R1:

interface loopback0
ip address 10.10.10.3 255.255.255.0

Then we can start configuring OSPF. We will use OSPF with process id of 1.

R1:

router ospf 1
router-id 1.1.1.1
network 10.10.10.1 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0

R2:

router ospf 1
router-id 2.2.2.2
network 10.10.10.2 0.0.0.0 area 0

R3:

router ospf 1
router-id 3.3.3.3
network 10.10.10.3 0.0.0.0 area 0

You can do the "show ip ospf interface" command to see the network type of serial1/0 interface. Here's the partial output of the command.

It should list the network type as NON_BROADCAST. If not, you can change the OSPF network type with the command "ip ospf network non-broadcast" at the interface configuration command level. At this point, you will not have any OSPF neighbor, since in non-broadcast network, neighbors should be specified manually. Remember that we only have to type the neighbor command one-way, only on one router and it is a good idea to configure it at the hub-router, which is R1. So, we go to R1 and type in the following command at the global configuration level:

router ospf 1
neighbor 10.10.10.2
neighbor 10.10.10.3

After entering the command, you can type the "show ip ospf neighbor" command to see that R1 is ATTEMPT-ing to become neighbor with R2 and R3. You might want to wait before the neighbor status becomes FULL. When it comes to FULL, we can verify that the network of R1 loopback0 interface is advertised to R2 and R3 and is listed in their routing table. From the picture bellow, for you who might be wondering why does 192.168.1.1 as advertised as a host route with /32 subnet mask when you expect it to be /24. This is because loopback interfaces are advertised with /24 subnet. To get a /24 network in the routing table, the OSPF network type of the loopback interface could be change to point-point with the command "ip ospf network point-to-point".

But, there is still a problem. If you try to ping R3 from R2 and vice-versa, the ping will fail. This is because both R2 and R3 think that they have direct connectivity because both of the reside in the same network. But actually, they have to send the packets to R1 first before reaching each other. To solve this, we add the manual frame-relay map command for them to reach each other using the DLCI used to reach R1. On R2 serial1/0 interface configuration level, type the following command:

frame-relay map ip 10.10.10.3 201 broadcast

On R3 serial1/0 interface configuration level, type the following command:

frame-relay map ip 10.10.10.2 301 broadcast

Now, if you try to ping R3 from R2 or vice-versa, the ping will succeed.