Tag Archives: ipv6

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

IPv6 and Junos – Firewall Filter (ACLs)

Reading Time: 4 minutes

For IPv6 testing I’ve been asked to do one of the more noddy things to test Firewall Filters; these are Stateless Firewall Filters and are what Cisco call Access Control Lists (ACL). Unlike Stateful Firewall Filters, Stateless Filters do not inspect traffic flows, pattern or keep a record of network connections, as such TCP streams and/or UDP communication. Instead, these filters evaluate packet contents statically against a set of packet-matching rules that either permit or deny packets transiting the switch.

Firewall Filter (ACL) is an important feature for a switch to have as it provides some (although limited) protection for devices and host directly connected. I said that this was one of the more noddy things as there’s only one difference between creating a Firewall Filter for IPv4 and IPv6. However, as they say, better to be safe than sorry! With all that said and done, this post will be to show how you’d configure and implement a Stateless Firewall Filter within Junos.

Let’s get cracking 🙂

I had a pretty simple topology, using a Juniper EX Series 4200 switch configured with two Layer-3 vlans, and I’ve set up two Ubuntu 14.04LTS ESXi host; 1 of the host will be configured as a webserver (km-vm1) and the other as a client trying to access the server (km-vm3)

Firewall Filter Topology

Firstly, I created all of the physical and logical connections were expected, by running show ipv6 neighbors and show lldp neighbors

IPv6 SubnetsServers
[email protected]> show ipv6 neighbors 
IPv6 Address                 Linklayer Address  State       Exp Rtr Secure Interface
2001:123:212:1::2            00:0c:29:fc:d5:de  stale       202 no  no      vlan.300       
2001:192:168:2::2            00:0c:29:4f:26:c5  stale       1197 no no      vlan.200
[email protected]> show lldp neighbors 
Local Interface    Parent Interface    Chassis Id          Port info          System Name
ge-0/0/0.0         -                   00:0c:29:4f:26:bb   eth1               km-vm1                          
xe-0/1/0.0         -                   00:0c:29:fc:d5:d4   eth1               km-vm3

The goal of this test is ensure that KM-VM3 can ONLY access KM-VM1 on TCP ports 80 and 443, as these are well-known and IANA defined ports for unsecured (HTTP) and secured (HTTPS) web traffic, and ICMP traffic (ie. ping and traceroute).

Before configuring the Firewall Filter I wanted to see what was accessible for KM-VM3, so I ran a very useful open source utility for network discovery and a security auditing tool called nmap , to produce a port scan of the webserver. From the output we can see that not only are HTTP and HTTPS accessible, but the Port 22 Secure Shell (SSH) is open. As KM-VM1 doesn’t have any firewalling configured on the server level via iptables, KM-VM3 could be used to try and hack KM-VM1 by attacking the SSH port to gain access to the server, which is never good!

Port ScanSSH access
[email protected]:~$ nmap -6 2001:192:168:2::2

Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-11 14:17 GMT
Nmap scan report for 2001:192:168:2::2
Host is up (0.0017s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https
[email protected]:~$ ssh 2001:192:168:2::2
The authenticity of host '2001:192:168:2::2 (2001:192:168:2::2)' can't be established.
ECDSA key fingerprint is e3:e3:f7:91:c0:30:a3:02:f9:1f:fd:aa:b7:0d:9c:9d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '2001:192:168:2::2' (ECDSA) to the list of known hosts.
[email protected]:192:168:2::2's password:

With that security risk in mind, lets add a Firewall Filter that will only allow access to ports 80, 443 and ICMP traffic. I created a prefix-list, webservers, that would list all the prefixes (IP addresses) for the webservers. Although in this example I’ll only have the one prefix, I was always taught to use prefix-lists for ease of configuration. This was configured under edit policy-options prefix-list stanza:

[email protected]# show policy-options       
prefix-list webservers {
    2001:192:168:2::2/128;
}

Now, for the Filter you’ll need to be under firewall family inet6 filter stanza, (for an IPv4 filter; firewall family inet filter). You can name your filter anything however, it can’t be more than 64 characters and if you have any spaces you’ll need to use ” ” marks. The same goes with naming your rules, which Junos calls terms. The Filter must have at least one term and the term(s) must have from or then statement. The from and then statements provide the actions of the term.

As you can see below, the Firewall Filter is named ALLOW-HTTP/HTTPS and has 3 terms:

{master:0}[edit firewall family inet6 filter ALLOW-HTTP/HTTPS]
[email protected]# show 
term allow-http/https {
    from {
        source-address {
            ::/0;
        }
        destination-prefix-list {
            webservers;
        }
        destination-port [ 80 443 ];
    }
    then accept;
}
term allow-icmp {
    from {
        icmp-type [ echo-reply echo-request neighbor-advertisement packet-too-big destination-unreachable neighbor-solicit ];
    }
    then accept;
}
term deny-all {
    then {
        count deny-all;
        log;
        discard;
    }
}

Lets break down each aspect of this Firewall Filter:

  • The first term allow-http/https states from source-address ::/0, for IPv6 is any address to the destination of the webservers, which has been defined in the prefix-list to ports 80 and 443 (HTTP and HTTPS) to then accept those packets
  • The second term allow-icmp states the different type of icmp packets that I want allowed and then those are accepted
  • The final term deny-all states that any other packets should be counted under deny-all, logged and discarded. By using the action discard, this will silently drop all packets without sending an ICMP reply back to the requestor
Note
With Junos, it is important to remember that when creating a Firewall Filter:

  • They works as Top-Down List, so the order of your rules is very significant, because once a rule has been matched, any rules below WILL NOT be checked.
  • Additionally just like with Cisco Firewall Filters come with an Implicit Deny at the end. If any packets don’t match any of the previous terms then they will be dropped automatically. Although this Implicit Deny is there, best practice to add a deny-all term at the end any Firewall Filter or ACL.
  • Finally, you can have only one input and one output filter per interface however have as many terms as you like. You can find all the guidelines that come with Firewall Filters here on Juniper’s TechLibrary page

Having created the filter, it will an input filter, as it is configured to filter traffic coming into the switch. Additionally, it will be place on the outside-facing interface, in this example, that has KM-VM3 in (vlan.300). This is because with any Filter, ACL or Firewall Policy, you want to stop any unnecessary traffic traversing your network at the furthest possible point, which is normally the edge of your network.

So under interface vlan unit 300 family inet6 filter stanza the Firewall Filter is placed as an input filter:

{master:0}[edit interfaces vlan unit 300]
[email protected]# show 
family inet6 {
    filter {
        input ALLOW-HTTP/HTTPS;
    }
    address 2001:123:212:1::1/64;
}

Having committed the configuration, if we go back onto KM-VM3 and do some testing we’ll be able to see the effect of the Firewall Filter. As we can see below, when the port scan was run again, only ports 80 and 433 are in an OPEN STATE and SSH port 22 isn’t shown at all now, and we’re able to ping. When we try SSH we get nothing, which shows that this filter is working as expected.

Port ScanICMP PingSSH access
[email protected]:~$ nmap -6 2001:192:168:2::2

Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-11 15:30 GMT
Nmap scan report for 2001:192:168:2::2
Host is up (0.00072s latency).
Not shown: 998 filtered ports
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https
[email protected]:~$ ping6 2001:192:168:2::2
PING 2001:192:168:2::2(2001:192:168:2::2) 56 data bytes
9 packets transmitted, 9 received, 0% packet loss, time 7999ms
rtt min/avg/max/mdev = 0.464/0.545/0.662/0.066 ms
[email protected]:~$ ssh 2001:192:168:2::2
^C

For further verification, we can check the counter that was set under the deny-all term to see how many packets have been dropped. By running the command show firewall counter filter ALLOW-HTTP/HTTPS deny-all we’re able to see the counters at that time.

[email protected]> show firewall counter filter ALLOW-HTTP/HTTPS deny-all 

Filter: ALLOW-HTTP/HTTPS                                       
Counters:
Name                                                Bytes              Packets
deny-all                                              490                    5

As I said, when I started this post, the method of applying a Firewall Filter is exactly same in IPv6 world as it is in IPv4, with the exception of the filter location. Firewall Filters are extremely important in giving protection to hosts and devices connected to the switch if a stateful firewall such as a Juniper SRX or Cisco ASA isn’t suitable and/or available in your network design.

Share this:
Share

Configuring a Dual Stacked DHCP Server

Reading Time: 4 minutes

As part of my IPv6 Testing, I needed to test whether we would either use SLAAC or DHCPv6 in a particular situation. Having never setup a DHCP server before, of course, I had to write a post on how I did it 😀

Dynamic Host Configuration Protocol or DHCP is defined in RFC2131:

The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.

DHCP supports three mechanisms of IP address allocation; Automatic, Dynamic and Manual allocation. RFC2131: describes how each of these mechanisms works within the DHCP process

Dynamic allocation is the only one of the three mechanisms that allows automatic reuse of an address that is no longer needed by the client to which it was assigned. Thus, dynamic allocation is particularly useful for assigning an address to a client that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of clients that do not need permanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new client being permanently connected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old clients are retired. Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in environments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.

In a nutshell:

  • Automatic allocation; the DHCP process will assign a permanent IP address to the host/device.
  • Dynamic allocation; the DHCP assigns an IP address to a client for a limited period of time or until the client release the address.
  • Manual allocation; the a client’s IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client.

With DHCPv6 the communication process between server and client is a little different compared DHCPv4, as explained in RFC3315:

Clients and servers exchange DHCP messages using UDP. The client uses a link-local address or addresses determined through other mechanisms for transmitting and receiving DHCP messages. DHCP servers receive messages from clients using a reserved, link-scoped multicast address. A DHCP client transmits most messages to this reserved multicast address, so that the client need not be configured with the address or addresses of DHCP servers.

To allow a DHCP client to send a message to a DHCP server that is not attached to the same link, a DHCP relay agent on the client’s link will relay messages between the client and server. The operation of the relay agent is transparent to the client and the discussion of message exchanges in the remainder of this section will omit the description of message relaying by relay agents. Once the client has determined the address of a server, it may under some circumstances send messages directly to the server using unicast.

NOTE
For more in-depth detail about the DHCP and DHCPv6, I would suggest looking into RFC2131 and RFC3315 respectfully.

For this testing, I used a two ESXi Ubuntu 14.04LTS Hosts, one as the DHCP server and client, and the other was a Juniper EX4200 connecting them together. The switch configuration is extremely basic, both devices are in the same Vlan and the Vlan has a layer-3 interface IPv4: 192.168.1.1/24 and IPv6: 2001:192:168:1::1/64.

With all the talk out of way.. Let’s get cracking 🙂

You will need to have sudo or root privileges

Firstly, a static IPv4 and IPv6 will need to be set on the interface that will be advertising the DHCP to the LAN. For my example I’m using eth1

[email protected]:~$ ifconfig -a eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:d3:ac:77  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fed3:ac77/64 Scope:Link
          inet6 addr: 2001:192:168:1::2/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1308 (1.3 KB)  TX bytes:4204 (4.2 KB)

The DHCP package is available via the apt-get repository

sudo apt-get install isc-dhcp-server

You will need to edit /etc/default/isc-dhcp-server and set the NIC that you want to run DHCP from. In addition, you need to set options with “-6” flag to tell the package we’ll be running IPv6. For my server, I’ll be using interface “eth1”. Make you use the appropriate NIC in your configuration.

[email protected]:~$ cat /etc/default/isc-dhcp-server 
# Defaults for isc-dhcp-server initscript
# sourced by /etc/init.d/isc-dhcp-server
# installed at /etc/default/isc-dhcp-server by the maintainer scripts

#
# This is a POSIX shell fragment
#

# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
#DHCPD_CONF=/etc/dhcp/dhcpd.conf

# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
#DHCPD_PID=/var/run/dhcpd.pid

# Additional options to start dhcpd with.
#    Don't use options -cf or -pf here; use DHCPD_CONF/ DHCPD_PID instead
OPTIONS="-6"

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#    Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES="eth1"

From doing some digging, unfortunately the original isc-dhcp-server doesn’t allow you to run IPv4 and IPv6 under the same config file. I had to create a new file and edit it to be IPv6 specific. I backed the original dhcpd.conf file and created a new dhcpd6.conf file; the two files should look similar to the below if you have a simple set up like myself.

Note
With a DHCP server you can have the server configured to set DNS, hostnames and other administrative settings. You can see examples of this if you look at the full original dhcpd.conf file. This is out of scope of what I was testing currently, but with knowing what else I’ll be testing in the future I’ll likely shown how in a future post 🙂
dhcpd6.confdhcpd.conf
[email protected]:~$ cat /etc/dhcp/dhcpd6.conf 
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed.
ddns-update-style none;

# Option definitions common to all supported networks...
default-lease-time 600; 
max-lease-time 7200; 

# This DHCP server is the official DHCP server for the local network
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
 
# Subnet declaration
subnet6 2001:192:168:1::/64  {
    range6 2001:192:168:1::110 2001:192:168:1::120;
}
[email protected]:~$ cat /etc/dhcp/dhcpd.conf 
#
# Sample configuration file for ISC dhcpd for Debian
#
# Attention: If /etc/ltsp/dhcpd.conf exists, that will be used as
# configuration file instead of this file.
#
#

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

default-lease-time 600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# This is a very basic subnet declaration.

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.110 192.168.1.120;
}

An DHCPv6 lease file will need to be created because, unlike IPv4, there isn’t a predefined file. In addition this file will need to have its owner changed to dhcpd daemon. This is because the daemon will need write, read and execute permissions

sudo touch /var/lib/dhcp/dhcpd6.leases
sudo chown dhcpd:dhcpd /var/lib/dhcp/dhcpd6.leases

To finish up on the server, we will need to start the DCHP processes

sudo service isc-dhcp-server start
sudo service isc-dhcp-server6 start

Once this has been done, the server is configured. Next we will hop to the other VM to see if we can get some IP addresses assigned!

Once on the client, we have to set its interface to listening for DHCP packets. Under /etc/network/interfaces both for IPv4 and IPv6 we will need to DHCP.

[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

Once this has been set, the interface will automatically pick up an address. If you’re like me and want to see everything, you can manually release any addresses learnt by using the following commands: for IPv6 dhclient -6 -v -r eth1 and for IPv4 dhclient -v -r eth1

dhclient -v -r eth1dhclient -6 -v -r eth1
[email protected]:~$ sudo dhclient -v -r eth1
[sudo] password for marquk01: 
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/

Listening on LPF/eth1/00:0c:29:4f:26:c5
Sending on   LPF/eth1/00:0c:29:4f:26:c5
Sending on   Socket/fallback
DHCPRELEASE on eth1 to 192.168.1.2 port 67 (xid=0x45baa909)
[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
RTNETLINK answers: Cannot assign requested address
XMT: Forming Release, 0 ms elapsed.
XMT:  X-- IA_NA 29:4f:26:c5
XMT:  | X-- Release Address 2001:192:168:1::111
XMT:  V IA_NA appended.
XMT: Release on eth1, interval 1000ms.
RCV: Reply message on eth1 from fe80::20c:29ff:fed3:ac77.
RCV:  X-- Server ID: 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77
message status code Success: "Release received."

Running an ifconfig will show that eth1 has no IP addresses set (except for its link-local address)

[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
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3487 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1272 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:501952 (501.9 KB)  TX bytes:267192 (267.1 KB)

Now we can request addresses from DHCP server to bind the next available IP addresses to km-vm1 by using the command for IPv4 dhclient -v eth1 and for IPv6 dhclient -6 -v eth1 respectfully.

dhclient -v eth1dhclient -6 -v eth1
[email protected]:~$ sudo dhclient -v 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/

Listening on LPF/eth1/00:0c:29:4f:26:c5
Sending on   LPF/eth1/00:0c:29:4f:26:c5
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3 (xid=0x7cae5613)
DHCPREQUEST of 192.168.1.112 on eth1 to 255.255.255.255 port 67 (xid=0x1356ae7c)
DHCPOFFER of 192.168.1.112 from 192.168.1.2
DHCPACK of 192.168.1.112 from 192.168.1.2
bound to 192.168.1.112 -- renewal in 230 seconds.
[email protected]:~$ sudo dhclient -6 -v 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
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: Solicit on eth1, interval 1050ms.
RCV: Advertise message on eth1 from fe80::20c:29ff:fed3:ac77.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1447710742
RCV:  | X-- t1 - renew  +0
RCV:  | X-- t2 - rebind +0
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::111
RCV:  | | | X-- Preferred lifetime 7200.
RCV:  | | | X-- Max lifetime 43200.
RCV:  X-- Server ID: 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77
RCV:  Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC:  X-- Initial candidate 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77 (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::111
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Request on eth1, interval 1040ms.
RCV: Reply message on eth1 from fe80::20c:29ff:fed3:ac77.
RCV:  X-- IA_NA 29:4f:26:c5
RCV:  | X-- starts 1447710744
RCV:  | X-- t1 - renew  +0
RCV:  | X-- t2 - rebind +0
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 2001:192:168:1::111
RCV:  | | | X-- Preferred lifetime 7200.
RCV:  | | | X-- Max lifetime 43200.
RCV:  X-- Server ID: 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77
PRC: Bound to lease 00:01:00:01:1d:dc:60:db:00:0c:29:d3:ac:77.

We can confirm by using ifconfig again:

[email protected]:~$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet addr:192.168.1.110  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link
          inet6 addr: 2001:192:168:1::111/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3647 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1365 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:519662 (519.6 KB)  TX bytes:292435 (292.4 KB)

And with that, we now have a Dual Stacked DHCP server! Although this looks quite straightforward, now I’ll tell you that it took me a few days to get understand and get the IPv6 side of things working as expected. There was plenty of googling, troubleshooting, screen staring and frustration with this one, but I have to give major props to a great page by Jochen Kirstätter on how the IPv6 side of install was done if I hadn’t have found it, I would still be poking in the dark *covers face*! You will find some great nuggets on Jochen’s blog here 🙂

Share this:
Share

IPv6 and Junos – Stateless Address Autoconfiguration (SLAAC)

Reading Time: 3 minutes

From my research and testing, I’ve notice there are a few ways you can set IPv6 addresses to hosts. Essentially you have 3 methods; manually setting a Static IP address, Using Stateful Dynamic Address allocation via a DHCPv6 server, or by using Stateless Dynamic Address allocation. The first two methods are pretty standard as addressing with IPv4 is done this way however, the last method is new method that comes with IPv6 and this is actually known as Stateless Address Autoconfiguration (SLAAC). SLAAC, as its name suggestions, allows a host to auto configure itself without any manual intervention.

RFC4862 describe the SLAAC as

The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an “interface identifier” that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link.

In essence, when using SLAAC to get the full 128-bit IPv6 address, it uses the 64-bit prefix that is advertised by the host or router for the first half, then in conjunction with the EUI-64 process, is able to allocation the second 64-bit of the address.

Note
The EUI-64 process in a nutshell, is the method of extending the 48-bit MAC Address and making it into a 64-bit value. This is done by splitting the 48-bit address into two 24-bit halves and adding the 16-bit hex value 0xFFFE in middle to create the last 64-bits

Configuring SLAAC

Enabling SLAAC with Junos is pretty straightforward. For my example, I’ve got an EX4200 connected to an Ubuntu 14.04LTS ESXi host in Vlan 200.

Before enabling the switch, the host’s interface has to be set to auto

[email protected]:~$ cat /etc/network/interfaces
{...}
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

auto eth1
iface eth1 inet6 auto

Once that’s done, to make sure no address was learnt as I configured the switch, the interface was disabled using ifdown.

With the switch configuration, under the protocol router-advertisement stanza, the interface and the prefix (first 64-bits) that will be advertised need to be set. Additionally I enabled a traceoption to see the process from the switch’s perspective.

Interface ConfigurationEnabling SLAAC
{master:0}[edit]
[email protected]# show interfaces vlan unit 200 
family inet6 {
    address 2001:192:168:2::1/64;
}
{master:0}[edit protocols router-advertisement]
[email protected]# show 
traceoptions {
    file RA.log;
    flag all;
}
interface vlan.200 {
    prefix 2001:192:168:2::/64;
}

Verification

With that SLAAC has been enabled, simple isn’t it 🙂

Now, back on the host, I re-enabled the interface using ifup. By using ifconfig we can see that the IPv6 address has been auto configured onto the host.

[email protected]:~$ ifconfig -a eth1
eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet addr:192.31.1.2  Bcast:192.31.1.255  Mask:255.255.255.0
          inet6 addr: 2001:192:168:2:20c:29ff:fe4f:26c5/64 Scope:Global
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:563 (563.0 B)  TX bytes:2334 (2.3 KB)

By looking closer at the ifconfig output, we can see how the EUI-64 process has been used to allocate the IPv6 address, as well as its link-local address:

eth1      Link encap:Ethernet  HWaddr 00:0c:29:4f:26:c5  
          inet6 addr: 2001:192:168:2:20c:29ff:fe4f:26c5/64 Scope:Global
          inet6 addr: fe80::20c:29ff:fe4f:26c5/64 Scope:Link

On the switch, by running the commands: show ipv6 neighbours, we can see the hosts’ link-local and SLAAC allocated addresses, both discovered by the Neighbour Discovery Protocol (NDP). And show ipv6 router-advertisement, which shows how many RA’s and RS’ have been sent and received by the switch.

IPv6 NeighborsRouter Advertisements
{master:0}
[email protected]> show ipv6 neighbors 
IPv6 Address                 Linklayer Address  State       Exp Rtr Secure Interface
2001:192:168:2:20c:29ff:fe4f:26c5
                             00:0c:29:4f:26:c5  stale       1110 no no      vlan.200    
fe80::20c:29ff:fe4f:26c5     00:0c:29:4f:26:c5  stale       1039 no no      vlan.200
{master:0}
[email protected]> show ipv6 router-advertisement 
Interface: vlan.200
  Advertisements sent: 4, last sent 00:04:45 ago
  Solicits received: 2, last received 00:04:46 ago
  Advertisements received: 0

When we look further at the traceoption, we can see the request from the host sent out Router Solicitation (RS) via its link-local address, to the destination of ff02::2 for the presence of routers (in this case a switch) on the link. The switch replies by sending a Router Advertisement (RA) to ff02::1 with the Router’s presence and link prefixes, MTU, and hop limits.

{Apr  7 06:29:13.002388 background dispatch running job ipv6_ra_delete_interface_config_job for task Router-Advertisement
Apr  7 06:29:13.002436 task_job_delete: delete background job ipv6_ra_delete_interface_config_job for task Router-Advertisement
Apr  7 06:29:13.002473 background dispatch completed job ipv6_ra_delete_interface_config_job for task Router-Advertisement
Apr  7 06:29:48.645889 ipv6_ra_receive_solicit: received solicit from fe80::20c:29ff:fe4f:26c5
Apr  7 06:29:48.646013 ipv6_ra_receive_solicit: task Router-Advertisement src fe80::20c:29ff:fe4f:26c5 dst ff02::2 hdr 0x26fc000 count 16 intf 0x283c0e8
Apr  7 06:29:48.646086 task_timer_reset: reset Router-Advertisement_ipv6ra
Apr  7 06:29:48.646137 task_timer_set_oneshot_latest: timer Router-Advertisement_ipv6ra interval set to 0.426219
Apr  7 06:29:49.073743 task_job_create_foreground: create job ipv6 ra for task Router-Advertisement
Apr  7 06:29:49.073857 foreground dispatch running job ipv6 ra for task Router-Advertisement
Apr  7 06:29:49.073978 ipv6_ra_send_advertisement: sending advertisement for ifl 73 to ff02::1
Apr  7 06:29:49.074018 (519322) sending advertisement for ifl 73
Apr  7 06:29:49.074106 	ifa 0x28383f0 2001:192:168:2::1/64
Apr  7 06:29:49.074942 	--> sent 56 bytes
Note
The ff02::1 and ff02::2 addresses are well-known IPv6 Multicast addresses that a host sends out to a RS, to all devices within the all-host multicast group for ff02::2, and for a router, the address ff02::1 is used to reply RS with RA. Although this process could be compared to the IPv4 broadcast address 255.255.255.255, its important to remember that broadcasts are not accepted by any IPv6 protocol.

SLAAC is a really useful way of easily enabling IPv6 across your network and let the host and devices auto configure themselves. In addition, as the EUI-64 process is key to SLAAC, as long as you keep a record of the MAC Addresses of each device, you’ll always be able to know what address goes with what device. Of course, there will be situations where Static or DHCP addressing will be more suitable however; if you need to quickly enable your network with IPv6 then SLAAC is the way to go!

Share this:
Share

IPv6 and Junos – VRRPv3

Reading Time: 5 minutes

With the Christmas season coming up, changes and the current course of projection slow down, so this is the perfect time to start messing around in the lab with things I wouldn’t normally get the chance to do. One thing I know will be happening in the future (but not the near future) on my work network is IPv6. We run IPv6 in the Internet Core however, it’s not to be seen anywhere else on the network, and I’ve heard they’re pushing hard to get IPv6 into our hosting datacentres. With this in mind, and having time to kill, it would be good to be proactive and start looking at how IPv6 and Junos work together!

From looking at the hosting and enterprise (a small bit of enterprise) network, I had a chat with a few of the seniors and we came up with list of things that we were most likely to be used on the network, and we agreed would be the best things to test:

Routing and Switching Features

  • VRRPv3
  • BGP
  • ACL
  • Virtual Routers (VRFs)
  • IGPs (OSPFv3, Static Routes & IS-IS)
  • SLAAC (Router Advertisements)
  • DHCPv6
  • Multicasting

Firewall Features

  • NAT64 / DNS64
  • Security Policies

Of course this list isn’t the be-all or end-all however, for now it’s a good base to get me started and from there we’ll see what happens next. Where I can, I’ll be mostly using IPv6 only, but there are a few features where I’ll have dual stacked setup as it will be good ‘real world’ testing! So with all that talk and explanation out of the way…. Let’s get cracking 😀

The first protocol on my list: Virtual Router Redundancy Protocol (VRRP). I’ve previously wrote a post on how to configure VRRP between Cisco and Juniper Switch, if you take look at that post it defines what VRRP is and why you would you use it within your network. When working with IPv6 (or in Dual Stacked environment) on the other hand you will need to make sure that we are using VRRPv3. VRRPv3 supports both IPv4 and IPv6 and can be defined best in RFC5798 for what the main advantages of VRRPv3:

The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms.

For this test, I’ll have a similar topology as my other VRRP post, but I’ll be using 2x Juniper EX4200 switches and I’ll have ESXi Ubuntu 14.04LTS host configured with active-backup bond; the 2 physical NICs were connected into each switch.

VRRPv3 Topology

VRRP Configuration

Firstly will need to enable VRRPv3. By default VRRPv3 isn’t enabled and VRRPv2 doesn’t support inet6, you will need to have this enabled and is done under protocol vrrp stanza. In addition, as IPv6 doesn’t use Address Resolution Protocol (ARP) for Link Layer Discovery, we need to enable the IPv6 version of ARP, Neighbor Discovery Protocol (NDP). This will allow Neighbor Discoveries (ND) to be sent out to Host and other Network devices with that subnet with are needed to VRRPv3 to work affectively.

NOTE
For about IPv6 NDP check out RFC4861

ND is set under protocol router-advertisement stanza, and the logical interface set.

{master:0}[edit protocols]
[email protected]# show 
router-advertisement {
    interface vlan.100 {
        prefix 2001:192:168:1::/64;
}
vrrp {
    version-3;
}

Just like with VRRPv2 you will need to set the entire configuration under the interface stanza whether you have vlan or on physical interface. It is very important to note that you will need to manually set the link-local address on the interface and set a virtual link-local address (these both will need to in the same subnet) without these you will not be able to commit the configuration.

VRRP MasterVRRP Backup
{master:0}[edit interfaces vlan unit 100]
[email protected]# show 
family inet6 {
    address 2001:192:168:1::2/64 {
        vrrp-inet6-group 1 {
            virtual-inet6-address 2001:192:168:1::1;
            virtual-link-local-address fe80:192:168:1::1;
            priority 200;
            preempt;
            accept-data;
        }
    }
    address fe80:192:168:1::2/64;
}
{master:0}[edit interfaces vlan]
[email protected]# show 
unit 100 {
    family inet6 {
        address 2001:192:168:1::3/64 {
            vrrp-inet6-group 1 {
                virtual-inet6-address 2001:192:168:1::1;
                virtual-link-local-address fe80:192:168:1::1;
                priority 100;
                no-preempt;
                accept-data;
            }
        }
        address fe80:192:168:1::3/64;
    }
}

VRRP Verification

Depending on the level of detail you want to go into, you can run any of these commands show vrrp summary, show vrrp detail or show vrrp extensive. I checked both the Master and Backup to make sure everything was expected and differences between the two, by using show vvrp detail.

VRRP Master show vrrp detailVRRP Backup show vrrp detail
[email protected]> show vrrp detail    
Physical interface: vlan, Unit: 100, Address: 2001:192:168:1::2/64
  Index: 72, SNMP ifIndex: 709, VRRP-Traps: disabled, VRRP-Version: 3
  Interface state: up, Group: 1, State: master, VRRP Mode: Active
  Priority: 200, Advertisement interval: 1, Authentication type: none
  Advertisement threshold: 3, Computed send rate: 0
  Preempt: yes, Accept-data mode: yes, VIP count: 2, VIP: fe80:192:168:1::1, 2001:192:168:1::1
  Advertisement Timer: 0.530s, Master router: fe80:192:168:1::2
  Virtual router uptime: 00:00:20, Master router uptime: 00:00:17
  Virtual Mac: 00:00:5e:00:02:01 
  Tracking: disabled

[email protected]> show vrrp detail 
Physical interface: vlan, Unit: 100, Address: 2001:192:168:1::3/64
  Index: 72, SNMP ifIndex: 709, VRRP-Traps: disabled, VRRP-Version: 3
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 100, Advertisement interval: 1, Authentication type: none
  Advertisement threshold: 3, Computed send rate: 0
  Preempt: no, Accept-data mode: yes, VIP count: 2, VIP: fe80:192:168:1::1, 2001:192:168:1::1
  Dead timer: 3.244s, Master priority: 200, Master router: fe80:192:168:1::2 
  Virtual router uptime: 00:00:28
  Tracking: disabled 

In addition, we can confirm that, from the VRRP Master, we are receiving ND’s from the ESXi host as we can see an entry when we run the command show ipv6 neighbors

[email protected]> show ipv6 neighbors 
IPv6 Address                 Linklayer Address  State       Exp Rtr Secure Interface
2001:192:168:1::3            cc:e1:7f:2b:82:81  stale       776 yes no      vlan.100    
2001:192:168:1::4            00:0c:29:d3:ac:77  stale       1070 no no      vlan.100   
fe80::20c:29ff:fed3:ac77     00:0c:29:d3:ac:77  stale       673 no  no      vlan.100    
fe80::20c:29ff:fed3:ac81     00:0c:29:d3:ac:81  stale       588 no  no      vlan.100    
fe80:192:168:1::3            cc:e1:7f:2b:82:81  stale       776 yes no      vlan.100

Failover Testing

Before testing the VRRP fail over, I enabled VRRP traceoptions on the master and backup, so that we will be able to see what’s happening under the bonnet. I found the logs from the backup were much simpler to understand compared to master however, on the master you were able to see what the VRRP daemon goes through the process of gaining mastership.

{master:0}[edit protocols vrrp]
[email protected]# show 
traceoptions {
    file vrrp.backup.log;
    flag all;
}

For the failover, the link down to the host and trunk link on the master were deactivated and from the logs on the VRRP Backup, we can see that VRRP daemon had received the vrrpd_process_ppmd_packet notifying that the VRRP master adjacency had gone down and then received another update ppmd_vrrp_delete_adj to remove the link-local address of the VRRP master and transition to become the VRRP Master.

Apr  2 14:43:03 vrrpd_process_ppmd_packet : PPMP_PACKET_ADJ_DOWN received
Apr  2 14:43:03 vrrpd_update_state_machine, vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 state: backup
Apr  2 14:43:03 vrrp_fsm_update IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: transition
Apr  2 14:43:03 vrrp_fsm_transition: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 state from: backup
Apr  2 14:43:03 vrrp_fsm_update_for_inherit IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: transition
Apr  2 14:43:03 ppmd_vrrp_delete_adj : VRRP neighbour fe80:192:168:1::2 on interface <72 1 1> deleted
Apr  2 14:43:03 vrrp_fsm_update IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: master
Apr  2 14:43:03 vrrp_fsm_active: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 state from: transition
Apr  2 14:43:03 VRRPD_NEW_MASTER: Interface vlan.100 (local address 2001:192:168:1::3) became VRRP master for group 1 with master reason masterNoResponse
Apr  2 14:43:03 vrrpd_construct_pdu if: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001, checksum flag 0, checksum 17650
Apr  2 14:43:03 vrrpd_ppmd_program_send : Creating XMIT on IFL 72, Group 1, Distributed 0, enabled 1
Apr  2 14:43:03 vrrp_fsm_update_for_inherit IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: master

When preempt has been configured on the Master, the two interfaces were reactivated, and it automatically takes over as VRRP Master. As we can see from the logs on the original backup switch, another vrrpd_process_ppmd_packet notification was received by the switch and the switch automatically transitions back to become VRRP Backup.

Apr  2 14:44:00 vrrpd_process_ppmd_packet : PPMP_PACKET_RECEIVE received
Apr  2 14:44:00 vrrp_fsm_update IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: backup
Apr  2 14:44:00 vrrp_fsm_backup: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 state from: master
Apr  2 14:44:00 VRRPD_NEW_BACKUP: Interface vlan.100 (local address 2001:192:168:1::3) became VRRP backup for group 1
Apr  2 14:44:00 vrrpd_construct_pdu if: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001, checksum flag 0, checksum 17650
Apr  2 14:44:00 vrrpd_ppmd_program_send : Creating XMIT on IFL 72, Group 1, Distributed 0, enabled 0
Apr  2 14:44:00 vrrp_fsm_update_for_inherit IFD: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 event: backup
Apr  2 14:44:00 Signalled dcd (PID 1225) to reconfig
Apr  2 14:44:00 ppmd_vrrp_set_adj : Created adjacency for neighbor fe80:192:168:1::2 on interface <72 1 1> with hold-time <3 609000000>, Distributed 0
Apr  2 14:44:00 ppmd_vrrp_program_send : Programmed periodic send on interface <72 1 1> with enabled = 0, Distribute = 0, MASTER RE = 1
Apr  2 14:44:00 vrrpd_rts_async_ifa_msg, Received Async message for: (null) index: 72, family 0x1c op: 0x3 address : 2001:192:168:1::1
Apr  2 14:44:00 vrrpd_rts_async_ifa_msg, Received Async message for: (null) index: 72, family 0x1c op: 0x3 address : fe80:192:168:1::1
Apr  2 14:44:00 vrrpd_rts_async_ifl_msg, Received Async message for: vlan index: 72, flags 0xc000 op: 0x2
Apr  2 14:44:00 vrrpd_if_find_by_ifname_internal, Found vlan.000.100: vlan.000.100.001.2001:0192:0168:0001:0000:0000:0000:0003.001 in run 1
Apr  2 14:44:00 vrrpd_find_track_if_entry_array_by_name: vlan.100

In addition, you can check to see how many transitional changes were made by using the show vrrp extensive command:

[email protected]> show vrrp extensive | match Backup 
    Idle to backup transitions               :4         
    Backup to master transitions             :4         
    Master to backup transitions             :0

From the host point of view, I had a rolling ping going to gateway during the failover testing and the results were as expected.

--- 2001:192:168:1::1 ping statistics ---
123 packets transmitted, 95 received, 22% packet loss, time 122275ms
rtt min/avg/max/mdev = 1.058/96.186/3257.648/494.372 ms, pipe 4

Although you see packet loss, this is normal due to the bond type (active-backup) and one of the two NICs was unavailable. In addition, the connectivity never completely dropped out and having a host running on 50% capacity is better than a host with no accessibility.

The full logs and ping6 outputs are available here: vrrp.master.log, vrrp.backup.log, ping6.

VRRPv3 has very similar configuration to VRRPv2 but it took me a while to work out that without small differences, i.e. enabling router-advertisement and version-3 , you could be looking at the screen scratching your head! And with that we’ve got another post in the books. Keep an eye for future posts on IPv6 and Junos 🙂

Share this:
Share