Friday, February 14, 2014

How to summarize external routes learned from another IGP into the OSPF backbone.

For example, if I had an ASBR in Area 0 redistributing 192.168.10.0/24, 192.168.11.0/24, and 192.168.12.0/24  from RIP into OSPF, I only want to advertise the 192.168.8.0/21 into the backbone.

Junos can summarize at the ABR using "area-range" or "nssa area-range" commands, but this is used to summarize an external route from another Area into the backbone, not from an ASBR. 

You can either do the following:

1. move the router into another area. (not practical)

or

1. Create an aggregate/generated route covering the desired routes
2. Instead of importing the IGP routes in the routing policy, import the aggregate/generated route

-----------------------------
user@R3# run show route protocol rip                                               

inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.10.0/24     *[RIP/100] 22:17:43, metric 2, tag 0
                    > to 192.168.0.30 via ge-0/0/3.0
192.168.11.0/24     *[RIP/100] 22:17:43, metric 2, tag 0
                    > to 192.168.0.30 via ge-0/0/3.0
192.168.12.0/24     *[RIP/100] 22:17:43, metric 2, tag 0
                    > to 192.168.0.30 via ge-0/0/3.0
224.0.0.9/32       *[RIP/100] 02:05:02, metric 1
                      MultiRecv

inet6.0: 36 destinations, 39 routes (36 active, 0 holddown, 0 hidden)

[edit]
user@R3# show protocols ospf 
export RIP->OSPF;
area 0.0.0.0 {
    interface ge-2/0/0.0;
    interface ge-2/0/1.0;
    interface lo0.0;
}
area 0.0.0.2 {
    nssa
    interface vlan.100 {
        bfd-liveness-detection {
            minimum-interval 100;
        }
    }
}

jnpr@R3# show routing-options 
aggregate {
    route 192.168.8.0/21;
}

jnpr@R3# show policy-options policy-statement RIP->OSPF 
term AGG {
    from {
        protocol aggregate;
        route-filter 192.168.8.0/21 exact;
    }
    then accept;
}
term LAST {
    then reject;
}




[edit]
user@R3# run show route protocol aggregate detail 

inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)
192.168.8.0/21 (1 entry, 1 announced)
        *Aggregate Preference: 130
                Next hop type: Reject
                Address: 0x1147eec
                Next-hop reference count: 4
                State: <Active Int Ext>
                Age: 2:36:04 
                Task: Aggregate
                Announcement bits (2): 0-KRT 2-OSPF 
                AS path: I (LocalAgg)
                Flags:          Depth: 0 Active
                AS path list:
                AS path: I Refcount: 3
                Contributing Routes (3):
                192.168.10.0/24 proto RIP
                192.168.11.0/24 proto RIP
                192.168.12.0/24 proto RIP

looking at the prefix from another router in area 0

user@R2# run show route 192.168.8/21  

inet.0: 37 destinations, 38 routes (37 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.8.0/21      *[OSPF/150] 02:32:53, metric 0, tag 0
                    > to 192.168.0.22 via ge-1/1/2.0

Looking at the prefix from another router in area 2 (NSSA)

user@R4# run show ospf database nssa    

    OSPF database, Area 0.0.0.2
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
NSSA     0.0.0.0          192.168.255.1     0x80000004  1209  0x20 0xec70  36
NSSA     192.168.8.0       192.168.255.3     0x80000001    16  0x20 0x809e  36
NSSA    *192.168.20.0      192.168.255.7     0x8000001d   360  0x28 0x7d95  36
NSSA    *192.168.21.0      192.168.255.7     0x8000001c  1563  0x28 0x749e  36
NSSA    *192.168.123.252   192.168.255.7     0x8000001c   961  0x28 0x2c83  36

user@R4# run show route 192.168.8/21 

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.8.0/21      *[OSPF/150] 00:02:12, metric 0, tag 0

                    > to 192.168.0.60 via vlan.100

Thursday, February 13, 2014

SDN - Unbundling platforms via Cumulus Networks

I went to a Meetup the other night and saw a presentation by JR Rivers (Co-founder) of Cumulus Networks.

He had an interesting point that most Enterprise networks have hardware that run a single OS. For instance a customer Data Center will run Cisco hardware running Cisco IOS. As it is, the Network Admin is stuck using that vendor and cannot move to another vendor without a forklift upgrade.

Who wants to reconnect links?

JR's proposition is to basically take what's currently going on in the server market and redefine the networking industry.


If you don't like your current vendor's OS, then you can re-image the gear and run the Network OS flavor of your choice.

I can see why Cumulus has taken this approach. In order to disrupt an incumbent, you need a way to remove them from the environment without disrupting the environment.

I can see this working on whitebox gear, but not really much on incumbent gear. A question from the audience was raised, who does the support? JR said that they would support software related issues. But what happens if Cumulus OS is running on top of a Cisco box? Good luck trying to call Cisco. They would automatically void the warranty in a situation like this. The one good thing about having a single vendor environment is that there is support. You know that the vendor will fix their bugs. In this new environment, you're not sure who's going to take responsibility to fix the bug. Also Cumulus is currently only targeting TOR boxes, so this unbundling of platforms will currently only happen in the Data Center.

The value that Cumulus adds is that their OS is Linux. With Linux, DevOps is very familiar with this OS and can program both the APP and the network, hence the SDN part. If Cisco doesn't have a feature in IOS that you need, as a customer you have to ask for a feature request, give your SE a dollar value tied to this feature and then wait x months for the new version to come out. Of course that software upgrade costs money.

As a Demo, JR showed us a BASH script that solved a problem. His point, he created the feature himself. It didn't cost him any money or require him to upgrade his OS.

Now for some vendors like Cisco you could do scripting off box using screen scrapes. But other vendors already have this capability. For instance, Arista has Python built into their OS, so JR's value add doesn't really hold a lot of weight. Juniper has a scripting language called SLAX which is based on XML/XLST.

A problem I see is that the OS is Linux and Security is a big problem. The reason why some vendors don't want to open up a scripting language on their box is because of this very reason. If a hacker is able to take control of your OS, they could create malicious code to do all sorts of things. I wouldn't want to be the Network Admin who has to figure out why their network is all of a sudden DDOSing their own servers and other networks. Which is why Juniper removed Perl from their early implementation of Junos and also why they support SLAX which basically prevents users from messing around with the kernel.

An audience member asked about JR's take on OpenFlow.  He was mostly against this. His response was that there would be lots of problems getting all the vendors to support this. This is an incorrect assumption. Networking vendors always update their OSes to support new protocols. As a vendor, you have to adapt to new things or you die.

I believe JR's reluctance is the threat OpenFlow can create. A SDN controller using OpenFlow can basically take the brains out of a switch. If you have 100 switches, you basically have 100 OSes,  a separate OS running on each switch. With Openflow, you can theoretically control all 100 switches with a single SDN controller and not rely on the underlying OS to do the decision making. Program the whole network, not just each individual switch.

While Cumulus does make an interesting point in unbundling platforms, SDN using a controller that is able to program your whole network is way more interesting.

Wednesday, November 20, 2013

Running shell scripts on Junos

You can run a shell script in Junos.

user@R1> start shell
% su
Password:
root@R1% sh tpl.sh 
root@R1% ls
op1.txt tpl.sh
root@R1% more op1.txt 
set interfaces xe-0/0/0 description to-R4-xe-0/3/0
set interfaces xe-0/0/0 unit 0 family inet mtu 1500

root@R1% 
root@R1% more tpl.sh 
#!/sbin/sh

cli -c 'show configuration interfaces | display set' >> op1.txt
root@R1% 
root@R1% exit
exit
% exit

Saturday, November 9, 2013

Op script to disable a vc-port in a virtual chassis

A customer asked for a script to disable a vcp-port in case there were flapping issues.

There is a cli command that does this

jnpr@EX4200-VC-2> request virtual-chassis vc-port set interface vcp-0 disable member 0 
fpc0:
--------------------------------------------------------------------------

{master:0}
jnpr@EX4200-VC-2> show virtual-chassis vc-port 
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Disabled     32000   <<<<<<<<<<<<<<<< HERE
vcp-1       Dedicated           2    Up           32000        1   vcp-0  

fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        0   vcp-1  
vcp-1       Dedicated           2    Down         32000

jnpr@EX4200-VC-2> request virtual-chassis vc-port set interface vcp-0 member 0           
fpc0:
--------------------------------------------------------------------------

{master:0}
jnpr@EX4200-VC-2> show virtual-chassis vc-port                                    
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        1   vcp-1  <<<<<<<<<<< re-enabled
vcp-1       Dedicated           2    Up           32000        1   vcp-0  

fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        0   vcp-1  
vcp-1       Dedicated           2    Up           32000        0   vcp-0  

----------------------

Demo of the script to disable vc-port

-----------------------

jnpr@EX4200-VC-2# run show virtual-chassis vc-port 
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        1   vcp-1  
vcp-1       Dedicated           2    Up           32000        1   vcp-0  

fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        0   vcp-1  
vcp-1       Dedicated           2    Up           32000        0   vcp-0  

{master:0}[edit]
jnpr@EX4200-VC-2# run op vcp ?
Possible completions:
  <[Enter]>            Execute this command
  <name>               Argument name
  action               0 to enable, 1 to disable
  detail               Display detailed output
  interface            interface name.
  |                    Pipe through a command
{master:0}[edit]
jnpr@EX4200-VC-2# run op vcp interface vcp-0 action 1 

jnpr@EX4200-VC-2# run show virtual-chassis vc-port 
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Disabled     32000
vcp-1       Dedicated           2    Up           32000        1   vcp-0  

fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        0   vcp-1  
vcp-1       Dedicated           2    Down         32000

{master:0}[edit]
jnpr@EX4200-VC-2# run op vcp interface vcp-0 action 0    

{master:0}[edit]
jnpr@EX4200-VC-2# run show virtual-chassis vc-port       
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        1   vcp-1  
vcp-1       Dedicated           2    Up           32000        1   vcp-0  

fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        0   vcp-1  
vcp-1       Dedicated           2    Up           32000        0   vcp-0  


---------------------------- 
Source code
----------------------------

jnpr@EX4200-VC-2# run file show /var/db/scripts/op/vcp.slax 
version 1.0;

ns junos= "http://xml.juniper.net/junos/*/junos";

ns xnm= "http://xml.juniper.net/xnm/1.1/xnm";

ns jcs= "http://xml.juniper.net/junos/commit-scripts/1.0";

import "../import/junos.xsl";

var $arguments = {
    <argument> {
        <name> "interface";
        <description> "interface name.";
    }
    <argument> {
        <name> "action";
        <description> "0 to enable, 1 to disable";
    }
}
param $interface;
param $action =0;

                                        
match /
{
    <event-op-results> {

        if ($action = 1) {
           var $interface-info = <command> "request virtual-chassis vc-port set interface " _ $interface _ " disable member 0";
           var $interface-result = jcs:invoke($interface-info);
        }
        if ($action = 0) {
           var $interface-info = <command> "request virtual-chassis vc-port set
interface " _ $interface _ " member 0";
           var $interface-result = jcs:invoke($interface-info);
        }

    }

}

Thursday, November 7, 2013

FEC 129 - VPLS with BGP auto-discovery using LDP

New version of JUNOS supports FEC 129 BGP auto-discovery.
You don't have to manually configure each pseudo wire. You will use BGP to auto discover the other PEs. no need for a site-ids (rsvp based) or vpls-ids (manual ldp psuedowires). 

Two commands to consider is the l2vpn-id which is similar to the vrf-target. And the auto-discovery-only command in BGP. 

Below will connect to various PEs 

user@router# show routing-instances 
VPLS {
    instance-type vpls;
    interface et-0/1/0.1;
    route-distinguisher 2.2.2.2:852;
    l2vpn-id l2vpn-id:100:1;
    vrf-target target:100:1;
    protocols {
        vpls {
            encapsulation-type ethernet-vlan;
            no-tunnel-services;
        }
    }
}

{master}[edit]
user@router# show protocols bgp 
path-selection external-router-id;
log-updown;
group RR {
    type internal;
    local-address 2.2.2.2;
    family l2vpn {
        auto-discovery-only;
    }
    neighbor 192.168.1.1;
    neighbor 192.168.1.2;
    neighbor 192.168.1.3;
    neighbor 192.168.1.4;
    neighbor 192.168.1.5;
    neighbor 192.168.1.6;               
    neighbor 192.168.1.7;
    neighbor 192.168.1.8;
    neighbor 192.168.1.10;
}

{master}[edit]
user@router# show interfaces et-0/1/0 
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 1 {
    encapsulation vlan-vpls;
    vlan-id 1;
    family vpls;
}


user@router# run show ldp database session 192.168.1.1 
Input label database, 2.2.2.2:0--192.168.1.1:0
  Label     Prefix
     16      FEC129 NoCtrlWord VLAN 000a0064:00000001 c0a80101 02020202

Output label database, 2.2.2.2:0--192.168.1.1:0
  Label     Prefix
      0      2.2.2.2/32
 299920      192.168.1.1/32
 299936      192.168.1.2/32
 299952      192.168.1.3/32
 299968      192.168.1.4/32
 299984      192.168.1.5/32
 300000      192.168.1.6/32
 300016      192.168.1.7/32
 300032      192.168.1.8/32
 300048      192.168.1.9/32
 300064      192.168.1.10/32
 262145      FEC129 NoCtrlWord VLAN 000a0064:00000001 02020202 c0a80101

{master}[edit]
user@router# run show bgp summary 
Groups: 1 Peers: 9 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       0          0          0          0          0          0
inet6.0              
                       0          0          0          0          0          0
bgp.l2vpn.0          
                       9          9          0          0          0          0
inet.2               
                       0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.1.1             852         18         20       0       0        8:07 Establ
  inet.0: 0/0/0/0
  inet6.0: 0/0/0/0
  bgp.l2vpn.0: 1/1/1/0
  inet.2: 0/0/0/0
  VPLS.l2vpn.0: 1/1/1/0

                                        
{master}[edit]
user@router# run show vpls connections 
Layer-2 VPN connections:

Legend for connection status (St)   
EI -- encapsulation invalid      NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch     WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down    NP -- interface hardware not present 
CM -- control-word mismatch      -> -- only outbound connection is up
CN -- circuit not provisioned    <- -- only inbound connection is up
OR -- out of range               Up -- operational
OL -- no outgoing label          Dn -- down                      
LD -- local site signaled down   CF -- call admission control failure      
RD -- remote site signaled down  SC -- local and remote site ID collision
LN -- local site not designated  LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status  IL -- no incoming label
MM -- MTU mismatch               MI -- Mesh-Group ID not available
BK -- Backup connection         ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby SN -- Static Neighbor
LB -- Local site not best-site   RB -- Remote site not best-site
VM -- VLAN ID mismatch

Legend for interface status 
Up -- operational           
Dn -- down

Instance: VPLS
  L2vpn-id: 100:1
  Local-id: 2.2.2.2
    Remote-id                 Type  St     Time last up          # Up trans
    192.168.1.1               rmt   Up     Nov  7 20:58:18 2013           1
      Remote PE: 192.168.1.1, Negotiated control-word: No
      Incoming label: 262145, Outgoing label: 16
      Local interface: lsi.1048841, Status: Up, Encapsulation: VLAN
        Description: Intf - vpls VPLS local-id 2.2.2.2 remote-id 192.168.1.1 neighbor 192.168.1.1

Monday, October 28, 2013

Use a script to customize the snmp utility mib

Example of snmp utility mib via CLI
-----------------------

user@router> request snmp utility-mib set instance test object-type string object-value ABC
Utility mib result: successfully populated utility mib database

user@router> show snmp mib walk jnxUtil
jnxUtilStringValue.116.101.115.116 = ABC

user@router> request snmp utility-mib clear instance test object-type string
Utility mib result: successfully de-populated utility mib database


user@router> show snmp mib walk jnxUtil

------------

Now via script:
jnpr@Chef-RE0> op mib-util value "Hello World"

jnpr@Chef-RE0> show snmp mib walk jnxUtil
jnxUtilStringValue.116.101.115.116 = Hello World

Source Code:
------------







version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
ns ext = "http://xmlsoft.org/XSLT/namespace";

import "../import/junos.xsl";

var $arguments = <argument> {
    <name> "value";
    <description> "object value";
}
param $value;

match / {

        <op-script-results> {



                var $mibset-subs = <request-snmp-utility-mib-set> {

                    <object-type> "string";

                    <instance> "test";

                    <object-value> $value;

                }

                var $result=jcs:invoke($mibset-subs);

                }

}

Friday, October 25, 2013

Are the snmp index values for Mpls Tunnels persistent? And how to decode the index values.

A customer was reporting that the mplsTunnelDown SNMP Trap shows a tunnel index, but that the correlating mplsTunnelUp SNMP Trap shows a different tunnel index. We wanted to know if the indexes were persistent.


It looks like this can possibly happen if mpls has to rebuild the lsps (i.e. due to a crash), but not when there is a link flap.

user@PE-router-RE0# run show snmp mib walk mplsTunnelName.29702 
mplsTunnelName.29702.1.2870018049.2870018050 = router-to-MX-1

[edit]
user@PE-router-RE0# run restart routing 
Routing protocols process signalled but still running, waiting 8 seconds more
Routing protocols process started, pid 1707

[edit]
user@PE-router-RE0# run show snmp mib walk mplsTunnelName     |  Match router
mplsTunnelName.26096.1.2870018049.2870018050 = router-to-MX-1

[edit]
user@PE-router-RE0# run show snmp mib walk mplsTunnelName.29702    

[edit]
user@PE-router-RE0# run show snmp mib walk mplsTunnelName | match router 
mplsTunnelName.26096.1.2870018049.2870018050 = router-to-MX-1

When I flapped a link on the lsp, the tunnel index stayed the same. So something has to happen where rpd has to rebuild the lsps.

The second part is how can you decipher the snmp OID index value.

user@PE-router-RE0> show mpls lsp ingress name router-to-MX-1 
Ingress LSP: 6 sessions
To              From            State Rt P     ActivePath       LSPname
171.17.0.2      171.17.0.1      Up     0 *                      router-to-MX-1
Total 1 displayed, Up 1, Down 0

user@PE-router-RE0> show snmp mib get mplsTunnelName.26096.1.2870018049.2870018050    
mplsTunnelName.26096.1.2870018049.2870018050 = router-to-MX-1


2870018049 as an integer and convert to hex to get 0xAB110001.

Split it into 4 octets:
AB = 171
11 = 17
00 = 0
01 = 1

Which is 171.17.0.1