NetworkTalk & BGP

C.2.c) “Show ip bgp neighbor ip-address advertised routes”

1. We know that when a customer advertises its prefixes to an ISP:

a) The customer will allow packets to enter from the ISP (or the internet) to its networks.
We can say that the customer downloads packets from the ISP (and reciprocally we can say that the ISP uploads packets to the customer).

b) By advertising its prefixes, a customer controls its inbound/ingress/download traffic IP-packets.

2. This command helps to check if the traffic engineering has been designed rightly on how the customer wants to download its traffic from the Internet.
Unfortunately, this command will not show us the community number applied to each network; we need to use another command and looking-glass for it.
The input will allow:

a) to see how many prefixes you advertise to your Ebgp speakers. In our case, it should list all the /24 ip blocks and the two aggregated blocks.

b) to see if you advertise your networks, which originate from your as-number and no other routes received from your other Ebgp peers.
In the case, you advertise other routes that are received from your peers (which can happen by accident through a bad setup of the Ibgp session); you are in the risk to provoke BGP black holes, if your neighbor did not put some filter protections.

c) to see if you do not advertise ip blocks higher than /24. It is common to advertise the /30 to /32 blocks, mainly because of the redistributed connect command under the router bgp session.
Even if your ISP filters it, it happens that an ISP tolerates a certain number of received prefixes. This accident can higher the number and so resets or stops the BGP session.

d) To check if your boggon list is applied and working.

4. The information about the next hop indicates, where the packet will be sent, once it comes in the router.

a) The origin of the network indicates also from where the route advertised is learned.

b) In our case, the next-hop 11.11.224.3 shows that packets will be sent to Customer-G’s router directly. The Ibgp next-hop, show that packets will be sent to the Ibgp peer, but also that this network is advertised from the Ibgp peer and not this router originally.

5. In the case of RT-B, the following outputs show that we advertise to ISP-B and ISP-C Ebgp speaker 38 /24 ip blocks which originate from our as-number, and 1 /19 and 1 /20 blocks.
Sadly we cannot see which communities values are applied, for this information you will need to check your config and the looking glass of ISP-B.

Log C-2c-1

Log C-2c-2

The next-hop indication is quite important; in our case, we have four results:

  • 11.11.224.3 which is the router connected directly, managing Zone_G customers ingress traffic.
  • Remember that all network statements are not originated from this router but also from RT-A. For these networks, 11.11.226.27 is the next-hop and Ibgp peer address of RT-A. LocalPref is set up to 90, since we tag all prefixes coming from the Ibgp neighbor to 90. When the traffic comes into RT-A, it is sent to the router 11.11.224.3 which manages in addition the inbound traffic of Zone-G customers.
  • 11.11.226.241 which is the ip address of the router managing the traffic for Zone-B customers.
  • Null0, in order to force the advertisement of the aggregated blocks.

6. Now let’s give a look to the following output which displays what RT-B advertises to its Ibgp neighbor RT-A.

We can note that it broadcasts the full main routing table, including all prefixes of ISP-A originated from this router. This is correctly expected according to our configuration. The route-map sends all routes to the Ibgp peers. This has been discussed previously, if all Ebgp speakers of RT-A are down, customers from RT-A need to upload their traffic though RT-B.

You can notice that for external prefixes, paths are originated with as-number of ISP-B its BGP table is the best by default (localpref100).

Log C-2c-3

7. One last information but not least, concerns for RT-A, the Zone_C customer’s ingress traffic. As told before, ISP-C shares an Ebgp session with ISP-A, and its ingress traffic is going exclusively through ISP-D-Link2 Ebgp speaker. The output below displays clearly that prefixes received from ISP-C, are advertised to ISP-D-Link2 Ebgp speaker. Configuration details about this result can be found above.

Log C-2c-4

top

Come back to Tutorial Index”