Cisco | IPNET - Part 8

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(0x64,0x1840), broadcast

R1#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.

Cisco – Remote VTY Command Script

Running one or more interactive CLI commands is a common task in network management. Having a script to automate this task becomes a critical tool.

This script automates interactive TELNET or SSH sessions. Any command that can be issued in CLI can be issued via the VTY run command script in an automated fashion. Below are some example uses:

* Run a set of commands on hundreds of devices
* Configuration changes
* Archive configurations and software
* Audits, inventory and discovery
* Automated troubleshooting

Requirements

This script is written in Expect. A current version of Expect is required. Expect and installation requirements for Expect can be found at Expect Homepage

Tested on RHEL 5 running expect 5.43.0-5.1 and Mac OS X 10.6 running Expect 5.44.1.11.

The script is platform independent and should run on any platform that can run Expect.

Cisco AutoQoS VoIP

QoS – one of the most interesting and challenging part of the network engineer’s life. I think I’m not wrong when I’m saying that most engineers that hear the word QoS, react somehow like “ah, that ugly stuff…” I have to be honest and say that QoS is not one of my preferred part, but as a network engineer you have to accomplish all task, not only the one that you like. With QoS you can achieve some great results, and once you have started to work with it, you’ll see that is not such a monster. The idea that QoS is not a friendly topic was develop due to historical ways to configure this service. In fact there were so many ways that without working with this topic everyday, you have no chance to remember how has to be implemented. Even among Cisco devices, there were multiple way to configure QoS from device to device. Nowadays Cisco is putting a lot of effort to standardize the implementation of QoS and in the same time to simplify it.

In this context AutoQoS appeared. First, AutoQoS VoIP was developed as the more QoS configuration is needed for Voice traffic over the network and then a more complex Auto QoS Enterprise was released. Today I plan to speak a little bit about AutoQoS VoIP and in one of the future articles about the Enterprise edition.

AutoQoS VoIP gives you the ability to deploy QoS features for converged IP telephony and data networks in a fast and reliable way, by simplifying the MQC (Modular QoS command-line interface). AutoQoS VoIP generate automatically traffic classes and policy map CLI templates. In more human terms, if AutoQoS VoIP is configured on an interface, the traffic that is passing by is receiving the required QoS treatment automatically. By doing this automatically AutoQoS spares you from having in-depth knowledge about the services policies, link efficiency mechanism or best practice for Voice QoS. Everything is done by AutoQoS, which automatically discovers applications and provides appropriate QoS treatment, generate policies and provide configuration.

Of course that are some drawbacks like in any other technology, but this can be easy overcome if you have some knowledge about QoS configuration. It theory everything should run smoothly, but in real environment, you run into the situation that QoS should be fine tuned to reach the level of your expectation. This is easy done with AutoQoS, as after it enable and configure the QoS templates, you can easy configure them to fine tune parameters, add or delete policies. Basically you start from nice template, sourced by AutoQoS, and develop your own QoS. As I said before, you have only to do this is something is not working or if you feel the strong attraction to “make it your own way”.

AutoQoS VoIP is supported on the most popular Cisco routers and switches platform with the appropriate IOS or CatOS image. Before you configure AutoQoS VoIP you should know that:

– CEF is required to be configured, as AutoQoS use NBAR (Network-Based Application Recognition) which is based on Cisco Express Forwarding
– no QoS Policies are attached on the interface on which you are configuring AutoQoS
– correct bandwidth has to be configured on the interface; if there is no bandwidth statement, then this defaults to 1544 Mbps, which is not all the time accurate

Now a tricky part in regards to interface bandwidth. If this is 768kbps or below, you have to configure an IP address on the interface due to the fact the AutoQoS is enabling by default Multilink PPP and copy the configured IP under the multilink interface. If you configure AutoQoS on a remote site, and the 768kbps (or lower) interface is the only connection there, please pay attention as configuring AutoQoS Voip may break your connection due to MLP situation explained above.

Another recommendation from Cisco and me, is that you should use no auto qos voip command when you stop using the interface on which AutoQoS VoIP is configured. In this way you assure that all the QoS configuration will be removed. If you just shutdown the interface or delete the PVC, without the above command, then the AutoQoS VoIP will not be completely removed.

Configuration is very simple:

router# configure terminal
router(config)# interface Serial x/y
router(config-if)# bandwidth 1540
router(config-if)# auto qos voip
router(config-if)# exit

I tried to put together a scenario like in the following topology, to generate some traffic and show you have AutoQoS behave when configuring policies:

After applying the AutoQoS config you should see something like this in your running-config:

class-map match-any AutoQoS-VoIP-Remark
match ip dscp ef
match ip dscp cs3
match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
match protocol rtp audio
match access-group name AutoQoS-VoIP-RTCP
!
!
policy-map AutoQoS-Policy-UnTrust
class AutoQoS-VoIP-RTP-UnTrust
priority percent 70
set dscp ef
class AutoQoS-VoIP-Control-UnTrust
bandwidth percent 5
set dscp af31
class AutoQoS-VoIP-Remark
set dscp default
class class-default
fair-queue
!
ip access-list extended AutoQoS-VoIP-Control
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
permit udp any any range 16384 32767

I will try to generate some traffic between this, so called, voice server and client and to let AutoQoS VoIP do it’s job and configure automatically traffic flow policies.

Below you have a video tutorial about AutoQoS VoIP has to be configured and some monitoring commands that will output the result of traffic flow:

Cisco: How to configure HSRP

In this post I proposed to discuss a little bit about Hot Standby Router Protocol and how it can be configured on a Cisco device. For this I have chosen the following topology:

I had in mind this scenario due to the fact that the traffic can take multiple paths in case of link being down and this give us the possibility to have a little bit of conversation on HSRP topic.
HSRP is defined in the document RFC2281 and according to the definition in this document: “The Hot Standby Router Protocol, HSRP, provides a mechanism which is designed to support non-disruptive failover of IP traffic in certain circumstances.” If you want to read more about the details how HSRP is working, please the RFC2281. I think there is not point in reproducing here what is already written there.
Regarding our topology, what you should know is that after configuring HSRP on R1 and R2 we will achieve a failover mechanism for the traffic from the Client (192.168.0.10) to the Server(10.10.10.10). From the beginning we will assume that R1 and R2 have the proper routing already configured to reach this destinations.

In the below presentation, you will see how the failover is achieved and what’s happening when you have a proper HSRP configuration in case that the link SC – R1 is broken:

So, how to achieve this behavior? From the topology you notice that proper configuration of HSRP involves 3 IP addresses from the same subnet (in our case this is 192.168.0.0 /24). One of the IP is configured on R1 the second one on R2 and the third one is HSRP IP address, which will be announced to the Client as gateway.

Configuration is straight forward on R1:

configure terminal
interface fa0/0
ip address 192.168.0.1 255.255.255.0
standby 1 ip 192.168.0.254
standby 1 priority 110

and on R2:

configure terminal
interface fa0/0
ip address 192.168.0.2 255.255.255.0
standby 1 ip 192.168.0.254

First we configure an IP address on the interface. Then we configure HSRP by typing the command “standby” followed by HSRP group (in our case group 1) and then the IP address. HSRP default priority is 100, and the principle is the higher the better. To force the path R1-SC to be the preferred one, we increse the priority to 110, making R1 to be the “Active” one. The other router, in our case R2, will have the HSRP status “Standby“. Maybe you are wondering what happens if you don’t configure the priority and both routers are having the same value 100. In this case HSRP has a mechanism that help it to chose the active router by comparing the IP addresses and chosing the one with the higher value. In our case this would be R2 (192.168.0.2 > 192.168.0.1).
Another useful feature that I recommend to configure for HSRP is “preemption“. The HSRP preemption feature enables the router with highest priority to immediately become the Active router. The configuration is also very simple and inquire only one additional line to the above ones:

standby 1 preempt

Also recommended is to configure “authentication“ between the HSRP participants:

standby 1 authentication somepassword

where “somepassword” can be what ever you want.

Going back to the topology, another scenario can take place. What if the link R1 – SC remains active, and instead the R1 – SS goes down. Since the R1 – SC is UP, the router R1 has no intention to cease the HSRP Active status. If you are having some kind of dynamic routing between R1 and R2, then you are on the safe side as the traffic will flow like in the scenario below (I’m assuming R1 to be the Active one for both R1-SC and R1-SS):

Remember that if do not have some routing between R1 and R2, the packets will be dropped on R1 as they will not have any path to the Server IP address 10.10.10.10.

This situation can be avoid with another HSRP feature, that will force the R1 to change it’s status from Active to Standby by monitoring the interface from R1 to SS. This feature is called “interface tracking“. This HSRP feature you have to configure at least on the router which is usual in Active mode:

standby 1 track FastEthernet1/0 30

In this scenario I assume that interface Fa1/0 is the connection to SS switch. This tracking command is watching for the status on the interface Fa1/0. When it’s status changes to “down” the “priority” value (110 in this example) is decremented with 30 (or whatever you will configure in the command line). After decremental, the “priority”
will have a value of 80 which is lower than the default one (100), forcing R2 to become the Active router and changing the R1 status to Standby.

Checking the status of an HSRP participant is very easy, and you can see this in the output below:

R1#show standby brief
P indicates configured to preempt.
|
Interface   Grp Prio P State    Active          Standby         Virtual IP
Fa0/0       1   110 P Active   local           192.168.0.2 192.168.0.254

R2#show standby brief
P indicates configured to preempt.
|
Interface   Grp Prio P State    Active          Standby         Virtual IP
Fa0/0       1   100 P Standby 192.168.0.1     local   192.168.0.254

All the HSRP configuration from this article can be fine tuned or extended according to your needs. I have presented here only the basics about the HSRP configuration. If you want don’t be afraid to explore and to “play” with the commands. Of course I would recommend to do that in test environment first.

Cisco: 2-Bytes / 4-Bytes ASN BGP scenarios

In my last post I wrote some basics about the new 4-bytes AS number which is supported on new Cisco IOS images. Now I would like to give you a brief overview about different BGP peering scenarios that you can meet in the real world. Even if the configuration examples in this article are on a Cisco hardware with the latest IOS, the BGP scenarios can be applied to any other platform.

OK, let take the following topology (the high quality PDF file can be downloaded here):

2bytesAS-4bytesAS-BGP

You can see that I think of 3 main scenarios when it comes to have in the same topology 2-Bytes only and 4-Bytes ASN BGP routers:
– 2-Bytes support ASN peering with a 4-Bytes ASN, which has a number greater that 65535 (if you remember from the previous article, this can be wrote as ASPLAIN or ASDOT)
– 4-Bytes ASN peering with a router that support 4-Bytes ASN, but in fact has a number smaller than 65535 (e.g old telecom provider which has has the ASN already asigned as 3456)
– 2-Bytes ASN peering with the same 4-Bytes supported ASN, but with a number smaller than 65535, as in the above scenario

I chose this particular scenarios because it will be interesting to see how we configure a 2-Bytes ASN BGP router which has a 4-Bytes ASN peer or how the same 2-Bytes ASN BGP router will have the AS-Path containing the 4-Bytes ASN router.

For the R1 and R3 routers I will use a C3640 with an IOS image that support only 2-Bytes ASN, and for R2 and R3 a C7200 with the newest IOS image that can support 4-Bytes ASN. All routers have a Loopback interface that will be the BGP router-id an also announced into BGP (e.g. R2 will have interface Loopback100 with IP address 2.2.2.2/32). The AS number that I will use (ignore the fact that I use public ones, it’s just to be more easy to follow):

R1 – ASN 1111
R2 – ASN 2.2 (ASPLAIN 131074)
R3 – ASN 3333
R4 – ASN 4444

I will skip all the boring point-2-point configuration and present only the BGP config.

#### R1-C3600 ####

router bgp 1111
bgp router-id 1.1.1.1
neighbor 10.10.12.2 remote-as 23456
network 1.1.1.1 mask 255.255.255.255

As you can see in BGP peering between R1 and R2 we have to use the remote-as number 23456, due to the fact that R1 is not supporting 4-Bytes ASN. If you read my previous post, or from other sources, you know that any BGP router that does not support 4-Bytes ASN, will use a transitory number for peering with 4-Bytes ASN BGP routers and this number is 23456.

#### R2-C7200 ####

First let’s be sure that the IOS is supporting 4-Bytes ASN. Simplest way:

router bgp ?
<1-65535> Autonomous system number
<1.0-XX.YY> 4 Octets Autonomous system number

I think it’s obvious that it supports. A small note. On all Cisco platforms (usually C3600, C7200) with IOS that I tried testing 4-Bytes ASN BGP, I saw that only ASDOT format is supported. I don’t know about other software platforms (like NX-OS) or something high-end hardware if they support ASPLAIN. Now for the configuration, R2 is peering with R1 and R3:

router bgp 2.2
bgp router-id 2.2.2.2
neighbor 10.10.12.1 remote-as 1111
neighbor 10.10.23.3 remote-as 3333
network 2.2.2.2 mask 255.255.255.255

#### R3-C7200 ####

R3 supports 4-Bytes ASN, but due to the fact that it’s and “old telecom provider” it had been assigned a 2-Bytes ASN, so I will preserve this form:

router bgp 3333
bgp router-id 3.3.3.3
neighbor 10.10.23.2 remote-as 2.2
neighbor 10.10.34.4 remote-as 4444
network 3.3.3.3 mask 255.255.255.255

The difference between R3 and R1 is that R3 support for “remote-as” a 4-bytes ASN number (again only ASDOT representation). So, in it’s peering with R2, the remote ASN is 2.2

#### R4-C3600 ####

R4 only support 2-Bytes ASN, but the difference from R1 is that it has to peer with a 4-Bytes supported ASN router that in fact has a 2-Bytes AS number.

router bgp 4444
bgp router-id 4.4.4.4
neighbor 10.10.34.3 remote-as 3333
network 4.4.4.4 mask 255.255.255.255

This is the basic configuration in this topology. Let’s take now the IP address 1.1.1.1 which is advertised into BGP from R1. If you will check the AS-Path on R4 and R3, you will see a big difference. Have a look into the screen capture below to see the real environment for the above topology: