Thursday, October 11, 2012

category type to enable RPM traps

If you've configured your Junos real-time performance monitoring probe with the "traps" keyword, either for probe failures, test success, or test completion, it's not enough to generate the traps off the device.

probe TEST-PROBE {
    test TEST {
        probe-type icmp-ping;
        target address 192.168.100.100;
        probe-count 5;
        test-interval 5;
        routing-instance test-instance;
        thresholds {
            successive-loss 5;
        }
        traps probe-failure;
    }
}


Under your trap-group, you also need to make sure you specify "categories remote-operations" or RPM-related traps will not be generated:

trap-group PROBE {
    categories {
        remote-operations;
    }
    targets {
        172.16.150.45;
    }
}




Saturday, September 29, 2012

filtering CDP on Juniper EX switches

A Juniper EX switch connecting two Cisco devices running CDP will forward the CDP messages between those devices. This may result in erroneous %CDP-4-DUPLEX_MISMATCH messages being generated by the Cisco device(s).  Cisco uses the 01:00:0c:cc:cc:cc address as the destination for CDP.  This can be filtered on the EX, either at the port level, or for the VLAN.

First create a firewall filter blocking traffic to this address:

firewall {
    family ethernet-switching {
        filter block-cdp {
            term block-cdp {
                from {
                    destination-mac-address {
                        01:00:0c:cc:cc:cc/48;
                    }
                }
                then {
                    discard;
                    count cdp-count;
                }                      
            }
            term traffic-allow {
                then accept;
            }
        }
    }
}


Then apply to an interface:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family ethernet-switching {
                vlan {
                    members v100;
                }
                filter {
                    output block-cdp;
                }
            }
        }
    }                                  
}


(Apply the filter in the output direction, since this filtering this addressing doesn't work on all EX models as an input filter.)

Or apply to the entire vlan:

vlans {
    v100 {
        vlan-id 100;
        filter {
            input block-cdp;
        }
    }
}     






Or, you could just run LLDP, if vendor lock-in to proprietary protocols isn't really your thing.



Friday, September 21, 2012

updating backup partition on EX

Starting in JUNOS 10.4R3.4, the internal flash on EX switches was partitioned with dual-root slices to make the switch more resilient against root file system corruption, which sometimes occurred during sudden power loss.  It is important to make sure both root slices have the same JUNOS image, to prevent unexpected software from loading in the event the switch fails to boot from the primary slice.  What follows is an example of this.

 Issuing a show version displays the actively running software:

{master:0}
admin@ex4200-02> show version
fpc0:
--------------------------------------------------------------------------
Hostname: ex4200-02
Model: ex4200-24t
JUNOS Base OS boot [11.4R4.4]
JUNOS Base OS Software Suite [11.4R4.4]
JUNOS Kernel Software Suite [11.4R4.4]
JUNOS Crypto Software Suite [11.4R4.4]
JUNOS Online Documentation [11.4R4.4]
JUNOS Enterprise Software Suite [11.4R4.4]
JUNOS Packet Forwarding Engine Enterprise Software Suite [11.4R4.4]
JUNOS Routing Software Suite [11.4R4.4]
JUNOS Web Management [11.4R4.4]
JUNOS FIPS mode utilities [11.4R4.4]


And a show system storage partition shows that the system last booted from s1a:

admin@ex4200-02> show system storage partitions
fpc0:
--------------------------------------------------------------------------
Boot Media: internal (da0)
Active Partition: da0s1a
Backup Partition: da0s2a
Currently booted from: active (da0s1a)

Partitions information:
  Partition  Size   Mountpoint
  s1a        183M   /
  s2a        184M   altroot
  s3d        369M   /var/tmp
  s3e        123M   /var
  s4d        62M    /config
  s4e               unused (backup config)


However the backup partition does not have the same software on it as the active partition:

admin@ex4200-02> show system snapshot media internal
fpc0:
--------------------------------------------------------------------------
Information for snapshot on       internal (/dev/da0s1a) (primary)
Creation date: Jun 28 11:54:59 2012
JUNOS version on snapshot:
  jbase  : ex-11.4R4.4
  jcrypto-ex: 11.4R4.4
  jdocs-ex: 11.4R4.4
  jkernel-ex: 11.4R4.4
  jroute-ex: 11.4R4.4
  jswitch-ex: 11.4R4.4
  jweb-ex: 11.4R4.4
  jpfe-ex42x: 11.4R4.4
Information for snapshot on       internal (/dev/da0s2a) (backup)
Creation date: Jun 22 06:30:39 2011
JUNOS version on snapshot:
  jbase  : 11.2R1.2
  jcrypto-ex: 11.2R1.2
  jdocs-ex: 11.2R1.2
  jkernel-ex: 11.2R1.2
  jroute-ex: 11.2R1.2
  jswitch-ex: 11.2R1.2
  jweb-ex: 11.2R1.2
  jpfe-ex42x: 11.2R1.2


To update the backup partition, use the snapshot command:

{master:0}
admin@ex4200-02> request system snapshot slice alternate
fpc0:
--------------------------------------------------------------------------
Formatting alternate root (/dev/da0s2a)...
Copying '/dev/da0s1a' to '/dev/da0s2a' .. (this may take a few minutes)
The following filesystems were archived: /


And then both slices will have the same software:

{master:0} admin@ex4200-02> show system snapshot media internal fpc0: -------------------------------------------------------------------------- Information for snapshot on       internal (/dev/da0s1a) (primary) Creation date: Jun 28 11:54:59 2012 JUNOS version on snapshot:   jbase  : ex-11.4R4.4   jcrypto-ex: 11.4R4.4   jdocs-ex: 11.4R4.4   jkernel-ex: 11.4R4.4   jroute-ex: 11.4R4.4   jswitch-ex: 11.4R4.4   jweb-ex: 11.4R4.4   jpfe-ex42x: 11.4R4.4 Information for snapshot on       internal (/dev/da0s2a) (backup) Creation date: Sep 21 03:31:14 2012 JUNOS version on snapshot:   jbase  : ex-11.4R4.4   jcrypto-ex: 11.4R4.4   jdocs-ex: 11.4R4.4   jkernel-ex: 11.4R4.4   jroute-ex: 11.4R4.4   jswitch-ex: 11.4R4.4   jweb-ex: 11.4R4.4   jpfe-ex42x: 11.4R4.4



Saturday, September 15, 2012

em0 and em1 interfaces on SRX cluster

Customer asked me this week about em0 and em1 on SRX cluster.  Specifically, he wanted to know what these interfaces are used for, why one of them is down in his configuration, and why they have strange (and seemingly public, non-RFC1918) addressing.

This is from a pair of clustered SRX1400s:

{primary:node0}[edit]
admin@srx1400-node0# run show interfaces terse | match inet
em0.0                   up    up   inet     129.16.0.1/2   
em1.0                   up    up   inet     129.16.0.1/2   
fab0.0                  up    up   inet     30.17.0.200/24 
fab1.0                  up    up   inet     30.18.0.200/24 
fxp0.0                  up    up   inet     192.168.1.150/24
lo0.0                   up    up   inet     192.168.40.3        --> 0/0
lo0.16384               up    up   inet     127.0.0.1           --> 0/0
lo0.16385               up    up   inet   
reth0.0                 up    up   inet     192.168.31.2/24
reth1.0                 up    up   inet     192.168.32.2/24
reth2.0                 up    up   inet     192.168.34.1/24
reth3.0                 up    up   inet     192.168.35.1/24

There's a Juniper KB article that says "Both EM0 and EM1 are internal interfaces that connect between the Routing Engine (RE) and the Control Board (CB).  There is no correlation between EM0/EM1 to any physical interfaces."

The em0 and em1 interfaces correspond to the 2 potential control links between the clustered chassis.  On the SRX1400, ports ge-0/0/10 and ge-0/0/11 on both chassis are dedicated to this function when the chassis are configured into a cluster.  When both sets of ports are cabled together, both control links are up:

{primary:node0}[edit]
admin@srx1400-node0# run show chassis cluster interfaces
Control link status: Up

Control interfaces:
    Index   Interface        Status
    0       em0              Up   
    1       em1              Up   


When the link on ge-0/0/11 is disconnected, em1 goes down:

{primary:node0}[edit]
admin@srx1400-node0# run show chassis cluster interfaces    
Control link status: Up

Control interfaces:
    Index   Interface        Status
    0       em0              Up   
    1       em1              Down  


Control plane redundancy works a little differently on the SRX3K and the SRX5K series, but this is a separate blog post.

As for the strange addressing, it is not unusual on JUNOS platform for the device to use internal-only addressing for intrachassis communication.  These addresses show in the earlier output for the em and fab addressing live inside private, usually-ignored routing instances:

{primary:node0}[edit]
admin@srx1400-node0# run show route private

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

30.18.0.0/24       *[Direct/0] 07:36:24
                    > via fab1.0
30.18.0.200/32     *[Local/0] 11:32:26
                      Local via fab1.0
128.0.0.0/2        *[Direct/0] 11:43:39
                    > via em0.0
                    [Direct/0] 11:43:39
                    > via em1.0
129.16.0.1/32      *[Local/0] 11:43:39
                      Local

__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)


These addresses are not reachable from the global routing table:

{primary:node0}[edit]
admin@srx1400-node0# run ping 129.16.0.1
PING 129.16.0.1 (129.16.0.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- 129.16.0.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss


And are only reachable from inside the private routing-instance:

{primary:node0}[edit]
admin@srx1400-node0# run ping 129.16.0.1 routing-instance __juniper_private1__   
PING 129.16.0.1 (129.16.0.1): 56 data bytes
64 bytes from 129.16.0.1: icmp_seq=0 ttl=64 time=0.197 ms
64 bytes from 129.16.0.1: icmp_seq=1 ttl=64 time=0.120 ms
64 bytes from 129.16.0.1: icmp_seq=2 ttl=64 time=0.119 ms
^C
--- 129.16.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.119/0.145/0.197/0.037 ms


Sunday, August 12, 2012

First Post

This is a new blog where I'm going to post some configuration notes on Juniper and Cisco gear.