7

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.

  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 8 '17 at 14:36
1

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.

| improve this answer | |
  • I think this is a good suggestion, but with this logic every eBGP peer would have this counter increment for every eBGP session that they have, would it not? – John Jensen Oct 3 '13 at 8:42
  • No. If you have two eBGP sessions receiving receiving 100 unique prefixes from each (for a total of 200 unique prefixes), and are originating a single prefix, you would then advertise exactly 101 prefixes to each BGP peer. In your example, you have a single eBGP peer and are originating nothing. Thus, that peer is the best path for all prefixes. Therefore, split-horizon will filter all outbound advertisements back to that peer. – Ryan Oct 3 '13 at 14:24
  • If you can find me official documentation that confirms your assertions, please post an answer and I'll be happy to accept it. – John Jensen Oct 3 '13 at 18:01
  • (Or I'll accept this answer since your answer would essentially be the same as Pradosh's) – John Jensen Oct 3 '13 at 18:21
  • I'll also add one more thing because I realize my comments might be coming off as rude, but it's really only out of my frustration at a lack of understanding of this. At first I thought the no bgp enforce-first-as was to blame but after recreating the scenario that @Ryan describes without that knob turned off - it's certainly left me with more questions than understanding, and a lack of documentation on this behavior is also adding to the frustration. – John Jensen Oct 3 '13 at 22:49
0

I will assume you are running IBGP, you never send a prefix you received via IBGP to an IBGP neighbor, also there would be split horizon (don't send a route back to the person who sent it to you). Since this box only has one neighbor and it is not originating any routes by itself, it will not send any routes, so the policy is implicit, but there.

| improve this answer | |
  • This is actually an eBGP session - should have clarified that in my question - good catch. I'll edit it to clarify. And regarding the iBGP split horizon rule - I'd believe this if the reason wasn't "bestpath from this peer" - the same doc in the link I found shows a separate reason for iBGP split horizon - "* Bestpath from iBGP peer Deploys inbound denials because the bestpath came from an iBGP neighbor." - see groupstudy.com/archives/ccielab/200511/msg00629.html – John Jensen Sep 14 '13 at 4:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.