Network Technologies | IPNET

Cisco: BGP path selection for inbound traffic

In some previous post we saw how we can manipulate BGP paths using attributes for outgoing traffic. Today we will see how to use another BGP attribute, but this time for manipulating inbound traffic. First I would like to ask you to have a look into the topology file and also to check the config files (if you have a basic idea about how BGP is configured that you don’t need the config files).

From the table above:
we see that the attributes needed for inbound traffic manipulation are AS-Path and MED. Today we will use AS-Path for traffic manipulation (MED sometime in closer future).

Beside using BGP attributes, there are other ways to manipulate traffic and paths in a BGP environment, but usually this need that the provider will support your actions. As an example to understand, you can do route tagging in your network (for example in MPLS on your CE) and your ISP will apply rules based on different tags (on PE side), but this is out of the scope of this tutorial and will be discussed maybe in another tutorial.

For our test environment, that you see in the topology, we advertise everything into BGP domain, exactly as draw, so there will be no problems of reachability.

Please see the tutorial and explanations below:

Cisco: Traffic manipulation with Policy Based Routing

Cisco Policy Based Routing provides a flexible mechanism for network administrators to customize the operation of the routing table and the flow of traffic within their networks. Policy Based Routing (PBR) offers many advanced features, including selection and forwarding of traffic to discreet Virtual Routing and Forwarding (VRF) instances, as well as Enhanced Tracking of the availability of next-hops. More about PBR you can read here.

Before we start this tutorial please download the topology file which contain the routers connection, BGP topology and some explanations. As you can see in the topology file, traffic going from R4 to R5 will choose the shortest path through R1-R2. For this tutorial let’s assume that we want the traffic from R4 to R5 (and viceversa) to flow through path R1-R3-R2 (BGP is full mesh configured among these devices). For this we need to apply Policy Based Routing (PBR) on R1 and R2. What is PBR basically doing? It will change the next-hop for interesting traffic to R3 on this devices.

Please see below the tutorial about how to configure PBR:

Cisco: Very simple NTP configuration

NTP (Network Time Protocol) is usually very simple to configure on Cisco devices. Of course you can reach complex configuration, but since I work in this field I didn’t saw somebody to push the things to extreme in NTP configuration.

NTP is based on server – client relation. It is recommended that in a Cisco network environment, you should use online the client part of the NTP, and to choose some external NTP sever to synchronize with. This is because using a NTP server (master) on your networ violates NTP’s hierarchical trust model. You should use a NTP master only is there is no possibility to reach an external one or if some corporate policies dictate this.

NTP can operate in 4 different modes. See a short explanation below:
-> Client: A NTP client is configured to let its clock be set and synchronized by an external NTP timeserver. NTP clients can be configured to use multiple servers to set their local time and are able to give preference to the most accurate time sources. They will not, however, provide synchronization services to any other devices.
-> Server: A NTP server is configured to synchronize NTP clients. Servers can be configured to synchronize any client or only specific clients. NTP servers, however, will accept no synchronization information from their clients and therefore will not let clients update or affect the server’s time settings.
-> Peer: With NTP peers, one NTP-enabled device does not have authority over the other. With the peering model, each device shares its time information with the other, and each device can also provide time synchronization to the other.
-> Broadcast / Multicast: Broadcast/multicast mode is a special server mode with which the NTP server broadcasts its synchronization information to all clients. Broadcast mode requires that clients be on the same subnet as the server, and multicast mode requires that clients and servers have multicast access available and configured.

For our simple NTP configuration we will use the server and client mode. For this tutorial we will use the same topology like in the post “Cisco: BGP path selection for outgoing traffic” where we have already a working BGP environment. If you do not have the topology, you can download it here. Please see the tutorial below:

Cisco: How to improve BGP table stability with route dampening

[UPDATE Feb 13, 2013]
After gaining some more years of experience, playing more with BGP also from SP perspective, I would recommend to be careful with this feature. It can help in your enterprise environment, where you have access to BGP routers and can clean the dampened prefixes. If you have your Service Provider involved in routing your prefixes, I would prefer that the SP does not enable this feature. Imagine that because of some flaps your provider dampen all your prefixes. Or negotiate your SLA in such way that the provider can support if the BGP dampening feature is active and you need support.

———-

One of the issues that can affect BGP table stability is link flapping. Imagine that if a link to a network is flapping very often, BGP process has to remove the route to that network from the BGP table and implicit from the routing table and then we the link is available again to re-introduce the prefix in these tables. All this means some BGP operations that consume CPU and memory of the machine.

A way to improve the BGP table stability is to use route dampening. This BGP feature monitor the prefixes in the BGP table and when a route to some prefixes flaps more than BGP dampening is set to allow, it will take out the prefixes from the BGP table. In the following tutorial I will show you a way to configure BGP dampening with some explanations.

For this tutorial we will use the same topology like in the post “Cisco: BGP path selection for outgoing traffic” where we have already a working BGP environment. I took out the configuration for BGP path selection, so we have a simple BGP config running. If you do not have the topology, you can download it here and the initial configuration files here.

Please see the tutorial below:

Cisco: BGP path selection for outgoing traffic

Before going further on, please download the topology and the initial configuration files and have a close look into them (mostly into topology drawing). Also, this tutorial is addressed to people that know what is BGP and how to do a basic configuration for peering establishing.

For modifying the BGP automate selection of the best path, we have to modify some of BGP attributes from the table below:
Since today we will deal with outgoing traffic, we are interested in Weight and Local preference attributes, which we have to modify to reach our desired result. For the incoming traffic I will make another tutorial in some days.

So, let assume that we have some networks in the LAN after R1 in the topology and we advertise this into the BGP network. On R3, we will learn this prefixes by the way of R1 as it is the shortest path. But in our case the shortest path does not mean the fastest one. As you can see the connection between R1 and R3 is a Serial connection (let’s assume E1). The connections between R1 – R2 and R2 – R3 are FastEthernet connections. Even if this a longer path, for us would be better to reach the LAN subnets in behind R1 through R2, as this is more faster (bigger bandwidth and lower latency). We will force the outgoing traffic through R2 by modifying the Weight and Local preference attribute.

Please see the tutorial below: