Ok, so my lab is now moved upstairs and all the final pieces of kit have arrived.
The lab now consists of;
R1 - 2610xm w/WIC-2T
R2 - 2610xm w/ 2x WIC-1T
R3 - 2610xm w/ NM-4A/S, 2x WIC-1T
R4 - 1841 w/ WIC-2T
R5 - 2611xm w/ 2x WIC-1T
R6 - 2611xm w/ 2x WIC-1T
FR switch - 2610xm w/ NM-4A/S, 2x WIC-1T
The more observant among you may have noticed that the FR switch has now changed from a 2611 to a 2610xm. This is due to the problems I had once I had received the second NM-4A/S etc and tried cabling to the INE Lab topology. For some reason, as soon as I enabled an interface on the NM-4A/S in the 2611 and tried to use Frame-Relay, the router would crash and reload..
Luckily, I managed to borrow a 2610xm from work, and that does not suffer the same problem. I didn't want to troubleshoot the 2611 too much, as it is obviously much older and therefore running an older version of IOS. Also, as it is the only non-xm 2600 that I have in my possession, it would not have been easy to get hold of an updated IOS.
The next obstacle I came across was with the WIC-2T in R1. For some reason, I could not get the connection to the FR-Switch to stay UP-UP, it always went UP-DOWN after a few moments. Debugging showed that frame-relay encapsulation was failing, but I could not see what was wrong.
I now believe, that because I had changed R1 from using 2x WIC-1T to using a single WIC-2T, I focused my troubleshooting on that end of the connection. Finding nothing wrong, I then played about with the FR-Switch end and must've messed up the configs..
As the WIC-2T was what had changed, and as it was the only one in a 2610xm that I was using, I (wrongly) assumed it was perhaps a hardware problem / cable problem / incompatibility issue.. So, I recabled and moved a few cards around such that my WIC-2T was in R3 and was just for point-to-point links (rather than Frame-Relay), and my R1 was back to 2x WIC-1T.
Imagine my displeasure when R1 STILL reverted to UP-DOWN.. As it was late, I gave up and went to bed.
The following day, I was sat installing my new printer and thought i'd have another look at what the problem was, thinking to myself "There MUST be something I can see using 'show' and 'debug' commands.. What if this was an exam question!?".. So, a quick 'show interface s0/0' command and I spot this;
LMI enq sent 131, LMI stat recvd 116, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
Unfortunately, that DTE was showing on both the FR-Switch interface, as well as the R1 interface.. I double-checked the config at the FR-Switch end against another, and sure enough the 'frame-relay intf-type dce' command is missing on the connection to R1.. So I put everything back how it was, and it's all now working.
I still do not know how I managed to miss this! I think it's primarily down to the text-file I had saved of the FR-Switch config. I used a template from a forum, and then ran across the DTE error that I blogged about here, so started adding the intf-type command from then.
I had (wrongly) assumed that the DTE error was due to the physical cabling, rather than specific to Frame-Relay, and so wasted a fairly large amount of time!
But, I have learned a lot about Frame-Relay, whereas before I knew absolutely zilch. I've also realised that, had this been a Dynamips / Dynagen / GNS3 set-up, I doubt I would ever have come across this problem, nor learned as much about Frame-Relay.
In amongst all of this, I've watched the videos on MPLS twice each, and tried to recreate the lab example in the videos. Unfortunately i'm not running the same equipment / IOS, so my outputs are slightly different. Because of this (and because I ran out of time), i've started on the IPSec videos, as MPLS VPNs are actually outside the scope of the CCNP ISCW exam and i'm conscience that time is marching on..