Tag Archives: SRX Series

Configuring IPv4 DHCP Juniper SRX

Reading Time: 1 minute

After configuring a Dual Stacked DHCP server and DHCPv6 on Juniper SRX, it’s only right that I did something on Configuring DCHPv4 on a Juniper SRX.

This wont be a long or detailed post, as the configuration is very much the same as my previous post on how to configure DHCPv6 on a SRX, and I’ve went thought quite a lot before about how DHCP works etc.

First, under the system services dhcp-local-server stanza, you will need to create group and set a physical or logical interface that will have DHCP enabled

[email protected]# show system services dhcp-local-server    
group dhcpv4-group {
    interface vlan.3407;
}

Next, under the access address-assignment stanza, you will need to set the network, the DHCP range and set the IP address that the router will be using within the DCHP pool. The propagate-settings will take configuration from the client DHCP on vlan.3407, if not otherwise specified, most importantly name-server which changes from ISP to ISP and is very important otherwise name resolutions on the LAN won’t work.

[email protected]# show access   
address-assignment {
    pool v4 {
        family inet {
            network 172.31.106.16/29;
            range v4-range {
                low 172.31.106.18;
                high 172.31.106.22;
            }
            dhcp-attributes {
                router {
                    172.31.106.17;
                }
                propagate-settings vlan.3407;
            }
        }
    }
}

This will be all configuration needed to have DHCPv4 on Juniper SRX220. For troubleshooting DHCP you will be able to use the commands below:

[email protected]> show dhcp ? 
Possible completions:
  client               Show DHCP client information
  relay                Show DHCP relay information
  server               Show DHCP server information
  snooping             Show DHCP snooping information
  statistics           Show DHCP service statistics

As I said, this is the quick post :p

I have included the set commands used in my example below:

DHCP Set Commands
set system services dhcp-local-server group dhcpv4-group interface vlan.3407
set access address-assignment pool v4 family inet network 172.31.106.16/29
set access address-assignment pool v4 family inet range v4-range low 172.31.106.18
set access address-assignment pool v4 family inet range v4-range high 172.31.106.22
set access address-assignment pool v4 family inet dhcp-attributes router 172.31.106.17
set access address-assignment pool v4 family inet dhcp-attributes propagate-settings vlan.3407
Share this:
Share

IPv6 and Junos – Stateful Auto-configuration with DHCPv6

Reading Time: 4 minutes

As part of my on-going IPv6 testing, I was asked to look into stateful auto-configuration for devices and host using DHCPv6. I had already looked into Stateless Address Auto configuration and looked into another method of providing stateful auto-configuration using a Dual Stacked DHCP server. This time I’ll be looking into how this could be done using Juniper hardware, to be specific Juniper SRX series routers. If you haven’t used DHCP before my other DHCP related post gave an explanation on what DHCP is and how DHCPv6 communications work slightly different to DHCPv4. With that in mind, I won’t be going over what DHCP is again, but instead I’ll be going straight into the good stuff!

Lets get cracking 😀

For this test I had simple topology; I used a Juniper SRX220 as the DHCP server and a single ESXi Ubuntu 14.04LTS hosts connected on port ge-0/0/0 as the client.

Firstly, with the SRX, I had to enabled IPv6 flow mode. By default, IPv6 IS NOT enabled. You enable IPv6 flow mode by running the command set security forwarding-options family inet6 mode flow-based, once committed you’ll need to reboot the device for the change to take effect. When the SRX is finished booting you can confirm IPv6 flows will be able to be permitted by using show security flow status:

[email protected]> show security flow status 
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: flow based
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
  Flow trace status
    Flow tracing status: off
  Flow session distribution
    Distribution mode: RR-based
  Flow ipsec performance acceleration: off
  Flow packet ordering
    Ordering mode: Hardware

Now that we know we can actually get stateful IPv6 flows traversing the SRX, we can start with enabling the SRX as a DHCPv6 server.

Under the system services dhcp-local-server stanza, we will need to confirm that we’ll be using DHCPv6 and set the interface(s) that will be requesting addresses. Additionally there are a few optional commands. For my example I’ve set the max limit of DHCP clients to 100 by using the interface-client-limit statement, and by default there are no limits on amount of clients that can request an address.

[email protected]# show system services 
dhcp-local-server {
    dhcpv6 {
        overrides {
            interface-client-limit 100;
        }
        group v6 {
            interface vlan.100;
        }
    }
}

Next, under the access address-assignment stanza is where we’ll set the prefix pool that will be advertised to host, and your IP range. In addition, within this stanza you’re able to set other DHCP details such as lease time, grace period and dns-server under dhcp-attributes. The attributes are optional however they should be looked into and configured according to your own requirements.

[email protected]# show access   
address-assignment {
    pool v6 {
        family inet6 {
            prefix 2001:192:168:1::/64;
            range dhcpv6-range {
                low 2001:192:168:1::200/128;
                high 2001:192:168:1::299/128;
            }
            dhcp-attributes {
                maximum-lease-time 120;
                grace-period 3600;
            }
        }
    }
}

We need to set the SRX so that the router advertises our IPv6 prefix on the correct interface, and in addition, by adding the statement managed-configuration, the router will be both stateful (DHCP) and stateless (SLAAC) address assignments. Finally, in order for the DHCPv6 server to allow DHCPv6 requests, a security policy is needed to enable DHCPv6 traffic.

ProtocolsSecurity Zone
[email protected]# show protocols 
router-advertisement {
    interface vlan.100 {
        managed-configuration;
        prefix 2001:192:168:1::/64;
    }
}
[email protected]# show security zone security-zone internal {
    tcp-rst;
    interfaces {
        vlan.100 {
            host-inbound-traffic {
                system-services {
                    dhcpv6;
                }
            }
        }
    }
}

With SRX configured, we can now check the client side to make sure it’s enabled for DHCP. On the client, we have to set its interface to listening for DHCP packets. For IPv6 we’ll need to set the interface to DHCP under /etc/network/interfaces.

[email protected]:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
{...}
auto eth1
iface eth1 inet dhcp

# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

auto eth1
iface eth1 inet6 dhcp

Now that we have both the SRX and the client configured, we can bring it all together and run some tests!

Verification Testing

On the client, we’ll request an IP address from the SRX by running dhclient eth1 -6 -v and can confirm that an address has been successful assigned by doing an ifconfig

Requesting an addressifconfig eth1
[email protected]:~$ sudo dhclient eth1 -6 -v 
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/eth1
Sending on   Socket/eth1
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT:  | X-- Request address 2001:192:168:1::111.
XMT:  | | X-- Request preferred in +7200
XMT:  | | X-- Request valid in     +10800
XMT:  | X-- Request address 2001:192:168:1::200.
XMT:  | | X-- Request preferred in +7200
XMT:  | | X-- Request valid in     +10800
XMT: Solicit on eth1, interval 1060ms.
RCV: Advertise message on eth1 from fe80::120e:7eff:fe4e:2e88.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1452250973
RCV:  | X-- t1 - renew  +60
RCV:  | X-- t2 - rebind +96
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::200
RCV:  | | | X-- Preferred lifetime 120.
RCV:  | | | X-- Max lifetime 120.
RCV:  X-- Server ID: 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38
RCV:  Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC:  X-- Initial candidate 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32 (s: 153, p: 0).
XMT: Forming Request, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAADDR 2001:192:168:1::200
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Request on eth1, interval 930ms.
RCV: Reply message on eth1 from fe80::120e:7eff:fe4e:2e88.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1452250974
RCV:  | X-- t1 - renew  +60
RCV:  | X-- t2 - rebind +96
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::200
RCV:  | | | X-- Preferred lifetime 120.
RCV:  | | | X-- Max lifetime 120.
RCV:  X-- Server ID: 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38
PRC: Bound to lease 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38:31.
[email protected]:~$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link
          inet6 addr: 2001:192:168:1::200/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12342 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11980 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4052626 (4.0 MB)  TX bytes:3303461 (3.3 MB)

Having confirmed that an IP address from DHCP pool has been assigned on the client, we can now look on SRX to see what has happened there!

Firstly, I checked to see if I could see the session flow from the client to SRX by running show security flow session. As the output below shows, as per RFC3315, DHCPv6 communications are done on UDP ports 546 (clients) and 547 (server/relay) and via link-local addresses.

[email protected]> show security flow session       
Session ID: 1, Policy name: self-traffic-policy/1, Timeout: 1800, Valid
  In: 10.1.0.17/46789 --> 10.1.0.158/22;tcp, If: ge-0/0/7.0, Pkts: 5631, Bytes: 416401
  Out: 10.1.0.158/22 --> 10.1.0.17/46789;tcp, If: .local..0, Pkts: 3109, Bytes: 389005

Session ID: 9, Policy name: self-traffic-policy/1, Timeout: 54, Valid
  In: fe80::120e:7eff:fe4e:2e88/547 --> fe80::20c:29ff:fe4f:26c5/546;udp, If: .local..0, Pkts: 2, Bytes: 288
  Out: fe80::20c:29ff:fe4f:26c5/546 --> fe80::120e:7eff:fe4e:2e88/547;udp, If: vlan.100, Pkts: 0, Bytes: 0
Total sessions: 2

We only get two show commands with a DHCP server, whether it’s v4 or v6, show dhcpv6 server binding and show dhcpv6 server statistics.

  • show dhcpv6 server binding provides details on the address that has been assigned to a client, which including; MAC address, Prefix, Lease time, current state and interface.
  • show dhcpv6 server statistics, as the name suggests, provides figures on sent and receive messages between the server and clients.
DHCPv6 BindingsDHCPv6 Statistics
[email protected]> show dhcpv6 server binding        
Prefix                  Session Id  Expires  State    Interface    Client DUID
2001:192:168:1::200/128 2           74       BOUND    vlan.100     LL_TIME0x1-0x1ddd0462-00:0c:29:4f:26:c5
[email protected]> show dhcpv6 server statistics 
Dhcpv6 Packets dropped:
    Total               0

Messages received:
    DHCPV6_DECLINE             0
    DHCPV6_SOLICIT             1
    DHCPV6_INFORMATION_REQUEST 0
    DHCPV6_RELEASE             0
    DHCPV6_REQUEST             1
    DHCPV6_CONFIRM             0
    DHCPV6_RENEW               0
    DHCPV6_REBIND              0
    DHCPV6_RELAY_FORW          0
    DHCPV6_RELAY_REPL          0

Messages sent:
    DHCPV6_ADVERTISE           1
    DHCPV6_REPLY               1
    DHCPV6_RECONFIGURE         0
    DHCPV6_RELAY_REPL          0

For completeness, I had the client release the assigned address to check the statistics, just to make sure I did see an increment change.

Releasing Assigned AddressDHCPv6 Statistics
[email protected]:~$ sudo dhclient -6 -v -r eth1
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/eth1
Sending on   Socket/eth1
XMT: Forming Release, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Release Address 2001:192:168:1::200
XMT:  V IA_NA appended.
XMT: Release on eth1, interval 1070ms.
RCV: Reply message on eth1 from fe80::120e:7eff:fe4e:2e88.
RCV:  X-- Server ID: 00:02:00:00:05:83:43:46:34:37:31:33:41:4b:30:32:38
[email protected]> show dhcpv6 server statistics    
Dhcpv6 Packets dropped:
    Total               0

Messages received:
    DHCPV6_DECLINE             0
    DHCPV6_SOLICIT             1
    DHCPV6_INFORMATION_REQUEST 0
    DHCPV6_RELEASE             1
    DHCPV6_REQUEST             1
    DHCPV6_CONFIRM             0
    DHCPV6_RENEW               1
    DHCPV6_REBIND              0
    DHCPV6_RELAY_FORW          0
    DHCPV6_RELAY_REPL          0

Messages sent:
    DHCPV6_ADVERTISE           1
    DHCPV6_REPLY               3
    DHCPV6_RECONFIGURE         0
    DHCPV6_RELAY_REPL          0

And with that a DHCPv6 Server has been configured using a Juniper SRX series router!

I’ve included a useful show command and the set commands that I used in my example below 🙂

Operational CommandsSet Commands
show security flow session
show dhcpv6 server binding
show dhcpv6 server statistics
clear dhcpv6 server binding
clear dhcpv6 server statistics
set security forwarding-options family inet6 mode flow-based

set system services dhcp-local-server dhcpv6 overrides interface-client-limit 200
set system services dhcp-local-server dhcpv6 group v6 interface vlan.100

set protocols router-advertisement interface vlan.100 prefix 2001:192:168:1::/64

set access address-assignment pool v6 family inet6 prefix 2001:192:168:1::/64
set access address-assignment pool v6 family inet6 range dhcpv6-range low 2001:192:168:1::200/128
set access address-assignment pool v6 family inet6 range dhcpv6-range high 2001:192:168:1::299/128
set access address-assignment pool v6 family inet6 dhcp-attributes maximum-lease-time 120
set access address-assignment pool v6 family inet6 dhcp-attributes grace-period 3600

set security zones security-zone internal interfaces vlan.100 host-inbound-traffic system-services dhcpv6

More in-depth detailed information can be found on Juniper’s TechLibrary pages

Share this:
Share

Leaking Routes into a Routing-Instance

Reading Time: 4 minutes

In a previous post I wrote about how I went about configuring a NTP server and setting NTP clients. A few days later, when speaking with my senior, the plan changed slightly and we weren’t configuring our own NTP server using Linux based OS, but get satellite feeds running our own LANTIME Stratum 1 Server o_O! In other words that previous post is now invalid haha!

For now I don’t know if I’ll be involved in that side of the project, I hope I am, but that’s for another day! Back to my actual point, because of the environment we run in our datacentres, our firewalls run with Virtual-Router Routing-Instances. A Virtual Router is similar than Cisco’s VRF concept however, with Juniper’s a Virtual Router is used for non-VPN related applications. So, I was asked to investigate if it was possible for our firewalls to be NTP clients to a NTP server via the master instance and also be able to act as a NTP server to attached clients within a routing-instance.

Note
You can get more detail about Juniper’s Routing-Instance Types on their TechLibrary Routing Instances Overview

Although it sounds a bit of a mouthful, the topology itself is quite straightforward. The diagram below shows the topology I’ll be testing with:

Routing

As the diagram shows, I’ll be using a standalone Juniper SRX220h and two ESXi Ubuntu 14.04LTS servers. The SRX will be a NTP client of the NTP server (km-vm4) via the master inet.0 table. The second client km-vm1 will be located within the Routing-Instance “test” and will be using the SRX220 as its NTP server. Security policies will need to be defined, as the stateful functionalities of the SRX will still be in use. Without creating security between the zones all traffic will be dropped.

Note
The Base configuration used in this topology is below. (I using this SRX for IPv6 testing as well, so ignore the vlan name lol)
Base Config
set interfaces ge-0/0/0 enable
set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members internal-v6
set interfaces ge-0/0/1 enable
set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members ntp-server
set interfaces vlan unit 100 family inet address 192.168.1.1/24
set interfaces vlan unit 101 family inet address 192.168.2.1/24

set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp match source-address any
set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp match destination-address any
set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp match application junos-ntp
set security policies from-zone vlan100 to-zone vlan101 policy allow-ntp then permit

set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp match source-address any
set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp match destination-address any
set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp match application junos-ntp
set security policies from-zone vlan101 to-zone vlan100 policy allow-ntp then permit

set security zones security-zone vlan100 interfaces vlan.100 host-inbound-traffic system-services any-service
set security zones security-zone vlan101 interfaces vlan.101 host-inbound-traffic system-services any-service

set routing-instances test instance-type virtual-router
set routing-instances test interface vlan.100

set vlans internal-v6 vlan-id 100
set vlans internal-v6 l3-interface vlan.100
set vlans ntp-server vlan-id 101
set vlans ntp-server l3-interface vlan.101

With this setup, the overall goal of this testing is to see if it’s possible to advertise specific routes from the inet.0 table to another routing table, to allow end to end connectivity between routing instances.

This post will not show/explain how the stateful functionalities of the SRX series firewall works. That will be in another post :p

With all that talk and background out of the way… Let’s get cracking 🙂

With the NTP server already configured, the SRX need to set as an NTP client. This configuration is done under system ntp stanza. We set the remote server, ntp version and preference. In addition, I set two other statements; one is optional and the other had to be set. The statements, boot-server and source-address, Juniper defines these statements as:

  • boot-server: When the router or switch boots, it immediately synchronizes with the boot server even if the NTP process is explicitly disabled or if the time difference between the client and the boot server exceeds the threshold value of 1000 seconds.
  • source-address: This is statement useful for controlling which source address NTP will use to access your network when it is either responding to an NTP client request from your network or when it itself is sending NTP requests to your network.

As described above, and in a nutshell, by adding the source-address this will allow other clients/devices to set an IP address that’s located on the SRX as their remote NTP server. Thus providing a /32 address that can be advertised. For my example the address 192.168.2.1, the gateway address for the ntp server, will be the address used as the source address.

[email protected]# show system ntp 
boot-server 192.168.2.100;
server 192.168.2.100 version 4 prefer;
source-address 192.168.2.1;

We can verify the NTP association by using the command show ntp assocication.

[email protected]# run show ntp associations                      
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.2.100   43.255.190.16    3 -  148  256  377    2.313    0.748   0.063

With NTP verified on the SRX, we have to leak the NTP source address for the SRX 192.168.2.1 from the inet.0 table to the test.inet.0 table. As we can see, when we look at the routing instance’s routing table, we don’t have the route installed into the table:

[email protected]# run show route table test.inet.0      

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

192.168.1.0/24     *[Direct/0] 04:02:28
                    > via vlan.100
192.168.1.1/32     *[Local/0] 06:31:31
                      Local via vlan.100

To get the route installed into the test.inet.0 table, we’ll need to leak the 192.168.2.1/32 route into the test.inet.0 table, and we’ll do this by creating two policy statements. For my example I’ve named them master and instance just for ease!

  • Master: This statement allows all routes from routing instance test to be accepted into the master routing table.
  • Instance: This statement has two terms. Term 1 only allows the exact route 192.168.2.1/32 from the master instance to be accepted. Term 2 denies all other routes from master instance.
[email protected]# show policy-options 
policy-statement master {
    from instance test;
    then accept;
}
policy-statement instance {
    term 1 {
        from {
            instance master;
            route-filter 192.168.2.1/32 exact;
        }
        then accept;
    }
    term 2 {
        then reject;
    }
}

Now we’ll need to import the relevant policy into each instance, under the routing-options stanza for the inet.0 table and routing-instance test routing-options for the test.inet.0 table.

Master Instance Routing-OptionsRouting-Instance Routing-Options
[email protected]# show routing-options 
static {
    route 0.0.0.0/0 {
        next-hop 10.1.0.1;
        no-readvertise;
    }
}
instance-import master;
[email protected]# show routing-instances test routing-options 
instance-import instance;

Having committed the policy statements, when we check both routing tables we can see the 192.168.1.0/24 route have been leaked into the inet.0 table, and that only the 192.168.2.1/32 route has been installed into the test.inet.0 table. All other routes have not been leaked.

inet.0 tabletest.inet.0 table
[email protected]> show route table inet.0 

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


0.0.0.0/0          *[Static/5] 1w2d 09:40:34
                    > to 10.1.0.1 via ge-0/0/7.0
10.1.0.0/24        *[Direct/0] 1w2d 09:40:34
                    > via ge-0/0/7.0
10.1.0.158/32      *[Local/0] 1w2d 09:40:39
                      Local via ge-0/0/7.0
192.168.1.0/24     *[Direct/0] 2d 04:15:32
                    > via vlan.100
192.168.1.1/32     *[Local/0] 2d 04:15:32
                      Local via vlan.100
192.168.2.0/24     *[Direct/0] 2d 07:20:32
                    > via vlan.101
192.168.2.1/32     *[Local/0] 3d 08:44:24
                      Local via vlan.101
[email protected]> show route table test.inet.0   

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

192.168.1.0/24     *[Direct/0] 09:32:22
                    > via vlan.100
192.168.1.1/32     *[Local/0] 12:01:25
                      Local via vlan.100
192.168.2.1/32     *[Local/0] 05:28:32
                      Local via vlan.101

Finally, on the client we’ll need to set a static route so that the host knows if it wants to get the 192.168.2.0/24 subnet it will need to use the gateway 192.168.1.1 via eth1

[email protected]:~$ sudo route add -net 192.168.2.0/24 gw 192.168.1.1 dev eth1
[email protected]-vm1:~$ ip route
default via 10.1.0.1 dev eth0 
10.1.0.0/24 dev eth0  proto kernel  scope link  src 10.1.0.137 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.100 
192.168.2.0/24 via 192.168.1.1 dev eth1

Once that route has been installed we can see that the host has now become a NTP client to the SRX by running the command ntpq -p. In addition on the SRX, we can see the flow session between inet.0 and test.inet.0 routing tables.

NTP AssociationSRX flow Session
[email protected]:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.2.1     192.168.2.100    4 u   15   64    3    2.086   -0.094   0.109
[email protected]> show security flow session destination-prefix 192.168.2.1 
Session ID: 21218, Policy name: allow-ntp/4, Timeout: 40, Valid
  In: 192.168.1.100/123 --> 192.168.2.1/123;udp, If: vlan.100, Pkts: 7, Bytes: 532
  Out: 192.168.2.1/123 --> 192.168.1.100/123;udp, If: .local..5, Pkts: 7, Bytes: 532
Total sessions: 1

And with that we’ve been able to route between routing instances! The most important thing that I found whilst do this testing is that you need to remember to add the static route on the host or device that is directly connected to router with the routing-instance. This same setup would work with a switch in between the SRX and end host, just have the static route and you’ll be sorted. In addition to having the right security policies, as they’ll bite you in the bum as well :p

I’ve included the set commands that I used in my example below, if you wanted to give it a try for yourself 🙂

Set Commands
set system ntp boot-server 192.168.2.100
set system ntp server 192.168.2.100 version 4
set system ntp server 192.168.2.100 prefer
set system ntp source-address 192.168.2.1

set routing-options instance-import p1

set policy-options policy-statement p1 from instance test
set policy-options policy-statement p1 then accept

set policy-options policy-statement p2 term 1 from instance master
set policy-options policy-statement p2 term 1 from route-filter 192.168.2.1/32 exact
set policy-options policy-statement p2 term 1 then accept
set policy-options policy-statement p2 term 2 then reject

set routing-instances test routing-options instance-import p2

Reference

Juniper Knowledge Base: NTP over routing-instance on EX-series switches
Juniper TechLibrary: NTP Configuring

Share this:
Share

SNMP Polling over a Routing Instance

Reading Time: 3 minutes

Polling SNMP over a Routing Instance is quite straightforward once you understand the syntax necessary to specify that you want to poll the routing-instance. But when I tried this the first time, I didn’t have a clue why it didn’t work!

For a bit of background, we had a request from another team who’s network we manage, asking if they could SNMP details so they could poll an edge pair of SRX240’s. We use a routing instance to keep the management traffic separate from production traffic, so configured a SMNPv2 community and asked them to test it, but and they said it wasn’t working… BALLS :S

I set this up in the lab for testing; I used a Juniper SRX220 with Routing-Instance that had a Ubuntu 14.04LTS host directly connected to poll SNMP

I had configured SNMPv2 and enabled it to allow the relevant routing-instance to have access under the community stanza and enabled routing instance access under the overall stanza as well, thinking that this would be enough:

[edit]
[email protected]# show snmp 
community test {
    authorization read-only;
    routing-instance test {
        clients {
            192.168.1.0/24;
        }
    }
}
routing-instance-access;

However, when I did a snmpwalk….. I got nothing :/

[email protected]:~$ snmpwalk -v2c -ctest 192.168.1.1
^C

Not Good 🙁

I messed about with the configuration and asked a few colleagues and a senior, but none of them could see the issue. So, as you do when you don’t have a clue…. Time to Google! From my searches managed to find Juniper KB page that explained the different variations of syntax when polling SNMPv1/v2c with Routing Instances

There are 3 variations:

  • community string – which works if the user polls directly from inet.0
  • [email protected] string – which polls information for specific routing instance
  • [email protected] string – which allows polling information about inet.0 only

In essence when I was tried to SNMP poll the SRX with the syntax snmpwalk -v2c -ctest 192.168.1.1, it wasn’t referencing the routing instance because snmpwalk was trying to poll the master instance, which routing-instance had no access to.

For the syntax, I should have been using was snmpwalk -v2c [email protected] 192.168.1.1. By referencing the routing instance I was able to SNMP poll the SRX and all the interfaces that were within the routing-instance:

[email protected]:~$ snmpwalk -v2c [email protected] 192.168.1.1
\iso.3.6.1.2.1.1.1.0 = STRING: "Juniper Networks, Inc. srx220h2 internet router, kernel JUNOS 12.1X47-D30.4 #0: 2015-11-13 14:16:02 UTC     [email protected]:/volume/build/junos/12.1/service/12.1X47-D30.4/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel Build date: 2015-11-13 15:4"

SNMPv3 Polling

For SNMPv3 when configuring your user, under snmp v3 access group stanza, the context-prefix HAS to be the same name as the Routing-Instance

[email protected]# show snmp 
v3 {
    usm {
        local-engine {
            user keeran {
                authentication-sha {
                    authentication-key "$9$WS8LdbYgojk.aJDkqmF3Ap01cyevWXNdleZUDjq.hSyKLx-VwoaUbwgJGU.m1RESrvXxdsYohSvLxNY2z3n/p0REylvW1IxN-VY2JGDk5Q/Ct01RUjqfzFAt8XxdYgDikf5FGU69CA0OLx7NdsUjHTFniHmTznCA8Xx7s2aJDmPQjiCt0ORE-VbsYo"; ## SECRET-DATA
                }
                privacy-des {
                    privacy-key "$9$qmz3/CtIhSpu1hcyW8-Vw2JGjHqPTzDj0B1IcSaZGimfQFntpB3nCuOBSy24oZUHPfz6/taZHmfT/9M8LxVw4oGDHq2gfTQF/9uO1hevxNdw24BIclMW-d.Pfz/C1RhleWOBX7N-wsmf5Tz6BIEKWLREyKMLN-.Pf569pu1yrvIRNdws4oQF36/t"; ## SECRET-DATA
                }
            }
        }
    }
    vacm {
        security-to-group {
            security-model usm {
                security-name keeran {
                    group view-all;
                }
            }
        }
        access {                        
            group view-all {
                context-prefix test {
                    security-model usm {
                        security-level privacy {
                            read-view view-all;
                            notify-view view-all;
                        }
                    }
                }
            }
        }
    }
}
view view-all {
    oid .1 include;
}
routing-instance-access;

Then when you run the snmpwalk you’ll need to add the flag -n to specify the context name, which will be the routing-instance. If you’ve used the same authentication and privacy types as me, your syntax should look something like this: snmpwalk -v 3 -u keeran -l authPriv -a SHA -A test1234 -x DES -X test1234 -n test 192.168.1.1

snmpwalk -v 3 -u keeran -l authPriv -a SHA -A test1234 -x DES -X test1234 -n test 192.168.1.1
iso.3.6.1.2.1.1.1.0 = STRING: "Juniper Networks, Inc. srx220h2 internet router, kernel JUNOS 12.1X47-D30.4 #0: 2015-11-13 14:16:02 UTC     [email protected]:/volume/build/junos/12.1/service/12.1X47-D30.4/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel Build date: 2015-11-13 15:4"

This was pretty frustrating as there was no clear reason why it wasn’t working, and something that should have taken a few moments took days! So I’m hoping this will help you so that you don’t end up in a bit of a rage like I was lol

References

Juniper Knowledge Base: SNMP Polling SNMPv1/v2c via Routing Instance
Juniper Knowledge: SNMP Polling SNMPv3 via Routing Instance
Snmpwalk Man Page
snmpwalk -h

Share this:
Share

Clearing IDLE TTY Sessions in Junos

Reading Time: 2 minutes

This is going to be a quick post on how you can forcibly disconnect idle and/or other users by using their PID or TTY session.

This is very useful, when you have too many simultaneous concurrent connections (normally when you having some issue) or because of some dodgy connections you get from time to time, and your terminal gets timed out in the middle of configuring and you have to reconnect. To be then greeted with:

[[email protected] ~]$ ssh 10.1.0.243
Password:
--- JUNOS 14.1X53-D25.2 built 2015-04-01 01:53:36 UTC
{master:0}
[email protected]> edit 
Entering configuration mode
Users currently editing the configuration:
  marquk01 terminal p0 (pid 41263) on since 2015-05-04 11:22:50 UTC, idle 02:01:13
      {master:0}[edit firewall]
  marquk01 terminal p1 (pid 41306) on since 2015-05-04 12:02:30 UTC, idle 01:16:58
      {master:0}[edit]

If you’re like me and find this annoying. There is a simple way of; firstly, showing all the current concurrent session on the device and then how you can disconnect them.

To show all the user sessions that are on the switch, you can run the command show system users no-resolve:

[email protected]> show system users no-resolve 
fpc0:
--------------------------------------------------------------------------
 1:26PM  up 33 days,  6:56, 3 users, load averages: 0.00, 0.01, 0.00
USER     TTY      FROM                              [email protected]  IDLE WHAT
marquk01 p0       10.1.0.17                        11:22AM  2:03 -cli (cli)    
marquk01 p1       10.1.0.17                        12:02PM  1:19 -cli (cli)    
marquk01 p2       10.1.0.17                        1:24PM      - -cli (cli)

This command provides information on:

  • Connected Users
  • TTY session
  • IP address each user has connected from
  • Login Times
  • Idle Timer
  • User’s method of remote access

We can see that I have 3 sessions currently but only one is active, as 2 connection have IDLE times.

To clear to two session we can either use the TTY session number, shown in the output or by the process ID (pid).

To clear by the TTY session, I had to need to run the command request system logout terminal {TTY session} to disconnect the first idle session.

[email protected]> request system logout terminal p0
{master:0}
[email protected]> show system users no-resolve         
fpc0:
--------------------------------------------------------------------------
 1:27PM  up 33 days,  6:57, 2 users, load averages: 0.23, 0.06, 0.02
USER     TTY      FROM                              [email protected]  IDLE WHAT
marquk01 p1       10.1.0.17                        12:02PM  1:19 -cli (cli)    
marquk01 p2       10.1.0.17                        1:24PM      - -cli (cli)

The other method would be to clear the user’s pid number. You can find their pid either; in Operational mode, by using the TTY session number running the command show system processes | match {TTY session} (you will need to look for the pid with mgd process) or in Configuration mode, by running the command status:

[email protected]> show system processes | match p1 
41299  ??  Is     0:00.17 sshd: [email protected] (sshd)
41306  ??  Is     0:00.06 mgd: (mgd) (marquk01)/dev/ttyp1 (mgd)
41307  p1  Ss+    0:00.47 -cli (cli)

{master:0}
[email protected]> edit 
Entering configuration mode

{master:0}[edit]
[email protected]# status 
  marquk01 terminal p1 (pid 41306) on since 2015-05-04 12:02:30 UTC, idle 01:20:58
      {master:0}[edit]

Once I found the pid number, I ran the command request system logout pid {pid number} to disconnect the second idle session.

[email protected]> request system logout pid 41306

{master:0}
[email protected]> show system users no-resolve       
fpc0:
--------------------------------------------------------------------------
 1:32PM  up 33 days,  7:02, 1 user, load averages: 0.00, 0.02, 0.00
USER     TTY      FROM                              [email protected]  IDLE WHAT
marquk01 p2       10.1.0.17                        1:24PM      - -cli (cli)

And that’s how you clear idle TTY connections in Junos 🙂

Share this:
Share