Protocol fundamentals – Traceroute

On July 30, 2010, in Fundamentals, by Darren

Traceroute is a powerful tool. Extremely useful when checking the path of a packet through the network. But how does it ACTUALLY work? What is REALLY going on?

Layer3 packets all have a TTL. A Time To Live. If a router receives a packet with a TTL of 1 (and the packet is addresses to a host not directly connected to this router) it will drop the packet. It will also then create an ICMP error packet and send it back to the original source of the packet to let it know that the address was unreachable this time.

If you ping another machine, the OS will generally create a TTL of 255 for sent packets, though it doesn’t HAVE to be 255.

traceroute1 Protocol fundamentals   Traceroute

Traceroute will force an ICMP error message so it can get more information from each hop in the path.

As an example, let’s run a quick traceroute to 4.2.2.1 and see what it gives us:

C:\Users\Darren>tracert 4.2.2.1

Tracing route to vnsc-pri.sys.gtei.net [4.2.2.1]
over a maximum of 30 hops:

  1   1 ms  <1 ms  <1 ms  DD-WRT [10.50.80.1]
  2   8 ms   9 ms   8 ms  10.3.280.1
  3   8 ms   9 ms  26 ms  walt-cam-1a-ge96.network.virginmedia.net [80.1.170.69]
  4  18 ms   7 ms   8 ms  popl-core-1a-ae2-0.network.virginmedia.net [195.182.175.229]
  5   8 ms   6 ms  16 ms  popl-bb-1a-as2-0.network.virginmedia.net [213.105.174.234]
  6  31 ms  15 ms  15 ms  195.50.91.69
  7  12 ms  13 ms  31 ms  ae-11-51.car1.London1.Level3.net [4.69.139.66]
  8  14 ms  16 ms  22 ms  vnsc-pri.sys.gtei.net [4.2.2.1]

Trace complete.

I’ve loaded up Wireshark to tell me exactly what’s going on. The very first packet sent from my PC was sent with a destination IP of 4.2.2.1 – but with a TTL of only 1.

traceroute2 Protocol fundamentals   TracerouteWhen my router (10.50.80.1) received that packet, it noticed that the TTL was 1, but also that 4.2.2.1 was not directly connected to it. It responded to my PC with an ICMP code 11 – Time-to-live exceeded. It also responded with it’s own source address.

traceroute3 Protocol fundamentals   Traceroute

Traceroute now knows that the very first hop to 4.2.2.1 happens to be my local router. It also knows that the routers IP is 10.50.80.1 – It send 3 ECHO reply requests with a TTL of 1. This is the reason you see the 3 values in the traceroute output

It doesn’t stop there though. As soon as traceroute knows that 10.50.80.1 is the first hop, it’ll ask 10.50.80.1 what it’s hostname is via a DNS PTR request. The router will respond to my PC with a DNS PTR response letting it know the hostname. Now traceroute knows what the IP address and hostname is for the first hop. Note that not ALL devices on the internet will respond with a PTR record and so you won’t ALWAYS get a hostname.

Traceroute will now start again and send 3 more packets with a TTL of 2. Exactly the same will happen as above, but for the second hop in the path. This will continue to happen until we eventually get to the host, or we run into the maximum hop count.

traceroute4 Protocol fundamentals   Traceroute

When we finally get ICMP echo replies from 4.2.2.1 – traceroute knows it’s job is complete.

traceroute5 Protocol fundamentals   Traceroute

btw, traceroute attempts to get PTR records from the devices in the path only when it gets a TTL time exceeded reply. The actual host you are trying to get to is different though. As soon as I ran traceroute 4.2.2.1 it immediately tried to get the PTR record of 4.2.2.1 first. Once it had that it started with all of the above.

Protocol fundamentals – ARP

On July 28, 2010, in Fundamentals, by Darren

What is ARP and how does it actually work? I’m surprised at the amount of people who don’t know exactly what it does and how important it is.

To illustrate, I’m going to use this extremely simple network:

lan Protocol fundamentals   ARP

Both of these systems are really just connected to a home router. Remember that these ports are really just switched ports. The only time they traverse a layer3 port is when they are sending traffic outside the local LAN.

ARP is the Address Resolution Protocol. Essentially all it does is resolve a logical IP address to a physical Hardware (MAC) address.

In the above diagram, if 10.20.30.108 wants to send traffic to 10.20.30.4, it will move down the IOS layers. It will eventually get down to layer2. The layer2 header needs to have both a source and a destination MAC address. 10.20.30.108 has the layer3 address already, but not layer2. This is where ARP comes into the picture.

10.20.30.108 will send a broadcast out onto the lan asking that whoever holds 10.20.30.4 respond with its MAC address (In that broadcast it’ll let everyone know what the MAC address of 10.20.30.108 is – so they can reply). When 10.20.30.4 get’s that broadcast, it’ll respond with it’s OWN MAC address with a unicast.

Once 10.20.30.108 has received 10.20.30.4′s MAC address, it will add that mapping to it’s own local ARP cache. As long as that value is in the cache, it’ll know exactly how and where to send traffic bound for 10.20.30.4

As an example, I’ve run the above through wireshark to see exactly what is happening (Click the image to see the full request and response):

arp11 150x29 Protocol fundamentals   ARP

The first ARP packet was a broadcast to the local lan asking for the owner of the 10.20.30.4 address. It also asks to respond to 10.20.30.108 (this ARP request also contains 10.20.30.108′s own MAC address) – The second packet is a simple unicast back to 10.20.30.108 letting it know that 10.20.30.4′s MAC address is 00:11:32:06:0c:8a

This can be verified as follows:

C:\Windows\system32>arp -a

Interface: 10.20.30.108 --- 0xb
  Internet Address      Physical Address      Type
  10.20.30.4            00-11-32-06-0c-8a     dynamic

ARP is one of the fundamental parts of TCP/IP – Make sure you know it :)

Tagged with:  

Educational IOS Petition

On July 22, 2010, in CCIE, by Darren

Sign it here: http://etherealmind.com/petition/

DO IT!!!

We the undersigned ask you to sign our petition.

We are the people who are learning about Data networking and Cisco IOS software. As students and practitioners, we need to learn theory and knowledge and then to take that knowledge and practice on Cisco IOS software.

We want to be able to practice that knowledge, and demonstrate our competence. We know that you are considering the value. This petition is to show our need for this solution. Wendel Odom discusses the possibility Cisco Considers IOS for Certifcation Self Study and we are calling for Cisco to make an option available.

This experience and knowledge we gain gives us the capability to make the most of Cisco equipment for our employers, your customers. We help drive the best return on investment, and keep the network performing in the way that your customers expect.

We can test configurations prior to making and be better prepared. We can develop more complex configurations than would otherwise be possible, and not blame the equipment afterwards.

We resolve problems more quickly, we make better designs and we have greater confidence in our work. We raise less support cases (and reduce your costs) by being to perform our own testing and validation.

Whether we are resellers, consultants, students or just interested in learning, we all need an practical method to access IOS and practice.

Therefore, we are asking Cisco Systems to make a version of IOS available for educational and testing purposes.

Greg Ferro

Tagged with:  

TRILL – the future of switching?

On July 22, 2010, in CCIE, by Darren

STP works extremely well, but you lose operational links with it. i.e. you lose bandwidth. There are also quite a few other problems with STP (convergence speed being 1 of them)

TRILL seems to be the new technology coming in to resolve this. I’ve gone through the RFC: http://tools.ietf.org/html/rfc5556 and it looks pretty awesome stuff. I particularly like the following:

3.2. Zero Configuration and Zero Assumption

Both bridges and hubs are zero configuration devices; hubs having no
configuration at all, and bridges being automatically self-
configured. Bridges are further zero-assumption devices, unlike
hubs. Bridges can be interconnected in arbitrary topologies, without
regard for cycles or even self-attachment. Spanning tree protocols
(STPs) remove the impact of cycles automatically, and port
autolearning reduces unnecessary broadcast of unicast traffic.

A TRILL solution should strive to have a similar zero-configuration,
zero-assumption operation. This includes having TRILL solution
components automatically discover other TRILL solution components and
organize themselves, as well as to configure that organization for
proper operation (plug-and-play). It also includes zero-
configuration backward compatibility with existing bridges and hubs,
which may include interacting with some of the bridge protocols, such
as spanning tree.

VLANs add a caveat to zero configuration; a TRILL solution should
support automatic use of a default VLAN (like non-VLAN bridges), but
would undoubtedly require explicit configuration for VLANs where
bridges require such configuration.

Autoconfiguration extends to optional services, such as multicast
support via Internet Group Management Protocol (IGMP) snooping,
broadcast support via serial copy, and support of multiple VLANs.

and

3.4. Spanning Tree Management
In order to address convergence under reconfiguration and robustness
to link interruption (Section 2.2), participation in the spanning
tree (STP) must be carefully managed. The goal is to provide the
desired stability of the TRILL solution and of the entire Ethernet
link subnet, which may include bridges using STP. This may involve a
TRILL solution participating in the STP, where the protocol used for
TRILL might dampen interactions with STP, or it may involve severing
the STP into separate STPs on ‘stub’ external Ethernet link subnet
segments.

A requirement is that a TRILL solution must not require modifications
or exceptions to the existing spanning tree protocols (e.g., STP,
RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree
Protocol)).

Basically, even though TRILL sounds complicated, it very well could be plug and play (well about as plug and play as current STP mind you)

Tagged with:  

Lab Solution – MPLS Lab #1

On July 7, 2010, in CCIE, by Darren

As promised, I’ll now start writing up solutions to my previously posted labs. I hope this will spur up some conversation.  I still stress that you should always try to do the lab without my help first. This will ensure you learn how to do it properly. Also remember that there are always multiple ways to do certain labs, so don’t take my solution as gospel.

I’ll be walking through my first MPLS lab which was originally posted over here: http://mellowd.co.uk/ccie/?p=518

  • Use RIP as the routing protocol on CPE devices
  • CPE1 and CPE5 belong to Company_A
  • CPE2 and CPE6 belong to Company_B
  • Each site has a /24 that is advertised via the loopback
  • CPE1 should be able to ping CPE5’s loopback and vice-versa
  • CPE2 should be able to ping CPE6’s loopback and vice-versa
  • Different companies should NOT be able to ping each other. They must stay completely separate
  • Now remove RIP and configure it so that both companies are using OSPF
  • Once complete, remove the OSPF config and use EIGRP

The first part is very easy. As far as the config on the CPE goes, it’s standard. The CPE devices don’t know, or care, that the ISP is running MPLS. As an example, I’ve posted the relevent config from CPE6:

interface Loopback0
 ip address 172.16.2.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.4.1 255.255.255.0
 duplex auto
 speed auto
!
router rip
 version 2
 network 10.0.0.0
 network 172.16.0.0
 no auto-summary

The actual core routers also have a very simple configuration. This has already been setup in my provided configuration files. All thats needed is a IGP running correctly; CEF to be enabled; and then MPLS IP to be enabled on all links going to MPLS routers. As an example, I’ll show a bit of the configuration on CR1:

ip cef
!
interface FastEthernet0/0
 ip address 10.0.0.5 255.255.255.252
 duplex auto
 speed auto
 mpls ip
!
interface Serial1/0
 ip address 10.3.0.1 255.255.255.252
 mpls ip
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.0.0.3 area 0
 network 10.0.0.4 0.0.0.3 area 0
 network 10.2.0.0 0.0.0.3 area 0
 network 10.3.0.0 0.0.0.3 area 0
 network 10.255.255.2 0.0.0.0 area 0

The real meat of the configuration comes in on the AR routers. i.e. the edge MPLS routers that the CPE devices connect to. These are the routers which needs to hold the customer routing tables, as well as keeping customer networks separate from each other.

The first thing that needs to be done is to configure the VRF’s on each AR router that will connect. I’ll use the vrf name of CUS1 for the first customer and CUS2 for the second.

For the first customer:

AR1#(config)ip vrf CUS1
AR1#(config)rd 400:1
AR1#(config)route-target both 400:1

And now the second:

AR1#(config)ip vrf CUS2
AR1#(config)rd 400:2
AR1#(config)route-target both 400:2

We now need to setup the interfaces that the CPE devices will connect to:

AR1#interface FastEthernet0/0
AR1#ip vrf forwarding CUS1
AR1#ip address 10.1.1.2 255.255.255.0

AR1#interface FastEthernet2/0
AR1#ip vrf forwarding CUS2
AR1#ip address 10.1.2.2 255.255.255.0

Now it’s time to set up the routing protocol between the ISP vrf and the customer device. We are using RIP for this lab, so the configuration will be as follows for both customers:

AR1#router rip
AR1#version 2
AR1#no auto-summary

AR1#address-family ipv4 vrf CUS2
AR1#redistribute bgp 400 metric 10
AR1#network 10.0.0.0
AR1#no auto-summary
AR1#version 2

AR1#address-family ipv4 vrf CUS1
AR1#redistribute bgp 400 metric 10
AR1#network 10.0.0.0
AR1#no auto-summary
AR1#version 2

You can see in the above commands that we are redistributing BGP even though we haven’t configured BGP yet. Don’t worry, that step is next.

MPLS used MP-BGP for the MPLS VPN feature. i.e. it uses MP-BGP to distribute routes via each customers VRF, through the core, and then out the other side.

The first part of the MP-BGP configuration is a simple iBGP config. AR1′s configuration is below:

AR1#router bgp 400
AR1#neighbor 10.255.255.7 remote-as 400
AR1#neighbor 10.255.255.7 update-source Loopback0
AR1#no auto-summary

The second part of the MP-BGP configuration is to enable the vpnv4 part of BGP:

AR1#address-family vpnv4
 AR1#neighbor 10.255.255.7 activate
 AR1#neighbor 10.255.255.7 send-community extended

The final part is to set up the actual VRF part for each customer, and enable redistribution of RIP routes learned earlier:

AR1#address-family ipv4 vrf CUS2
AR1#redistribute rip metric 10
!
AR1#address-family ipv4 vrf CUS1
AR1#redistribute rip metric 10

To have a quick recap, this is the MPLS specific configuration now on AR1:

ip cef
!
ip vrf CUS1
 rd 400:1
 route-target export 400:1
 route-target import 400:1
!
ip vrf CUS2
 rd 400:2
 route-target export 400:2
 route-target import 400:2
!
!
interface FastEthernet0/0
 ip vrf forwarding CUS1
 ip address 10.1.1.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2/0
 ip vrf forwarding CUS2
 ip address 10.1.2.2 255.255.255.0
 duplex auto
 speed auto
!
router rip
 version 2
 no auto-summary
 !
 address-family ipv4 vrf CUS2
  redistribute bgp 400 metric 10
  network 10.0.0.0
  no auto-summary
  version 2
 exit-address-family
 !
 address-family ipv4 vrf CUS1
  redistribute bgp 400 metric 10
  network 10.0.0.0
  no auto-summary
  version 2
 exit-address-family
!
router bgp 400
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.255.255.7 remote-as 400
 neighbor 10.255.255.7 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.255.255.7 activate
  neighbor 10.255.255.7 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf CUS2
  redistribute rip metric 10
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf CUS1
  redistribute rip metric 10
  no synchronization
 exit-address-family

A similar configuration will of course need to be done on AR3.

Once done, we should be able to log onto CPE6 and ensure that it has CPE2′s networks. We should also see that it has NO access to CPE1 and CPE5′s networks. This is exactly what we see:

CPE6#sh ip route
Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.1.0 [120/10] via 10.1.4.2, 00:00:19, FastEthernet0/0
C       172.16.2.0 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 2 subnets
R       10.1.2.0 [120/10] via 10.1.4.2, 00:00:19, FastEthernet0/0
C       10.1.4.0 is directly connected, FastEthernet0/0

Can we ping CPE2′s loopback? We sure can:

CPE6#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/60/92 ms

Can we ping CPE1′s loopback? No we cannot!

CPE6#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

If we run a traceroute to CPE2′s loopback, we can see it going through the MPLS core:

CPE6#trace 172.16.1.1

Type escape sequence to abort.
Tracing the route to 172.16.1.1

  1 10.1.4.2 8 msec 0 msec 20 msec
  2 10.8.0.1 [MPLS: Labels 28/38 Exp 0] 44 msec 68 msec 84 msec
  3 10.1.2.2 [MPLS: Label 38 Exp 0] 60 msec 48 msec 28 msec
  4 10.1.2.1 112 msec *  44 msec
CPE6#

Lab done. If there are any questions, please let me know! :)

Tagged with:  

© 2009-2014 Darren O'Connor All Rights Reserved