Solved: BGP route advertisement and received routes issue - Page 3

KevA · ‎12-07-2023

BGP advertised and received routes issue

Can someone explain to me what I am missing my configuration given the issues below? I have attached devices mentioned below as well as others in the AS-PATH as well as the section of topology relevant to my issue.

Objective:
• R7 and R12 are peering (eBGP) with R200 and must only receive a BGP default route from it.
• R7 and R8 must advertise only a BGP default route to their eBGP neighbors. This default route must only be advertised if a default route is already installed on their routing tables.
• R9 should see the default route from it eBGP neighbors R8 and R23 but route is only being received from R8.

ISSUE #1:

On R7, when I run the command

show ip bgp neighbors 10.0.100.1

advertised-routes I get the following output with Total number of prefixes 0. Shouldn't the total number of prefixes be 1 given when I run

show ip bgp

command I can see the prefix in the bgp table?:

R7#sh ip bgp neighbors 10.0.100.1 advertised-routes
BGP table version is 3, local router ID is 10.1.7.7
<Output omitted for brevity>
Originating default network 0.0.0.0

Network Next Hop Metric LocPrf Weight Path

Total number of prefixes 0

However, I can see the prefix exist in the BGP table:

R7#sh ip bgp
BGP table version is 3, local router ID is 10.1.7.7
<Output omitted for brevity>
RPKI validation codes: V valid, I invalid, N Not found

       Network          Next Hop       Metric    LocPrf     Weight     Path
*>   0.0.0.0            10.1.100.1     0                                         65001 i

ISSUE #2:

R9 should be learning this prefix from both its eBGP neighbors but the prefix is being ignored from R23 because it
is already being received from R8. How do I resolve this issue?

R9#sh ip bgp summary
BGP router identifier 10.2.9.9, local AS number 65002
<Output omitted for brevity>
Neighbor          V     AS          MsgRcvd     MsgSent     TblVer    InQ    OutQ   Up/Down      State/PfxRcd
10.1.100.1      4    65001         278            278            4            0       0         04:03:23         1
10.2.10.10      4    65002         44              46              4            0       0         00:37:00         0
172.16.100.9  4     65000          111              117             4               0        0          01:31:57           0

R9#clear ip bgp * soft
*Dec 8 01:23:24.637 EET: BGP: nbr_topo global 10.1.100.1 IPv4 Unicast:base (0xF5AB8BD8:1) refresh_epoch is 3
*Dec 8 01:23:24.640 EET: BGP(0): 10.1.100.1 rcvd UPDATE w/ attr: nexthop 10.1.100.1, origin i, merged path 65001, AS_PATH
*Dec 8 01:23:24.640 EET: BGP(0): 10.1.100.1 rcvd 0.0.0.0/0...duplicate ignored

KevA · ‎12-08-2023

Hello @M02@rt37

For issue 1, my route-map is configured in outbound direction

(neighbor 10.0.100.1 prefix-list DEFAULT out).

Can you explain more what you meant? Not sure if this has anything to do with why R7 show ip bgp neighbors advertised-routes not displaying Total prefixes 1 was advertised to R3.

For issue 2, software version I running show

maximum-path eibgp and not ebgp

. I did try maximum-paths eibgp 2 but did not make any deference. Still seeing 10.1.100.1 rcvd 0.0.0.0/0...duplicate ignored.....

KevA · ‎12-08-2023

Seems files were not attached so will try to attach again.

MHM Cisco World · ‎12-08-2023

When you run the debug ip bgp updates on the receiving router, you see:

BGP(0): 10.1.3.4 rcvd UPDATE w/ attr: nexthop 10.1.3.4, origin i, 
metric 0, merged path 4, AS_PATH
BGP(0): 10.1.3.4 rcvd 10.100.1.1/32...duplicate ignored

The received update is recognized as a duplicate, so it is ignored and no best path change occurs.

Assume you have a router with 100.000 prefixes in the BGP table, and the BGP Table Version increases by 100.000 every minute. This is not expected, and the behavior must be examined. One reason for the behavior could be that the next-hop for the BGP prefixes is flapping for all prefixes every minute.

One of the results when the BGP Table Version increases rapidly is that the process BGP Router and BGP IO are busy, which might cause a constant high router CPU.

it issue of BGP table version, since you do clear ip bgp you get this duplicated ignore in debug.

FOR MORE CHECK BELOW

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/116511-technote-tableversion-00.html

MHM Cisco World · ‎12-11-2023

simple lab show the duplicate error