How to advertise networks in BGP

(Marty S) #8

Thank you Rene.

Getting back to Alfred0’s question regarding null routes, why would someone need to advertise a prefix which is not existing in their local AS? Yes, it does make sense to use null route(s) with route summarization. I think there is one more case where you need null route, namely when you don’t want your public (peering) IP to be advertised upstream in BGP.

M/

(Rene Molenaar) #9

Hi Marty,

There’s a couple of good reasons. For example, let’s say the ISP has the entire 1.0.0.0/8 range but at the moment they are only using a small part of this address space, just a few subnets:

1.1.1.0/24
1.1.2.0/24
1.1.3.0/24

You could advertise just these subnets in BGP and be done with it but advertising your entire address space might be a better idea:

Stability of routing updates is important in BGP. If one of your interfaces that has a subnet that is advertised in BGP is flapping then this will trigger a routing update. When you use a static route (to the null interface) then this route will always be advertised…it doesn’t matter what your interfaces are doing. This will greatly improve the stability of BGP routing.

The second thing to consider is that you are the only one using the 1.0.0.0/8 address space so you might as well advertise it right away. This also improves stability since you won’t be advertising (and removing) new subnets all the time. It also helps to reduce the size of routing tables.

Hope this helps!

Rene

1 Like
(Marty S) #10

Thank you Rene.

Excellent! So let’s make sure I understand your logic. If I was the ISP and I owe the entire 1.0.0.0/8 subnet (utilizing/advertizing only 1.1.1.0/24, 1.1.2.0/24, and 1.1.3.0/24) then I will manually configure ip route 1.0.0.0 255.0.0.0 null 0 so to contribute for my AS stability and reduce the size of the routing table. Am I correct?

Thanks,
MS/

(Rene Molenaar) #11

Hi Marty,

That’s right, you got it.

Rene

(Derek J) #12

Can you shed any light on the default information originate and it’s use in BGP.

(Andrew P) #13

Hi Derek,
There are three cases that must be considered for your question. I will answer your question directly first, and then mention the other two cases.

Case #1:
Think of “default-information originate” as a safety check. Suppose there was some careless BGP admin that told a router to redistribute some other protocol’s routes into BGP, say EIGRP. If that admin didn’t use a route-map or some other filter, and he didn’t think about that EIGRP was advertising a default route, the consequences could be really bad. You might not want all of your BGP peers to learn a default route from you! As a precaution against this, if you redistribute other routes into BGP and you really intended the default to be included, you must additionally type in “default-information originate.” So in other words, “default-information originate” really has no meaning with BGP unless it is paired with a “redistribute” statement.

Case #2
(config-router)#neighbor 1.1.1.1 default default-originate
What this does is advertise a default route to a specific neighbor. BGP will do this even if it doesn’t have a default route itself (so this is an exception to the rule where you can only advertise networks that are in your routing table).

Case #3
The last case is advertising the default network explicitly like this
(config-router)#network 0.0.0.0 mask 0.0.0.0
Doing this will cause BGP to advertise a default network, but only if you already have the default network in your routing table.

--Andrew

(Derek J) #14

Thanks that helps to clear it up!

(ADRIAN T) #15

Hi Rene,
What if behind R1 - on the left side - we have a cloud and then 1.0.0.0/8. How R2 will ever be capable to send traffic to this net, through R1?
Because R1 has:


ip route 1.0.0.0 255.0.0.0 null 0 

which will sink to null 0 every packet, right?!
One solution would be: if R1 will have more specific routes to subnets of 1.0.0.0/8, traffic to those subnets will reach its destination because of the longest match rule.
Thanks!
A.

(Rene Molenaar) #16

Hi Adrian,

With a static route like this, everything that matches 1.0.0.0/8 will be discarded unless there is a more specific route. For example, if R1 has 1.1.0.0/16 pointing to another router then any packed with destination 1.1.x.x would match that second static route.

If there was a router with networks that match 1.0.0.0/8 behind R1 then you should change the next hop from null0 to the IP address of the router behind R1 :slight_smile:

Rene

(rouzbeh t) #17

Hello Rene,

I have seen some documents that they advertise a network in BGP without using mask like below:

router bgp 1
network 1.0.0.0 

Just wondering as you said the exact mask has to be added in network command, why bgp process accepts this without mask?

Regards,
-Rouzbeh

(ADRIAN T) #18

Hi Rouzbeh,

  1. If no mask is specified, default mask is used, that is /8 in your example.
  2. When Rene said “exact mask has to be added in network command” meant that if we have a prefix in routing table (say 192.168.1.0/25), and we want this prefix to be injected in bgp with network command we should use
router bgp 1
network 192.168.1.0 255.255.255.128

in our config.
If we are going to use:

router bgp 1
network 192.168.1.0

, router will assume an implicit mask (255.255.255.0).
So 192.168.1.0/24 prefix will not enter bgp table because we do not have 192.168.1.0/24 in routing table. We have 192.168.1.0/25 but not 192.168.1.0/24.
Briefly, if we have 192.168.1.0/25 in r. table, we should use EXACT prefix (of course) and mask (!) in network statement
network 192.168.1.0 255.255.255.128
Hope it helps.
A.

1 Like
(rouzbeh t) #19

Thank you so much for the answer, now it is clear for me.

Regards,
-Rouzbeh

(sajid k) #20

Hi,

How do I advertise public IP to a peer? for example, my server 10.123.10.50 should NAT to <public-IP> and routed to neighbor.

The router only knows the 10.123.10.0/24 network as connected.

Best.

(Mohammad Hasanuz Zaman) #21

Hlw Rene,

Hope you are doing great …

One questions …

The BGP router will trigger a routing update to neighbor if belonging subnets are flap again & again in internal domain ?? How could we get routing upadate stability if BGP router always send Update. Could you please explain more on it .Many thanks

br/
zaman

(Shantel - Networklessons.com) split this topic #22

19 posts were merged into an existing topic: How to advertise networks in BGP

(zain n) #23

HI Rene,
SInce BGP only advertises network which matches in the routing table, why doesn’t it advertise prefixes learnt from other neighbor as its own network to other neighbors .
the show ip route command does show route is being self-originated but the last update still shows that is prefix is being learnt from neighbor
Please advise

(Lazaros Agapides) #24

Hello Sajid.

This is a very good question concerning how BGP and NAT can function together. For BGP to advertise a route, this route must be in the router’s routing table. But if you’re using NAT, then the routes in the router’s routing table will be the internal or private ranges, ranges that you don’t actually want advertised. So how do you get the routable or public IP ranges to be advertised by BGP?

Well, in simple terms, you would have to insert the route to the public IP address space that is being used for NAT translation. If for example, you are translating 10.123.10.50 to the external IP address 147.52.3.15, then you would add a static route on the NAT router that points to a null interface like so:

ip route 147.52.3.15 255.255.255.255 Null0

For this route to be advertised via BGP, you would add the following network command to the appropriate BGP AS:

network 147.52.3.15 mask 255.255.255.255

This IP address will then be advertised via BGP.

If you have a whole range of public IP addresses that are used for NAT, then you can add the whole range of addresses to the above two commands. For example, if you are translating to the external range 147.52.3.0/27, then the respective commands would be:

ip route 147.52.3.0 255.255.255.224 Null0
and
network 147.52.3.0 mask 255.255.255.224

I hope this has been helpful!

Laz

(Lazaros Agapides) #25

Hello Mohammad

BGP does use triggered updates when it learns of a change on its internal domain. However, there are a few things that affect the operation of this triggering that will in turn affect the behaviour of BGP.

Lets say that there is a network on the internal domain that is learned via OSPF, and this network continually goes up and down. BGP updates will be affected by the following:

  1. The detection of the changes - how fast does the router detect that the OSPF route is down? This depends primarily on the BGP scanner process. This process walks the BGP table and confirms reachability of the next hops. The most important issue here is that BGP will do this once a minute.

  2. Propagation of the changes - How fast and often can BGP advertise the changes? By default, BGP waits for the Advertisement Interval to expire before sending any changes. For eBGP, the default is 30 seconds and for iBGP the default is 5 seconds. Even if a change is detected in an OSPF route for example, BGP will not send out any advertisements until this timer expires. The benefit is that updates can be sent more efficiently, solving the problem of stability to a certain degree, but this comes at a cost of convergence time.

If however you have a flapping route on an internal network, BGP will not issue updates at the same frequency thus giving you some stability until the problem can be solved.

I hope this has been helpful!

Laz

1 Like
(Hussein Samir) #26

Hi @ReneMolenaar

Let assume that R1 have three eBGP neighbors ( R2 , R3 , and R4 ) and I need to advertise the network in interface loopback of R1 to only R2.

Is that possible by using network statement with route-map ?? or there is something else to achieve this ??

It’s very helpful for me if you can do that by using network statement with route-map.

(Rene Molenaar) #27

Hello Hussein,

That is no problem. You advertise the network with the network command and then use route-maps to filter what you need.

Here’s R1 advertising to R2:

R1#show ip bgp neighbors 192.168.12.2 advertised-routes 
BGP table version is 4, local router ID is 1.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, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   1.1.1.1/32       0.0.0.0                  0         32768 i

Total number of prefixes 1 

And to R3:

R1#show ip bgp neighbors 192.168.13.3 advertised-routes 
BGP table version is 4, local router ID is 1.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, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   1.1.1.1/32       0.0.0.0                  0         32768 i
 *>   2.2.2.2/32       192.168.12.2             0             0 2 i

Total number of prefixes 2

If you want to filter 1.1.1.1/32 from being advertised to R3, do something like this:

R1(config)#ip prefix-list R1_L0 permit 1.1.1.1/32

R1(config)#route-map TO_R3 deny 10
R1(config-route-map)#match ip address prefix-list R1_L0
R1(config)#route-map TO_R3 permit 20         

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.13.3 route-map TO_R3 out

And it’s gone:

R1#show ip bgp neighbors 192.168.13.3 advertised-routes 
BGP table version is 4, local router ID is 1.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, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   2.2.2.2/32       192.168.12.2             0             0 2 i

Total number of prefixes 1

Hope this helps!

Rene

1 Like