"How to check udp port is open using IOS CLI only" or "Do you really know how traceroute works"?

Just want to share with you one interesting but very simple trick with udp traceroute which can be used to check if udp port is open or filtered. In practical case it can be very handy to use it if you think somebody in the middle filtering your ISAKM udp/500 or NAT-T udp/4500 ports for example and you can't use any third-party tools to check it (CCIE lab environment?)
Only few key things you had to remember: Cisco IOS using UDP traceroute and you can define initial destination port, moreover this port number is incremented with each subsequent packet, even if to the same hop with same TTL.
The technique is simple as said above: you need to send traceroute in such way so that intermediate hop router will receive packet with verifiable destination port number. If intermediate hop router is doing filtering and configured to allow to send ip unreachables ICMP messages, you will receive "!A" symbol in your traceroute output, meaning "Administratively filtered". This is the simplest case, but observed very rare since most of the routers configured with "no ip unreachables" to lower the load on CPU resources. Later I will also show how to check a port if "no ip unreachables" is configured on a verifiable router.

Anyway here is the example step by step, ip addresses is self-explained:

R1#traceroute 155.1.45.5 numeric probe 1 port 500
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 64 msec
  2 155.1.23.3 112 msec
  3 155.1.34.4 136 msec
  4 155.1.45.5 136 msec

All OK. At this step we know full path to the final router R5, and second router in the line (R2) was not filtering UDP/500. Lets decrement port number to 499, so next router R3 will receive UDP/500 packet:

R1#traceroute 155.1.45.5 numeric probe 1 port 499
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 60 msec
  2 155.1.23.3 124 msec
  3 155.1.34.4 108 msec
  4 155.1.45.5 148 msec

Once again all fine, R3 is not filtering,  we are decrementing destination port number again and testing R4:

R1#traceroute 155.1.45.5 numeric probe 1 port 498
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 60 msec
  2 155.1.23.3 88 msec
  3 155.1.34.4 !A

Gotcha! Next to the last router (R4) is filtering our ISAKMP packets! Here is how it looks in Wireshark:

Now let's try to do the same testing, but on R4 with "no ip unreachables" configured:

R1#traceroute 155.1.45.5 numeric probe 1 port 500
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 68 msec
  2 155.1.23.3 108 msec
  3 155.1.34.4 128 msec
  4 155.1.45.5 132 msec
R1#traceroute 155.1.45.5 numeric probe 1 port 499
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 52 msec
  2 155.1.23.3 100 msec
  3 155.1.34.4 104 msec
  4 155.1.45.5 140 msec
R1#traceroute 155.1.45.5 numeric probe 1 port 498
Type escape sequence to abort.Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 92 msec
  2 155.1.23.3 84 msec
  3  *
  4 155.1.45.5 136 msec
R1#traceroute 155.1.45.5 numeric probe 1 port 497
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 60 msec
  2 155.1.23.3 100 msec
  3 155.1.34.4 108 msec
  4  *
  5 155.1.45.5 128 msec
R1#traceroute 155.1.45.5 numeric probe 1 port 496
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 92 msec
  2 155.1.23.3 100 msec
  3 155.1.34.4 100 msec
  4 155.1.45.5 168 msec

As you can see, on the third step (bold text), exactly when R4 receives UDP/500 we can see symbol "*" which meaning timeout. On the fourth step here is also timeout, it is again because of R4 is filtering and UDP/500 packet can't reach R5. Here is how 3rd iteration looks like:

Please note that in our sandbox case filtering was made with simple extended access-list which was applied to inbound (ingress) interface to the "in" direction:

ip access-list extended DENY_IKE
 deny   udp any any eq isakmp
 permit ip any any
!
interface FastEthernet0/0
 ip address 155.1.34.4 255.255.255.0
 ip access-group DENY_IKE in

In case of this access-list applied to the outbound (egress) interface FastEthernet0/1 to the "out" direction, traceroute behavior will be different, but it still can bring us results and required information to detect intermediate hop router which performing filtering, behavior is just like in the fourth step/iteration in the previous example. 

R1#traceroute 155.1.45.5 numeric probe 1 port 496
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 104 msec
  2 155.1.23.3 100 msec
  3 155.1.34.4 140 msec
  4 155.1.45.5 128 msec
R1#traceroute 155.1.45.5 numeric probe 1 port 497
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 56 msec
  2 155.1.23.3 116 msec
  3 155.1.34.4 120 msec
  4  *
  5 155.1.45.5 156 msec
R1#traceroute 155.1.45.5 numeric probe 1 port 498
Type escape sequence to abort.
Tracing the route to 155.1.45.5
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.12.2 88 msec
  2 155.1.23.3 104 msec
  3 155.1.34.4 140 msec
  4 155.1.45.5 128 msec

Instead of conclusion I recommend for best results to make the same testing in both directions, obvious since some kind of filtering can be applied in outbound direction of ingress interface and you will not notice it until testing done from another side. Thank you for reading.

EIGRP named mode "passive-interface default" vs "af-interface default shutdown" and Virtual-Template

    As you probably know, EIGRP named mode is a new style standard for EIGRP configuration in current IOS versions. So I would like to note some interesting points on configuration.
May be not so interesting really, but this significant difference was noted between "af-interface default shutdown" and "af-interface default passive" (except it's primary goals ;)) so we need to be accurate with behavior related to Virtual-Template interfaces. Let's look at the firs useful application of "shutdown". It is very handy to use it in OSPF-like interface configuration style to include only required interfaces in routing protocol:

interface Virtual-Template1 type tunnel
 ip ospf 2 area 1

And if our Virtual-Access is connected, OSPF will enable process on this interface also:

R1#sh ip ospf interface b

Virtual-Access1            10.0.1.2        YES unset  up                    up
Virtual-Template1          10.0.1.2        YES unset  up                    down

R1#sh ip ospf interface b
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Vi1          2     1               Unnumbered Lo0     1     P2P   1/1

In this example we are enabling EIGRP only on Virtual-Template1 interface similarly to OSPF:

router eigrp TEST
 !
 address-family ipv4 unicast autonomous-system 1
  !
  af-interface default
   shutdown
  exit-af-interface
  !
  af-interface Virtual-Template1
   no shutdown
  exit-af-interface
  !
  topology base
  exit-af-topology
  network 0.0.0.0
 exit-address-family

But note significant difference. EIGRP will not be enabled on Virtual-Access interface although it is up and running:

R1#sh ip int b
Virtual-Access1            10.0.1.2        YES unset  up                    up
Virtual-Template1          10.0.1.2        YES unset  up                    down 

R1#sh ip eigrp neighbors
EIGRP-IPv4 VR(IPSEC) Address-Family Interfaces for AS(1)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Vt1                      0        0/0       0/0           0       6/6            0           0

 Now let's look at "passive-interface default" behaviour:

router eigrp TEST
 !
 address-family ipv4 unicast autonomous-system 1
  !
  af-interface default
   passive-interface
  exit-af-interface
  !
  af-interface Virtual-Template1
   no passive-interface
  exit-af-interface
  !
  topology base
  exit-af-topology
  network 0.0.0.0
 exit-address-family

And as you can see, It is all fine, up and running in such way, just as expected:

R1#sh ip int b
Virtual-Access1            10.0.1.2        YES unset  up                    up
Virtual-Template1          10.0.1.2        YES unset  up                    down

R1#sh ip eigrp neighbors
EIGRP-IPv4 VR(IPSEC) Address-Family Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   10.0.1.1                Vi1                      10 00:00:09  479  2874  0  5

All testing were made with  IOS version 15.2(4)M6. Thank you for interest to this blog post. Please say couple words in comments if it was usefull/interesting, because it seems to me nobody interested in my posts :(

Random note about bgp ttl-security, ebgp-multihop and disable-connected-check commands.

Just simple note in case you're studying ccie lab. As you know, anything you can do - you can also do it another way.
For example you need to configure eBGP session between 2 directly connected routers and initiate session from Loopback interfaces. All of the following commands will be suitable:

 ttl security hops 2 = disable-connected-check = ebgp-multihop 2

Please note that ebgp-multihop 2 and ttl-security hops 2 will also allow to establish bgp session with router one hop away, even if you're initiating session from loopbacks, it may be not desired in redundant topologies. For example:
R1 ---- R2 ---- R3
R1 and R3 can also form bgp peering.

disable-connected-check is not modifying TTL of bgp ip packets, it just allow bgp session to be established from non directly connected subnets (it disables this default precheck behavior).

Also here is interesting buggy trick to make somebody crazy. You can configure ebgp-multihop 1 and it will be not shown in configuration (as of  15.2(4)M6 ) and will not allow to configure ttl-security.
For example:

R1(config-router)#neighbor 120.100.2.1 ebgp-multihop 1
R1(config-router)#do sh run | sec bgp
router bgp 100
 bgp log-neighbor-changes
 neighbor 120.100.2.1 remote-as 300
 neighbor 120.100.2.1 update-source Loopback0
R1(config-router)#neighbor 120.100.2.1 ttl-security hops 2
Remove ebgp-multihop before configuring ttl-security
R1(config-router)#do sh run | sec bgp
router bgp 100
 bgp log-neighbor-changes
 neighbor 120.100.3.1 remote-as 300
 neighbor 120.100.3.1 update-source Loopback0
R1(config-router)#no neighbor 120.100.2.1 ebgp-multihop 1
R1(config-router)#neighbor 120.100.2.1 ttl-security hops 2