cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
585
Views
0
Helpful
2
Replies

Making data in one service template accessible to another

tcragg1
Cisco Employee
Cisco Employee

Hi,

 

Is there a way to use data entered in one service model in the templates of another model? For example, I have a simple service template for BGP VPN connections, with customers each having multiple VRFs. Some of the configuration data is VRF specific, but some is common to all VRFs for the same customer. Would it be possible to have a service model for the customer level configuration, then reference that in a VRF level service model and template to avoid having to include the customer level variables for every new VRF?

 

In particular, I would need to be able to use data from the customer level service in the VRF level service template (e.g. router sub-interfaces created per VRF need to include the physical interface name defined at the customer level for the config to be valid), rather than having them as separate configuration templates.

2 Replies 2

vleijon
Cisco Employee
Cisco Employee

Yes, that is a common use-case. There are two main options, you can either have a top-level model that you call something like "global-vrf-settings" that you always reference with a static reference to the names, or you can have a separate list with multiple options that you then give a leafref to. The latter is common for things like qos-profiles, where you might want to be able to define qos-profiles and choose one of them for a particular service instance.

 

You can look at  examples.ncs/service-provider/mpls-vpn/packages/l3vpn/src/yang/l3vpn.yang that does seems to do something like that for the qos profiles.

If the models are in separate modules/namespaces, what would I need to do to make data from one model available to another?

 

As an example, if I have a model like the following for BGP:

 

 

module bgp-vrf {
  namespace "http://com/example/bgp-vrf";
    prefix bgp-vrf;

    import ietf-inet-types {
      prefix inet;
    }
    import tailf-ncs {
      prefix ncs;
    }
    import tailf-common {
      prefix tailf;
    }
    import tailf-ned-cisco-ios {
           prefix ios;
    }
    augment /ncs:services {
      list bgp-vrf {
        description "Customer BGP VRF";
        key vrf-name;
        leaf vrf-name {
          tailf:info "VRF-Name";
          type string;
        }
        uses ncs:service-data;
        ncs:servicepoint "bgp-vrf";
        leaf remote-as {
          mandatory true;
          tailf:info "BGP Remote AS of peer";
          type uint32;
        }
        leaf rd {
          mandatory true;
          tailf:info "BGP Route Distinguisher";
          type string {
            pattern '(((\d|[1-9]\d|1\d{2}|2[0-4]\d|25[0-5])\.){3}(\d|[1-9]\d|'
                  + '1\d{2}|2[0-4]\d|25[0-5])):(6553[0-5]|655[0-2]\d|'
                  + '65[0-4]\d{2}|6[0-4]\d{3}|[0-5]?\d{0,3}\d)';
          }
        }
        list router {
          min-elements 1;
          key "hostname";
          leaf hostname {
            tailf:info "Hostname of router";
            type leafref {
              path "/ncs:devices/ncs:device/ncs:name";
            }
          }
          list bgp-peer {
            min-elements 1;
            key "peer-ip";
            leaf peer-ip {
              tailf:info "IP Address of BGP peer";
              type inet:ipv4-address;
            }
            leaf prefix-limit {
              tailf:info "Prefix limit for BGP session";
              type uint16;
            }
            leaf peer-session-template {
              tailf:info "BGP Peer Session Template";
              type leafref {
                path "deref(../../hostname)/../ncs:config/ios:router/ios:bgp/ios:template/ios:peer-session/ios:name";
              }
            }
            leaf peer-policy-template {
              tailf:info "BGP Peer Policy Template";
              type leafref {
                path "deref(../../hostname)/../ncs:config/ios:router/ios:bgp/ios:template/ios:peer-policy/ios:name";
              }
            }
          }
        }
      }
    }
  }

and I have a model like the following for per-region BGP configuration elements:

 

 

 

module bgp-as {
  namespace "http://com/example/bgp-as";
  prefix bgp-as;

  import tailf-ncs {
    prefix ncs;
  }
  augment /ncs:services {
    list bgp-as {
      key region;

      uses ncs:service-data;
      ncs:servicepoint "bgp-as";

      leaf region {
        type string;
      }
      leaf local-as {
        type uint16;
      }
    }
  }
}

If I want to create a region leaf in the bgp-vrf model and have it populate a variable in the bgp-vrf template with the local-as value from the matching region in the bgp-as service, how do I make the data from the bgp-as service available to the bgp-vrf service? I keep getting make errors when I try to add a leafref to bgp-as in the bgp-vrf model.