This post is about frame-relay. Knowing frame-relay is core knowledge
for the CCIE exam. We need to have our layer 2 functioning to be able
to move on to routing and other tasks. While I do have an OK understanding
of frame-relay I wanted to take it one step further and really know all
of my options and a little more about the inner workings like LMI.
We will be using the topology below.
The picture below is the setup in GNS3, the cloud in the diagram above
is the R5 router in GNS3. We could have just used used a frame-relay
switch in GNS3 but where is the fun in that? Also, frame-relay switching
may or may not be a part of your lab in either the troubleshooting
section or the config section.
We start by configuring the frame-relay switch.
The config is pretty self explanatory but here is how it works.
If we receive a frame with DLCI 102 route it to interface Serial0/1
PVC 201. The interface is set to DCE just as if this was a service
provider frame switch. DCE side needs to set clock rate and we
have a bit rate of 64 kbit/s. The encapsulation is of course
Then we repeat the config for the other interfaces.
We now have the frame switch configured, it is time to configure the
R3 and R4 will be using multi-point subinterfaces, R1 will use its
physical interface and R2 will use a point-to-point subinterface.
These three interfaces are the different interfaces that are
available in frame-relay. A physical interface is a multi-point
interface. Physical interfaces are special in that they will use
all PVCs by default which they learn via LMI. Below is a debug
output from the LMI conversation between R1 and the frame switch.
First the debug is turned on.
Put the right encapsulation in and unshut the interface.
Now lets look at LMI.
You can see that we have learned PVC 102, 103 and 104 from the
frame switch and we didn’t have to do a single thing! Lets
confirm with show frame pvc.
We see all DLCI’s, they have a status of inactive since the other side
is not yet up. If a PVC was missing in the frame switch the status
would be deleted.
We will now enable frame-relay on R2 and debug LMI there.
Look at the LMI output below.
The DLCI 201 is assigned to the physical interface Serial0/0 but
we want to use it on the point-to-point interface.
The frame-relay interface-dlci tells the interface which DLCI it should use.
There is no need to run inverse ARP on point-to-point interfaces since
there is only one way out. However the interface will still reply to
inverse ARP requests. Look at the output below.
R2 responded to R1s ARP request. We can now communicate between R1 and R2.
Now we configure R3 and R4 as multipoint interfaces.
R3 will send inverse ARP requests to find out which remote layer 3 address
that maps to the local DLCI. Look at output from R1.
R1 responds to the ARP requests and we now have full communication.
If we are not allowed to use inverse ARP this will not work. To
disable inverse ARP we use the command no frame-relay inverse-arp.
When disabling inverse ARP we are disabling requests but not replies.
So how do we map if we cannot use inverse ARP? Then we need to use
the frame-relay map statements. We will reconfigure R3 to use map
This post should give you a better understanding of frame-relay. If you
are interested in running this lab you can find the GNS3 topology
and final configs here.
Yesterday I did a vol3 lab and one of the tasks was to enable EIGRP on a couple
of the switches. I had enabled EIGRP, however I was not getting any routes
installed in the routing table. Look at the output below.
This should have rung an alarm bell right here. Default gateway is not set.
When not using ip routing on switches we use ip default-gateway to set a gateway
for management traffic etc. I thought there was an issue with EIGRP so I looked
in the topology table.
We have plenty of successors, so there are potential routes in EIGRP.
Remember that a successor in EIGRP is the best path to a prefix.
Now I started thinking about if there was a possibility that I had
these routes installed via another routing protocol but then I
finally realized that I had forgot to turn on ip routing.
The routes are now getting installed.
When configuring routing on switches remember that even though we
are allowed to configure the routing protocols, no routes will be
installed if we don’t have ip routing configured.
Reflexive access-lists is a way of filtering traffic where only return traffic
is allowed if it belongs to a session initiated on the “inside”. In a regular
access-list we can use the keyword established for filtering but that only
looks at if the TCP flag ACK has been set which is the case for all packets
except the first one in a session. This isn’t really stateful filtering.
We will use a very simple topology with three routers, diagram is below.
The objective is to allow all TCP from R3 to R1. R1 should be able to use ping
and traceroute and to establish routing peerings with R2.
If you want to try this lab yourself you can download topology, initial configs
and final configs from here.
Lets start by doing a telnet from R3 to R1 and reverse just to see that we have
reachability and that nothing is being filtered.
Everything working as expected. Now lets start creating access-lists. We will
be filtering on R2 Fa0/0. Traffic from R3 to R1 will be outbound and traffic
from R1 to R3 will be inbound.
The keyword here is reflect, we need to match MYREFLECT on the inbound ACL to make
it reflexive. If we want to add more statements like UDP we can do that but
remember to use the reflect keyword.
Now we create the inbound ACL.
We need to explicitally allow ICMP since ICMP is not stateful. We also need
to allow routing because the traffic is terminated on the router.
Apply ACL to R2 Fa0/0.
If our configuration is correct telnet from R3 to R1 should work but not
the other way around.
Still working. We can also see matches in the ACL.
Now lets try from R1 to R3.
That was denied. Are we still able to ping R1 from R3?
There is also matches in the ACL.
Traceroute from R1.
Can R1 form an EIRGP peering?
So reflexive access-lists can be a very useful feature. If you have
a lab task that says that only traffic initiated from inside should
be allowed back in it’s a good bet to use reflexive access-lists.
If you download the .net file remember to set the IOS image dir and your working dir.
This is some notes for the post that I did on conditional BGP advertisement.
I found an easier way of seeing the status for the advertise-map. It is
available by looking at the neighbor status, look at the following output.
The prefix is currently being advertised. Then we bring up the interface.
The prefix is no longer advertised. Remember that the BGP scanner runs every
60 seconds by default so it may take some time before we see results.
In any IGP there are a lot of timers involved in running the protocol. This post will not
describe the hello and dead timers, these are well known. This post describes the less known
timers that control how often packets are sent and how often SPF is run. Modifying timers is
not recommended unless you have a very good reason to do so.
Every interface running OSPF has a flood-list with the LSAs that need to be sent out that
interface. This command configures how long to wait for additional LSAs and pack them into
a single update packet. This saves resources like CPU usage but setting it too high will lead
to slower convergence.
Controls how long to wait to send LSAs that are unacknowledged using the same grouping
Every LSA has a maxage, the default is 1 hour and LSAs are usually refreshed at half their
maxage which is 30 minutes. Earlier versions of IOS would refresh all LSAs at once regardless
of age which led to CPU spikes. Later an individual timer was implemented which led to not all
LSAs expiring at once but every LSA was sent individually. The group pacing feature looks at
LSAs that are expiring at the near same time and group these together. LSAs that
expire within 75 seconds will be grouped together, the default value is 240 seconds.
Next we will look at throttling the SPF algorithm.
This timer throttles the SPF algorithm, if there is a flapping link or something causing a lot
of LSAs being sent and requiring SPF to run this can affect performance of CPU. When the first
LSA arrives the timer will run SPF after spf-start msecs. If there is another event within spf-
hold the timer will be doubled. If Another event occurs inside this hold-time the timer is once
again doubled, it is an exponential timer. Spf-max-wait makes sure there is a roof so that the
timer is not set to high. If there are no events for 2 times the max-wait the timer will revert
back to spf-start.
Also the sending and receiving of LSAs can be throttled.
Defines how long to wait before sending LSAs. By default the first LSA is sent immediately and
the timer is set to hold-interval. If another LSA needs to be generated it will be generated at
hold-interval and the hold-interval will doubled. When the topology is stable after 2 times the
max-interval the timer will revert back to start-interval. If there are several events during an
interval they will be grouped and sent at hold-interval or max-interval depending on how
many events that have occured.
How long to wait before accepting the same LSA. If it is received faster than this timer the LSA
will be dropped. This timer should be set to less than or equal to the hold-interval of the
timers throttle lsa all command.
Interface command. Estimate of time needed to send a link-state update over
a link. Should only matter on really low bandwidth links. LSAs that are sent will
have their age incremented by the amount this command specifies before
How long to wait before transmitting unacknowledged LSAs.
This post will describe how to do conditional advertising with BGP. In a real life scenario this can be used to only announce routes to your backup provider when your primary link is down. In a lab scenario this can be used when you are faced with a scenario that says you have to make sure that traffic comes in on interface X/X but if that interface fails it should come in on interface Y/Y. The image below describes the scenario.
We start by putting addresses on interfaces and enable basic BGP. The loopbacks on the Cust router are used for announcing networks.
If we look at ISP2 we have two active BGP session with four prefixes over each.
Lets do a ping and traceroute to verify reachability first.
We have reachability. The next step is to announce the Ethernet link on the
cust router into BGP. We need this prefix in BGP to be able to track it.
ISP will see this prefix as a RIB-failure since it has a route with better AD (connected).
We then configure the Cust router to only advertise 188.8.131.52/24 if the Ethernet link is down.
The advertise-map permits prefixes to be announced when the prefixes in the NON_EXIST map are not in the BGP table.
Other prefixes will not be affected by this configuration. Lets look at what Cust is announcing to ISP2.
We can see that 184.108.40.206/24 is no longer being announced. Ping from ISP2 confirms reachability and a traceroute shows that traffic is passing through ISP1.
We then do a shutdown of the Ethernet link on Cust and look at the results.
BGP table on ISP2. Ping working and traffic now going the direct path.
If we debug BGP updates we will se entries like this.