BGP notes on Multi homing

i)Classes of BGP Attributes

1.Well Known a)Mandatory - AS_PATH, NEXT_HOP, ORIGIN
b)Discretionary - LOCAL_PREFERENCE, ATOMIC_AGGREGATE
2.Optional c)Transitive - AGGREGATOR, COMMUNITY
d)Non Transitive - MED(metric)

The well-known attributes must be recognised by anything that runs BGP. If it’s mandatory, then its value must be included in every BGP Update message sent: discretionary attributes do not have to always be sent. Well-known attributes, if included, must be passed along to the next BGP peer.

BGP implementations do not have to understand optional attributes, however if it’s a transitive attribute, it should still be passed to the next BGP peer, even if this one doesn’t know what to do with it. If it’s marked as non-transitive, then the router can simply ignore it, and shouldn’t pass it on, although if does understand it, it can act on it if it wants to.

ii)Some notes on BGP route selection at the time of Multihoming

1.If the router is of Cisco make , straight away make use of the Weight attribute to influence outgoing path from a branch office(in case multiple paths-from Same or Different ISP- are available and u want to load share) using route-mpas. WEIGHT is known to only the local router.
2.If not cisco make, use the local-preference attribute to influence outgoing path from a branch office. Also make use of local peference to influence the exit path, in case there are multiple exit points in the AS.(more than one router) since the local preference attribute is propagated throughout the local AS.
3.To influence the interface on which packets are coming in use prepend-as, (When multi homed to different ISP's, since AS_PATH is well known mandatory)
4. Use MED to influence incoming packets path only when multihomed to same ISP(since MED is optional "non-transitive"), and the ISP recognises MED. MEDs are advertised throughout the local AS.

Community Attribute

The community attribute provides a way of grouping destinations, called communities, to which routing decisions (such as acceptance, preference, and redistribution) can be applied. Route maps are used to set the community attribute. Predefined community attributes are listed here:

•no-export—Do not advertise this route to EBGP peers.

•no-advertise—Do not advertise this route to any peer.

•internet—Advertise this route to the Internet community; all routers in the network belong to it.

Figure 39-7 illustrates the no-export community. AS 1 advertises 172.16.1.0 to AS 2 with the community attribute no-export. AS 2 will propagate the route throughout AS 2 but will not send this route to AS 3 or any other external AS.

Figure 39-7 BGP no-export Community Attribute

In Figure 39-8, AS 1 advertises 172.16.1.0 to AS 2 with the community attribute no-advertise. Router B in AS 2 will not advertise this route to any other router.

Figure 39-8 BGP no-advertise Community Attribute

Figure 39-9 demonstrates the internet community attribute. There are no limitations to the scope of the route advertisement from AS 1.

Figure 39-9 BGP internet Community Attribute

BGP Path Selection

BGP could possibly receive multiple advertisements for the same route from multiple sources. BGP selects only one path as the best path. When the path is selected, BGP puts the selected path in the IP routing table and propagates the path to its neighbors. BGP uses the following criteria, in the order presented, to select a path for a destination:

•If the path specifies a next hop that is inaccessible, drop the update.

•Prefer the path with the largest weight.

•If the weights are the same, prefer the path with the largest local preference.

•If the local preferences are the same, prefer the path that was originated by BGP running on this router.

•If no route was originated, prefer the route that has the shortest AS_path.

•If all paths have the same AS_path length, prefer the path with the lowest origin type (where IGP is lower than EGP, and EGP is lower than incomplete).

•If the origin codes are the same, prefer the path with the lowest MED attribute.

•If the paths have the same MED, prefer the external path over the internal path.

•If the paths are still the same, prefer the path through the closest IGP neighbor.

•Prefer the path with the lowest IP address, as specified by the BGP router ID.

http://www.cisco.com/en/US/docs/internetworking/technology/handbook/bgp.html





refer for BGP and MPLS http://www.netcraftsmen.net/resources/archived-articles/373.html

Cisco IOS CAR-Committed Access Rate- / rate-limit to control Download/Upload limit for a user or Uer or VALN using ACL

reference: http://articles.techrepublic.com.com/5100-10878_11-6151305.html

Committed access rate (CAR)—or "rate limiting"—is a method for managing unwanted traffic on your network and making sure it doesn't affect important traffic.
To use CAR, you must enable CEF on your routers.
CAR can be very useful as a basic QoS function.
Essentially, CAR controls the bandwidth of a certain type of traffic, and an access control list (ACL) defines which traffic it controls. Once you've created the ACL, you can set CAR to enforce a bandwidth rate on that traffic in either an INBOUND or OUTBOUND direction, according to the interface on which you applied CAR.

Using CAR requires two simple steps:

1. Create an ACL to define the traffic you want to rate limit.
2. Use the rate-limit command, referencing the ACL on your interface closest to the source of the traffic, referencing the proper direction, and referencing the proper bandwidth amounts.

For example, let's say you have a production application at a remote location across a 128-Kb WAN connection. The application works fine until, one day, a new employee gets a PC, a Web browser, and Internet access.

When in use, that single Web browser slows down the entire remote production network by downloading Web pages and documents over the 128-Kb connection. So how can you prevent the Web browsing from taking over the WAN connection and slowing down the production application?

To return to our example, let's say you have a headquarters location that provides the Internet access for this single PC across the WAN. Even if browsing the Web is a necessary business function, it's negatively affecting the performance of the production application on the remote network.

Let's look at how you can use to control this Web traffic. First, define the traffic you want to rate limit on the headquarters' router. Here's an example:

HQ-Router(config)# access-list 120 permit tcp any eq www host
10.200.200.200

In this example, the remote PC has an IP address of 10.200.200.200. So, we're saying that the source server could be any Web server serving Web pages on port 80.

Next, use the rate-limit command on the interface. Here's an example:

HQ-Router(config)# interface Serial0/0
HQ-Router(config-if)# rate-limit output access-group 120 50000
10000 20000 conform-action transmit exceed-action drop

This applies the rate limit to the interface, referencing ACL 120. We applied it in the outbound direction because we applied it on the headquarters router (not the remote router). That's because we want to prevent unwanted Web traffic from going across the WAN to the remote site—we don't want to wait until the traffic arrives there before slowing it down.

50000, 10000, 20000 represents the normal bits per second (bps) for this traffic (i.e., 50000 bps or about 50 Kb), the normal burst size for the traffic (i.e., 10000 or about 10 Kb), and the maximum burst size for the traffic (i.e., 20000 or about 20 Kb). The traffic must conform to these numbers in order for the router to transmit it (as specified by conform-action transmit). If the traffic exceeds those bandwidth settings, the router will drop it (as specified by exceed-action drop).

Configuring these settings on the headquarters' router on the Serial0/0 interface (i.e., the interface that goes to the remote location) limits the extraneous Web traffic to consuming less than 50 Kb of the 128-Kb circuit used for the production application.

While you can use CAR in a variety of situations, keep in mind that CAR only limits what you tell it to limit with the ACL. In addition, the CAR bandwidth settings you reference limit all traffic referenced in the ACL.

BGP Synchronization and Split Horizon

BGP Synchronization rule:

Applicable to the following situations
1.When the AS is a transit AS,
2.When atleast one of the router in the AS is not running BGP
3.All the routers are running bgp but, they are not fully meshed or there is no RR.

When a BGP router learns about a network from an eBGP peer it advertises to other iBGP peers only after verifying that the network information is already available in the IGP.

BGP Split Horizon Rule:An iBGP router never advertises a route learned from its neighbour to any other iBGP peer. ( Conventional split horizon says that a route/network learned through an interface will never be advertised back on that interface)

One doubt: Suppose a Service Provider(SP) network. If all the internal routers are capable of running BGP(ibgp) and if a RR is there what is the need for running an IGP in the network?? Ans: For each of the RR clients to reach the RR, the IGP is required. Also the route to each networks between the routers also are propogated by the IGP.

Elections in Cisco Switches and Routers

Hi,

I will describe the election processes taking place in routers and switches.

1. Routers: IGMP Designated Querier: Highest IP
2. Switch/Router: HSRP/VRRP/GLBP: Active/Master/AVG :Highest Priority :IP address with HSRP enabled, second is Standby/backup/standby AVF