Using the PING TOS field

The extended ping command can be useful when testing MQC policies. The IP header TOS value of packets can be explicitly set, and hence MQC configuration can subsequently be tested.

The extended ping command expects the TOS value to be set using a decimal value (see below).


R1#ping
Protocol [ip]:
Target IP address: 10.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 184
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/68 ms

If you only know or are given the DSCP marking the question then arises 'How to i derive the TOS value from the DSCP marking?

This can easily be calculated when remembering the DSCP marking denotes the decimal value of the first 6 bits of the IP TOS header field. The last 2 bits of the TOS field are not used, so will always be zero.

As an example DSCP 46 equates to 101110 binary. To convert to a TOS value simply append the last two zero bits and convert back to decimal. Therefore 101110 becomes10111000 and when converted back to decimal this becomes 184. This is the decimal TOS representation of DSCP 46.

BGP transit AS's and how to avoid

How can you prevent your own BGP AS becoming a transit path? This can be achieved by making use of a distribute-list or a prefix-list. However these methods do not scale well as future ip addressing changes or additions require access lists to be revisited.

BB1 ------ R1 (AS 101) ------- R2 (AS 101) ------- BB2

Here are 2 options that scale and do not require revisiting when ip addresses change.

OPTION 1 - Make use of the no-export community.
-------------------------------------------------------------

Here i apply the community no-export to ALL incoming bgp routes.

R1
route-map NOEXPORT
set community no-export

router bgp 101
neigh {ip addr BB1} route-map NOEXPORT in
neigh {ip addr r2} send-community


OPTION 2 – Make use of the filter-list command
-----------------------------------------------------------

Here i create an as-path access list and only allow bgp routes originated in the routers own as (AS 101) to be advertised out.

R2
ip as-path access-list 1 permit ^$

router bgp 101
neigh {ip addrBB2} filter-list 1 out


With both commands i use show ip bgp {ip address} advertise for verification of advertised routes.