cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
196
Views
1
Helpful
1
Replies
Highlighted
Enthusiast

Trade-offs of modeling a service per-device versus for the entire network

When deploying network services on my devices where the service is configured identically for each device (for example, list of DNS servers for my devices to use), I can either model my services so that I end up creating an individual service instance for each device, which would get modeled like this:

module dns-service {

   ...

    augment "/ncs:services" {

        list dns  {

            key hostname;

            leaf hostname {

                tailf:info "Single device to apply this DNS profile to";

                type leafref {

                    path "/ncs:devices/ncs:device/ncs:name";

                }

            }

            leaf-list dns-server-ips {

                type inet:ip-address;

            }

        }

    }

}

Or, I can create a single instance and apply it to the whole network (or subsets of devices on the network), like this:

module dns-service {

   ...

    augment "/ncs:services" {

        list dns  {

            key profile-name;

            leaf profile-name {

                tailf:info "Name of this DNS profile";

                type string;

            }

            list devices {

                leaf hostname {

                    tailf:info "All devices to apply this DNS profile to";

                    type leafref {

                        path "/ncs:devices/ncs:device/ncs:name";

                    }

                }

            }

            leaf-list dns-server-ips {

                type inet:ip-address;

            }

        }

    }

}

The second way let's me apply mass changes across the network very easily.  If I want to add a third DNS server into my network, it's a single set and commit on a single service.   If I want to have certain devices on the network have different DNS profiles, I just create another service instance and move those devices from the device list in the old service instance to the device list in the new one.

Is there any downside to this second method over the first?

1 REPLY 1
Highlighted
Cisco Employee

Hi Rob,

In short, I think your second option makes sense, but I think you might want to use commit queues to make it truly effective.

One of the strengths of NSO is the ability to deploy a service in a network-wide transaction, and this way to ensure that all devices are either fully configured with the service or not at all.

This is particularly useful when all devices configured with a service instance are serving one purpose (e.g. VPN), and should either be fully configured or none should be configured at all.

If we assume the case of the DNS server configurations, let's imagine that your service instance includes 1000 devices, and 3 of them are unreachable, then when you commit the service instance, the transaction will fail and none of the devices will be configure for DNS.

In the case of DNS, I think it might make sense to allow the said 997 devices to be configured although 3 devices are unreachable. To allow that, NSO offers a mechanism called Commit Queues, which allows the transaction to finish regardless of the status of the devices. NSO will queue up the device configurations and will try to configure the devices on the queue once the transaction is done (instead of including the device configurations into the transaction).

More details on commit queues can be found on the NSO user guide.

Hope that helps.

Yftach