JunosV Firefly Perimeter in VirtualBox and Serial Ports

Today I learned:

• OVA files are zip files that contain OVFs, VMDKs, and Manifests
• You can unpack the JunosV Firefly OVA using unzip.
• Edit the OVF to make it compatible with VirtualBox. Look for the string %iid% and replace it with a hard sequence number (for my file it was after 1 and before 3 so I used ‘2’.)
• Then you need to calculate a new SHA1 sum for the OVF and replace the sum in the manifest (.mf) file.

To get the serial port working on Mac OSX:

• Modify Virtual Box to add a serial port
• make it for COM1/IRQ4/0x3F8
  • But change Port Mode to 'Host Pipe’
  • Check “Create Pipe”,
  • and set a filename in the tmp folder such as /tmp/pipe

• To get networking to work, use “Paravirtualized network adapter (virtio-net)” adapters. I was able to get this to work with host-only networking. Additional steps may be required to increase multicast TTL on the host config if you want it to work with Virtualbox NAT networking.

• install socat if you don’t already have it (using homebrew).

  • brew install socat
• then use it to associate the host pipe with a PTY
  • socat -d -d /tmp/pipe PTY
• the logs will include the /dev/ttySXXX path…
  • 2014/08/14 19:40:07 socat[96334] N PTY is /dev/ttys006
• note the /dev/ttySXXX in the output and use screen to connect.

See also: http://tonejito.blogspot.com/2012/05/virtualbox-serial-console-on-mac-os-x.html

“When troubleshooting Junos class-of-service for aggregated interface bundles, always check the memberlinks too.”

— me

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.

JUNOS - How to Configure an MSTP Instance for VPLS

WARNING: THIS CONFIGURATION DOES NOT WORK AND IS NOT SUPPORTED

Update: Looks like this configuration may not work at all… I may update this post when I get more information. In the meantime, reference: http://www.juniper.net/techpubs/en_US/junos12.3/topics/usage-guidelines/vpns-configuring-vpls-and-integrated-routing-and-bridging.html

Given this vpls config

routing-instances VPLS {
    instance-type vpls;
    interface ge-1/1/0.4000;
    interface ge-1/1/1.4000;
    interface ge-1/1/2.4000;
    interface ge-1/1/3.4000;
    vrf-target target:1:1;
    forwarding-options {
        family vpls {
            flood {
                input VPLS-BUM-POLICER;
            }
        }
    }
    protocols {
        vpls {
            site local-site {
                automatic-site-id;
            }
        }
    }
}

interfaces ge-1/1/XXX {
    flexible-vlan-tagging;
    mtu 9188;
    encapsulation flexible-ethernet-services;
    unit 4000 {
        description "VPLS Instance";
        encapsulation vlan-vpls;
        vlan-id-list 4000-4029;
        family vpls;
    }
}

Here is the MSTP Configuration

routing-instances MSTP {
    instance-type layer2-control;
    /* don't configure interfaces at this level */
    protocols {
        mstp {
            /* don't include units on the interface configs */
            interface ge-1/1/0;
            interface ge-1/1/1;
            interface ge-1/1/2;
            interface ge-1/1/3;
            /* put VLANs you're not interested in another msti instance */
            msti 1 {
                vlan [ 1-3999 4030-4094 ];
            }
        }
    }
}

Show commands will need to have the name of the routing instance added

fluong@victor-wooten> show spanning-tree bridge routing-instance MSTP
Feb 28 18:00:26
STP bridge parameters
Routing instance name               : MSTP
Context ID                          : 2
Enabled protocol                    : MSTP

STP bridge parameters for CIST
  Root ID                           : 32768.5c:5e:ab:d2:73:d2
  CIST regional root                : 32768.5c:5e:ab:d2:73:d2
  CIST internal root cost           : 0
  Hello time                        : 2 seconds
  Maximum age                       : 20 seconds
  Forward delay                     : 15 seconds
  Number of topology changes        : 1
  Time since last topology change   : 820 seconds
  Local parameters
    Bridge ID                       : 32768.5c:5e:ab:d2:73:d2

STP bridge parameters for MSTI 1
  MSTI regional root                : 32769.5c:5e:ab:d2:73:d2
  Hello time                        : 2 seconds
  Maximum age                       : 20 seconds
  Forward delay                     : 15 seconds
  Number of topology changes        : 0
  Local parameters
    Bridge ID                       : 32769.5c:5e:ab:d2:73:d2


fluong@victor-wooten> show spanning-tree interface routing-instance MSTP
Feb 28 18:00:55

Spanning tree interface parameters for instance 0

Interface    Port ID    Designated      Designated         Port    State  Role
                         port ID        bridge ID          Cost
ge-1/1/0        128:51       128:51  32768.5c5eabd273d2     20000  FWD    DESG
ge-1/1/1        128:52       128:51  32768.5c5eabd273d2     20000  BLK    BKUP
ge-1/1/2        128:53       128:53  32768.5c5eabd273d2     20000  FWD    DESG
ge-1/1/3        128:54       128:53  32768.5c5eabd273d2     20000  BLK    BKUP 


fluong@victor-wooten> show spanning-tree mstp configuration routing-instance MSTP
Feb 28 18:01:13
MSTP configuration information
Context identifier     : 2
Revision               : 0
Configuration digest   : af:0c:a9:14:79:da:16:86:71:e3:ae:cd:7b:00:d4:63


MSTI     Member VLANs                                                      
   0      0,4000-4029                                                     
   1      1-3999,4030-4094

NetConf: XML Namespaces

I’ve been bashing my head tonight against XML namespaces tonight. It looks like I have to qualify my XPATH statements with the namespace at each level. e.g… (where j is a namespace label mapped to a URI)

“j:chassis-inventory/j:chassis/j:serial-number/text()”

This is unwieldy. I started poking around the Juniper/ncclient github repo because I didn’t remember having to qualify the hell out of everything with Python and I found that there is a proc that does an XSLT to strip namespaces from the RPC reply. There is probably some drawback that I haven’t yet considered. But so far it seems like it will declutter my XPATH statements considerably if I do so.

[juniper-helpers] I will be doing XML Parsing in TCL using tDom

Looks like tDom is going to be my pick for parsing XML outputs gathered by NetConf. I’m trying to figure out how to incorporate this into my Juniper Helpers TCL framework which I am actively developing.

I had been learning a lot of python because I was being silly and convinced that it had a better community than TCL. Now I am not so sure that that’s totally true.

And ultimately it doesn’t matter. I’m having fun and writing something interesting… and that’s what counts!

Exploring NetConf with SSH

I spent a bit of time tonight exploring NetConf using openssh and a notepad. Per RFC 6242, you initiate a NetConf session to router r1 (user ‘lab’) as follows:

ssh lab@r1 -p 830 -s netconf

And a handy reminder for those of you using JUNOS, you can get the XML-RPC equivalent of any command by piping the command to “| display xml rpc”

lab@R1> show chassis hardware detail | display xml rpc

xml <rpc-reply xmlns:junos="http://xml.juniper.net/junos/12.1X46/junos"> <rpc> <get-chassis-inventory> <detail/> </get-chassis-inventory> </rpc> <cli> <banner></banner> </cli> </rpc-reply>