Add peer-address to BGP next-hop-type

[lamehost]

Dear developers,

I suggest to support set next-hop peer-address through your BGP model

As far as i can see it could be achieved by adding PEER under bgp-next-hop-type's enumeration. Here is the suggested syntax:

  typedef bgp-next-hop-type {
    type union {
      type oc-inet:ip-address;
      type enumeration {
        enum SELF {
          description "special designation for local router's own
          address, i.e., next-hop-self";
        }
        enum PEER {
          description "special designation for peer's own
          address, i.e., peer-address";
        }
      }
    }
    description
      "type definition for specifying next-hop in policy actions";
  }

Overriding next-hop to peer-address is recommended when peering over IXP peering LANs. Please check RFC7948 for further details.

Thank you

Regards

[sbarguil]

HI @lamehost do you receive any feedback on this issue?

What do you think to include the next-hop-self option as a boolean in the config and state parameters of the neighbor and peer-group configuration:

config{
 leaf next-hop-self {
      type boolean;
      default false;
      description
        "Enable next hop self";
    }
}

state{ 
leaf next-hop-self {
      type boolean;
      config false;
      default false;
      description
        "Enable next hop self";
    }
}

[robshakir]

Today, this is achieved in OpenConfig through applying a policy that manipulates the next-hop -- i.e., set-next-hop allows you to set the next-hop to SELF. The intention of this implementation was to try and keep a single consistent mechanism for assigning a next-hop.

Since most vendors have this configuration available (e.g., XR, JUNOS) to do this via policy, then translation in the policy model is relatively simple -- however, if you're translating to vendor configuration that has next-hop-self directly specified within the configuration I can see a reason that one might need this modelling. Is this the motivation for having this explicitly modelled?

thanks, r.

[jefftant]

In IETF models we have followed a similar approach:

draft-ietf-idr-bgp-model: typedef bgp-next-hop-type { type union { type inet:ip-address-no-zone; type enumeration { enum self { description "Special designation for local router's own address, i.e., next-hop-self"; } } } description "Type definition for specifying next-hop in policy actions"; }

draft-ietf-rtgwg-policy-model:

+--rw actions +--rw policy-result? policy-result-type +--rw set-metric | +--rw metric-modification? | +--rw metric? uint32 +--rw set-metric-type | +--rw metric-type? identityref +--rw set-route-level | +--rw route-level? identityref +--rw set-preference? uint16 +--rw set-tag? tag-type +--rw set-application-tag? tag-type +--rw bp:bgp-actions +--rw bp:set-route-origin?bt:bgp-origin-attr-type +--rw bp:set-local-pref? uint32 +--rw bp:set-next-hop? bgp-next-hop-type ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Aug 18, 2020, at 3:36 PM, Rob Shakir [email protected] wrote:

Today, this is achieved in OpenConfig through applying a policy that manipulates the next-hop -- i.e., set-next-hop http://ops.openconfig.net/branches/models/master/docs/openconfig-routing-policy.html#routing-policy-policy-definitions-policy-definition-statements-statement-actions-bgp-actions-config-set-next-hop allows you to set the next-hop to SELF http://ops.openconfig.net/branches/models/master/docs/openconfig-routing-policy.html#type-bgp-next-hop-type. The intention of this implementation was to try and keep a single consistent mechanism for assigning a next-hop.

Since most vendors have this configuration available (e.g., XR https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/routing/command/reference/rrasr9kplcy.html#wp1074807, JUNOS https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/policy-configuring-actions-in-routing-policy-terms.html) to do this via policy, then translation in the policy model is relatively simple -- however, if you're translating to vendor configuration that has next-hop-self directly specified within the configuration I can see a reason that one might need this modelling. Is this the motivation for having this explicitly modelled?

thanks, r.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openconfig/public/issues/75#issuecomment-675753538, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSIDQ5TKA7GNBB4AO6RJVLSBL67JANCNFSM4DRYZBQQ.

[lamehost]

Hello everybody,

I am sorry, but there's a misunderstanding as next-hop-self and next-hop-peer-address achieve very different goals. I believe the reason was me and my silly idea to put next-hop-self and next-hop-peer-address together.

With the the former (next-hop-self) the router who's originating the update messages overwrites NEXT_HOP to its own primary IP address. While the latter makes it so the receiving routers do the same, but use the IP address of the peer instead.

As a result next-hop-self is used to override the NEXT_HOP attribute of the prefixes advertised into iBGP. While next-hop-peer-address to protect from what is called BGP NEXT_HOP Hijacking where a peer could send update messages that state that a certain prefix is advertised by another network connected to the same peering LAN.

Should we perhaps, add next-hop-peer-address to the list of bgp-next-hop-types?

typedef bgp-next-hop-type {
     type union {
       type inet:ip-address-no-zone;
       type enumeration {
         enum self {
           description
             "Special designation for local router's own
              address, i.e., next-hop-self";
         }
         enum peer-address {
           description
             "Special designation for remote peer's own
              address, i.e., next-hop-peer-address";
         }
       }
     }
     description
       "Type definition for specifying next-hop in policy actions";
   }

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.