Back to Back Multilink Frame-Relay

I had this task on a recent lab. I was surprised I actually got it to work (with some help from the DocCD). Sometimes I skip these boring WAN technology tasks, but sometimes they can be fun if you get them to work :)

R6 ==== R9

R6 and R6 are connected via two serial links, serial 0/2/0 and serial 0/2/1. The task says to configure these with a /31 on the subnet 172.30.96.0 network. R6 should use DLCI 609 and R9 should use DLCI 906. Now let me say the PG was mistaken in its answer, it didn't have any frame-relay whatsoever - still waiting to hear via email what the deal was. So this is my "tentative" solution, which works great.

Here is my R6 config:

interface MFR1
ip address 172.30.96.0 255.255.255.254
no keepalive
frame-relay map ip 172.30.96.0 609
frame-relay map ip 172.30.96.1 906 broadcast
frame-relay interface-dlci 609
!
interface Serial0/2/0
no ip address
encapsulation frame-relay MFR1
clock rate 2000000
no arp frame-relay
!
interface Serial0/2/1
no ip address
encapsulation frame-relay MFR1
clock rate 2000000
no arp frame-relay

Here is the R9 config:

interface MFR1
ip address 172.30.96.1 255.255.255.254
no keepalive
frame-relay map ip 172.30.96.0 609 broadcast
frame-relay map ip 172.30.96.1 906
frame-relay interface-dlci 609
!
interface Serial0/2/0
no ip address
encapsulation frame-relay MFR1
no arp frame-relay
!
interface Serial0/2/1
no ip address
encapsulation frame-relay MFR1
no arp frame-relay

The one thing I am confused about is when the task says "R6 should use DLCI 609". I don't know whether they are referring to a global-dlci type configuration where R9 uses 609 to reach R6 or if R6 should use 609 to reach R9. Anyways, here are the points to to remember:

- Create the MFR with the the "Interface MFR 1" command first. The use the enacpsulation command on each serial interface to specify the MFR number.
- When using different DLCI's on each end, remember to map your local IP to the DLCI that the other device is using. In this case R6 needs to map it's local IP address to DLCI 609, because R9 is sending on this DLCI.
- Remember "no keepalive" on the MFR interface. Otherwise the line protocol will not come up.

VRRP - Tracking the metric of a route

R5 and R6 are configured for VRRP on a LAN. R5 is to be the master unless its route to 172.30.21.0/24 disappears or its metric increases.

Here is the basic VRRP config on R5:

interface FastEthernet0/0
ip address 172.30.200.5 255.255.255.0
vrrp 1 ip 172.30.200.1
vrrp 1 priority 105
vrrp 1 authentication ipexpert

Now we need to figure out the metric threshold for the network we are tracking. Let's find our metric first:

IPeR5#show ip route 172.30.21.0 | in metric
Known via "ospf 1", distance 80, metric 65, type inter area
Advertised by eigrp 1 metric 1 1 1 1 1 route-map OSPF2EIGRP
Route metric is 65, traffic share count is 1
IPeR5#

Here we see our metric is 65. This will be our "UP" metric and anything above this will be our down metric. Let's configure the tracking object:

IPeR5(config)#track 2 ip route 172.30.21.0/24 metric threshold
IPeR5(config-track)#threshold metric ?
down Down threshold
up Up threshold
IPeR5(config-track)#threshold metric up 65 down 66
IPeR5(config-track)#int f0/0
IPeR5(config-if)#vrrp 1 track 2

Now let's check the state of our tracked object:

IPeR5#show track 2
Track 2
IP route 172.30.21.0 255.255.255.0 metric threshold
Metric threshold is Up (OSPF/65/65)
8 changes, last change 00:02:04
Metric threshold down 66 up 65
First-hop interface is Serial0/1/0
Tracked by:
VRRP FastEthernet0/0 1
IPeR5#

Let's increase our metric to 66. The route is learned via OSPF on inerface serial 0/1/0 so it is easy to change:

IPeR5(config)#interface s0/1/0
IPeR5(config-if)#ip ospf cost 65
IPeR5#
*Nov 2 22:59:35.437: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Master -> Backup
IPeR5#

Notice we are back up now...what is the state of our tracked object?

IPeR5#show track 2
Track 2
IP route 172.30.21.0 255.255.255.0 metric threshold
Metric threshold is Down (OSPF/66/66)
9 changes, last change 00:00:42
Metric threshold down 66 up 65
First-hop interface is Serial0/1/0
Tracked by:
VRRP FastEthernet0/0 1
IPeR5#

It is DOWN! Let's bring it up:

IPeR5(config-if)#ip ospf cost 64
IPeR5(config-if)#^Z
*Nov 2 23:01:05.029: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Backup -> Master
IPeR5#

Remember to be patient. The object may take 20-30 seconds to change state after the metric is changed.

Debugging an E-BGP multihop scenario

I have the following frame-relay hub and spoke topology:

R5----R2----R6

R2 is the hub, all routers are in the 150.100.100.0/24 subnet.

R2 = 150.100.100.2
R5 = 150.100.100.5
R6 = 150.100.100.6

Please note that R2 has one multipoint subinterface connected to R5 and R6. Blogspot doesn't like text drawings so I must draw it like above.

All routers are in sub-AS bgp confederations. R2 can only peer with one, and R5 and R6 must peer with each other.

The peers will not come up without ebgp-multihop configured, but suppose we forgot that. What kind of debugging could we do to lead us to that conclusion?

1) debug ip bgp

R6#
*May 25 04:46:18.587: BGP: 150.100.100.5 open active, local address 150.100.100.6
*May 25 04:46:48.587: BGP: 150.100.100.5 open failed: Connection timed out; remote host not responding, open active delayed 29387ms (35000ms max, 28% jitter)

This debug command shows us that BGP never completes the Active state. RFC 1771 tells us this about the Active state:

"In this state BGP is trying to acquire a peer by initiating a transport protocol connection."

So our TCP connection is not completing. Do you we have IP connectivity to R5? Sure:

R6#ping 150.100.100.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.100.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/102/108 ms
R6#

So now we can look higher up the protocol stack (e.g. filtering), or maybe the problem is still in the IP layer. In this case we have no ACL's applied.

2) debug ip packet detail

What I am looking for here is some packets from R5, sourced from 150.100.100.5. Debugging shows that I am getting none! However it also shows that I am getting ICMP type 11 messages from R2 immediately after I send a packet to R5:

R6#
*May 25 04:51:44.539: IP: tableid=0, s=150.100.100.6 (local), d=150.100.100.5 (Serial0/1/0), routed via FIB
*May 25 04:51:44.539: IP: s=150.100.100.6 (local), d=150.100.100.5 (Serial0/1/0), len 44, sending
*May 25 04:51:44.539: TCP src=24713, dst=179, seq=1584149779, ack=0, win=16384 SYN
*May 25 04:51:44.563: IP: tableid=0, s=150.100.100.2 (Serial0/1/0), d=150.100.100.6 (Serial0/1/0), routed via RIB
*May 25 04:51:44.563: IP: s=150.100.100.2 (Serial0/1/0), d=150.100.100.6 (Serial0/1/0), len 56, rcvd 3
*May 25 04:51:44.563: ICMP type=11, code=0

Seems that R2 is telling us something about our packet sent to R5.

3) debug ip icmp

*May 25 04:53:23.839: ICMP: time exceeded rcvd from 150.100.100.2

Here we get our answer. At this point we realize that our tcp syn packets sent to R5 have an IP TTL of 1, and thus are getting dropped by R2.

Do you know any other commands that would help you come to this conclusion?