Injecting prefixes

Understanding methods for specifying prefixes to be advertised over a BGP sesssion The Routing information databases (RIBs) used by BGP

Injecting prefixes

Injecting prefixes using the network statement.

Injecting prefixes using redistribution. Using the network statement network (prefix [ mask network-mask ] ) * Do not confuse this with the IGP network statement.-- IGP network statement specifies interface addresses on which the IGP runs. -- BGP network statement specifies prefixes to be adertised- mask option allow for exact prefix matching Note: Lets say there are multiple subnets in the routing table and you want only some subnets to be injected into BGP , then you specify that with the help of 'mask' command. At the injection point the prefix must how ever exist.Hence prefix must be in the routing table before it can be injected

--Learned by IGP

--Learned by static route

--A directly connected interface

Injecting Prefixes with redistribution

redistribute protocol

Redistributing between BGP and IGPs is dangerous

-- Instabilities in IGP prefixes can destablilize BGP

--Very large numbers of BGP prefixes can cause IGPs to fail

To use redistribution safely::

-- Configure a static route for each prefix to be redistributed

-- Redistribute the static route

--Use filters to ensure only the static prefixes of interest are redistributed. Useful for route aggregation.

Lab -

R2 and R3 additional configuration

======================= router ospf 1 network 10.2.1.0 0.0.0.255 area 0

network 10.2.255.0 0.0.0.255 area 0

We will advertise R1 prefixes with network statement and R4 using redistribution.

R1(config-router)#do sh run | sec bgp

router bgp 65520 bgp

log-neighbor-changes

network 10.18.0.0 mask 255.255.0.0

network 172.16.5.0 mask 255.255.255.0

network 192.168.20.0

neighbor 10.1.1.2 remote-as 65501 R1(config-router)#do sh ip bgp

BGP table version is 4, local router ID is 10.1.1.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 *> 10.18.0.0/16 0.0.0.0 0 32768 i *> 172.16.5.0/24 0.0.0.0 0 32768 i *> 192.168.20.0 0.0.0.0 0 32768 i

R4(config)#do sh run | sec bgp

router bgp 64950

bgp log-neighbor-changes

redistribute static

neighbor 10.3.1.1 remote-as 65501 R4(config)#do sh ip bgp

BGP table version is 3, local router ID is 10.3.1.2

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, ? - incompleteRPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 10.5.0.0/16 0.0.0.0 0 32768 ? *> 192.168.1.0 0.0.0.0 0 32768 ? Lets check if we are seeing routes at R2 and R3.

R3#sh ip bgpBGP table version is 3, local router ID is 10.2.255.3Status 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, ? - incompleteRPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 10.5.0.0/16 10.3.1.2 0 0 64950 ? * i 10.18.0.0/16 10.1.1.1 0 100 0 65520 i * i 172.16.5.0/24 10.1.1.1 0 100 0 65520 i *> 192.168.1.0 10.3.1.2 0 0 64950 ? * i 192.168.20.0 10.1.1.1 0 100 0 65520 i

NEXT_HOP Path attribute As the name signifies , carries the address of the next hop along the path towards an advertised destinationEvery BGP NLRI must have a NEXT_HOP attributeDefault rules to NEXT_HOP::- NEXT_HOP is set to outgoing interface address when advertising to an external neighbor- NEXT_HOP is not changed when advertising to internal neighbor If NEXT_HOP is unreachable, NLRI is not entered into routing table. Two ways of making NEXT_HOP reachable to internal neighbors:- Make external subnet of NEXT_HOP known to IGP * IGP passive interfce statement,or *redistribute connected statement - Change default behavior *Next-hop-self statement (Rather than not changing the next hop when advertising to internal neighbor , change it to something that is already known to IGP) The Next-hop-self statement *Next-hop-self is modern best practice - Making external subnets reachable can be an IGP scaling and security problem. next-hop-self: - Sets Next_HOP attribute to outgoing interface address (default); or - To address of interface specified in neighbor update-source statement. NEXT_HOP needs only to be changed at AS edge routers - on prefixes sent to IBGP neighbors neighbor ip-address next-hop-self