Thursday, July 30, 2015

BGP - Redistribution

R1#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 33.3.3.3/32, 1 successors, FD is 2560000256
via Redistributed (2560000256/0)
P 13.0.0.0/24, 1 successors, FD is 28160
via Connected, FastEthernet0/1
P 66.6.6.6/32, 1 successors, FD is 2560000256, tag is 65837
via Redistributed (2560000256/0)
P 55.5.5.5/32, 1 successors, FD is 2560000256
via Redistributed (2560000256/0)
P 1.1.1.1/32, 1 successors, FD is 128256
via Connected, Loopback0

BGP over GRE

R6#sh ip bgp 44.4.4.4
BGP routing table entry for 44.4.4.4/32, version 140
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
505 303 201
5.5.5.5 from 5.5.5.5 (55.5.5.5)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
R6#

R6#sh ip route 44.4.4.4
Routing entry for 44.4.4.4/32
Known via "bgp 1.301", distance 20, metric 0
Tag 505, type external
Last update from 5.5.5.5 00:01:23 ago
Routing Descriptor Blocks:
* 5.5.5.5, from 5.5.5.5, 00:01:23 ago
Route metric is 0, traffic share count is 1
AS Hops 3
Route tag 505
MPLS label: none

R6#ping 44.4.4.4 so 66.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 44.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 66.6.6.6
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 160/222/324 ms
R6#

BGP NEXT_HOP Manual Configuration

Thursday, July 23, 2015

BGP- Confederation

Confederation peer has EBGP peering between them. like in R3 & R5.

The NEXT_HOP attribute of routes external to the confederation is preserved throughout the confederation.
MULTI_EXIT_DISC attributes of routes advertised into a confederation are preserved throughout the confederation.
LOCAL_PREF attributes of routes are preserved throughout the entire confederation, not just within the member AS In which they are assigned

The AS numbers of the member autonomous systems are added to the AS_PATH within the confederation but are not advertised outside of the confederation.

Like in R6

Network Next Hop Metric LocPrf Weight Path

*> 11.11.1.1/32 5.5.5.5 0 101 i

*> 22.22.2.2/32 5.5.5.5 0 101 i

*> 33.3.3.3/32 5.5.5.5 0 101 i

*> 44.4.4.4/32 5.5.5.5 0 101 201 i

*> 55.5.5.5/32 5.5.5.5 0 0 101 i

*> 66.6.6.6/32 0.0.0.0 0 32768 i

in R1

R1#sh ip bgp 22.22.2.2
BGP routing table entry for 22.22.2.2/32, version 47
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
(65001)
5.5.5.5 (metric 156160) from 3.3.3.3 (33.3.3.3)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
rx pathid: 0, tx pathid: 0x0

R1#

BGP- Route reflector with cluster

BGP Route reflectors are used as an alternate method to full mesh IBGP .

Here R5 ------R2 iBGP

R3------R1 iBGP

R5 RR-1 R2 is RR client

R3—RR2 R1 is RR client

R5 sh ip bgp

Network Next Hop Metric LocPrf Weight Path

*>i 22.22.2.2/32 2.2.2.2 0 100 0 i

*> 55.5.5.5/32 0.0.0.0 0 32768 i

*> 66.6.6.6/32 6.6.6.6 0 0 1.301 i

We can see no route from R1,R3

R3#sh ip bgp

Network Next Hop Metric LocPrf Weight Path

*>i 11.11.1.1/32 1.1.1.1 0 100 0 i

*> 33.3.3.3/32 0.0.0.0 0 32768 i

*> 44.4.4.4/32 4.4.4.4 0 0 201 i

We can see no route from R2,,R5

#sh ip bgp

Network Next Hop Metric LocPrf Weight Path

*> 22.22.2.2/32 0.0.0.0 0 32768 i

*>i 55.5.5.5/32 5.5.5.5 0 100 0 i

* i 66.6.6.6/32 6.6.6.6 0 100 0 65837 i

We can see no route from R1,,R3

#sh ip bgp

Network Next Hop Metric LocPrf Weight Path

*> 11.11.1.1/32 0.0.0.0 0 32768 i

*>i 33.3.3.3/32 3.3.3.3 0 100 0 i

* i 44.4.4.4/32 4.4.4.4 0 100 0 201 i

We can see no route from R1,,R3

…

R3#sh ip bgp

BGP table version is 225, local router ID is 33.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

*>i 11.11.1.1/32 1.1.1.1 0 100 0 i

*>i 22.22.2.2/32 2.2.2.2 0 100 0 i

*> 33.3.3.3/32 0.0.0.0 0 32768 i

*> 44.4.4.4/32 4.4.4.4 0 0 201 i

*>i 55.5.5.5/32 5.5.5.5 0 100 0 i

*>i 66.6.6.6/32 5.5.5.5 0 100 0 65837 i

R3#

R3#sh ip bgp 22.22.2.2

…………

…………..

Local

2.2.2.2 (metric 156160) from 5.5.5.5 (55.5.5.5)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 2.2.2.2, Cluster list: 55.5.5.5

rx pathid: 0, tx pathid: 0x0

R3#

R1#sh ip bgp 22.22.2.2

……….

………..

Originator: 2.2.2.2, Cluster list: 33.3.3.3, 55.5.5.5

rx pathid: 0, tx pathid: 0x0

R1#

In the above pic R5 & R3 has different cluster –ID …

So prefixes are forwarded .

CLUSTER_LIST Propagation Rules

· Classic—Before reflecting a route, the RR appends the global cluster ID to the CLUSTER_LIST. If the received route had no CLUSTER_LIST attribute, the RR creates a new CLUSTER_LIST attribute with that global cluster ID.

Loop Prevention Based on CLUSTER_LIST

· Classic—When receiving a route, the RR discards the route if the RR's global cluster ID is contained in the CLUSTER_LIST of the route.

Note – To prevent loop prefixes from same cluster Id will be discarded.

Now we will configure same cluster Id in both RR.

R3# & R5

router bgp 101

bgp cluster-id 101.101.101.101

R3#sh ip bgp

Network Next Hop Metric LocPrf Weight Path

*>i 11.11.1.1/32 1.1.1.1 0 100 0 i

*> 33.3.3.3/32 0.0.0.0 0 32768 i

*> 44.4.4.4/32 4.4.4.4 0 0 201 i

*>i 55.5.5.5/32 5.5.5.5 0 100 0 i

*>i 66.6.6.6/32 5.5.5.5 0 100 0 65837 i

R3#

In above example there is no route from R2 because it is from same cluster 101.101.101.101

same in r1

Network Next Hop Metric LocPrf Weight Path
*> 11.11.1.1/32 0.0.0.0 0 32768 i
*>i 33.3.3.3/32 3.3.3.3 0 100 0 i
* i 44.4.4.4/32 4.4.4.4 0 100 0 201 i
*>i 55.5.5.5/32 5.5.5.5 0 100 0 i
*>i 66.6.6.6/32 5.5.5.5 0 100 0 1.301 i

No route from R2

When EBGP prefix is advertised to iBGP peer, No cluster list attribute is on update.

Like in R5 for 44.4.4.4 ( EBGP route )

R5#sh ip bgp 44.4.4.4
BGP routing table entry for 44.4.4.4/32, version 32
........
3.3.3.3 (metric 158720) from 3.3.3.3 (33.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

R5#

but same route can be advertised to R2 as RR client because this is not a internal route or same cluster ID.

R2#sh ip bgp 44.4.4.4
BGP routing table entry for 44.4.4.4/32, version 323
........
3.3.3.3 (metric 156160) from 5.5.5.5 (55.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 33.3.3.3, Cluster list: 101.101.101.101

again we pt different cluster-id.

in R3

router bgp 101
bgp asnotation dot
bgp acluster-id 101.101.101.100

in R5 now,

R5#sh ip bgp

Network Next Hop Metric LocPrf Weight Path
*>i 11.11.1.1/32 1.1.1.1 0 100 0 i
*>i 22.22.2.2/32 2.2.2.2 0 100 0 i
*>i 33.3.3.3/32 3.3.3.3 0 100 0 i
*>i 44.4.4.4/32 3.3.3.3 0 100 0 201 i
*> 55.5.5.5/32 0.0.0.0 0 32768 i
*> 66.6.6.6/32 6.6.6.6 0 0 1.301 i

R2#sh ip bgp 11.11.1.1
BGP routing table entry for 11.11.1.1/32, version 344
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
1.1.1.1 (metric 158720) from 5.5.5.5 (55.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 1.1.1.1, Cluster list: 101.101.101.100, 101.101.101.101
rx pathid: 0, tx pathid: 0x0
R2#

Tuesday, July 21, 2015

iBGP - Next Hop Self

Refering to Route Reflector

we can see R6 and R4 dont have routes from each other

R6#

Network Next Hop Metric LocPrf Weight Path

*> 11.11.1.1/32 5.5.5.5 0 101 i

*> 22.22.2.2/32 5.5.5.5 0 101 i

*> 33.3.3.3/32 5.5.5.5 0 101 i

*> 55.5.5.5/32 5.5.5.5 0 0 101 i

*> 66.6.6.6/32 0.0.0.0 0 32768 i

R6#

in R6 we still don't have route from R4

R4#

Network Next Hop Metric LocPrf Weight Path

*> 11.11.1.1/32 3.3.3.3 0 101 i

*> 22.22.2.2/32 3.3.3.3 0 101 i

*> 33.3.3.3/32 3.3.3.3 0 0 101 i

*> 44.4.4.4/32 0.0.0.0 0 32768 i

*> 55.5.5.5/32 3.3.3.3 0 101 i

R4#

in R4 we still don't have route from R6

Next_Hop must be reachable to install route into routing table.

Problem ------

see in R5 ,

Sh ip bgp

Network Next Hop Metric LocPrf Weight Path

* i 44.4.4.4/32 4.4.4.4 0 100 0 201 i

Route is not best . next hop 4.4.4.4 is unreachable

R5#sh ip route 4.4.4.4

% Network not in table

R5#

This route will not forward to any peer. R5 don't have route.

Solutions----

There are two solution .

1.Make 4.4.4.4 reachable in IGP.

2. Change Next _Hop in the BGP which is reachable

We will configure Next Hop self command in R3 and R5 see the result..

in R3

R3(config)#router bgp 101

R3(config-router)#nei 5.5.5.5 next-hop-self .

Now in R5

R5#sh ip bgp

Network Next Hop Metric LocPrf Weight Path

*>i 44.4.4.4/32 3.3.3.3 0 100 0 201 i

Now the next hop is 3.3.3.3 , which is reachable now

And in R6

R6#sh ip bgp

Network Next Hop Metric LocPrf Weight Path

*> 11.11.1.1/32 5.5.5.5 0 101 i

*> 22.22.2.2/32 5.5.5.5 0 101 i

*> 33.3.3.3/32 5.5.5.5 0 101 i

*> 44.4.4.4/32 5.5.5.5 0 101 201 i

*> 55.5.5.5/32 5.5.5.5 0 0 101 i

*> 66.6.6.6/32 0.0.0.0 0 32768 i

R 6 has all prefixes.

Same we will do in R5.

R5(config-router)#nei 3.3.3.3 next-hop-self.

R3 has

R3#sh ip bgp

Prefix from R6. Next hop is 5.5.5.5 , reachable from R3.

.*>i 66.6.6.6/32 5.5.5.5 0 100 0 65837 i.

now r4 has all prefixes

iBGP - Route Reflector

R5#sh run | sec bgp
router bgp 101
bgp asnotation dot
bgp log-neighbor-changes
network 55.5.5.5 mask 255.255.255.255
neighbor 2.2.2.2 remote-as 101
neighbor 2.2.2.2 update-source Loopback0
neighbor 6.6.6.6 remote-as 1.301
neighbor 6.6.6.6 disable-connected-check

R1#sh run | sec bgp
router bgp 101
bgp asnotation dot
bgp log-neighbor-changes
network 11.11.1.1 mask 255.255.255.255
neighbor 2.2.2.2 remote-as 101
neighbor 2.2.2.2 shutdown
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 101
neighbor 3.3.3.3 update-source Loopback0
neighbor 5.5.5.5 remote-as 101
neighbor 5.5.5.5 update-source Loopback0

R2#sh run | sec bgp
router bgp 101
bgp log-neighbor-changes
net 22.22.2.2 mask 255.255.255.255
neighbor 1.1.1.1 remote-as 101
neighbor 1.1.1.1 shutdown
neighbor 1.1.1.1 update-source Loopback0
neighbor 3.3.3.3 remote-as 101
neighbor 3.3.3.3 update-source Loopback0
neighbor 5.5.5.5 remote-as 101
neighbor 5.5.5.5 update-source Loopback0
R2#

R3#sh run | sec bgp
router bgp 101
bgp log-neighbor-changes
network 33.3.3.3 mask 255.255.255.255
neighbor 1.1.1.1 remote-as 101
neighbor 1.1.1.1 update-source Loopback0
neighbor 2.2.2.2 remote-as 101
neighbor 2.2.2.2 update-source Loopback0
neighbor 4.4.4.4 remote-as 201
neighbor 4.4.4.4 ebgp-multihop 255
neighbor 4.4.4.4 update-source Loopback0

Problem area-----

R1 Neighbor

3.3.3.3 4 101 13 14 89 0 0 00:05:13 2
5.5.5.5 4 101 21 18 89 0 0 00:10:55 2

R1#sh ip bgp

Network Next Hop Metric LocPrf Weight Path
*> 11.11.1.1/32 0.0.0.0 0 32768 i
*>i 33.3.3.3/32 3.3.3.3 0 100 0 i Route from R3 (iBGP)
* i 44.4.4.4/32 4.4.4.4 0 100 0 201 i
*>i 55.5.5.5/32 5.5.5.5 0 100 0 i From R5 (iBGP)
* i 66.6.6.6/32 6.6.6.6 0 100 0 1.301 i
R1#

we can see there is no prefix from R2 .

Same in R2

Network Next Hop Metric LocPrf Weight Path
*> 22.22.2.2/32 0.0.0.0 0 32768 i
*>i 33.3.3.3/32 3.3.3.3 0 100 0 i
* i 44.4.4.4/32 4.4.4.4 0 100 0 201 i
*>i 55.5.5.5/32 5.5.5.5 0 100 0 i
* i 66.6.6.6/32 6.6.6.6 0 100 0 65837 i
R2#

No prefix from R1 but R2 has prefix from R6 because R5 will forward prefix to any iBGP peer if prefix is coming from EBGP.

in R3

Network Next Hop Metric LocPrf Weight Path
*>i 11.11.1.1/32 1.1.1.1 0 100 0 i
*>i 22.22.2.2/32 2.2.2.2 0 100 0 i
*> 33.3.3.3/32 0.0.0.0 0 32768 i
*> 44.4.4.4/32 4.4.4.4 0 0 201 i
R3#

No Prefix from R5 ,

in rule, iBGP never forward prefix coming from iBGP peer to any iBGP peer, but this will be forward to EBGP peer.

see in R6.

R6 and R5 EBGP.

R6#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 11.11.1.1/32 5.5.5.5 0 101 i
*> 22.22.2.2/32 5.5.5.5 0 101 i
*> 55.5.5.5/32 5.5.5.5 0 0 101 i
*> 66.6.6.6/32 0.0.0.0 0 32768 i

R6#

*> 11.11.1.1/32 (R1 Prefix) is coming from R5 where R5-R1 has iBGP peering.
*> 22.22.2.2/32 (R2 Prefix) is coming from R5 where R5-R2 has iBGP peering.

but no prefix from R3 & R4.

----Router reflector ---

To make prefix visible in all router Route reflector is the sloution.
In Route reflector,A route reflector can have three types of peers:
EBGP peers,
client peers,
nonclient peers

route reflector has the following three rules:
1. Routes learned from EBGP peers can be sent to other EBGP peers, clients, and nonclients.

2. Routes learned from client peers can be sent to EBGP peers, other client peers, and
non-clients.

3. Routes learned from non-client peers can be sent to EBGP peers, and client peers,
but not other non-clients..

Solution..

making R5 as Route reflector.

R1 & R2 are RR client

router bgp 101

neighbor 1.1.1.1 route-reflector-client

neighbor 2.2.2.2 route-reflector-client

Now in R1

R1#sh ip bgp

Network Next Hop Metric LocPrf Weight Path
*> 11.11.1.1/32 0.0.0.0 0 32768 i
*>i 22.22.2.2/32 2.2.2.2 0 100 0 i
*>i 33.3.3.3/32 3.3.3.3 0 100 0 i
* i 44.4.4.4/32 4.4.4.4 0 100 0 201 i
*>i 55.5.5.5/32 5.5.5.5 0 100 0 i
* i 66.6.6.6/32 6.6.6.6 0 100 0 1.301 i

All prefix

prefix 22.22.2.2/32 is from R2 .

in R5
Network Next Hop Metric LocPrf Weight Path
*>i 11.11.1.1/32 1.1.1.1 0 100 0 i
*>i 22.22.2.2/32 2.2.2.2 0 100 0 i
*> 55.5.5.5/32 0.0.0.0 0 32768 i
*> 66.6.6.6/32 6.6.6.6 0 0 1.301 i
R5#

R5#sh ip bgp 22.22.2.2
BGP routing table entry for 22.22.2.2/32, version 245
Paths: (2 available, best #2, table default)
Advertised to update-groups:
37 48 49
Refresh Epoch 1
Local, (Received from a RR-client)
2.2.2.2 (metric 156160) from 3.3.3.3 (33.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
Originator: 2.2.2.2, Cluster list: 33.3.3.3
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
Local, (Received from a RR-client)
2.2.2.2 (metric 156160) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

We still don't have all prefix now to solve this problem , there can be different solultions here we will make iBGP peering with R3and R3 as RR client.

R5#sh ip bgp sum
neighbor 3.3.3.3 remote-as 101
neighbor 3.3.3.3 update-source Loopback0

neighbor 3.3.3.3 route-reflector-client

Now in R5

Network Next Hop Metric LocPrf Weight Path
*>i 11.11.1.1/32 1.1.1.1 0 100 0 i
* i 22.22.2.2/32 2.2.2.2 0 100 0 i
*>i 2.2.2.2 0 100 0 i
*>i 33.3.3.3/32 3.3.3.3 0 100 0 i
* i 44.4.4.4/32 4.4.4.4 0 100 0 201 i
*> 55.5.5.5/32 0.0.0.0 0 32768 i
*> 66.6.6.6/32 6.6.6.6 0 0 1.301 i
R5#

we have all prefix

in R3

Network Next Hop Metric LocPrf Weight Path
* i 11.11.1.1/32 1.1.1.1 0 100 0 i
*>i 1.1.1.1 0 100 0 i
* i 22.22.2.2/32 2.2.2.2 0 100 0 i
*>i 2.2.2.2 0 100 0 i
*> 33.3.3.3/32 0.0.0.0 0 32768 i
*> 44.4.4.4/32 4.4.4.4 0 0 201 i
*>i 55.5.5.5/32 5.5.5.5 0 100 0 i
* i 66.6.6.6/32 6.6.6.6 0 100 0 65837 i
R3#

in R2

Network Next Hop Metric LocPrf Weight Path
* i 11.11.1.1/32 1.1.1.1 0 100 0 i
*>i 1.1.1.1 0 100 0 i
*> 22.22.2.2/32 0.0.0.0 0 32768 i
* i 33.3.3.3/32 3.3.3.3 0 100 0 i
*>i 3.3.3.3 0 100 0 i
* i 44.4.4.4/32 4.4.4.4 0 100 0 201 i
* i 55.5.5.5/32 5.5.5.5 0 100 0 i
*>i 5.5.5.5 0 100 0 i
* i 66.6.6.6/32 6.6.6.6 0 100 0 65837 i
R2#

in R6

R6#

Network Next Hop Metric LocPrf Weight Path

*> 11.11.1.1/32 5.5.5.5 0 101 i

*> 22.22.2.2/32 5.5.5.5 0 101 i

*> 33.3.3.3/32 5.5.5.5 0 101 i

*> 55.5.5.5/32 5.5.5.5 0 0 101 i

*> 66.6.6.6/32 0.0.0.0 0 32768 i

R6#

in R6 we still don't have route from R4

R4#

Network Next Hop Metric LocPrf Weight Path

*> 11.11.1.1/32 3.3.3.3 0 101 i

*> 22.22.2.2/32 3.3.3.3 0 101 i

*> 33.3.3.3/32 3.3.3.3 0 0 101 i

*> 44.4.4.4/32 0.0.0.0 0 32768 i

*> 55.5.5.5/32 3.3.3.3 0 101 i

R4#

in R4 we still don't have route from R6

Note ---Route reflector does not change path attribute like Next Hop

to solve above problem see BGP -Next hop Self

Monday, July 20, 2015

Establishing BGP Peerings

BGP- Authentication

R6#sh ip bgp nei 1.1.1.1 | in md5
Option Flags: nagle, path mtu capable, md5, Retrans timeout

R1#sh ip bgp nei 6.6.6.6 | in md5
Option Flags: nagle, path mtu capable, md5

Sunday, July 12, 2015

BGP Basics- Path Attribute

Path Attributes

A path attribute is a characteristic of an advertised BGP route. Path attributes are what allow BGP to set and communicate routing policy.

Each path attribute falls into one of four categories:

Well-known mandatory
Well-known discretionary
Optional transitive
Optional non-transitive

The ORIGIN Attribute- Well-known mandatory,

It specifies the origin of the routing update,

IGP— The Network was learned from a protocol internal to the originating AS. An IGP origin gets the highest preference of the ORIGIN values.” i”

EGP— The NLRI was learned from the Exterior Gateway Protocol. EGP is preferred second to

IGP. “e”

Incomplete— The NLRI was learned by some other means like disribution. Incomplete is the lowest-preferred ORIGIN value. Incomplete does not imply that the route is in any way faulty, only that the information for determining the origin of the route is incomplete “ ?”

AS_PATH - Well-known mandatory

AS_PATH is a well-known mandatory attribute that uses a sequence of AS numbers to describe the

inter-AS path, or route, to the destination specified by the NLRI,

AS_PATH describes all the autonomous systems it has passed through, beginning with the most recent AS and ending with the originating AS

NEXT_HOP - Well-known mandatory

It describes the IP address of the next-hop router on the path to the advertised destination,

There are three condition for next_hop .

1. If the advertising router and receiving router are in different autonomous systems (external

peers), the NEXT_HOP is the IP address of the advertising router's interface.

2. If the advertising router and the receiving router are in the same AS (internal peers), and the

NLRI of the update refers to a destination within the same AS, the NEXT_HOP is the IP

address of the neighbor that advertised the route.

3. If the advertising router and the receiving router are internal peers and the NLRI of the

update refers to a destination in a different AS, the NEXT_HOP is the IP address of the

external peer from which the route was learned

NEXT_HOP IP must be reachable to install route into routing table

LOCAL_PREF - well-known discretionary

LOCAL_PREF is short for local preference, is used only in updates between internal BGP peers; it is not passed to other autonomous systems,

The attribute is used to communicate a BGP router's degree of preference for an advertised route.The route with the highest LOCAL_PREF is selected.

MULTI_EXIT_DISC -optional nontransitive

To influence incoming traffic, the MULTI_EXIT_DISC attribute, known as the MED for short, is used.

This attribute is carried in EBGP updates and allows an AS to inform another AS of its preferred ingress points. The lowest MED value is preferred.

MED is considered a metric, and with a metric the lowest value—the lowest distance—is preferred

MEDs also are not compared if two routes to the same destination are received from two different

autonomous systems

ATOMIC_AGGREGATE and AGGREGATOR Attributes

when summarization (route aggregation) is performed, some route information is lost and routing can become less precise. When aggregation is performed in a BGP-speaking router, path detail is lost.

ATOMIC_AGGREGATE is a well-known discretionary attribute that is used to alert downstream routersthat a loss of path information has occurred.

In summarization, BGP speaker must attach the ATOMIC_AGGREGATE attribute to the aggregate route, and receiver when advertising the route to other peers, the ATOMIC_AGGREGATE attribute must remain attached.

When the ATOMIC_AGGREGATE attribute is set, the BGP speaker has the option of also attaching theAGGREGATOR attribute, This is a optional transitive attribute provides information about where theaggregation was performed by including the AS number and the IP address of the router thatoriginated the aggregate route.

ORIGINATOR_ID and CLUSTER_LIST-- optional, nontransitive

ORIGINATOR_ID and CLUSTER_LIST are optional, nontransitive attributes used by route reflectors,

ORIGINATOR_ID is a 32-bit value created by a route reflector. The value is the router ID of the originator of the route in the local AS, If the originator sees its RID in the ORIGINATOR_ID of a received route, it knows that a loop has occurred, and the route is ignored.

CLUSTER_LIST is a sequence of route reflection cluster IDs through which the route has passed, If a route reflector sees its local cluster ID in the CLUSTER_LIST of a received route, it knows that a loop has occurred, and the route is ignored.

COMMUNITY Attribute,

COMMUNITY is an optional transitive attribute that is designed to simplify policy enforcement.

The COMMUNITY attribute is a set of four octet values.

RFC 1997 specifies that the first two octets are the autonomous system and the last two octets are an administratively defined identifier, giving a format of AA:NN.

The default Cisco format, on the other hand, is NN:AA. It can be changed to the RFC 1997 format with the command ip bgp-community new-format.

We known communities are,

INTERNET

NO_EXPORT

NO_ADVERTISE

LOCAL_AS

NO_EXPORT_SUBCONFED.

Administrative Weight -Cisco Specific

Administrative weight is a Cisco-specific BGP parameter that applies only to routes within an

individual router. It is not communicated to other routers. The weight is a number between 0 and

65,535 that can be assigned to a route; the higher the weight, the more preferable the route

All routes learned from a peer have a weight of 0, and all routes generated by the local router have a weight of 32,768.