Traceroute

Tags

, , ,

Traceroute is a very cool command, it shows you the path the packet will take to the destination and all the hops in the path.

Although, it gives you these useful details, personally I don’t rely much on it, it can be considered as a very good tool for troubleshooting but going back to my CCNP TSHOOT exam and to some real life experiences, the traceroute command can trick you sometimes. So, the main tool remain the famous “PING”.

But this article is about Traceroute, so I will describe below the Traceroute process:

Imagine these guys connected to one another, let’s just simply assume that there is one path to R4 from R1 as below:

20170616_120813

R1 – R2 – R3 – R4

R1 does the traceroute to R4:

R1#debug ip icmp
ICMP packet debugging is on
R1#traceroute 30.3.4.4

Type escape sequence to abort.
Tracing the route to 30.3.4.4

1 10.1.2.2 44 msec 24 msec 28 msec
2 20.2.3.3 32 msec 56 msec 92 msec
3 30.3.4.4 72 msec 92 msec 76 msec
R1#
*Jun 16 11:56:59.323: ICMP: time exceeded rcvd from 10.1.2.2
*Jun 16 11:56:59.351: ICMP: time exceeded rcvd from 10.1.2.2
*Jun 16 11:56:59.383: ICMP: time exceeded rcvd from 10.1.2.2
*Jun 16 11:56:59.419: ICMP: time exceeded rcvd from 20.2.3.3
*Jun 16 11:56:59.479: ICMP: time exceeded rcvd from 20.2.3.3
*Jun 16 11:56:59.575: ICMP: time exceeded rcvd from 20.2.3.3
*Jun 16 11:56:59.651: ICMP: dst (10.1.2.1) port unreachable rcv from 30.3.4.4
*Jun 16 11:56:59.747: ICMP: dst (10.1.2.1) port unreachable rcv from 30.3.4.4
*Jun 16 11:56:59.831: ICMP: dst (10.1.2.1) port unreachable rcv from 30.3.4.4

So, what’s happening here:

R1 sends 3 User Datagram Protocol messages with a TTL of 1 to R4’s IP 30.3.4.4 and with a fake destination port.

When R2 gets these UDP packets, it decrements the TTL, drops the packets, and sends back to R1 straight away an ICMP Type 11 – Code 0, which means Time Exceeded Message (TEM). In other words R2 is telling to R1, you know what, your UDP packets died, they were too old.

R1 gets the responses and send again 3 UDP packets with a TTL of 2 this time.

R3  responses are the same as R2’s, it sends back to R1 a Time Exceeded Message.

R1 receives the responses from R3 and sends again 3 UDP packets, now with a TTL of 3.

R4 receives the packets, and sends back to R1 and ICMP Type 3 – Code 3, which means Destination Unreachable – Port Unreachable.

Advertisements

GRE Tunnel, Keepalives and IGP

Tags

, , ,

Generic Routing Encapsulation –  It’s a way to encapsulate packets inside a transport protocol. GRE acts like PPP and it’s done between 2 endpoints, so we can throw almost any type of traffic inside a GRE Tunnel, this is also a way where New York and London can be neighbors through EIGRP or OSPF and they can form a relationship easily by the help of GRE Tunnel and IPSec, in case you want the traffic to be encrypted.

GRE is considered stateless, and what does this mean, it means that it does not keep track of the other end of the Tunnel by default, or in other words, the other end might be down but the local Tunnel Interface it’s still up.

There are few reasons why the State is Up and the Line Protocol is Down:

Tunnel1                    192.168.1.1     YES manual up                    down

1 – There is no route to the other end of the Tunnel, including a Default Route

2 – The Interface which serves as the Tunnel Source is Down

3 – The Tunnel Destination is through the Tunnel itself.

I will post an example below of a GRE Tunnel between 2 Routers and some other specifications:

20170604_181940

I got a GRE Tunnel established between R1 and R3.

Here’s the configuration:

R1#sh run int tun 1
!
interface Tunnel1
ip address 192.168.1.1 255.255.255.252
tunnel source Loopback0
tunnel destination 3.3.3.3
!
end

And on R3:

R3#sh run int tun 1
!
interface Tunnel1
ip address 192.168.1.2 255.255.255.252
tunnel source Loopback0
tunnel destination 1.1.1.1
!
end

I’m running EIGRP also on all interfaces on every Router. Let me show you, why did I mention in the begginning of this article that GRE it’s stateless. As you can see the Tunnel between R1 and R3 is established using R1’s source Loopback 0 1.1.1.1 and R3’s source and R1’s destination Loopback 0 3.3.3.3. The behaviour of the Tunnel itself is interesting as you’re trying different things with it.

The Tunnel Destination doesn’t need to be reachable, it just needs to be routable. So for example on these R1 and R3 if I have a default route or a static route to the Tunnel Destination, the Tunnel is UP/UP and stays fine and the connection is fine, when pinging the Tunnel Destination from Loopback source or from Tunnel itself.

I the case below I got a static route on R1 to R3’s Loopback. On R3 to R1’s Loopback. And on R2 to R1 and R3’s Loopbacks respectively.

All works fine, see below:

R1#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 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R1#ping 3.3.3.3 source tun 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/55/56 ms

With the default configuration of the GRE Tunnel on both R1 and R3, when I shut down R3’s Loopback Interface, R1 simply doesn’t care and it keeps the Tunnel Up even when the Tunnel is down on R3 because the source interface of R3 is down itself:

R3:

R3(config)#int l0
R3(config-if)#sh
R3(config-if)#
*Jun 4 18:57:11.951: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Jun 4 18:57:12.951: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
R3(config-if)#
*Jun 4 18:57:17.795: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
R3(config-if)# do sh int tun 1
Tunnel1 is up, line protocol is down

R1:

R1#sh int tun 1
Tunnel1 is up, line protocol is up

R1#ping 192.168.1.2

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

As we can see, R1 says the Tunnel is UP/UP but it cannot reach the other end, in this case R3 Tunnel IP Address 192.168.1.2.

Well, this is how GRE behaves with the default configuration. Now let’s do this:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int tun 1
R1(config-if)#keepalive 3 3
R1(config-if)#
*Jun 4 19:03:12.859: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

OK, something happend, R1 sent 3 Keepalives in 9 seconds and nobody answered, so it turned down the Tunnel Interface Protocol:

R1(config-if)#do sh int tun 1
Tunnel1 is up, line protocol is down

This is interesting, because if I bring back up the Loopback Interface of R3 and shut down the Loopback Interface of R1, R3 will keep the Tunnel Up and only R1 will take down the Tunnel Interface Protocol.

R1(config-if)#int l0
R1(config-if)#sh
R1(config-if)#
*Jun 4 19:06:51.327: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Jun 4 19:06:51.875: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Jun 4 19:06:52.327: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down

R3#sh int tun 1
Tunnel1 is up, line protocol is up

Why is that ? Because R3 only responds to R1’s Keepalives sent every 3 seconds, but it does not send Keepalives itself to R1, to keep track of it. Let’s add the Keepalive to R3 under Tunnel Interface configuration:

First of all I will turn debug on R3:

R3#debug tunnel

R3#debug tunnel keepalive

R3(config)#int tun 1
R3(config-if)#keepalive 3 3
R3(config-if)#
*Jun 4 19:09:46.255: Tunnel1: sending keepalive, 1.1.1.1->3.3.3.3 (len=24 ttl=2 55), counter=1
*Jun 4 19:09:46.255: Tunnel1: GRE/IP encapsulated 3.3.3.3->1.1.1.1 (linktype=7, len=48)
*Jun 4 19:09:46.255: Tunnel1 count tx, adding 0 encap bytes
R3(config-if)#
*Jun 4 19:09:49.255: Tunnel1: sending keepalive, 1.1.1.1->3.3.3.3 (len=24 ttl=2 55), counter=2
*Jun 4 19:09:49.255: Tunnel1: GRE/IP encapsulated 3.3.3.3->1.1.1.1 (linktype=7, len=48)
*Jun 4 19:09:49.259: Tunnel1 count tx, adding 0 encap bytes
R3(config-if)#
*Jun 4 19:09:52.255: Tunnel1: sending keepalive, 1.1.1.1->3.3.3.3 (len=24 ttl=2 55), counter=3
*Jun 4 19:09:52.259: Tunnel1: GRE/IP encapsulated 3.3.3.3->1.1.1.1 (linktype=7, len=48)
*Jun 4 19:09:52.259: Tunnel1 count tx, adding 0 encap bytes
R3(config-if)#
*Jun 4 19:09:55.255: Tunnel1: sending keepalive, 1.1.1.1->3.3.3.3 (len=24 ttl=2 55), counter=4
*Jun 4 19:09:55.255: Tunnel1: GRE/IP encapsulated 3.3.3.3->1.1.1.1 (linktype=7, len=48)
*Jun 4 19:09:55.259: Tunnel1 count tx, adding 0 encap bytes
*Jun 4 19:09:55.259: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, c hanged state to down

Fair enough, R3 sends every 3 seconds Keepalives to R1 and it repeats this 3 times, after 9 seconds it brings down the Tunnel Interface Protocol as we can see above.

Well, based on the above, this behaviour is not true in case when we running an IGP above all 3 Routers and not using Static Routing. I have removed the static routes and implemented the following configuration on all 3 Routers, where I said all interfaces to participate in EIGRP, including the Tunnel Interfaces:

conf t
router eigrp 1
network 0.0.0.0 255.255.255.255
end
!

Now when i shut down the L0 on R3, R1 sees this because of EIGRP, because R1 and R3 have formed a neighborship through the Tunnel, and when the L0 goes down on R2, the Tunnel Interface Protocol goes down as well and R1 sees this, as the neighbour R3 did not respond to its Hello messages so that’s why it pulls down the Tunnel Interface Protocol:
R3(config)#int l0
R3(config-if)#sh
R3(config-if)#
*Jun 4 19:29:30.811: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Jun 4 19:29:31.811: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
R3(config-if)#
*Jun 4 19:29:34.479: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Jun 4 19:29:34.495: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.1.1 (Tunnel1) is down: interface down
R1#
*Jun 4 19:33:28.299: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.1.2 (Tunnel1) is down: holding time expired

So, it’s a good thing to use Keepalives in case you’re using a Default Route or a Static Route to the Tunnel Destination, this way you’ll know when something happend to the other end of the Tunnel and not send the traffic in vain. For this matter it is also a good idea to use PBR or IP SLA with tracking, but in case you got 2 ways to the Tunnel Destination, so you can set up the stuff in some ways that when let’s say the primary path for Tunnel fails, you’ll use another path to the Tunnel Destination.

EIGRP Stub Routing

Tags

, , , ,

When A EIGRP router loses a successor route and it does not have in its table a feasible successor route, it will go active, actively looking for another path to that lost network that he lost. In the active state, a EIGRP router send Queries asking the other routers he’s connected to and it’s neighbour with, if those routers doesn’t have a route to that network he just lost. The Query message is sent and a timer is started, this timer is used to prevent the sending router to remove other routers from its table if they do not respond to his Queries and that are waiting themselves for other routers to respond to them for that Query, because they are active for that route as we are.

So, in other words, if I sent you a query asking for way to a specific route that I lost and you do not respond to me back, because you are in the active state and waiting for a reply yourself from other routers for that specific route, I will send you a Stuck In Active Query or shortly SIA Query, and I will wait for 90 seconds. After 90 seconds, I’ll say “Hey neighbour, are you still here ?” and if I don’t get any reply from you, I will remove my route to you from my table, If I do get a reply from you, you’ll tell me “Yes buddy, I’m still here, just waiting for others to respond to your Query”, then I will not remove my route to this neighbour from my table.

Even with this operation there is sometimes a lot of fun going on in the network, because a Stub Router lost a route and he’s Quering the whole network and consumes bandwidth and increases CPU and delay and a potential for a bigger problem than his lost route.

Fortunately, there is a feature called Stub Router in EIGRP which solves this stuff. Imagine that I’m R1 and below me is hanging R2 on a link, on R2 is hanging R3 and R4, on R3 and R4 is hanging R5 and R6 respectively. Logically, I will make my Router R1 a Stub Router, because he is connected just to one neighbour, to R2 and that’s it. This way, when R1 will lose a route from it’s table, he will not send a Query message asking other routers if they do have a path to that route, because it’s useless, maybe that route that R1 have lost is a Link to some end users, or just a loopback interface which we used for testing purposes for other thing and now we shut down this loopback by mistake, this way creating the whole network to flood a queries for that route, which of course they do not have another path to. So, here’s how to make R1 a Stub and limit this Queries messages to be sent from R1 and even from R2, because he will see that I’m a Stub Router and Queries are supressed.

Stub Area, Totally Stubby Area, NSSA, Totally NSSA

Tags

, , , , , ,

Stub Area

An area in which there are no Type 4 and 5 LSA sent by ABR. Stubby Area needs to be configured on ABRs, so that they agree on this flag and form adjacency. By default, Stub Area ABR will generate a Default Route pointing to itself.

Configuration:

conf t

router ospf 1

area 1 stub

end

!

Totally Stubby Area

An Area where there are no Type 4 and Type 5 LSA and also now there is no Type 3 LSA sent by ABR. Totally Stubby Area needs to be configured on ABRs, so that they agree on this flag and form adjacency. By default, Stub Area ABR will generate a Default Route pointing to itself.

Configuration:

conf t

router ospf 1

area 1 stub no-summary

end

!

Not So Stubby Area (NSSA)

In NSSA we are allowing the redistribution unlike other Areas, but in the meantime we also stop external routes, no Type 4 and 5 LSAs. Instead the ASBR sends external routes to the ABR via Type 7 LSA. ABR converts the Type 7 LSA external routes and send them as a Type 5 LSA to the OSPF Areas. NSSA needs to be configured on ASBR and ABR, so that they agree on this flag. By default, the ABR does not generate a Default Route pointing to itself, you have to configure it to inject a Default Route manually by using the keyword “default-information-originate” under the OSPF process on the ABR.

Configuration:

conf t

router ospf 1

area 1 nssa

end

!

To inject a Default Route back to NSSA use the following:

conf t

router ospf 1

area 1 nssa default-information-originate

end

!

Totally Not So Stubby Area (Totally NSSA) – Cisco Proprietary

In Totally NSSA we do the same thing like in NSSA but we also stop Type 3 LSA from being sent to the OSPF domain. So, in other words: No Type 3, 4, 5 LSAs, but allow redistribution. By default, the ABR does generate a Default Route pointing to itself.

Configuration:

conf t

router ospf 1

area 1 nssa no-summary

end

!