BGP Basics and understanding over TCP

Routing to the Next-Hop Address

*The Problem :: Potential lack of information on forwarding path to next-hop address*

The solution :: Full IBGP mesh An exact route in the routing table is required for a network statement with a mask in order for it to be installed into a BGP table .

R1 receives the advertisement from AS 1(10.1.1.1/32) ans sends it to R2 .

Just see it is in the BGP table , but is not having > sign (not the best route)

This is because when R1 forwards the advertisement sent by AS1 to R2 , it does not change the next hop address (which in other words means how to get to this route)

but when we use next-hop-self command the output changes.

R1(config)#router bgp 2

R1(config-router)#neighbor 2.2.2.2 next-hop-self

IBGP lssues: Loop Avoidance

===========

* The Problem :: AS_PATH has no relevance internally*

The Solution :: Force loop-free route advertisements

--- Forward routes learned from external neighbors to internal neighbors

--- Forward routes learned from internal neighbors to external neighbors.

--- Do not forward learned routes from an internal neighbor to other internal neighbor.

1. R1 will receive 10.1.1.1/32 from AS1 and send it to R2 (Rule 1)

2. R2 will not forward this route to R3 ( Rule 3)

How do we fix that? Instead of those 2 ibgp sessions that we see , we create a direct session between R1 and R3.

Note:: An IBGP session can traverse multiple router hops.

Now R3 forwards that route to AS 3 (Rule 2).

When communicating back towards AS1.

AS3 will see 10.1.1.1 in its routing table and try to reach it through R3. R3 will then do a look up for the route. Since the route was received via R1 (ibgp), the output is as below.

R3#sh ip bgp neighbors 2.2.2.1 received-routes

BGP table version is 6, local router ID is 3.3.3.1

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 10.1.1.1/32 1.1.1.1 0 100 0 1 i

*>i 11.11.11.11/32 2.2.2.1 0 100 0 i

Total number of prefixes 2

After changing it with next hop self

-----------------------------------------------

R3#sh ip bgp neighbors 2.2.2.1 received-routes

BGP table version is 7, local router ID is 3.3.3.1

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 10.1.1.1/32 2.2.2.1 0 100 0 1 i

*>i 11.11.11.11/32 2.2.2.1 0 100 0 i

Total number of prefixes 2

So IBGP session between R1 - R3 is used to exchange routes and IBGP sessions between R!-R2, R2-R3 are used to keep R2 aware about the external networks (10.1.1.1) so that whenever R3 queries , it knows how to get there.

IGP synchronization

IBGP/IGP synchronization rule : -- Do not enter a BGP route into the routing table unless it is known by the IGP.-- Assumption : IGP is required to forward inter- AS packets across AS Unnecessary when full IBGP mesh is used-- Must be disabled when IGP is not used for forwarding transit packets. Modern default:: No synchronization

Path redundancy

The problem:: Many sesssions to physical interfaces for redundancy The dolution :: TCP session between loopback interfaces -- IGP ensures that loopback addresses are reachable

Update source command

By default, TCP sessions are originated from outgoing interfaces of a device . So if we are trying to form neighborship between loopback interfaces of two given devices then we need to change the source of the TCP session . neighbor ip-address update-source interface

Review of EBGP

EBGP assumes directly connected neighbor by defaultEBGP messages are originated with TTL = 1 to enforce this. -- Neighbor decrements TTL to 0 on reception-- rule at receiver: TTL must be 0 or higher-- TTL = 0 prevents EBGP message from being forwarded beyond directly connected neighbor Multihop EBGP Applications

EBGP peering between MPLS Provider Edge (PE) routers-- Used in inter-AS MPLS

An EBGP Security Risk

EBGP is the most vulnerable protocol

-- Because it is at the AS boundary

-- Exposed to outside access

A router will accept an EBGP message with TTL >= 0

Hene EBGP message can be sent from an attacker not directly connected

-- Attack messages originated with TTL = 255

The TTL security option

has two effects::

-- changes TTL of originated EBGP messages to 255

-- changes default accepted TTL to >= specified value

Note :: TTL command and multihop command are exclusive to each other and cannot be used together.

Must be configured on both sides (both neighbors)

It replaces the multihop EBGP statement ( because they have same effect)

-- Has the same effect

-- In compatible with multihop EBGP statement

neighbor ip-address ttl-security hops hop-count