08-27-2013 01:40 AM - edited 03-04-2019 08:52 PM
Good day!
Friends, faced with strangeness when configuring protocol BGP - one of the boarders, I do not see prefixes that advertises my other Border ... In order ...
There are two boarders are included in the AS78:
Point1 - announcement 10.32.19.0/24, received full-view;
Point2 - announcement 10.32.110.0/24, received the default.
Each of the boarders has two BGP session c:
ISP1, AS70;
ISP2, AS32.
Between Point1 and Point2 not connected via iBGP, all communication must be through the external connections.
On Point1 received full-view:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up / Down State / PfxRcd
10.10.10.1 4 32 2632424 44442 43720971 0 0 4w0d 462061
10.10.20.1 4 70 1701047 36822 43720971 0 0 3w2d 464547
But I do not see in this table prefix 10.32.110.0:
Point1 # sh ip bgp 10.32.110.0/24
% Network not in table
Communicated with specialists ISP, they have successfully received the prefix 10.32.110.0/24 of Point2 and advertised to Point1.
It seems that he Point1, somehow excludes him from the table, the command "# sh ip bgp neighbors 10.10.10.1 received-routes" I do not see that the prefix 10.32.110.0/24 is received from a neighbor.
Maybe this is normal behavior and something needs tweaking to prefixes taken from their neighbors have the same AS, but as long as the documentation did not find anything about this situation. Please tip
The following topology:
Solved! Go to Solution.
08-27-2013 06:04 AM
Hi Yuri,
The reason point1 does not see 10.32.110.0/24 is that this prefix is reject on point1 because of the AS path loop detection. This prefix is originated by AS78 and on reception point1 checks the AS path, sees its own AS in the path and drops it. This is not an issue if point1 have a default route coming from ISP1 and ISP2 in addition to the full view. The other way to fix it is to allow point1 to receive prefixes originated by AS78 using the "allowas-in" command. This command should be used carefully as it disabled the AS path loop detection. It should not be a problem with the right filtering in place.
Regards
08-27-2013 06:04 AM
Hi Yuri,
The reason point1 does not see 10.32.110.0/24 is that this prefix is reject on point1 because of the AS path loop detection. This prefix is originated by AS78 and on reception point1 checks the AS path, sees its own AS in the path and drops it. This is not an issue if point1 have a default route coming from ISP1 and ISP2 in addition to the full view. The other way to fix it is to allow point1 to receive prefixes originated by AS78 using the "allowas-in" command. This command should be used carefully as it disabled the AS path loop detection. It should not be a problem with the right filtering in place.
Regards
08-28-2013 12:36 AM
Harold, thank you, it really works!
But I still have one more question:
I'm going to make an internal joint Point1 and Point2 via iBGP, each of which will only announce their prefixes. Do I need to use in this case "allowas-in"?, Because the path will AS78 AS78
08-28-2013 10:47 AM
Hi Yuri,
The "allowas-in" is not needed for ibgp learned prefixes. The reason is that the local AS is only inserted in the AS path when the update leaves the AS, or in other words, when it is advertised to an ebgp neighbor.
Regards
08-28-2013 11:43 PM
Hello Harold,
I got all the answers. Harold, thank you for the help!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide