NETCONF by Example

v0.1.1  (2015-­‐11-­‐05)  
 Overview  and  Objec6ves  
This  presenta6on  uses  a  set  of  common  configura6on  
management  tasks  to  walk  through  the  main  features  of  
the  NETCONF  protocol.  
AIer  this  presenta6on,  you  should  be  able  to:  
•  Obtain  desired  configura6on  aMributes  from  a  device  
using  NETCONF  
•  Configure  a  network  device  using  NETCONF  
•  Understand  NETCONF  transac6ons  
 NETCONF  Layering  Model  
Layer   NETCONF   Example  

Configura6on   No6fica6on   <rpc

Content    
data   data   xmlns="urn:ietf:params:x
 
ml:ns:netconf:base:1.0">

<get>   <edit-config>
Opera6ons  
<get-­‐config>  
<config>
...Content...
</config>
Messages   <rpc>   <no6fica6on>  
</edit-config>

Secure   </rpc>
ssh  
Transport  
 NETCONF  Datastores  

<copy>  
<copy>  
Candidate   Startup  
(:candidate)   Running  
<commit>   (:startup)  

Working  copy  to  manipulate   Complete  and  ac6ve   Configura6on  loaded  by  the  
with  no  impact  on  current   configura6on   device  at  startup  
configura6on  
 Basic  NETCONF  Session  
Capabili6es  Exchange  

<hello>  

Perform  opera6ons  
<rpc>    <rpc-­‐reply>  
...  
client   server  
End  session  
<close-­‐session>/<kill-­‐session>  
 Capabili6es  Exchange  -­‐  Hello  

<?xml version="1.0" encoding="UTF-8"?>

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.1</capability>
</capabilities>
</hello>

<?xml version="1.0" encoding="UTF-8"?>

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
...
</capabilities>
<session-id>5</session-id>
</hello>
 Some  Terminology  
1.  Opera6on:  A  specific  remote  procedure  call,  as  used  within  
the  NETCONF  protocol  
2.  Opera6ons  have  parameters  
3.  Parameters  may  have  aMributes  
1  
<rpc message-id="101” xmlns=”urn:ietf:param
<get>
2   3  
<filter type="subtree">
<top xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces";
<interfaces>
</interfaces>
</top>
</filter>
</get>
</rpc>
 Ge]ng  Data  
How  do  I  get  all  configura6on  and  
opera6onal  data?  
We  will  use:  
•  The  <get>  opera6on  to  get  the  configura6on  and  opera6onal  data  in  a  datastore  
•  The  <get-config>  opera6on  to  get  only  the  configura6on  data  in  a  datastore  
 Example  of  using  the  <get>  opera6on  
Obtaining  All  Data  from  device  
 
<rpc message-id="1"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get/>
<get>  
</rpc>

<rpc-reply message-id="1“
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data> <data>  
<!-- ... entire set of data returned ... -->
</data>
</rpc-reply>
 More  Realis6c  <get>  Response  
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data> <data>  
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
<enabled>true</enabled>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<address>
<ip>2001:db8:c18:1::3</ip>
<prefix-length>128</prefix-length>
</address>
</ipv6>
</interface>
<interface>
<name>eth1</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
<enabled>true</enabled>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<address>
<ip>2001:db8:c18:2::1</ip>
<prefix-length>128</prefix-length>
</address>
</ipv6>
</interface>
</interfaces>
</data>
</rpc-reply>
 Filtering  Data  
How  do  I  filter  to  get  data  for  just  one  
interface  instead  of  all?  
We  will  use:  
•  The  <get>  or  <get-config>  opera6ons  
•  The  <filter>  parameter  to  select  a  par6cular  subtree  in  the  reply  
 Example  of  Filtering  Data  
<rpc message-id="101” xmlns=”urn:ietf:param
<get>
<filter type="subtree">
Return  just  the  interfaces  list   <top xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces";
<interfaces>
</interfaces>
</top>
</filter>
</get>
</rpc>

<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:

1.0">
<get>
<filter xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interfaces>
Return  the  configura6on  data   <interface>
for  just  the  eth0  interface   <name>eth0</name>
</interface>
</interfaces>
</filter>
</get>
</rpc>
 Reply  to  a  filtered  <get>  on  leaf  
<rpc-reply message-id="1"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-
<data>  
type">ianaift:ethernetCsmacd</type>
<enabled>true</enabled>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<address>
<ip>2001:db8:c18:1::3</ip>
<prefix-length>128</prefix-length>
</address>
</ipv6>
</interface>
</interfaces>
</data>
</rpc-reply>
 Manipula6ng  Data  
How  do  I  manipulate  configura6on?  

Example:  Enabling  and  configuring  the  IPv6  address  for  an  interface  
 
We  will  use:  
•  The  <edit-config>  opera6on  to  edit  the  datastore  content  
–  The  <target>  parameter  to  specify  the  datastore,    
•  The  <commit>  opera6on  to  commit  the  candidate  datastore  content  to  the  running  
datastore  
 Using  <edit-­‐config>  
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1”>
<edit-config>
<target> ...Spcecify  the  data  store  to  edit  ...    </target>
<config> ... Provide  the  desired  configura6on  to  write  ...    </config>
</edit-config>
</rpc>
 Example:  Enabling  the  Interface  
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<edit-config>
<target>
<running/>
</target>
<config>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-
type">ianaift:ethernetCsmacd</type>
<enabled>true</enabled>
</interface>
</interfaces>
</config>
</edit-config>
</rpc>
Using  <edit-­‐config>  on  candidate  
<rpc>
•  Requires  :candidate  capability   <delete-config>
<target><candidate/></target>
</delete-config>
</rpc>

<rpc>
Clear  Candidate   <edit-config>
<target>
<candidate/>
</target>
<config>
Edit  Candidate   ...New Configuration...
</config>
</edit-config>
</rpc>

Commit   <rpc>
<commit\>
</rpc>
 Example:  Adding  IPv6  Address  
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<address>
<ip>2001:db8:c18:1::3</ip>
<prefix-length>128</prefix-length>
</address>
</ipv6>
</interface>
</interfaces>
</config>
</edit-config>
</rpc>

...and  then  commit  

 Locking  
I  don’t  want  others  to  change  the  
configura6on  while  I’m  edi6ng  it!  
We  will  use:  
•  The  <lock>  opera6on  to  lock  a  datastore  
•  The  <delete-config>  opera6on  to  clear  the  datastore  
•  The  <edit-config>  opera6on  to  edit  the  datastore  content  
•  The  <commit> opera6on  to  commit  candidate  to  running  
•  The  <unlock>  opera6on  to  lock  a  datastore  
 Locking  the  Running  Datastore    
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="1">
Lock  Datastore   <lock>
<target><running/></target>
</lock>
</rpc>

Clear  Candidate  

Edit  Candidate  

Commit  

Free  Datastore  
 Clear  the  Candidate  Datastore  
Lock  Datastore  
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="3">
<delete-config>
Clear  Candidate   <target>
<candidate/>
</target>
</delete-config>
Edit  Candidate   </rpc>

Commit  

Free  Datastore  
 Edit  the  Candidate  Datastore  
Lock  Datastore  

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
Clear  Candidate   message-id="4">
<edit-config>
<target>
<candidate/>
Edit  Candidate   </target>
<config>
...  Configura3on  data...
</config>
</edit-config>
Commit   </rpc>

Free  Datastore  
Commit  the  Candidate  to  the  Running  
Lock  Datastore  

Clear  Candidate  

Edit  Candidate  

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
Commit   message-id="5">
<commit/>
</rpc>

Free  Datastore  
 Unlock  the  Running  Datastore  
Lock  Datastore  

Clear  Candidate  

Edit  Candidate  

Commit  
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id=“6">
<unlock>
Unlock  Datastore   <target><running/></target>
</unlock>
</rpc>
 Valida6on  and  Rollback  
I  want  to  test  the  configura6on  before  
I  commit  and  cancel  out  if  necessary!  
We  will  use:  
•  The  <validate>  opera6on  to  validate  the  content  of  a  datastore  
•  The  <commit> opera6on  to  commit  candidate  to  running  
–  The  <confirmed> parameter  to  denote  a  confirmed  commit  
–  The  <persist> parameter  to  specify  a  commit  iden6fier  
–  The  <confirm-timeout> parameter  to  specify  a  6meout  before  rollback  
 Valida6on  
...  

Check  for  syntac6cal  and  seman6c  errors.  

Edit  Candidate  
<rpc message-id="5"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
Validate   <candidate/>
</source>
</validate>
</rpc>
Commit  
If  ok  is  received  back  proceed  to  Commit  
Confirming  Commit  
 Confirmed  Commit  
...   •  Requires  :confirmed-­‐commit  capability  
•  Commit  for  10  seconds  then  6meout  
and  revert  if  confirma6on  not  received  
Edit  Candidate  
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="6"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >
<commit>
Validate   <confirmed/>
<confirm-timeout>10</confirm-timeout>
<persist>IQ,d4668</persist>
</commit>
Commit   </rpc>

Confirming  Commit  
 Confirming  Commit  
...  

Edit  Candidate  

Validate  

<?xml version="1.0" encoding="UTF-8"?>

Commit   <rpc message-id="7"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >
<commit>
<persist>IQ,d4668</persist>
Confirming  Commit   </commit>
</rpc>
 Configuring  Mul6ple  Devices  
I  want  to  configure  mul6ple  devices  at  
once  and  rollback  if  anyone  fails  
This  leverages  a  combina6on  of  parallel  sessions  and  confirmed  
commits.  We  will  use  the  same  steps  as  in  the  previous  example,  but  
towards  three  network  devices.  
This  allows  for  two-­‐phase  commit  transac6ons  
 Step  #1:  Prepare      

Lock  Datastore   Lock  Datastore  

Lock  Datastore  

Clear  Candidate   Clear  Candidate  

Clear  Candidate  

Edit  Candidate   Edit  Candidate  

Edit  Candidate  

Validate   Validate  
Validate  
 Step  #1:  Commit  

Commit   Commit  
Commit  

Confirming  Commit   Confirming  Commit  

Confirming  Commit  

Unlock  Datastore   Unlock  Datastore  

Unlock  Datastore  
 Summary  
You  should  now  be  able  to:  
•  Obtain  desired  configura6on  aMributes  from  a  
device  using  NETCONF  
•  Configure  a  network  device  using  NETCONF  
•  Understand  NETCONF  transac6ons  
 
 Back  MaMer  
•  This  material  was  originally  developed  by  Charlie  
Justus  and  Carl  Moberg  with  the  support  of  Cisco  
Systems,  special  thanks  to:  
–  Kevin  Serveau  
 Changelog  
•  1.0  (2015-­‐10-­‐05)  –  Ini6al  version  
Carl  Moberg  <[email protected]>