All Entries in the "Technology" Category
Cisco: Frame-Relay back-to-back routers in simple steps
In one of my earlier posts I have presented how to connect 3 routers in a Hub and Spoke Frame-Relay topology. Now I want to show you how to connect 2 routers back to back, in a Frame Relay topology. With a back to back connection and without any FR switch, things are a little bit different than in the Hub and Spooke topology.
First let’s have a look to the topology:
We have 2 routers, connected back to back. The interface status on both routers:
sh run int s0/0
!
interface Serial0/0
no ip address
shutdown
First let set up the encapsulation to Frame-Relay and to bring the interfaces UP:
conf t
interface S0/0
encapsulation frame-relay
no shutdown
Everything should be fine now, but it’s not, as if you check your interfaces you will see that they are in a Up/Down status on both routers:
sh int s0/0
Serial0/0 is up, line protocol is down
Even this is messing up a little bit with our brains, the Up/Down status is normal in this phase. Why? Remember that we do not have a FR switch, both interface consider themselved DTE side and LMI is not working. You can check if LMI like this:
R1#sh frame-relay lmi
LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 6 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 5
Last Full Status Req 00:00:04 Last Full Status Rcvd never
You will see Sent packages on both routers, but nothing received as there is no FR switch. In this conditions we have to disable LMI and to assign DLCIs manually. To disable LMI, issue the following command under Frame-Relay interface:
interface S0/0
no keepalive
Now interfaces should be in a Up/Up status:
sh int s0/0
Serial0/0 is up, line protocol is up
As in this moment everything looks fine, let’s start to configure the Frame-Relay back to back connections. Obvious, at least for me, when you have a back to back connection, first things that comes into your mind is a point-to-point interface. Let’s start with this configuration (we will use from diagram the black line connection with subnet 100.100.100.0 /24) . I will show only the configuration on the primary router, but it’s the same on the secondary one, just with a different IP address in the 4th octet.
interface S0/0.100 point-to-point
ip address 100.100.100.1 255.255.255.0
frame-relay interface-dlci 100
Remember DLCIs are only local significant so you can define whatever number you want there, but of course the same DLCI number on both sides. Let’s check if everything is fine:
R1#show frame-relay map
Serial0/0.100 (up): point-to-point dlci, dlci 100(0×64,0×1840), broadcastR1#show frame-relay pvc | i STATUS
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = Serial0/0.100
We can see a point-to-point dlci in frame-relay map, and a static defined PVC. If you ping from R1 to R2 and viceversa it should work.
This was the straight forward solution, but going a little bit more into details, you can be required in some situations that you have to use a multipoint Frame-Relay interface. Actually what is a multipoint interface more than multiple point-to-point interfaces. Let’s take the sencond line (red one, with subnet 110.110.110.0 /24 in the topology) and configure this back to back connection using multipoint interfaces:
interface s0/0.110 multipoint
ip address 110.110.110.1 255.255.255.0
frame-relay map ip 110.110.110.2 110 broadcast
frame-relay map ip 110.110.110.1 110
As you see the configuration is different from the point-to-point interface. Actually under multipoint interface you can issue the frame-relay interface-dlci 110 command, but this will not help too much. Remember that we have disable LMI in the first steps because we do not have a FR switch. No FR switch means no automatic L3 to L2 mapping. In other words even if you specify the interface-dlci, the interface being a multipoint will not know where to forward packets. Why this didn’t happen in the point-to-point scenario, you may ask. Well, because there the keyword is interface sx/x point-to-point, so by it’s nature the interface knows that there is only one destination possible, meaning the other end (or point if you want).
In this scenario we had to manually map L3 to L2 with the command frame-relay map. Actually you only need the first frame-relay map, pointing to the other router IP address, but I add the last command just in case you want to ping your own interface.
Now maybe you ask which is the third scenario (blue line). Well, this is not very common in the real environment, but maybe you have to deal with it in a special condition like lab environment, Cisco exam and so on. Let’s say that you have a request that you need to have 3 virtual PVC connections, but only 2 subinterface. Now, you already have 2 subinterface configured, so how can you achieve the third PVC connection. The answer is that you configure the main interface with the same configuration like in multipoint subinterface scenario. By it’s nature and interface is described point to multipoint, so in a Frame Relay scenario like this you have to manually map L3 to L2:
interface Serial0/0
ip address 120.120.120.1 255.255.255.0
encapsulation frame-relay
no keepalive
frame-relay map ip 120.120.120.1 120
frame-relay map ip 120.120.120.2 120 broadcast
If you followed this tutorial, at the end you should have reachability over the 3 subnets.
Popularity: 7% [?]
Cisco: How to configure Frame-Relay Hub and Spoke in simple steps
Some days ago, during my preparation for CCIE RS I had to configure Frame-Relay Hub and Spoke environment. Since I already did it, I said that is good to have it here also, maybe somebody will find it useful. Even if it sounds quite complicate as title, FR hub and spoke. This post assume that you are somehow familiar with Frame-Relay concept and you know basic stuff. If you need to refresh your knowledge there is good topic about Frame-Relay on Ciscopress page.
So, what is this FR hub and spoke anyway? A basic example is with 3 device (can be more) in which on of them connect the other ones in a central point. This is the opposite to (full or circular) mesh in which every router is connected with at least another 2 devices. For things to be more clear please have a look to this topology file.
As you can see in the topology provided, R1 is connecting the other 2 routers in a central point. R1 device is the Hub and R2, R3 are the Spokes. Like explained in the topology, the green lines represent PVC circuit and red ones the physical connection. The communication between R2 and R3 will be done only through R1 since there is no PVC that connect this 2 devices. You can be tempted to say that the communication is direct, because red lines have a common point in the FR switch, but the things are not like this. This is not Ethernet, so for L3 to work you need a map from L2 to L3. Since there is no PVC define in FR switch for R2 to R3 communication, everything is passing through R1.
To configure Frame-Relay Hub and Spoke is not very difficult. The most hard part is regarding FR switch, but luckily you don’t have to deal with it, as this is usually a provider equipment, and they will do the L2 to L3 frame-relay routing, providing you with the need DLCI information. From this point you only have to be careful to details (IP, DLCI, interface) when configuring frame-relay map on your devices.
In a future post I will extend this topic and show how you can configure OSPF in a Frame-Relay Hub and Spoke environment. For now please check this topic presented in the tutorial below:
If Flash movie is not available for you, then please check this text file which contains the configuration.
Popularity: 16% [?]
Cisco: Quick IOS check in 4 simple steps
This post is rather for the beginners in Cisco’s world than for advance professionals, but still I encounter situation when IOS image was corrupted even if it was uploaded to the device by a network guru. Why? It’s quite simple! Because you can be the master of the Cisco networking, but still sometime you cannot control the device behavior or the transport of the packets to destination.
The problems is that in case of a corrupted IOS image being uploaded on a Cisco device, and having that device reloaded you can run into situation when it will not boot up anymore. When the device is in front of you, or on your desk, there is not a problem, because you can troubleshoot, find the issue (e.g wrong or corrupted IOS image) and solve it! But, what if your device is at 5000 km distance, it is 3:00 AM and you have no professional help on that location?! That’s one ugly situation and the reason for which I always insist to verify the IOS image after it is uploaded and ready to go into production.
For those of you who are dealing with this stuff everyday, this post may seem like a joke, but I bet that there are out there IT’s which never check this stuff or they are beginners and don’t know how to do it. It’s more simple that you may think it is, make you spend about 4-5 minutes for a full check, but can spare you for bigger problems in the future.
So, what are the 4 steps:
1. Check what Cisco device you have (to know what IOS image you need)
2. Check what IOS image Cisco device has (to know what IOS release to download)
3. Verify the IOS image
4. Check the results of your verification
As simplest as it can get.
Please check the tutorial by clicking the image below:
For those who cannot see a Flash movie, please read this text file, that consist of the command you should perform for IOS checking.
Popularity: 8% [?]
Cisco: OSPFv3 point-to-point network configuration
In the previous post I explained some basic stuff about IPv6 and how to configure IPv6 addresses on Cisco’s interfaces. Following this subject, I want to explain now how you can configure unicast dynamic routing protocols for IPv6 networks. The same as IPv4, the v6 generation of IP addresses supports routing protocol like OSPF, RIP and EIGRP, just that their names has been adapted to the v6 generation meaning OSPFv3, RIPng and EIGRP for IPv6.
From the routing protocols above I chose for today OSPFv3, because it is quite easy to understand and, why not, it is one my preferred routing protocols. OSPFv2 and OSPFv3 share the same key concepts, so if you understand the version for IPv4 you will have no problems to understand the one for IPv6. However, you should understand the most significant differences as well:
– to enable OSPFv3, you will have to use interface subcommands compared with the “network” statement under “router ospf” process in OSPFv2
– if there are multiple IPv6 addresses configured on a OSPFv3 enabled interface, then OPSFv3 advertise all the related networks
– OSPFv3 router-id (RID) has to be set in order to enable the routing protocol; this can be set automatically like in the OSPFv2 or manually
– OSPFv3 uses IPv4 for RID; if no IPv4 address is present on the router to be used as RID, than the OSPFv3 process cannot choose it’s RID
– OSPFv3 does not provide natively authentication like OSPFv2 does; for OSPFv3, the IPv6 structure covers this with its internal support for AH and ESP.
That’s about enough for you to configure a basic OSPFv3 routing protocol. If you are interested in more details about OSPFv3, you can check OSPFv3 documentation by Jeff Doyle and Jennifer Carroll on NetworkWorld.com
I will use the same topology like in the previous post. You can check here the IPv6 configuration of the routers. Please click below to see the tutorial:
If for some reasons the tutorial above is not available for you, please check this text file which present in text mode everything needed to enable OSPFv3 point-to-point network configuration between 2 Cisco devices.
Popularity: 9% [?]
