IPv4 and IPv6 Troubleshooting Enhancement through ...

17 downloads 289 Views 207KB Size Report
... of a network path between a source and a destination using traditional networking tools like ... network path discovery in production networks, without the necessity of a centralized monitoring system. ... Traceroute and SNMP supports.
Università degli Studi dell'Aquila

IPv4 and IPv6 Troubleshooting Enhancement through Reverse Path Discovery Francesco Valentini, Marco Pratesi, Fortunato Santucci

Tiziano Ionta

[email protected], {marco.pratesi, fortunato.santucci}@univaq.it

[email protected]

ABSTRACT—The analysis of a network path between a source and a destination using traditional networking tools like ping and traceroute, does not provide informations about the return path. We propose two techniques to perform network path discovery in production networks, without the necessity of a centralized monitoring system. The first solution is suitable for IPv6 networks, while the second one is suitable in both IPv4 and IPv6 contexts. In order to pursue troubleshooting efficiency and because of possible restrictive policies, the path discovery is triggered by acting only on a single device (Discovery Router), without the need of retrieving informations from multiple network equipments.

OBJECTIVES ●





IPv6 Address

2000:0:0:1::/64

2000:0:0:2::/64

2000:0:0:3::/64

IPv4 Address

10.0.0.0/30

10.0.0.4/30

10.0.0.8/30

Locating the traffic return path in the presence of asymmetric routing and, therefore, devices "invisible" to a traditional analysis (Fig. 1).

Target Router

Discovery Router \

Providing additional information to support the troubleshooting (e.g., the hop-by-hop delay). Take into account the upcoming migration to IPv6.

R1#traceroute ipv6 2000:0:0:3::2 [...]



1 2 3

Providing solutions to technicians operating in their own networks.

2000:0:0:1::2 2000:0:0:2::2 2000:0:0:3::2

4 msec 7 msec 14 msec

4 msec 5 msec 12 msec

1 msec 5 msec 17 msec

2000:0:0:4::/64

2000:0:0:5::/64

10.0.0.12/30

10.0.0.16/30

Fig 1: example of asymmetric path with a hidden device (R5) and related traceroute output.

IPv6 TROUBLESHOOTING LIMITATIONS

(1) The IPv4 Options field has been removed from the IPv6 Header, therefore the Record Route capability is missing.

(2) On Cisco devices, only few IPv6 SLAs are available and the most useful one for path discovery, i.e. ICMP Path Jitter, is unsupported.

REVERSE PATH DISCOVERY THROUGH IPv6 EXTENSION HEADERS (EH) Full IPv6 implementations must support the Hop-by-Hop Options which must be CPU processed by all nodes in the path. Cisco devices can add this EH in the ICMP Requests and in the consequent Replies, therefore it is possible to track those probes to discover the whole path. Send an ICMPv6 probe packet with the Hop-by-Hop Options extension header Routers are able to catch this kind of probe and generate local logging messages with timestamps Devices can react to log events using the scripting and automation tools and use the TFTP protocol to send collected data to the Discovery Router

(3) Manual detection of the minimum MTU along the path by sending ICMP probes of different sizes, is impossible due to the Path MTU Discovery process.

IPv4/IPv6 TRACEROUTE-BASED REVERSE PATH DISCOVERY This approach aims at the activation on the Target Router (TR) of a traceroute towards the Discovery Router (DR). The analysis can be started by a script, whose execution is triggered through the SNMP protocol. Results are provided to the Discovery Router via TFTP. Traceroute and SNMP supports both IPv4 and IPv6, so this solution is usable regardless of the IP version. Fig. 2 shows the rationale of the approach.

START

TR OIDv==0

START

No

Yes

OIDv>0 Yes

Set TR OIDv to DR IP Address

Start a traceroute to OIDv

TR OIDv==-1

Save the output to a local file

Yes

Get the output through the TFTP

No

No

Set OIDv to -1

Set TR OIDv to 0

(b)

END (a)

TR = Targer Router DR = Destination Router OIDv = SNMP MIB Object Identifier Value

Fig.2: behavior of DR (a) and of TR (b).

CONCLUSIONS Two valid solutions for the discovery of the flows return path have been identified. They can be readily implemented even within production networks through the use of currently available tools in most widely used devices (e.g., from Cisco and Juniper vendors). Most common corporate policies have been taken into account; consequently the proposed solutions have been evaluated in a real context of use and are not expected to encounter practical applicability limitations.