Quick Tip: TOS Ping in JUNOS

I recently ran into an issue with Class of Service on an SRX device where DSCP markings on traffic we not being seen on an upstream router when going through an SRX. After running packet captures showing the DSCP-marked traffic leaving the SRX the customer still wanted to proceed with troubleshooting the SRX as being at fault.

Because of this, I wanted to generate traffic with the DSCP markings directly from the SRX. In order to do this we can use a simple ping in order to generate a Type of Service (TOS) value. The command to do so is below:

ping tos <value> <host>

The <value> is where we set a TOS value, and <host> is the destination address we want to ping.

In the example below, we will use a TOS value of 46, and ping the host 1.2.3.4:

ping tos 46 1.2.3.4

From here we can open a second CLI window and can monitor traffic coming in and out of the SRX.

root@SRX> monitor traffic interface ge-0/0/0.0 detail matching "host 1.2.3.4" no-resolve   
Address resolution is OFF.
Listening on ge-0/0/0.0, capture size 1514 bytes

14:09:15.098657 Out IP (tos 0x2e,ECT(0), ttl  64, id 57053, offset 0, flags [none], proto: ICMP (1), length: 84) 1.1.1.1 > 1.2.3.4: ICMP echo request, id 56818, seq 0, length 64
14:09:15.163678  In IP (tos 0x0, ttl  60, id 43312, offset 0, flags [none], proto: ICMP (1), length: 84) 1.2.3.4 > 1.1.1.1: ICMP echo reply, id 56818, seq 0, length 64

Note how the packets are tagged with the TOS 0x2e going out, but the ICMP replies are coming back with the DSCP marker stripped! In this case, an intermediary switch the SRX was connected to was not trusting the DSCP markings. After that issue was corrected here is what we saw instead:

root@SRX> monitor traffic interface ge-0/0/0.0 detail matching "host 1.2.3.4" no-resolve   
Address resolution is OFF.
Listening on ge-0/0/0.0, capture size 1514 bytes

14:09:15.098657 Out IP (tos 0x2e,ECT(0), ttl  64, id 57053, offset 0, flags [none], proto: ICMP (1), length: 84) 1.1.1.1 > 1.2.3.4: ICMP echo request, id 56818, seq 0, length 64
14:09:15.163678  In IP (tos 0x2e,ECT(0), ttl  60, id 43312, offset 0, flags [none], proto: ICMP (1), length: 84) 1.2.3.4 > 1.1.1.1: ICMP echo reply, id 56818, seq 0, length 64

I hope this neat little trick helps someone else out in the future!

JNCIS-SP – Intro to IS-IS

While waiting to hear back on the results of my JNCIE-ENT exam I have decided to start learning about the service provider realm. In particular there are many techniques in the service provider realm that could be used to enhance the toolset of any engineer, and potentially can be used to re-think the architecture of any enterprise. In this post I will discuss IS-IS, and how to perform a basic configuration of it.

What is IS-IS?

IS-IS is an interior gateway protocol used in many networking environments to dynamically update routes. It utilizes link-state information to make routing decisions, and uses Dijkstra’s algorithm to calculate the shortest path on the network – similar to OSPF.

An IS-IS network is called an Autonomous System (AS) and is divided up into segments called Areas. A single AS can contain multiple areas, and each area contains End Systems (ESs) and Intermediate Systems (ISs). ESs send and receive packets while ISs send, receive, and relay packets to other ISs. For simplicity’s sake we will consider an IS a router from this point forward.

In each area a router can be configured to relay routes into its own area (Level 1), relay routes to another area or AS (Level 2), or act as both a Level 1 and Level 2 router. This is very similar to OSPF as Level 2 router could be considered a backbone area, and a Level 1&2 router behaves like an area border router.

How Do I Configure IS-IS?

IS-IS is relatively straightforward to configure:

  1. Enable family iso on each logical interface that will participate in IS-IS
  2. Configure a loopback interface with an ISO Network Address
  3. Enable the interface under protocols isis

Configuring the interface:

ge-0/0/0 {
    unit 0 {
        family inet {
            address 10.0.0.2/24;
        }
        family iso;
    }
}

Configuring the loopback:

lo0 {
    unit 0 {
        family inet {
            address 192.168.254.3/32;
        }
        family iso {
            address 49.0001.1921.6800.2543.00;
        }
    }
}

Enabling the interfaces:

protocols {
    isis {
        interface ge-0/0/0.0;
        interface lo0.0
    }
}

Now let us move on to a little more advanced design. The diagram below shows two Juniper SRX’s in packet mode that will be participating in IS-IS. In particular we will be configuring two virtual routers, and two IS-IS areas that will share routing information:

image

Let’s first start with the interface configuration.

SRX1:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 10.0.0.1/24;
            }
            family iso;
        }
    }
    lt-0/0/0 {
        unit 1 {
            encapsulation ethernet;
            peer-unit 2;
            family inet {
                address 172.16.1.0/31;
            }
            family iso;
        }
        unit 2 {
            encapsulation ethernet;
            peer-unit 1;
            family inet {
                address 172.16.1.1/31;
            }
            family iso;
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 10.1.0.1/24;
            }
            family iso;
        }                               
    }
    lo0 {
        unit 1 {
            family inet {
                address 192.168.254.1/32;
            }
            family iso {
                address 49.0001.1921.6800.2541.00;
            }
        }
        unit 2 {
            family inet {
                address 192.168.254.2/32;
            }
            family iso {
                address 49.0002.1921.6800.2542.00;
            }
        }
    }
}

SRX2:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 10.0.0.2/24;
            }
            family iso;
        }
    }
    lt-0/0/0 {
        unit 1 {
            encapsulation ethernet;
            peer-unit 2;
            family inet {
                address 172.16.1.2/31;
            }
            family iso;
        }
        unit 2 {
            encapsulation ethernet;
            peer-unit 1;
            family inet {
                address 172.16.1.3/31;
            }
            family iso;
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 10.1.0.2/24;
            }
            family iso;
        }                               
    }
    lo0 {
        unit 1 {
            family inet {
                address 192.168.254.3/32;
            }
            family iso {
                address 49.0001.1921.6800.2543.00;
            }
        }
        unit 2 {
            family inet {
                address 192.168.254.4/32;
            }
            family iso {
                address 49.0001.1921.6800.2544.00;
            }
        }
    }
}

In this example the SRX’s have multiple loopback addresses configured. These will be used to identify the connections inside each AS belonging to each router. The address can be variable in length ranging from eight octets to twenty octets, and consists of 5 major parts:

  • Authority and Format Identifier (AFI)
  • Domain ID
  • Area ID
  • System ID
  • Selector

In the case of the configured ISO addresses they are omitting the Domain ID. In the example of SRX1 lo0.1 and its address 49.0001.1921.6800.2541.00:

  • AFI: 49
  • Area ID: 0001
  • System ID: 1921.6800.2541
  • Selector: 00

The AFI and Area ID on each loopback address should match up to the area listed in each diagram.

Now onto the virtual router configuration, and enabling IS-IS in each virtual router.

SRX1:

routing-instances {
    r1 {
        instance-type virtual-router;
        interface ge-0/0/0.0;
        interface lt-0/0/0.1;
        interface lo0.1;
        protocols {
            isis {
                interface ge-0/0/0.0 {
                    level 2 disable;
                }
                interface lt-0/0/0.1;
                interface lo0.1 {
                    level 2 disable;
                }
            }
        }
    }
    r2 {
        instance-type virtual-router;
        interface lt-0/0/0.2;
        interface ge-0/0/1.0;
        interface lo0.2;
        protocols {                     
            isis {
                interface lt-0/0/0.2;
                interface ge-0/0/1.0 {
                    level 2 disable;
                }
                interface lo0.2 {
                    level 2 disable;
                }
            }
        }
    }
}

SRX2:

routing-instances {
    r1 {
        instance-type virtual-router;
        interface ge-0/0/0.0;
        interface lt-0/0/0.1;
        interface lo0.1;
        protocols {
            isis {
                interface ge-0/0/0.0 {
                    level 2 disable;
                }
                interface lt-0/0/0.1;
                interface lo0.1 {
                    level 2 disable;
                }
            }
        }
    }
    r2 {
        instance-type virtual-router;
        interface lt-0/0/0.2;
        interface ge-0/0/1.0;
        interface lo0.2;
        protocols {                     
            isis {
                interface lt-0/0/0.2;
                interface ge-0/0/1.0 {
                    level 2 disable;
                }
                interface lo0.2 {
                    level 2 disable;
                }
            }
        }
    }
}

With the exception of the lt interfaces, all interfaces have level 2 explicitly disabled. This is to ensure that those interfaces cannot establish adjacencies to routers outside of their respective areas. Let’s take a look at the interfaces and adjacencies below:

SRX1:

root@SRX-1> show isis interface instance r1    
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-0/0/0.0            1   0x2 SRX-1.02          Disabled               10/10
lo0.1                 0   0x1 Passive           Disabled                0/0
lt-0/0/0.1            3   0x1 SRX-1.00          1921.6800.2542.03      10/10

root@SRX-1> show isis interface instance r2    
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-0/0/1.0            1   0x2 1921.6800.2542.00 Disabled               10/10
lo0.2                 0   0x1 Passive           Disabled                0/0
lt-0/0/0.2            3   0x3 1921.6800.2542.00 1921.6800.2542.03      10/10

SRX2:

root@SRX-2> show isis interface instance r1    
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-0/0/0.0            1   0x1 SRX-1.02          Disabled               10/10
lo0.1                 0   0x1 Passive           Disabled                0/0
lt-0/0/0.1            3   0x1 SRX-2.02          SRX-2.02               10/10

root@SRX-2> show isis interface instance r2    
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-0/0/1.0            1   0x1 SRX-2.00          Disabled               10/10
lo0.2                 0   0x1 Passive           Disabled                0/0
lt-0/0/0.2            3   0x2 SRX-2.02          SRX-2.02               10/10

It appears that all the interfaces are configured correctly. Let’s check the adjacencies:

SRX1:

root@SRX-1> show isis adjacency instance r1 
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            SRX-2          1  Up                   24  0:c:29:48:6d:a4
lt-0/0/0.1            SRX-1          2  Up                    8  2:96:14:10:1:34

root@SRX-1> show isis adjacency instance r2    
Interface             System         L State        Hold (secs) SNPA
lt-0/0/0.2            1921.6800.2541 2  Up                   22  2:96:14:10:1:33

SRX2:

root@SRX-2> show isis adjacency instance r1 
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            SRX-1          1  Up                    7  0:c:29:a5:26:b3
lt-0/0/0.1            SRX-2          1  Up                    8  2:96:14:10:1:34
lt-0/0/0.1            SRX-2          2  Up                    8  2:96:14:10:1:34

root@SRX-2> show isis adjacency instance r2    
Interface             System         L State        Hold (secs) SNPA
lt-0/0/0.2            1921.6800.2543 1  Up                   24  2:96:14:10:1:33
lt-0/0/0.2            1921.6800.2543 2  Up                   24  2:96:14:10:1:33

That is odd; it appears that IS-IS established adjacencies across ge-0/0/0 and the lt interfaces, but not ge-0/0/1. Let’s monitor traffic on ge-0/0/1 and see what is going on:

SRX1:

root@SRX-1> monitor traffic interface ge-0/0/1 detail no-resolve 
Address resolution is OFF.
Listening on ge-0/0/1, capture size 1514 bytes

--snip--

01:06:46.358359  In IS-IS, length 48
        L1 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)
          source-id: 1921.6800.2544,  holding time: 27s, Flags: [Level 1 only]
          lan-id:    1921.6800.2544.00, Priority: 64, PDU length: 48
            Protocols supported TLV #129, length: 2
              NLPID(s): IPv4 (0xcc), IPv6 (0x8e)
            IPv4 Interface address(es) TLV #132, length: 4
              IPv4 interface address: 10.1.0.2
            Area address(es) TLV #1, length: 4
              Area address (length: 3): 49.0001
            Restart Signaling TLV #211, length: 3
              Flags [none], Remaining holding time 0s

--snip--

I think we found our problem; as per the diagram the address should be 49.0002 when coming from SRX2’s lo0.2 interface. Let’s correct that:

SRX2:

root@SRX-2> edit 
Entering configuration mode

[edit]
root@SRX-2# delete interfaces lo0.2 family iso address 49.0001.1921.6800.2544.00 

[edit]
root@SRX-2# set interfaces lo0.2 family iso address 49.0002.1921.6800.2544.00  

[edit]
root@SRX-2# commit and-quit

Now let’s check the adjacencies one more time:

SRX1:

root@SRX-1> show isis adjacency instance r1                         
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            SRX-2          1  Up                   20  0:c:29:48:6d:a4
lt-0/0/0.1            1921.6800.2542 2  Up                    8  2:96:14:10:1:34

root@SRX-1> show isis adjacency instance r2    
Interface             System         L State        Hold (secs) SNPA
ge-0/0/1.0            1921.6800.2544 1  Up                   25  0:c:29:48:6d:ae
lt-0/0/0.2            SRX-1          2  Up                   20  2:96:14:10:1:33

SRX2:

root@SRX-2> show isis adjacency instance r1    
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            1921.6800.2541 1  Up                    7  0:c:29:a5:26:b3
lt-0/0/0.1            1921.6800.2544 2  Up                    7  2:96:14:10:1:34

root@SRX-2> show isis adjacency instance r2    
Interface             System         L State        Hold (secs) SNPA
ge-0/0/1.0            SRX-1          1  Up                    6  0:c:29:a5:26:bd
lt-0/0/0.2            SRX-2          2  Up                   25  2:96:14:10:1:33

Perfect! And now look at the routing:

SRX1:

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

10.1.0.0/24        *[IS-IS/18] 00:04:13, metric 20
                    > to 172.16.1.1 via lt-0/0/0.1
172.16.1.2/31      *[IS-IS/15] 01:55:23, metric 20
                    > to 10.0.0.2 via ge-0/0/0.0
192.168.254.2/32   *[IS-IS/18] 01:54:31, metric 10
                    > to 172.16.1.1 via lt-0/0/0.1
192.168.254.3/32   *[IS-IS/15] 01:55:23, metric 10
                    > to 10.0.0.2 via ge-0/0/0.0
192.168.254.4/32   *[IS-IS/18] 00:04:07, metric 20
                    > to 172.16.1.1 via lt-0/0/0.1

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

10.0.0.0/24        *[IS-IS/18] 01:54:31, metric 20
                    > to 172.16.1.0 via lt-0/0/0.2
172.16.1.2/31      *[IS-IS/15] 00:04:08, metric 20
                    > to 10.1.0.2 via ge-0/0/1.0
192.168.254.1/32   *[IS-IS/18] 01:54:31, metric 10
                    > to 172.16.1.0 via lt-0/0/0.2
192.168.254.3/32   *[IS-IS/18] 01:54:31, metric 20
                    > to 172.16.1.0 via lt-0/0/0.2
192.168.254.4/32   *[IS-IS/15] 00:04:08, metric 10
                    > to 10.1.0.2 via ge-0/0/1.0

We have now successfully configured IS-IS inside Junos!

More to come soon.