Bgp – “Local Policy Denied Prefixes” in ‘show ip bgp neighbor’ output

bgpcisco-commandscisco-ios-12

I've been spending the last week or so troubleshooting some (maybe related, but probably not) issues with Quagga. I have a test router – 7204VXR-NPEG2 running 12.4(24)T6 – with a single BGP session to a Quagga host. The only BGP session on the 7204 is with the Quagga box. This is an eBGP session. There is literally zero policy configured on either side, yet I get this without fail in show ip bgp neighbor x.x.x.x output:

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:          19270        n/a
    Total:                            19270          0

Coincidentally (or maybe not?) this number is always the same as the number of prefixes that I am receiving from the peer (show ip bgp summary) There's a couple reasons why this is really puzzling:

1) Like I said, there is no policy. This is my BGP/neighbor config:

router bgp XXXXX
 no synchronization
 bgp router-id X.X.X.X
 no bgp enforce-first-as
 bgp log-neighbor-changes
 neighbor X.X.X.X remote-as XXXXX
 neighbor X.X.X.X next-hop-self
 neighbor X.X.X.X soft-reconfiguration inbound
 no auto-summary

2) The 7204 is not announcing anything – it's only meant to receive prefixes.

Anyone care to shed some light on what this means? Is this normal/expected output? A google search only yielded me one tidbit of information pulled from CCO:

Bestpath from this peer
Displays inbound denials because the bestpath came from the local router.

This would make sense … for inbound. What about outbound? I can easily see this being a stupid bug, but figured I'd reach out to other folks to see if they'd seen this before.

Best Answer

This is most probably because of EBGP split horizon kicking in... i.e. 7204 router receives those prefixes from Quagga, selects best path, and attempts to advertise them. Since the only neighbor is the neighbor the best path was received from, it filters the advertisements. The counter above shows that.

Related Solutions

Routing – After TCP is established which BGP peer will send open message first

which peer will send the open message first?

Normally, the speaker that opens the socket sends the first OPEN message. But it actually doesn't matter (ref the DelayOpen timer), because BGP also provides a way to delay the OPEN message so the opposite peer can send first:

    Option 1:     DelayOpen

    Description: The DelayOpen optional session attribute allows
                 implementations to be configured to delay sending
                 an OPEN message for a specific time period
                 (DelayOpenTime).  The delay allows the remote BGP
                 Peer time to send the first OPEN message.

         Value:       TRUE or FALSE

In the event that both speakers open duplicate TCP sessions and send OPEN messages on each socket simultaneously, the BGP Identifier is used to resolve which socket should be closed. See RFC 4271, Section 6.8:

6.8. BGP Connection Collision Detection

If a pair of BGP speakers try to establish a BGP connection with each other 
simultaneously, then two parallel connections well be formed. If the source IP address 
used by one of these connections is the same as the destination IP address used by the 
other, and the destination IP address used by the first connection is the same as the 
source IP address used by the other, connection collision has occurred. In the event 
of connection collision, one of the connections MUST be closed.

Based on the value of the BGP Identifier, a convention is established for detecting 
which BGP connection is to be preserved when a collision occurs. The convention is to 
compare the BGP Identifiers of the peers involved in the collision and to retain only 
the connection initiated by the BGP speaker with the higher-valued BGP Identifier.

Is there any good BGP Peer fsm diagram?

Wikipedia has this simplified BGP FSM.

Bgp – Why does export/import policy addition/removal cause a BGP session reset

Well, there are 3 ways to update policy (apply a policy to our Adj-RIB-In):

hard reset - cause a full reset of session with a neighbor and apply policies to recieving routes;
soft reset - neighbors should support Route Refresh feature [ https://www.rfc-editor.org/rfc/rfc2918 ]. This feature uses special Refresh message which request to send a full neighbor's Adj-RIB-Out to us. This feature do not interrupt a forwarding plane;
soft reconfiguration - our router always stores full neighbor's Adj-RIB-Out in its Adj-RIB-In, so if we update a policies we don't even sending any request to neighbor and applies in on our Adj-RIB-In. This feature do not interrupt a forwarding plane. This feature enabled by default in Juniper Junos OS and works autimatically when we commit a configuration.

If we consider all of the above it was the soft reset which not interrupt router's forwarding plane or it was if one of neighbors don't supports Route Refresh and "soft reconfiguration" feature is disabled with "keep none" keyword.

Recently i wrote a small article about those features, but in russian language - http://sk1f3r.ru/bgp-softreset

Related Topic