Routing

 View Only
last person joined: 7 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
Back to discussions
Expand all | Collapse all

bug or feature in BGP hierarchy levels

  • 1.  bug or feature in BGP hierarchy levels

    Posted 30 days ago

    just found that when configuring route-target and inet-vpn families in BGP, only the lower hierarchy level takes effect despite no conflict.

    the route-target is in group level, the inet-vpn is in neighbor level.

    route-target was added after inet-vpn. BGP summary shows the bgp.rtarget.0 table but the router does not even try to peer.

    peering work as soon as route-target was moved down to neighbor level.

    is this normal?



    ------------------------------
    DANIEL NG
    ------------------------------


  • 2.  RE: bug or feature in BGP hierarchy levels

    Posted 30 days ago

    Yes, if you define «family» at the neighbor level, only the families defined there are applied to this neighbor.



    ------------------------------
    Olivier Benghozi
    ------------------------------

    Original Message


  • 3.  RE: bug or feature in BGP hierarchy levels

    Posted 30 days ago

    is this behavior limited to BGP or just address families?

    i don't seem to find an awful lot of documentation describing this behavior.



    ------------------------------
    DANIEL NG
    ------------------------------

    Original Message


  • 4.  RE: bug or feature in BGP hierarchy levels

    Posted 29 days ago

    Not limited, if something (with dependant elements) can be defined at several levels, the smallest level will be the one that will be enforced for this neighbor.

    By example it's the same thing (but properly documented) with «import» or «export»: Applying Routing Policies at Different Levels of the BGP Hierarchy



    ------------------------------
    Olivier Benghozi
    ------------------------------

    Original Message


  • 5.  RE: bug or feature in BGP hierarchy levels

    Posted 28 days ago

    i believe that is only the case with conflicting scopes.

    when there is no conflict, all config from different levels should be applied.

    for example i should be able to have all neighbors in group level using ipv4 family and only some in neighbor level using inet-vpn family.

    i don't remember seeing what i saw elsewhere in junos, only when using route-target and inet-vpn families together in this particular case.



    ------------------------------
    DANIEL NG
    ------------------------------

    Original Message


  • 6.  RE: bug or feature in BGP hierarchy levels

    Posted 28 days ago

    Observable reality: if you configure «family» under both BGP protocol, group, and neighbor: only the families under the neighbor apply to this neighbor.

    Same for «export». Same for «import».



    ------------------------------
    Olivier Benghozi
    ------------------------------

    Original Message


  • 7.  RE: bug or feature in BGP hierarchy levels

    Posted 28 days ago
    Edited by DANIEL NG 28 days ago

    then it is abnormal behavior. can't call what's not supposed to happen a feature however observable it is.

    will anyone from Juniper look into this?

    version is 21.1R3.11



    ------------------------------
    DANIEL NG
    ------------------------------

    Original Message


  • 8.  RE: bug or feature in BGP hierarchy levels

    Posted 28 days ago

    It's exactly what it's supposed to happen.

    Because on a lower level, you can not cancel/avoid a family configured at a higher level (there are no commands for that). Therefore the whole family knob at a lower level supersedes the ones at higher levels.



    ------------------------------
    Olivier Benghozi
    ------------------------------

    Original Message


  • 9.  RE: bug or feature in BGP hierarchy levels

    Posted 28 days ago

    i understand the rationale if the higher level is global where no lower levels can disable the config without a specific command, but in the example of bgp, the neighbors that don't want the inheritance can just be placed in another bgp  group.

    this way they can still enjoy the config inherited from group level.

    moreover, is there a way to quickly tell which type of config always overrides higher level without using 'display inheritance' every time to check?

    or does junos just blanket overrides any higher levels?



    ------------------------------
    DANIEL NG
    ------------------------------

    Original Message


  • 10.  RE: bug or feature in BGP hierarchy levels

    Posted 27 days ago

    «inheritance» is strictly an apply-groups subject.

    This is not the case here.

    Therefore your synthesis about what is applied is shown by looking at the neighbor from operational commands (show bgp neighbor).



    ------------------------------
    Olivier Benghozi
    ------------------------------

    Original Message


  • 11.  RE: bug or feature in BGP hierarchy levels
    Best Answer

    Posted 27 days ago

    This is actually the behavior of BGP configuration from Day 1. I remember this even from Junos 3.x, so I guess it was originally designed that way and never touched.

    BGP has three levels, sorted from highest to the lowest: global, group, neighbor. 

    Anything configured on a lower level will OVERWRITE the statements configured on any higher level. So, for instance, if you have:

    set routing-options autonomous-system 64999
#
set protocols bgp group A peer-as 65111
set protocols bgp group A neighbor 198.51.100.1
set protocols bgp group A neighbor 198.51.100.2 peer-as 65222
set protocols bgp group B neighbor 198.51.100.3
set protocols bgp group B neighbor 198.51.100.4 peer-as 65444
set protocols bgp peer-as 65000
set protocols bgp local-as 65000

      What you will get is:

      198.51.100.1          65111          0          0       0       0           6 Idle
198.51.100.2          65222          0          0       0       0           6 Idle
198.51.100.3          65000          0          0       0       0           6 Active
198.51.100.4          65444          0          0       0       0           6 Idle

      In summary:

      • 198.51.100.1 - uses the peer-as defined within the group, because it has no more specific definition
      • 198.51.100.2 - uses the peer-as defined on the neighbor level
      • 198.51.100.3- uses the peer-as defined within the global level, because it has no peer-pas on the group or neighbor level
      • 198.51.100.4 - uses the peer-as defined on the neighbor level

      It's important to stress that overwriting starts from the topmost level. For instance, if you define another family on the neighbor level, any families defined on the group or global level will be overwritten.

      So, nothing is "inherited" here.



      ------------------------------
      Berislav Todorovic
      ------------------------------

      Original Message


    • 12.  RE: bug or feature in BGP hierarchy levels

      Posted 26 days ago

      very informative.

      is such overwrite unique to BGP or also some other config?



      ------------------------------
      DANIEL NG
      ------------------------------

      Original Message


    • 13.  RE: bug or feature in BGP hierarchy levels

      Posted 26 days ago

      Well, BGP is the sole protocol having the layered structure (global, group, neighbor). IGPs have strict per-domain and per-interface configurations, so you don't mix those two. For instance, ISIS has domain-wide authentication which is separate from interface-wide (hello only).

      Also, partially, the concept of configuration groups - even though it's completely different - has some similarities. Anything defined in a configuration group can be overruled by  more explicit configuration. However, this affects only the "leaf" part of the config, it does not rewrite the whole root of the "configuration tree". However, configuration groups are a part of UI/MGT, while BGP is a part of RPD. Different daemons, different logic.



      ------------------------------
      Berislav Todorovic
      ------------------------------

      Original Message


    • 14.  RE: bug or feature in BGP hierarchy levels

      Posted 24 days ago
      Edited by Olivier Benghozi 24 days ago

      Actually you can find the same kind of layered stuff (for import/export) with some other protocols like rip/ripng (global, group, neighbor).

      About the apply-groups, it's different: apply-groups get merged with the place where they apply, so it's really different from the configs defined in proto/group/neighbor.

      Therefore if you have an «export [ policy1 policy2 ]» somehere, it will be merged with some «export policy3» coming from an applygroup applying to the same level of the config.



      ------------------------------
      Olivier Benghozi
      ------------------------------

      Original Message