Fetching Configuration Subtrees Using Netconf

It took me a bit of struggling to figure out how to pull configuration subtrees via NetConf. Part of this was because I was using tags instead of . But also, I was hitting 256 character line-limits.

I’ll work that out later… the main reason for this post is to document what I found on how to get configuration subtrees. This particular example fetches the subtree for a specific neighbor under [protocols l2circuit].

To structure the rpc request, we use the command “get-config” and specify a source of candidate. Then we add a “filter” tag with an attribute of @type=“subtree” and under that we can specify the configuration subtree as xml tags.

<rpc message-id="1002 Tue Jun 17 23:25:48 -0400 2014">
    <get-config>
        <source><candidate/></source>
        <filter type="subtree">
            <configuration>
                <protocols>
                    <l2circuit>
                        <neighbor>
                            <name>192.168.104.69</name>
                        </neighbor>
                    </l2circuit>
                </protocols>
            </configuration>
        </filter>
    </get-config>
</rpc>
]]>]]>

This is the reply I got.

rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/12.3R4/junos" message-id="1002 Tue Jun 17 23:25:48 -0400 2014">
    <get-config>
        <source><candidate/></source>
        <filter type="subtree">
            <configuration>
                <protocols>
                    <l2circuit>
                        <neighbor>
                            <name>192.168.104.69</name>
                        </neighbor>
                    </l2circuit>
                </protocols>
            </configuration>
        </filter>
    </get-config>
</rpc>
<data>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm" junos:changed-seconds="1402600329" junos:changed-localtime="2014-06-12 19:12:09 UTC">
    <protocols>
        <l2circuit>
            <neighbor>
                <name>192.168.104.69</name>
                <interface>
                    <name>ae0.3909</name>
                    <virtual-circuit-id>55509</virtual-circuit-id>
                </interface>
                <interface>
                    <name>ae0.3933</name>
                    <virtual-circuit-id>55533</virtual-circuit-id>
                </interface>
                <interface>
                    <name>ae0.3959</name>
                    <virtual-circuit-id>55559</virtual-circuit-id>
                </interface>
                <interface>
                    <name>ae0.3983</name>
                    <virtual-circuit-id>55583</virtual-circuit-id>
                </interface>
                <interface>
                    <name>ae0.3991</name>
                    <virtual-circuit-id>55591</virtual-circuit-id>
                </interface>
            </neighbor>
        </l2circuit>
    </protocols>
</configuration>
</data>
</rpc-reply>
]]>]]>

My particular application in this case was that I wanted to get the interface associated with a certain virtual-circuit-id and neighbor. This made it easy to collect what I wanted and to also present the xml for logging.

Data Center Networking @ Facebook by David Swafford

I’ve been looking into data center fabrics and how you handle the scale of large networks lately so I decided I should take some time today to fully view the presentation(video and PDF) by David Swafford which he did at NANOG 59 late last year.

I met David Swafford when Facebook came to town for MPLS 2013. He was a really cool guy. I was inspired even at the time by hearing the way that they are going about support their networks. Very smart!

I took away a lot of nuggets from watching it. Here are a few:

• Assume we can’t trust any rack
• We can’t trust networking boxes either
• Backbone devices are powerful in the wrong ways for a data center. They can handle many routes but don’t have the desired port density.
• Going from 2 large leaf switches to many smaller leaf switches allows you to move from 1+1 to N+1.
• Beware of silent failures by complex networking devices. They are hard to detect, BTW.
• Automating ToR switch upgrades and handing a “push-button” interface to the service owners helped to remove the roadblocks for full upgrades of ToR switches. (I found it analogous to app upgrades on my phone)
• They even scripted many parts of the process, such as determining who the on-call is for a given group at a given time. Fascinating.

Monitor all the things:

• interface statistics and state
• bgp statistics and state
• FIBs
• TCP retransmits

Respond to your Alerts with Automation:

• FBAR stands for Facebook Automation Remediation
• Receive Alert, login to device, verify still down, either ignore or remedy.

He also covers a lot of thoughts on engineers that automate:

• Spend less time doing repetitive tasks
• Spend more time solving interesting problems or learning

His final challenge: What would you do if you weren’t afraid?

3 Fallacies That Prevent Network Engineers From Learning Scripting and Automation

3 Fallacies That Prevent Network Engineers From Learning Scripting and Automation

I don’t have enough time right now…

Life feels full. There are constant demands on your time. Maybe you’d feel overwhelmed if you took on just a little bit more. I understand. We’ve all been there. “I just have to get done with XXX and then things will settle down and then I’ll be able to start this new thing.” But will you really be done with project XXX any time soon? Will things really settle down afterward? And if they do, will you remember that there was this thing that you wanted to start?

If we were more honest, we might admit that there is never a perfect time to start some things: Parenting. Working out. Learn to play guitar. Learning a new language.

I’m willing to bet that in your recent past, you were able to find time for shopping for that new iPad, or Television, or Car. You probably didn’t even need to find the exact “right time” to start any of that… you just started it and it got done.

The irony about learning how to code is that your life would be so much less overwhelming if only you had some tools to make your computers do more of the work for you. You have to make a small commitment to get to the point of not being overwhelmed. This has to be paid upfront and there is never a good time to start. But if you look at that from another perspective, if there is never a good time to start, then you can get started any time… right now even!

I don’t know any languages…

This seems like a big stumbling block. You don’t know how to code. At all!

And let’s face it… coding is about as hard as learning to speak a new language. The comparison is apt. And here are some thoughts to challenge the way you think about both:

1. You have never learned any language by not speaking it.
2. You have never become fluent in any language in a classroom.
3. All languages are only learned by immersing yourself in their use.

And to immerse yourself, you have to embrace discomfort. And you have to do this often enough until it is not awkward. My advice to those who want to start learning a new language is to just start speaking it and let yourself be awkward for the first bit. Wanna learn to code? Just start writing code.

I don’t know how to begin…

If you are being held back by this thought, you are close to starting. Especially if you ask yourself or people around you how to begin. Or, more specifically, “What’s the smallest step I can take today to code?”.

Start small. Your first bit of code doesn’t even have to be useful.

Anticipate frustration and persist a little bit. When you encounter frustration, set a timer for 10 minutes during which time you will perform google searches for similar examples and try to mimic the examples to get things to work for whatever your current small project is. Then reward yourself with a break.

Make it a new habit. Use your new language skills a little each day. Those skills are either in growth or decay. You need to keep them growing.

Don’t overdo it and burn out.

Building Blocks toward Network Device Scripting

Here is a collection of building block steps I have used to get started:

1. Learn a language
2. Script login to a router using SSH
3. Collect “Show Version” using SSH
4. Script a configuration add to a router.
5. Have your script isolate the line containing the version number of the router.
6. Have your script isolate the text of the version number of the router.
7. Use regular expressions to check that the version of the router is some expected value.
8. Write a script to upload/download files to/from the router
9. Learn XML and XPATH
10. Script a login to a router using NetConf over SSH
11. Using NetConf, get the version, config, hardware inventory of a router

I used these steps and assembled an API for TCL/EXPECT which will make steps 1-10 pretty darn easy.