cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4740
Views
0
Helpful
7
Replies

BGP, prefixes not present in recevied-routes ?

Jonn cos
Level 4
Level 4

Hi all experts.

I have a simple topology.

[URL=http://img245.imageshack.us/i/bgp.jpg/][IMG]http://img245.imageshack.us/img245/5674/bgp.jpg[/IMG][/URL]

Over here, All  3 routers are peering with each other. R1 is advertising a prefixm 10.1.1.0/24 to R2 and R3. R3 is receieving the same prefix from R2, When i issue show ip bgp neighbor 13.0.0.1 advertised-routes on R3, i can see the prefix 10.1.1.0/24 being advertised back to R1, but on R1 when i issue this command, show ip bgp neighbor 13.0.0.3 received-routes, i dont see any result. kindly note, i have issued soft-reconfig inbound from both neighbors.

Does this mean, that R1 will not at all keep the copy of this prefix, since its totally invalid ? can some one refer me a doc that describes this behaviour ?

2 Accepted Solutions

Accepted Solutions

Using soft reconfiguration inbound merely instructs the router to store ALL the prefixes from a specific neighbor in a separate memory buffer. These prefixes are then handled by inbound prefix filtering before they make their way to Adj-RIB-in and finally to the BGP table. So, soft reconfiguration has nothing to do with your problem.

Hope this made it a bit clearer.

View solution in original post

Reza Sharifi
Hall of Fame
Hall of Fame

Hi Jonn,

In addition to what KFK noted, have a look at this document for more explanation of why routes are being ignored:

Why Routers Ignore Paths

Assume that all paths that a router receives for a particular prefix are arranged in a list. The list is similar to the output of the show ip bgp longer-prefixes command. In this case, some paths are not considered as candidates for the best path. Such paths typically do not have the valid flag in the output of the show ip bgp longer-prefixes command. Routers ignore paths in these circumstances:

  • Paths that are marked as not synchronized in the show ip bgp longer-prefixes output

    If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path. BGP synchronization is enabled by default in Cisco IOS® Software. If the matching route is learned from an Open Shortest Path First (OSPF) neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization with use of the no synchronizationBGP subcommand.

    Note: Synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later.

  • Paths for which the NEXT_HOP is inaccessible

    Be sure that there is an Interior Gateway Protocol (IGP) route to the NEXT_HOP that is associated with the path.

  • Paths from an external BGP (eBGP) neighbor if the local autonomous system (AS) appears in the AS_PATH

    Such paths are denied upon ingress into the router and are not even installed in the BGP Routing Information Base (RIB). The same applies to any path that is denied by a routing policy that is implemented via access, prefix, AS_PATH, or community lists, unless you have configured soft-reconfiguration inbound for the neighbor.

  • If you enabled bgp enforce-first-as and the UPDATE does not contain the AS of the neighbor as the first AS number in the AS_SEQUENCE

    In this case, the router sends a notification and closes the session.

  • Paths that are marked as (received-only) in the show ip bgp longer-prefixes output

    The policy has rejected these paths. However, the router has stored the paths because you have configured soft-reconfiguration inbound for the neighbor that sends the path.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

HTH

Reza

View solution in original post

7 Replies 7

Kostas Kyriakos
Level 1
Level 1

Hello.

R3 may be advertising it but R1 is not accepting it because it sees its own ASN in the AS_PATH. This feature is one of BGP's loop prevention mechanisms.

Hope this helps.

Dear KF,

I thought that using soft-reconfig feature, router keeps the copy of receieved routes. So why its not keeping this route at all ?

Using soft reconfiguration inbound merely instructs the router to store ALL the prefixes from a specific neighbor in a separate memory buffer. These prefixes are then handled by inbound prefix filtering before they make their way to Adj-RIB-in and finally to the BGP table. So, soft reconfiguration has nothing to do with your problem.

Hope this made it a bit clearer.

Hi,

IMHO, the prefix should still be visible via

sh ip bgp nei ...received-routes

when

nei ... soft-reconfiguration in

is configured.

BR,

Milan

Reza Sharifi
Hall of Fame
Hall of Fame

Hi Jonn,

In addition to what KFK noted, have a look at this document for more explanation of why routes are being ignored:

Why Routers Ignore Paths

Assume that all paths that a router receives for a particular prefix are arranged in a list. The list is similar to the output of the show ip bgp longer-prefixes command. In this case, some paths are not considered as candidates for the best path. Such paths typically do not have the valid flag in the output of the show ip bgp longer-prefixes command. Routers ignore paths in these circumstances:

  • Paths that are marked as not synchronized in the show ip bgp longer-prefixes output

    If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path. BGP synchronization is enabled by default in Cisco IOS® Software. If the matching route is learned from an Open Shortest Path First (OSPF) neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization with use of the no synchronizationBGP subcommand.

    Note: Synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later.

  • Paths for which the NEXT_HOP is inaccessible

    Be sure that there is an Interior Gateway Protocol (IGP) route to the NEXT_HOP that is associated with the path.

  • Paths from an external BGP (eBGP) neighbor if the local autonomous system (AS) appears in the AS_PATH

    Such paths are denied upon ingress into the router and are not even installed in the BGP Routing Information Base (RIB). The same applies to any path that is denied by a routing policy that is implemented via access, prefix, AS_PATH, or community lists, unless you have configured soft-reconfiguration inbound for the neighbor.

  • If you enabled bgp enforce-first-as and the UPDATE does not contain the AS of the neighbor as the first AS number in the AS_SEQUENCE

    In this case, the router sends a notification and closes the session.

  • Paths that are marked as (received-only) in the show ip bgp longer-prefixes output

    The policy has rejected these paths. However, the router has stored the paths because you have configured soft-reconfiguration inbound for the neighbor that sends the path.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

HTH

Reza

Try removing the route-map if you have configured any. Could be route-map issue.

milan.kulik
Level 10
Level 10

Hi,

can you provide your show command outputs?

IMHO, if everything is left in default values, from R3 point of view the best path to 10.1.1.0/24 should not be through R2 but directly through R1.

In that case, R3 should NOT advertise the prefix back to R1, as it has received the prefix from R1 originally.

BR,

Milan

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco