ASA to SRX Route-based IPSec VPN (part 1)

ASA to SRX Topology

Yes, you can have an IPSec tunnel between a Cisco and Juniper firewall!

It’s actually pretty easy to set up a tunnel between an ASA and an SRX. The above topology is set up as a traditional branch with an inside subnet being NAT’ted to the internet with a WAN address.

This is a two page post with this page going over the initial setup of the above topology covering addressing, NAT’ing, security policies and so on. If you’re just looking for the VPN config, skip to page 2!

ASA Initial Configuration

To get started on the ASA we’ll assign the interfaces IP Addresses, Security Zones, NAT and a default route like so:

ciscoasa(config-if)# int gi0/0 
ciscoasa(config-if)# nameif OUTSIDE INFO: Security level for "OUTSIDE" set to 0 by default. 
ciscoasa(config-if)# ip add 198.51.100.1 255.255.255.252 ciscoasa(config-if)# no shut 

ciscoasa(config)# int gi0/1 
ciscoasa(config-if)# nameif INSIDE INFO: Security level for "INSIDE" set to 100 by default. 
ciscoasa(config-if)# ip add 172.16.100.1 255.255.255.0 
ciscoasa(config-if)# no shut 

ciscoasa(config)# nat (INSIDE,OUTSIDE) after-auto source dynamic any interface description "PAT out the OUTSIDE interface from the INSIDE interface"

ciscoasa(config)# route OUTSIDE 0.0.0.0 0.0.0.0 198.51.100.2

One additional note for the ASA: by default ICMP passing through the firewall will be dropped. To get around this you need to inspect ICMP like so:

ciscoasa# conf t
ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)#  class inspection_default
ciscoasa(config-pmap-c)# inspect icmp
ciscoasa(config-pmap-c)# end

SRX Initial Configuration

Here we set the interfaces IP Addresses, assign Zones and set a Default Route.

set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.1/30                                                       set interfaces ge-0/0/1 unit 0 family inet address 192.168.50.1/24

set security zones security-zone UNTRUST interfaces ge-0/0/0.0
set security zones security-zone TRUST interfaces ge-0/0/1.0

set routing-options static route 0.0.0.0/0 next-hop 203.0.113.2

In addition on the SRX we’ll need to enable host inbound traffic for ICMP-PING and IKE. We’ll have a security policy allowing TRUST zone traffic to the UNTRUST zone.

set security zones security-zone UNTRUST host-inbound-traffic system-services ping
set security zones security-zone UNTRUST host-inbound-traffic system-services ike

set security policies from-zone TRUST to-zone UNTRUST policy PERMIT-ALL match source-address any
set security policies from-zone TRUST to-zone UNTRUST policy PERMIT-ALL match destination-address any
set security policies from-zone TRUST to-zone UNTRUST policy PERMIT-ALL match application any
set security policies from-zone TRUST to-zone UNTRUST policy PERMIT-ALL then permit

set security zones security-zone TRUST host-inbound-traffic system-services any-service
set security zones security-zone TRUST host-inbound-traffic protocols all

NAT is more than a one-liner on the SRX but performs the same exact function as above:

set security nat source rule-set UNTRUST-TO-TRUST from zone TRUST
set security nat source rule-set UNTRUST-TO-TRUST to zone UNTRUST
set security nat source rule-set UNTRUST-TO-TRUST rule RULE-1 match source-address 192.168.50.0/24
set security nat source rule-set UNTRUST-TO-TRUST rule RULE-1 then source-nat interface

Quick Sanity Checks

A ping from the East Host behind the SRX to the WAN interface and vice versa is successful.

EastPC> ping 198.51.100.1
84 bytes from 198.51.100.1 icmp_seq=1 ttl=253 time=3.665 ms
84 bytes from 198.51.100.1 icmp_seq=2 ttl=253 time=3.844 ms

WestPC> ping 203.0.113.1
84 bytes from 203.0.113.1 icmp_seq=1 ttl=63 time=4.912 ms
84 bytes from 203.0.113.1 icmp_seq=2 ttl=63 time=2.034 ms

Alright, after all that, we’re now ready to move on to the actual VPN set up on Page 2!

RouteSwitch.io now supports IPv6!

In some parts of the continental Unites States there are some locations that can only receive internet access through WISP’s. (Wireless Internet Service Providers)

With the internet exhausting the entire IPv4 address space, some of these WISP’s are only allocating IPv6 addresses to their clients.

As of now, I’m happy to announce that RouteSwitch.io now natively supports IPv6!

root@routeswitch:~# dig  aaaa routeswitch.io | grep AAAA

routeswitch.io.		3581	IN	AAAA	2600:3c03::f03c:91ff:fecb:6a23

And yes, it’s still encrypted.

ASA to SRX Route-based IPSec VPN (part 2)

ASA to SRX Topology

If you’ve been following from Page 1 we’re now ready to set up the VPN between the two sites.

ASA IKE, IPSEC, and VTI

First we create our IKE Policy and finally our IPSec Policy and Proposal.

crypto ikev1 enable OUTSIDE
crypto ikev1 policy 1
 authentication pre-share
 encryption aes-256
 hash sha
 group 5
 lifetime 86400

crypto ipsec ikev1 transform-set PHASE-TWO-PROPOSAL esp-aes-256 esp-sha-hmac

crypto ipsec profile TO-SRX
 set ikev1 transform-set PHASE-TWO-PROPOSAL
 set pfs group1
 set security-association lifetime seconds 86399

interface Tunnel100
 nameif ASA-SRX-TUNNEL
 ip address 10.255.255.1 255.255.255.252
 tunnel source interface OUTSIDE
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile TO-SRX

Finally on the ASA we create a tunnel-group that specifies what type of tunnel to create and our pre-shared-keys to be used for local and remote authentication.

tunnel-group 203.0.113.1 type ipsec-l2l
tunnel-group 203.0.113.1 ipsec-attributes
 ikev1 pre-shared-key TheCatInFranceSlept

With that, we are done with the configuration on the ASA. Now we can move on to the SRX

SRX IKE, IPSEC, and STo.0

Same as above: IKE Policy and Proposal followed with the IPSec Policy and Proposal.

set security ike proposal ASA-PHASE-ONE-PROPOSAL authentication-method pre-shared-keys
set security ike proposal ASA-PHASE-ONE-PROPOSAL dh-group group5
set security ike proposal ASA-PHASE-ONE-PROPOSAL authentication-algorithm sha1
set security ike proposal ASA-PHASE-ONE-PROPOSAL encryption-algorithm aes-256-cbc

set security ike policy ASA-IKE-POLICY mode main
set security ike policy ASA-IKE-POLICY proposals ASA-PHASE-ONE-PROPOSAL
set security ike policy ASA-IKE-POLICY pre-shared-key ascii-text TheCatInFranceSlept

set security ipsec proposal ASA-IPSEC-PROPOSAL protocol esp
set security ipsec proposal ASA-IPSEC-PROPOSAL authentication-algorithm hmac-sha1-96
set security ipsec proposal ASA-IPSEC-PROPOSAL encryption-algorithm aes-256-cbc
set security ipsec proposal ASA-IPSEC-PROPOSAL lifetime-seconds 86399

set security ipsec policy ASA-IPSEC-POLICY perfect-forward-secrecy keys group1
set security ipsec policy ASA-IPSEC-POLICY proposals ASA-IPSEC-PROPOSAL

In addition on the SRX we’ll need to create an IKE Gateway, VPN and an ST0 interface. (St0 is similar to a VTI)

set security ike gateway ASA-GATEWAY ike-policy ASA-IKE-POLICY
set security ike gateway ASA-GATEWAY address 198.51.100.1
set security ike gateway ASA-GATEWAY external-interface ge-0/0/0
set security ike gateway ASA-GATEWAY version v1-only

set security ipsec vpn ASA-VPN bind-interface st0.0
set security ipsec vpn ASA-VPN ike gateway ASA-GATEWAY
set security ipsec vpn ASA-VPN ike ipsec-policy ASA-IPSEC-POLICY

set interfaces st0 unit 0 family inet address 10.255.255.2/30
set security zones security-zone SRX-TO-ASA interfaces st0.0

Adding the final Security Policies

The final part is to add two final security policies on the SRX to allow traffic to flow to and from the TRUST zone over the tunnel.

set security policies from-zone TRUST to-zone SRX-TO-ASA policy ALLOW-EGRESS match source-address any
set security policies from-zone TRUST to-zone SRX-TO-ASA policy ALLOW-EGRESS match destination-address any
set security policies from-zone TRUST to-zone SRX-TO-ASA policy ALLOW-EGRESS match application any
set security policies from-zone TRUST to-zone SRX-TO-ASA policy ALLOW-EGRESS then permit

set security policies from-zone SRX-TO-ASA to-zone TRUST policy ALLOW-INGRESS match source-address any
set security policies from-zone SRX-TO-ASA to-zone TRUST policy ALLOW-INGRESS match destination-address any
set security policies from-zone SRX-TO-ASA to-zone TRUST policy ALLOW-INGRESS match application any
set security policies from-zone SRX-TO-ASA to-zone TRUST policy ALLOW-INGRESS then permit

Last part of the configuration: the routes

ASA

route ASA-SRX-TUNNEL 192.168.50.0 255.255.255.0 10.255.255.2 1

SRX

set routing-options static route 172.16.100.0/24 next-hop 10.255.255.1

Verifying and Testing

ASA

First we verify our phase one and then our phase two

ASAv# show crypto isakmp sa detail

IKEv1 SAs:

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: ASA-TO-SRX
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_ACTIVE
    Encrypt : aes-256         Hash    : SHA
    Auth    : preshared       Lifetime: 86400
    Lifetime Remaining: 86362

ASAv# show crypto ipsec sa detail
interface: ASA-SRX-TUNNEL
    Crypto map tag: __vti-crypto-map-4-0-100, seq num: 65280, local addr: 198.51.100.1

      access-list __vti-def-acl-0 extended permit ip any any
      local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      current_peer: ASA-TO-SRX


      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #pkts no sa (send): 0, #pkts invalid sa (rcv): 0
      #pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
      #pkts invalid prot (rcv): 0, #pkts verify failed: 0
      #pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
      #pkts invalid pad (rcv): 0,
      #pkts invalid ip version (rcv): 0,
      #pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
      #pkts replay failed (rcv): 0
      #pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
      #pkts internal err (send): 0, #pkts internal err (rcv): 0

      local crypto endpt.: 198.51.100.1/0, remote crypto endpt.: ASA-TO-SRX/0
      path mtu 1500, ipsec overhead 74(44), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: F4423134
      current inbound spi : CAD09FA2

    inbound esp sas:
      spi: 0xCAD09FA2 (3402669986)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 1, IKEv1, VTI, }
         slot: 0, conn_id: 1228800, crypto-map: __vti-crypto-map-4-0-100
         sa timing: remaining key lifetime (kB/sec): (3915000/86285)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0xF4423134 (4097978676)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 1, IKEv1, VTI, }
         slot: 0, conn_id: 1228800, crypto-map: __vti-crypto-map-4-0-100
         sa timing: remaining key lifetime (kB/sec): (3915000/86284)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

ASAv#

Look at all those 0’s. As we can see, both phase one and phase two are up however we haven’t sent any data through the tunnel. Lets do that now!

WestPC> ping 192.168.50.2

84 bytes from 192.168.50.2 icmp_seq=1 ttl=63 time=9.671 ms
84 bytes from 192.168.50.2 icmp_seq=2 ttl=63 time=2.579 ms
84 bytes from 192.168.50.2 icmp_seq=3 ttl=63 time=3.505 ms
84 bytes from 192.168.50.2 icmp_seq=4 ttl=63 time=2.653 ms
84 bytes from 192.168.50.2 icmp_seq=5 ttl=63 time=2.493 ms

ASAv# show crypto ipsec sa detail | i encaps:|decaps:
      #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
      #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5

ASAv# show route 192.168.50.0

Routing entry for 192.168.50.0 255.255.255.0
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.255.255.2, via ASA-SRX-TUNNEL
      Route metric is 0, traffic share count is 1

SRX

root@vSRX-1> show security ipsec security-associations
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
  <131073 ESP:aes-cbc-256/sha1 f4423134 86394/ 4608000 - root 500 198.51.100.1
  >131073 ESP:aes-cbc-256/sha1 cad09fa2 86394/ 4608000 - root 500 198.51.100.1

root@vSRX-1> show security ike security-associations detail
IKE peer 198.51.100.1, Index 6355135, Gateway Name: ASA-GATEWAY
  Role: Responder, State: UP
  Initiator cookie: d3571252c13d577f, Responder cookie: 6fad532d597e1cf7
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 203.0.113.1:500, Remote: 198.51.100.1:500
  Lifetime: Expires in 86068 seconds
  Reauth Lifetime: Disabled
  Peer ike-id: 198.51.100.1
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-5
  Traffic statistics:
   Input  bytes  :                 3876
   Output bytes  :                 3676
   Input  packets:                   36
   Output packets:                   35
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 1

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: 203.0.113.1:500, Remote: 198.51.100.1:500
    Local identity: 203.0.113.1
    Remote identity: 198.51.100.1
    Flags: IKE SA is created

root@vSRX-1> show security ipsec security-associations detail
  ID: 131073 Virtual-system: root, VPN Name: ASA-VPN
  Local Gateway: 203.0.113.1, Remote Gateway: 198.51.100.1
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv1
    DF-bit: clear
           , Copy-Outer-DSCP Disabled
    Bind-interface: st0.0

  Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 0x600a29
  Tunnel events:
    Sat Feb 23 2019
    : IPSec SA negotiation successfully completed          (1 times)
    Sat Feb 23 2019
    : IKE SA negotiation successfully completed            (1 times)
    Direction: inbound, SPI: f4423134, AUX-SPI: 0
    Hard lifetime: Expires in 85986 seconds
    Lifesize Remaining:  4607998 kilobytes
    Soft lifetime: Expires in 85396 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled

                          , Replay window size: 64
    Direction: outbound, SPI: cad09fa2, AUX-SPI: 0
    Hard lifetime: Expires in 85986 seconds
    Lifesize Remaining:  4607998 kilobytes
    Soft lifetime: Expires in 85396 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled

                          , Replay window size: 64

root@vSRX-1> show interfaces st0.0 | match put
    Input packets : 5
    Output packets: 5

root@vSRX-1> show route 172.16.100.0

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

172.16.100.0/24    *[Static/5] 13:42:01
                    > to 10.255.255.1 via st0.0

We’re good! Thanks for reading.

GRE Tunnel Modes

Our Simple Dual Stack Topology

Tunnel mode gre ip

By default a tunnel uses the mode tunnel mode gre ip.

A simple ping from R1’s loopback to R2’s loopback looks like this:

vIOS1#ping 192.168.200.1 source loopback 0 repeat 2

Internet Protocol Version 4, Src: 73.243.100.2, Dst: 73.243.100.1
Generic Routing Encapsulation (IP)
Flags and Version: 0x0000
Protocol Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.200.1, Dst: 192.168.100.1
Internet Control Message Protocol

But wait we can also use it for GRE IPv6 without changing the mode!

vIOS1(config-if)#do ping 2001:db8:2222::1 so l0 re 2

Internet Protocol Version 4, Src: 73.243.100.1, Dst: 73.243.100.2
Generic Routing Encapsulation (IPv6)
Flags and Version: 0x0000
Protocol Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: 2001:db8:1111::1, Dst: 2001:db8:2222::1
Internet Control Message Protocol v6

The only thing that has changed is the GRE Protocol Type to IPv6 0x86dd. So what gives; why are there so many types?

Tunnel mode gre ipv6

When this mode is selected it is necessary to have an IPv6 destination and source. The tunnel will use IPv6 as the underlay or carrier protocol.

vIOS1(config-if)#do ping 192.168.200.1 so l0 re 2

Internet Protocol Version 6, Src: 2001:db8:abcd::1, Dst: 2001:db8:abcd::2
Generic Routing Encapsulation (IP)
Flags and Version: 0x0000
Protocol Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.100.1, Dst: 192.168.200.1
Internet Control Message Protocol

Tunnel mode ipv6ip

Now we’re at the weird tunnels. This is no longer using GRE encapsulation. Instead the IPv4 header’s protocol field states that it’s IPv6. Confusing right?

This mode requires an Ipv4 destination configured.

vIOS1(config-if)#do ping 2001:db8:2222::1 re 2

Internet Protocol Version 4, Src: 73.243.100.2, Dst: 73.243.100.1
0100 …. = Version: 4
…. 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 120
Identification: 0x0037 (55)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: IPv6 (41)
Header checksum: 0x5f3c [validation disabled]
[Header checksum status: Unverified]
Source: 73.243.100.2
Destination: 73.243.100.1
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Protocol Version 6, Src: 2001:db8:2222::1, Dst: 2001:db8:ef::1
Internet Control Message Protocol v6

Tunnel mode ipv6

This requires an IPv6 destination address. Once again, there is no GRE in sight. Instead the IPv6 Next Header field specifies that it’ll be IPv4.

vIOS1(config-if)#do ping 192.168.200.1 so l0 re 2

Internet Protocol Version 6, Src: 2001:db8:abcd::1, Dst: 2001:db8:abcd::2
0110 …. = Version: 6
…. 0000 0000 …. …. …. …. …. = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
…. …. …. 0000 0000 0000 0000 0000 = Flow Label: 0x00000
Payload Length: 100
Next Header: IPIP (4)
Hop Limit: 255
Source: 2001:db8:abcd::1
Destination: 2001:db8:abcd::2
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Protocol Version 4, Src: 192.168.100.1, Dst: 192.168.200.1
Internet Control Message Protocol

That’s all I wrote!

Quick Subnetting

If you haven’t already, check out my previous post on Subnetting in Binary.

When studying for exams and just for everyday work, it’s important to be super quick when needing to subnet.

Thankfully, there are a few tricks to accomplish this.

Trick #1 The Easy Boundaries

There are four main bit boundaries that are dead giveaways.

Lets look at it in CIDR notation.

/8 = 255.0.0.0
/16 = 255.255.0.0
/24 = 255.255.255.0
/32 = 255.255.255.255

We know that if the range is between /9 and /15 we’re subnetting in the second octet. If the range is between /17 and /23 the third octet. Finally, if the range is between /25 and /31 the fourth octet.

Trick #2 The ‘in rule’

All subnet masks are continuous 1’s. A subnet mask is never discontinuous like 10100111.

Therefore if we have a mask of /17 we can determine right away from our previous trick that we’re only ‘1 in’ the octet. A /20 would be ‘4 in’ and a /23 would be ‘7 in’ or alternatively, ‘1 back’.

1 in or 7 back = 128 subnet size. Decimal notation is .128.
2 in  or 6 back = 64 subnet size. Decimal notation is .192.
3 in or 5 back = 32 subnet size. Decimal notation is .224.
4 in or 4 back = 16 subnet size. Decimal notation is .240.
5 in or 3 back = 8 subnet size. Decimal notation is .248.
6 in or 2 back = 4 subnet size. Decimal notation is .252.
7 in or 1 back = 2 subnet size. Decimal notation is .254.
8 in = The next octet. Doesn’t apply. Refer to Trick #1.

If you memorize the eight powers of two you’ll always know the correct subnet size.

Trick #3 Subtracting from 256

If we have a mask of /18 we know its equal to 255.192.0.0 in decimal notation. In this mask we only care about octets that are neither 255 or 0. So in this case its 192. To quickly find out the subnet size, we can just subtract 256 with 192! Which really quick equals 64 (our subnet size).

Trick #4 Wildcard masks

Here’s our mask /26. How do we find out the wildcard mask? Well first we convert it to dotted decimal notation. /26 equals 255.255.255.192

To get the wildcard mask all we do is simply subtract the DDN from 255.

255.255.255.255
255.255.255.192 -
000.000.000.063 <-- Wildcard Mask

Or an even faster way is to take the subnet size /26 equals a 64 and simply subtract 1 which still equals 63.

Last example: /19 is 255.255.224.0
224 equals a subnet size of 32 in the third octet.
Therefore our wildcard mask is 0.0.31.255

Subnet in Binary

Subnetting is one of the most important pieces of knowledge an engineer must know. There’s quick ways to subnet but before learning the tricks, it’s important to know what is actually happening in binary.

An IPv4 address consists of 32 individual bits ranging between 0.0.0 – 255.255.255.255. The reason for this is due to 255 being the biggest decimal number that we’re able to express in binary with 8 bits. 1111 1111 = 255.

Classful Address Ranges

Everyone has probably heard of these once or twice. The classes of addresses. Class A, B, C.

Class A: 1.0.0.0 – 126.0.0.0 ( a /8)

Class B: 128.0.0.0 – 191.255.0.0 ( a /16)

Class C: 192.0.0.0 – 223.255.255.0 (a /24)

Now that we know what they are, lets throw them out the window! This is no longer used any longer and now we incorporate classless subnetting called VLSM – variable length subnet masks. However, we need to know the address ranges of the classful subnets due to some older protocols like RIP. (and old people)

VLSM

VLSM means that the mask for example /24 or 255.255.255.0 determines the subnet size and no longer relies on the Class like A, B, or C to determine the subnet mask.

For instance you can have an address start with the class A IP address of 8.0.0.0 which by old standards would mean that you own all the IP address space of 8.0.0.0 – 8.255.255.255 (16,777216 addresses) but nowadays would be subnetted down through VLSM to maybe a /15 or 255.254.0.0. Which would give us an address range of 8.0.0.0 – 8.1.255.255.

Binary

Lets break down the previous example with binary and how it actually works. We used an 8.0.0.0 with a subnet mask of 255.254.0.0 or in CIDR (classless inter-domain routing notation) a /15.

Binary is simply either a 0 or a 1. An IPv4 address has 32 bits ( a bit is a 0 or a 1) cut into four separate chunks called octets. Therefore, an IPv4 address is composed of bits in the pattern of:

00000000.00000000.00000000.00000000 <-- 32 bits 
This example equals 0.0.0.0

00001000.00000000.00000000.00000000 equals 8.0.0.0
11111111.11111110.00000000.00000000 equals the subnet mask of 255.254.0.0

By looking at the above mask in binary, we can determine which bits are ‘locked’ and are non-permeable. Lets bold the Network ID with the Subnet Mask.

00001000.00000000.00000000.00000000 <- 8.0.0.0
11111111.11111110.00000000.00000000 <- 255.254.0.0

Going from the above, these bold bits are locked and can not be changed. To get the broadcast ID ( the last address in the subnet) we simply flip the unlocked bits.

00001000.00000000.00000000.00000000 <- 8.0.0.0 Original
00001000.00000001.11111111.11111111 <- 8.1.255.255 Flipped

By flipping our unlocked bits our broadcast ID is found of 8.1.255.255.

8.0.0.0 Network ID
255.254.0.0 Subnet Mask
8.1.255.255 Broadcast ID

One more example. 172.16.0.0/19

The /19 represents 19 locked bits meaning they can never change in this subnet. Lets show the the network ID and mask in binary.

10101100.00010000.00000000.00000000 equals 172.16.0.0
11111111.11111111.11100000.00000000 equals /19 or 255.255.224.0

If we flip the unlocked bits we get our broadcast

10101100.00010000.00000000.00000000 equals 172.16.0.0
10101100.00010000.00011111.11111111 equals 172.16.31.255

172.16.0.0 Network ID
255.255.224.0 Subnet ID
172.16.31.255 Broadcast ID

So now that we know what is actually happening at the bit level, we’re now ready to move on to faster ways to subnet. We’ll cover that in my next post Quick Subnetting!

 

 

 

 

A deep dive into the OSPF adjacency process

Although, the topology begs to differ...
Let me preface this by saying that this is not a crazy topology…

OSPF Packet Type Overview

OSPF uses it’s own protocol for communication.

This protocol defines five different packet types.

  1. Hello
  2. Database Descriptor
  3. Link-State Request
  4. Link-State Update
  5. Link-State Acknowledgement.

OSPF Adjacency Overview

RFC 2328 Adjacency States

Down State

A hello packet has not been heard.

Init State

A hello packet has been heard but does not list it’s own router ID.

2-way State

A hello packet has been heard and also is listing it’s own router ID. (both seen each other)

ExStart State

The two routers elect a master and a slave based on their Router ID and determine sequence numbers.

Exchange State

Routers start exchanging DBD Packets between each other.

Loading State

The routers send LSR’s to finish populating the LSDB.

Full State

The routers have finished syncing and have same LSDBs.

 

Now for the gory details

The standard OSPF Header and Hello Packet

Blue is the standard header / Red is the Hello

The Down State of the Adjacency

The routers are sending hello’s but have not received a hello packet from any neighbor. So sad.

Quick refresher on OSPF adjacency requirements:

  • MTU must match
  • Must be in same subnet
  • Same Area and type! (stub must match in entire area)
  • Router ID’s must be unique
  • Hello and Hold Timers must match

 

Two of the five above requirements are covered with a simple OSPF header with two more in the hello packet. MTU comes into play with the next packet type.

OSPF Header
Version: 2
Message Type: Hello Packet (1)
Packet Length: 44
Source OSPF Router: 2.2.2.2
Area ID: 0.0.0.0 (Backbone)
Checksum: 0xe79e [correct]
Auth Type: Null (0)
Auth Data (none): 0000000000000000

OSPF Hello Packet
Network Mask: 255.255.255.252
Hello Interval [sec]: 10
Options: 0x12 ((L) LLS Data block, (E) External Routing)
Router Priority: 1
Router Dead Interval [sec]: 40
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
OSPF LLS Data Block

Init and 2-way State of Adjacency

A router is now sending Hello Packets and as soon as a  router receives a Hello Packet, it enters Init State. Keep in mind that that Hello Packet still did not list its own router ID just yet.

The routers enter the 2-way State when the neighbors have both heard their own router ID’s in the network ID field of the hello packets.

Before transitioning to the next state, a DR and BDR is elected if necessary. If using the defaults, the higher router ID wins.

OSPF Hello Packet
Network Mask: 255.255.255.252
Hello Interval [sec]: 10
Options: 0x12 ((L) LLS Data block, (E) External Routing)
Router Priority: 1
Router Dead Interval [sec]: 40
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
Active Neighbor: 1.1.1.1

Database Description Packet

Up until now we’ve only seen one type of packet being used — the Hello Packet — now we’ll introduce another packet that is only ever utilized during the adjacency process.

Introducing, the Database Description Packet!

OSPF Database Description packet

A Database Description packet hereby known as a DD Packet only has a few fields which we’ll focus on at the moment.

  • I — Initial bit — set if it is the first packet being sent
  • M — More bit — set if there is more packets to send
  • MS — Master Slave bit — set if router is the master
  • LSA — Link State Advertisement Header

Knowledge of this packet leads us into our next adjacency phase.

EXSTART in green / Exchange in purple

EXSTART Adjacency Phase

So both routers have seen each other and are now ready to begin exchanging information. In this state the routers need to determine which one will be the MASTER and which one will be the SLAVE.

They both begin by sending empty DD Packets with the I, M and MS bit set to 1. They also both choose a DD sequence number.

Its at this point in time where the router with the lower router ID will realize that it should become the slave. Once this occurs, the SLAVE will adopt the sequence number of the MASTER and set it’s own MS bit to 0.

The entire purpose of the MASTER SLAVE relationship is to determine which router will send the initial DD Packets and set the sequence numbers.

vIOS2 as the master

OSPF DB Description
Interface MTU: 1500
Options: 0x52 (O, (L) LLS Data block, (E) External Routing)
DB Description: 0x07 ((I) Init, (M) More, (MS) Master)
…. 0… = (R) OOBResync: Not set
…. .1.. = (I) Init: Set
…. ..1. = (M) More: Set
…. …1 = (MS) Master: Yes
DD Sequence: 8146
OSPF LLS Data Block

 

vIOS1 as the SLAVE

OSPF DB Description
Interface MTU: 1500
Options: 0x52 (O, (L) LLS Data block, (E) External Routing)
DB Description: 0x00
…. 0… = (R) OOBResync: Not set
…. .0.. = (I) Init: Not set
…. ..0. = (M) More: Not set
…. …0 = (MS) Master: No
DD Sequence: 8146
OSPF LLS Data Block

Notice that vIOS1 has adopted vIOS2’s sequence number and has changed the I, M and MS bits to 0.

The SLAVE has agreed upon the DD Sequence Numbers and MASTER election. Time to move on to the next phase.

The OSPF Exchange Phase

The MASTER is now sending DD packets that are no longer empty. Instead, they hold LSA header information. We’ll cover the LSA’s in another post since this one is getting lengthy. Nonetheless, below is the first non-empty DD Packet sent from vIOS2.

vIOS2
OSPF DB Description
Interface MTU: 1500
Options: 0x52 (O, (L) LLS Data block, (E) External Routing)
DB Description: 0x01 ((MS) Master)
…. 0… = (R) OOBResync: Not set
…. .0.. = (I) Init: Not set
…. ..0. = (M) More: Not set
…. …1 = (MS) Master: Yes
DD Sequence: 8147

LSA-type 1 (Router-LSA), len 48
.000 0011 1010 1110 = LS Age (seconds): 942
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)
LS Type: Router-LSA (1)
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000003
Checksum: 0x121f
Length: 48

LSA-type 2 (Network-LSA), len 32
.000 0011 1010 1110 = LS Age (seconds): 942
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)
LS Type: Network-LSA (2)
Link State ID: 192.168.0.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000001
Checksum: 0x02bb
Length: 32
OSPF LLS Data Block

That one packet has two LSA’s a type 1 and a type 2.

vIOS1 will acknowledge receipt of the above packet by sending a DD packet back to vIOS2 with the same DD sequence number which in this case if looking above is 8147.

vIOS1 (the slave) is only sending empty DD packets for acknowledgement only. It is not advertising any of it’s own LSA’s through DD packets. Since there was only one DD packet to send which is indicated with the 0 bit set in the ‘More’ field, we’ve now reached the second to final stage.

OSPF Loading Phase

Time to introduce the final OSPF packet types: a Link-State Request Packet, Link-State Update Packet and finally a Link-State Acknowledgement packet. These are the last types of packets I promise!

Link-State Request Packet

This packet is sent from a router if it does not have up to date information regarding the LSA header that it received from the DD packets. It knows whether or not its up to date from the LSA age field in the initial DD packets.

vIOS1
OSPF Header
Link State Request
LS Type: Router-LSA (1)
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
Link State Request
LS Type: Network-LSA (2)
Link State ID: 192.168.0.2
Advertising Router: 2.2.2.2

Notice in the above packet vIOS1 is asking vIOS2 to send it information regarding two LSA’s.

So how does vIOS2 respond to a LSA Request Packet? With a LSA Update Packet.

OSPF LSA Update Packet

LSA Update Packet

This packet contains two fields. The number of LSA’s in the packet and the actual LSA’s themselves.

Below is the LSA Update Packet that vIOS2 sends upon receiving the LSA Request Packet.

vIOS2
OSPF Header
LS Update Packet
Number of LSAs: 2
LSA-type 1 (Router-LSA), len 48
.000 0000 0001 1010 = LS Age (seconds): 26
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)

LS Type: Router-LSA (1)
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000033
Checksum: 0xb14f
Length: 48
Flags: 0x00
Number of Links: 2
Type: Stub ID: 2.2.2.2 Data: 255.255.255.255 Metric: 1
Link ID: 2.2.2.2 – IP network/subnet number
Link Data: 255.255.255.255
Link Type: 3 – Connection to a stub network
Number of Metrics: 0 – TOS
0 Metric: 1
Type: Transit ID: 192.168.0.2 Data: 192.168.0.2 Metric: 1
Link ID: 192.168.0.2 – IP address of Designated Router
Link Data: 192.168.0.2
Link Type: 2 – Connection to a transit network
Number of Metrics: 0 – TOS
0 Metric: 1

LSA-type 2 (Network-LSA), len 32
.000 0011 0110 1001 = LS Age (seconds): 873
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)
LS Type: Network-LSA (2)
Link State ID: 192.168.0.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000005
Checksum: 0xf9bf
Length: 32
Netmask: 255.255.255.252
Attached Router: 2.2.2.2
Attached Router: 1.1.1.1

vIOS1 receives the update packet and acknowledges receipt with the final packet type a LSA Acknowledgement Packet which is discussed below.

OSPF LSA Acknowledgement Packet

LSA Acknowledgement Packet

This packet shares almost the same exact structure as a Database Description packet except it doesn’t have a sequence number field.

OSPF Header
LSA-type 1 (Router-LSA), len 48
.000 0000 0001 1010 = LS Age (seconds): 26
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)

LS Type: Router-LSA (1)
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000033
Checksum: 0xb14f
Length: 48
LSA-type 2 (Network-LSA), len 32
.000 0011 0110 1001 = LS Age (seconds): 873
0… …. …. …. = Do Not Age Flag: 0
Options: 0x22 ((DC) Demand Circuits, (E) External Routing)

LS Type: Network-LSA (2)
Link State ID: 192.168.0.2
Advertising Router: 2.2.2.2
Sequence Number: 0x80000005
Checksum: 0xf9bf
Length: 32

During the loading phase an OSPF router will continue requesting link-state information until it can build a complete database. The routers will continue sending link-state request, link-state update and link-state acknowledgement packets until this is achieved.

OSPF Full Phase

At this point adjacency has been fully established and the databases between area neighbors are fully synchronized.

We didn’t cover the LSA types in this post so we’ll save it for next time. All information in this post is in reference to RFC 2328.

Thanks for reading!