AI, ML, Development + Cisco Learning Blog Learning about Machine Learning, Artificial Intelligence, related devlopment topics and formerly Routing and Switching, Datacenter, Security and other topics, CCIE #23664, Frank Wagner

What is a route reflector? What is a cluster-id or originator-id and why should i need id?

If you start google for cluster-id it will not bring up many explanations about what is a clusters in bgp. However it’s quite simple. Because you can have multiple route reflectors inside one AS and this might break the normal AS path loop prevention mechanism. So normally AS path takes care of loop, but inside the AS it’s done with cluster-id and originator-id.

Let’s start with a route reflector. In BGP you would need a full mesh for all iBGP client peerings, to have routes propagated from client to client. Route reflection overcomes the need for a full mesh. The Route reflector reflects routes coming from a client to his route reflector clients.

Here a sample full mesh configuration within AS 200:

Here is a replaced full mesh example with one route reflector, which copies all updated to his clients. So if an update from AS100 is received it’s send to the route reflector and the route reflector copied the update to all of it’s clients:

Make sure next hop is reachable from within the peer. In case of this example, if no next-hop-self is configured from route reflector clients to the route reflector, the next hop for routes coming into AS 200 are pointing to AS100 and as AS300 gateways. This might be a problem for AS200 RR’s, if next hop self is not reachable via a local route.

The cluster is defined by the route reflector and the route reflector client(s). The cluster id will be the router reflector client if unset (for ex. 192.168.1.1). Or the cluster ID can be set with the „bgp cluster-id [number]“ command. So here one cluster is formed:

There are several way’s in configuring route reflector and clients in this scenario. It could be a demand that more than one route reflector should be available for redundancy. If in the above scenario the route reflector fails, there is no way to cope with the situation.

So it might be necessary to have more than one route reflector in the AS. A possible solution would be:

Cluster id is not passed between different sub asses inside the same confederation. The cluster id can avoid unwanted traffic by denying updates, here for example, if you set „bgp cluster-id 1“ on both router A and router B, they would deny accepting updates from each other, when they receive updates with the same cluster-id.

Updates are not needed because of the hierarchical route reflector setup. Since if an update come from router C, it will be propagated to A and B. Since A and B are from their perspective „None Clients“ to each other, cluster-id comes into place. Using the same cluster-id on both, will deny updates being accepted.

Example for „debug ip bgp 135.1.12.4 updates“ on Router B if Router C is sending a new prefix and Router B is recieving the update from Router A (135.1.12.4) also (assuming A and B have the same cluster-id configured). Clusterlist is the inside AS path replacement, for avoiding routing loops. As can be seen here clusterlist holds cluster-id 1 and cluster-id 2. Cluster-id 1 is configured for both A and B, as cluster-id 2 is configured on router D. Originator ID 2.2.2.2 is router C in this example:

*Mar 1 05:40:29.650: BGP(0): 135.1.12.4 rcv UPDATE w/ attr: nexthop 135.1.13.3, origin i, localpref 100, metric 0, originator 2.2.2.2, clusterlist 0.0.0.1 0.0.0.2, path , community , extended community

*Mar 1 05:40:29.658: BGP(0): 135.1.12.4 rcv UPDATE about 1.1.1.0/24 — DENIED due to: reflected from the same cluster;

The originator id is the last step, after cluster id has not effect, in preventing updates being sent in loops. At least, when the originator recieves his own update, then it will be dropped. If cluster-id is not by „bgp cluster-id [number]“ then, it will be set by the route-reflector-client sending updates to non clients with it’s own router-id.

Source:

Internet Routing Architectures, CiscoPress, P. 268ff

RFC2796, Route Reflection, http://www.faqs.org/rfcs/rfc2796.html

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml

A community in the BGP world is for sending attributes to neighbors that are members of the community. All community members will be send the attribute provided for the community.

Source:

http://www.cisco.com/warp/public/459/bgp-community.html

RFC  1930, 1771-1774
open – AS, HT (holdtime), Router ID, opt
keepalive – make sure links a established, checks if holdtime expires
update – inculdes, ip prefixes, route maintanace

notification – error code, subcode

^ Start of string

$ End of string

[] Range of characters

– Used to specify a range (i.e. [a-z])

() Local grouping

. Any single character

* Zero or more instances

+ One ore more instances

? Zero or one instance

\ the \ matches the charcter

– Comma, open or clase brace, open or close paranthese, start or end of string, or space

Some examples matches:

.* Anything

^$ Local originated routes

^200_ Learned from AS 200

_200$ Originated in AS 200

_100_ Any instance of AS 100

^[0-9]+(_[0-9])?$ Directly connected AS’s and their customers

^\(.*\)$ Routes originated in confederation peers

^(\(.*\))?$ Locally originated and/or routes originated in confederation peers

Here are some ways to control the way of BGP routing and sending updates to neighbors or controling updates from neighbors.

With „distribute-list“ it’s possbile to controll routes coming in on an interface or routes going out on an interface. You can for example say:

I don’t want to send route „192.168.1.0/24“ to router A an s0/0. So your distribute-list would look like:

(config)# acces-list 10 deny 192.168.1.0 0.0.0.255
(config)# access-list 10 any any
(config)# router bgp 500
(config-router)# distribute-list 10 out s0/0

So A would not receive 192.168.1.0

There are prefix lists are very similiar to acl’s. But they allow for example the use of sequence numbers. So you can a prefix-list inbetween other lists and don’t have to apply them at the end, like with acl’s.

Prefix-lists are more designed to filter route information.

BGP decision process

1. Weight check, highest
2. Local preference check, highest
3. Local route check.
4. AS path length check, shortest
5. Origin check, lowest, 0, 1, 2
6. MED check, lowest
7. prefer EBGP over IBGP Patch
8. Prefer the path to the closest IBGP neighbor
9. prefer the oldest route for EBGP paths

10. prefer the lowest BGP neighbor ID

Attributes are one of the most important things concerning BGP. With attributes almost everything can be controlled.

There are diefferent types of attributes:

• Welll-known-attributes
• mandatory
• Origin
• AS_Path
• Next_Hop
• discretionary
• Local_Preference
• Atomic_Aggregate
• Operational-attributes
• transitiv
• Aggregator
• Community
• non-transitiv
• Multi_Exit_Descriminator
• Propriatary-attributes
• Weight (Cisco specific)

Description of Attributes:

Origin

• Type Code 1
• Well known, mandatory
• Identifies the route was originally learned from by BGP
• 0 – by an IGP
• 1 – by an EGP
• 2- not complete /unrelaiable

AS_Path

• Type Code 2
• Well known, mandatory
• Lists ASs between local and destination

Next_Hop

• Well known, mandatory
• Type Code 3
• Identifies next hop to destination
• Next_Hop = IP address of peer

MED – Multi-Exit Discremitnator (MED)

• Type Code 4
• Optional, non-transitiv
• AKA „metric“
• Indicats preference of one route into an AS over another
• Only shared with neighboring AS’s
• Lowest MED is preferred

Here in this example the MED 100 is preferred as the host with the better Path.



MED ist configured with the „default-metric [number]

Local_Preference

• Type Code 5
• Well known, discretionary
• Indicates preference of one route over another
• Within AS only
• Higher Local_Preferance preferred
• Cisco’s default is 100
• It’s setup with a route-map

If there are two path’s from an AS to another and you can setup the local preference for your AS, you can set the Local_Preference to a lower value to become the one route more preferable. So this can be used to optimize the way routers communicate.

Atomic_Aggregate

• Type Code 6
• Well known, discretionary
• Automatically sent when two overlapping routes are received
• Less specific route is chosen
• More specific route is not chosen

Aggregator

• Type Code 7
• Optional and transitiv
• Any router that aggregates routes can use this attribute
• Attribute contains
• Aggregators AS number
• Aggregators IP address

Community

• Definded in RFC 1997
• Type Code 8
• Optional and transitiv
• Allows for grouping of destinations
• Apply policies to the group
• Transitiv but dropped by default
• Predefined communities
• No_Export – Do not advertise to EBGP peers
• No_Advertise – Advertise to no one
• Internet – Advertise to everyone

Weight

• Cisco defined
• Non-transitiv
• Wight assigned on peer-by-peer basis
• Integer value (0-65535)
• Higher values are preferred
• Default is 32768 for originated local routes
• Default for other routes is 0
• BGP config command: neighbor [ip] weight [weight]

This routing Protokol is an exterior routing protocol. It’s not neede on local area networks. It’s neede converge the internet. It’s completly different from the internel routing protocols like OSPF, EIGRP, RIP or IS-IS.

Here is a basic overview:

• It’s used to route between AS (autonomous systems)
• It’s an enhanced vector routing protocol
• uses tcp for transissions, three way handshake, port 179
• support cidr
• triggered updates
• granular metrics
• garanteed to be loopfree

Defintion of Autonomous System (AS):

A set of routers under a single technical administration using an interior gateway routing protocol and common metrics to route packets.

The AS is using an exterior gateway routing protocol to route packets to other ASs.

Terminology:

• A connection – is something like a adjacency between bgp peers using port tcp 179. The connection is not dependend on the routers between. They don’t have to be on the same subnet. There can be multiple routers in between.
• Update – is used to exchange routing information, including in every route a destination network and an as path list.
• AS Path list – it contains a list of AS’s that have to be passed to reach a certain destination, it’s including path attributes
• Routing information Bases are stored in RiBs, updates are stored in RiB’s, Adj-RiB-In, Loc-RiB, Adj-RiB-Out
• decision process – how a best route is choosen, bgp will weight the result of all of it’s attributes
• policies – support of routing through policies, to controll the flow of routes