Test Case ID
|
Test Case Description
|
Expected
|
Test
case1
|
Configure bgp having different med with aggregation enabled and check
for aggregated routes.
|
Routes should not be aggregated.
|
Test
case 2
|
Configure bgp having same med with aggregation enabled and check for
aggregated routes.
|
Routes should be aggregated.
|
NOTE ABOVE SCENARIO:
BGP Overview
############
->Open Standards based
->RFC 4271 “ A border
gateway protocol 4 (BGP-4)”
->Classless path vector
routing protocol
->uses multiple
“attributes” for routing decision
->supports VLSM and
summarization.
BGP ASNs
#########
-> Autonomous Systems
(AS)
-a set of routers under a single technical administration, using an interior gateway protocol(IGP) and
-a set of routers under a single technical administration, using an interior gateway protocol(IGP) and
common metrics to determine how to route packets
within the AS, and using an inter-AS routing protocol to determine how to route
packets to other AS'es.
-> ASNs are allocated by
Internet assigned number authority (IANA)
-> Generally BGP relies
on OSPF, ISIS, EIGRP [IGP Protocols ] to advertise routing within AS.
BGP ASN Values
###############
-> Originally 2 byte field: -value 0-65535
-> public ASNs
1-64511
-> private ASNs
64512-65535
Now 2 byte is already
occupied so we come up with 4 byte AS
-> Currently 4-byte field
-> BGP support for
four-octect AS number space.
4-Byte BGP ASN
##############
-> 0.0 – 65535.65535 notation
-> 0.[0-65535] denote
original 2 byte ASNs
-> Requires backwards compatibility with old code.
-> 4 byte ASN support
negotiated during capability exchange
-> old bgp speakers are
sent ASdot numbers encoded as ASN “23456”
-> real AS-Path encoded
with optional transitive attributes AS4_AGGREGATOR and AS4_PATH
Establishing BGP Peerings
#######################
-> Like IGP, first step
in BGP is to find neighbors to exchange information with
Unlike IGP..
-> BGP does not have its
own transport
-> BGP has different
types of neighbors
-> BGP neighbors are not
discovered ---Has to be manually configured.
-> BGP neighbors do not
have to be connected
Since we have a TCP
used as a L4 protocol(logical) for establishment, hence neighbors in case of
IBGP need not to be directly connected.
BGP Transport
#############
-> BGP uses TCP port 179
for transport
-Implies that BGP
needs IGP first
-> BGP neighbor
statements tells process to
-listen for remote
address via TCP 179
-initiate a session to
remote address via TCP 179
-If collision, higher
router-id becomes TCP client
Note: if you want to
use BGP only then there should be a physical connection between all routers ie
full mesh which has again routing issues. Hence we use IGP within IBGP for
route recursion process to BGP next hop value.
BGP Peering Types
#################
-> External BGP (EBGP )
peers
-neighbors outside my
AS
-> Internal BGP(iBGP)
Peers
-neighbors inside my
AS
Update and path
selection rules change depending on what type of peer a route is being sent
to/received from.
BGP Peering Rules
################
-> EBGP packets default
to TTL 1
-Can be modified if
neighbors are multiple hops away
neighbor
ebgp-multihop [ttl]
neighbor ttl-security
hops [ttl]
Non multi-hop peers
must be directly connected by default
-can be modified if
connected neighbors peer via Loopbacks
-neighbor disable –connected-check
-> Loop prevention via
AS-PATH
-Local ASN is
prepended to outbound updates
-Inbound updates
containing local ASN are discarded
-can be modified with
neighbor allows-in
-> Next-hop processing
-outbound EBGP updates
have local update-source for neighbor set as next-hop
Ex:. If update-source
is Loopback0, next –hop is loopback0
-Can be modified with
route-map action set ip next-hop but typically shouldn’t
Ex: third-party
next-hop
Note :
Control plane =
session = routing update
Data plane = data forwarding
= actual data flow.
-> IBGP packets default
to TTL 255
-implies neighbors do
not have to be connected as long as IGP reachability exists
-> Loop prevention via
route filtering
-iBGP learned routes
cannot be advertised on to another IBGP neighbor
-Implies need for
either..
-fully meshed iBGP
peerings
-router reflection
-confederation
Next-hop Processing
##################
-> Outbound iBGP updates
do not modify the next-hop attribute regardless of IBGP peer type
-BGP peer
-Route reflector’s
client peer
-Route Reflector’s
non-client peer
-Confederation EBGP
peer
-Can be modified with
neighbor next-hop-self on route-map action set ip next-hop
Note : in case of BGP control and data plane are disconnected which gives us a flexibility to route
outbound traffic based on route-map.
BGP Transport
#############
-> TCP server must agree
on where client’s session is coming from
-if server does not
expect session it will refuse
-> Client’s packet is
sourced from outgoing interface in the routing table.
-can be modified with
update-source per neighbor
iBGP Route reflection
###################
-> Eliminates need of
full mesh
-only need peering(s)
to the RR(s)
-> Like OSPF DR &
IS-IS DIS, minimizes prefix replication
-send one update to
the RR
-> RR sends the update to
its “clients”
-> Loop prevention
through Cluster-ID
-> RR discards routed received with its own cluster-id
-> RR discards routed received with its own cluster-id
-> Does not modify other
attributes such as next-hop
Route reflector
Peerings
#####################
-> Route reflector can
have three types of peers
-EBGP peers
.neighbors in
differnet AS
-Client peers
.IBGP peers with
route-reflector-client
-Non-client
peers
.IBGP peers without
route-reflector-client
Route Reflector Update
Processing
##############################
-> RR processes update
differently depending on what type of peer they came from
-> EBGP learned routes:
.can be advertised to
EBGP peers, clients, & Non clients
-> client learned routes
.can be advertised to
EBGP peers, clients, & non clients
-> Non-cleient learned
routes
.can be advertised to
EBGP peers and clients
RR placement based
upon these rules
Large Scale Route
Reflection
#########################
Larger scale BGP
designs cannot be serviced by only a single RR
-> single RR is a single
point of failure
RR “clusters” allow
redundancy and hierarchy
-> cluster is defined by
the clients a RR servers
-> RRs in the same
cluster use the same cluster-ID
Inter-Cluster peerings
between RRs can be client or non-client peerings
-depends on redundancy
design
BGP Confederation
#################
Reduces full mesh IBGP
requirement by splitting AS into smaller Sub-Ases
-> inside Sub-AS full
mesh or RR requirement remains
-> between sub-AS acts
like EBGP
Devices outside the
confederation do not know about the internal structure
-> Sub-AS numbers are
stripped from advertisements to “true” EBGP peers
Typically uses ASNs in private range (64512-65635)
Typically uses ASNs in private range (64512-65635)
BGP Confederation
Configuration
#############################
Enable the BGP process
-> router bgp [sub-as]
Specify the main AS
number
-> bgp confederation-id
[main-as]
Specify other Sub-Ases
that you peer with
-> bgp
confederation-peers [sub-as1 sub-asn]
-> Not all sub-Ases,
just those directly peered with
BGP NLRI Advertisement
#####################
BGP NLRI can be
originated by
-> network statement
.requires exact match
in the routing table first
-> redistribute statement
.won’t include OSPF
External by default
-> aggregate-address
statement
.requires one subnet
in BGP table first
-> bgp inject-map
statement
.opposite of
aggregation
BGP Network Statement
#####################
Originates prefixes
with ORIGIN of iGP(i)
Requires exact match
in the routing table
-> Does not have to be a
connected prefix, can be learned via IGP
Without mask
keyword assumes classful mask
BGP redistribute
statement
#######################
Originates prefixes
with ORIGIN of INCOMPLETE (?)
Originates classfull
summary if auto-summary is enabled
Automatically copies
IGP metric to BGP MED
Won’t include OSPF
external by default
-> redistribute ospf
[pid] match internal external
BGP Aggregation
###############
Can be applied at any
point in the network as long as one subnet is in the bGP table
Configured as
aggregate-address [network] [mask] [args]
Arguments are ..
-> summary-only
-> suppress-map
-> attribute-map |
route-map
-> as-set
-> advertise-map
BGP conditional Route
Injection
###########################
Originates subnest(s)
from aggregate for purpose of longest match traffic engineering
Configured as bgp
inject-map inject-map exist-map exist-map [copy-attributes]
-> Inject Map
.subnet to be
advertised
.set ip address
prefix-list [list]
-> Exist Map
.Aggreate to be
originated from
.match ip address
prefix-list [list]
.match ip route-source
prefix-list [list]
BGP Best Path
Selection
#####################
Chooses which routes
can be
-> installed in the
RIB/FIB
-> Advertised to the
other BGP peers
Best path selection
prerequisites
############################
Nexthop value must be
in the routing table
-> prevents
route-recursion failure
Synchronization rule
must be met or disabled
->Legacy black-hole
prevention technique
AS-Path must not
contain local-AS
-> Normal EBGP loop
prevention
First ASN in path must
be neighbor’s ASN
-> bgp enforce-first-as
command
Best path Selection
Order
######################
Weight
Local Preference
Locally Originated
AS-Path
Origin
MED
EBGP over IBGP (This
is different form the AD)
IGP metric to Next-hop
Tie breakers
-Oldest
-Lowest RID
-Shortest cluster list
-Lowest neighbor
address
Manipulating Best path
selection
############################
Outbound routing
policy affects inbound traffic
Inbound routing policy
affects outbound traffic
Weight and local pref
-> set inbound
-> affects outbound
traffic
AS-path and MED
-> set outbound
-> affects inbound
traffic
Best Path Selection
Exception
##########################
AS-Path
-bgp bestpath as-path
ignore
MED
-bgp
always-compare-med
-bgp bestpath
med-confed
.compare med for
routes locally originated in the confederation
-bgp bestpath med
missing-as-worst
.assign MED of
4,294,967,294 to NULL MED
-bgp deterministic med
.compare MED against
all possible paths
BGP Communities
################
BGP’s implementation
of a route-tag
Used to group prefixes
together for
-advertisement policy
-filtering policy
-best path selection
policy
Community is an
optional transitive attribute
-not exchanged between
peers by default
-neighbor [address]
send-community
BGP Community Values
####################
Standard community is
4-byte value
Can be denoted as ..
-decimal
(0-42944967296)
-AA:NN(00: -
65635:65535)
.ip bgpcommunity
new-format
-same binary value
regardless of visual format
Three “well-known”
values are reserved
BGP well-known
communities
##########################
No-export (0xFFFFFF01)
-don’t advertise to
EBGP peers
No-advertise
(0xFFFFFF02)
-don’t advertise to
any peers
Local-AS (0xFFFFFF03)
-don’t advertise to
confederation EBGP peers
-RFC defines as
NO_EXPORT_SUBCONFED
Matching and setting
Communities
##############################
Set occurs in
route-map
-set community
{community-number [additive] [well-known-community] | none}
-not additive by
default
Match occurs by
community-list
-Define list
.standard list matches
community name or number
-ip community-list 1
standard permit no-export
.expanded matches
regular expression
-ip community-list
expanded AS100 permit 100:[0-9]+
-Reference from
route-map
.match community AS100
BGP Filtering
###########
BGP updates filtering
occurs on a per peer basis with..
-neighbor [address]
distribute-list
-neighbor [address]
filter-list
-neighbor [address]
prefix-list
-neighbor [address]
route-map
Using route-map avoids
order of operations issues.
BGP Convergence
################
Hello and keepalive
timers
-lowest timers are
negotiated during peering establishment
-timers bgp
-neighbor timers
Link down detection
-bgp
fast-external-fallover
Update timers
.neighbor
advertisement-interval
-bgp nexthop {trigger
{delay seconds | enable} | route-map map-name}
-bgp scan-time
-bgp update-delay
BGP Default routing
#################
Three ways to
originate default
-default-information
originate + redistribute
-network 0.0.0.0 mask
0.0.0.0
-neighbor
default-originate
Miscellaneous :
Attributes:
well known mandatory:everyone supports, must be in update message (next_hop, origin, as_path)
well known
discretionary: everyone supports, might not be in update message (local
pref, atomic aggregate)
Optional transitive:
travel from router to router or from AS to AS
Optional non-transitive: does not travel from router to router (Aggregator, MED)
Most preferred:Ignore routes with an inaccessible next hop address.
In bgp table : * means
valid and > means best route
Two ways to get
networks into BGP
-network commands
-redistribution
BGP Synchronisation:
Do not use or
advertise a route learned via IBGP until the same route has been learned from
the internal routing protocol.
BGP next-hop
processing:
-for IBGP peers
:do not change next hop address on advertised routes.
-for EBGP peers :change next hop address on advertised routes.
When we create
neighbor relation within IBGP or EBGP between loopback addresses we need to use
update source loopback
when we create
neighbor relation between EBGP routers having loopback address we need to use
ebgp multihop since loopback address sees itself sees as one hop away.
When only BGP is
configured on IBGP, do no synchronisation on all routers in AS and do clear
and reset the process(clear ip bgp *)
Issue : since with
IBGP, next hop is not changed, internal router will not be able to reach ebgp
router so solution is to redistribute external ebgp route to routers in
internal AS or another solution is to set next hop- self command in
border router.
Weight is cisco
propriety and its local to router. It is set on per neighbor basis.
To disable the
neighbor
neighbor 10.1.1.2 shut
origin code : i
iGP(entering with network command) or e EGP or ? incomplete (redistribute
routes into BGP)
local pref :
advertised within AS
bgp default local-preference
100. Mainly used when we want to pass routes through that particular router.
policy_routing : the
programming language of routing table.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.