Archive

Archive for April, 2011

Understanding frame-relay

April 20, 2011 2 comments

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.

frame-relay switching
!
interface Serial0/0
description Connected to R1
no ip address
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 102 interface Serial0/1 201
frame-relay route 104 interface Serial0/3 401
frame-relay route 103 interface Serial0/2 301
no shutdown

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
frame relay.

Then we repeat the config for the other interfaces.

interface Serial0/1
description Connected to R2
no ip address
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 201 interface Serial0/0 102
no shutdown
!
interface Serial0/2
description Connected to R3
no ip address
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 301 interface Serial0/0 103
frame-relay route 304 interface Serial0/3 403
no shutdown
!
interface Serial0/3
description Connected to R4
no ip address
encapsulation frame-relay
clockrate 64000
frame-relay intf-type dce
frame-relay route 401 interface Serial0/0 104
frame-relay route 403 interface Serial0/2 304
no shutdown

We now have the frame switch configured, it is time to configure the
routers.

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.

R1#debug frame-relay lmi
Frame Relay LMI debugging is on
Displaying all Frame Relay LMI data

Put the right encapsulation in and unshut the interface.

R1(config)#int s0/0
R1(config-if)#encapsulation frame-relay
R1(config-if)#no sh
R1(config-if)#^Z

Now lets look at LMI.

*Mar 1 00:09:07.791: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:09:08.931: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar 1 00:09:08.935: Serial0/0(out): StEnq, myseq 1, yourseen 0, DTE up
*Mar 1 00:09:08.935: datagramstart = 0x7DFFD34, datagramsize = 14
*Mar 1 00:09:08.935: FR encap = 0x00010308
*Mar 1 00:09:08.939: 00 75 95 01 01 00 03 02 01 00
*Mar 1 00:09:08.943:
*Mar 1 00:09:08.943: Serial0/0(out): StEnq, myseq 1, yourseen 0, DTE up
*Mar 1 00:09:08.943: datagramstart = 0x7DFFE74, datagramsize = 13
*Mar 1 00:09:08.943: FR encap = 0x00010308
*Mar 1 00:09:08.943: 00 75 51 01 00 53 02 01 00
*Mar 1 00:09:08.947:
*Mar 1 00:09:08.947: Serial0/0(out): StEnq, myseq 1, yourseen 0, DTE up
*Mar 1 00:09:08.951: datagramstart = 0x7DFFFB4, datagramsize = 13
R1#
*Mar 1 00:09:08.951: FR encap = 0xFCF10309
*Mar 1 00:09:08.951: 00 75 01 01 00 03 02 01 00
*Mar 1 00:09:08.955:
*Mar 1 00:09:08.971: Serial0/0(in): Status, myseq 1, pak size 37
*Mar 1 00:09:08.971: RT IE 1, length 1, type 0
*Mar 1 00:09:08.971: KA IE 3, length 2, yourseq 1 , myseq 1
*Mar 1 00:09:08.975: PVC IE 0x7 , length 0x6 , dlci 102, status 0x0 , bw 0
*Mar 1 00:09:08.975: PVC IE 0x7 , length 0x6 , dlci 103, status 0x0 , bw 0
*Mar 1 00:09:08.979: PVC IE 0x7 , length 0x6 , dlci 104, status 0x0 , bw 0
R1#
*Mar 1 00:09:18.931: Serial0/0(out): StEnq, myseq 2, yourseen 1, DTE up
*Mar 1 00:09:18.931: datagramstart = 0x7E00234, datagramsize = 13
*Mar 1 00:09:18.931: FR encap = 0xFCF10309
*Mar 1 00:09:18.931: 00 75 01 01 01 03 02 02 01
*Mar 1 00:09:18.935:
*Mar 1 00:09:18.995: Serial0/0(in): Status, myseq 2, pak size 37
*Mar 1 00:09:18.995: RT IE 1, length 1, type 0
*Mar 1 00:09:18.995: KA IE 3, length 2, yourseq 2 , myseq 2
*Mar 1 00:09:18.995: PVC IE 0x7 , length 0x6 , dlci 102, status 0x0 , bw 0
*Mar 1 00:09:18.999: PVC IE 0x7 , length 0x6 , dlci 103, status 0x0 , bw 0
*Mar 1 00:09:18.999: PVC IE 0x7 , length 0x6 , dlci 104, status 0x0 , bw 0
*Mar 1 00:09:19.931: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
R1#
*Mar 1 00:09:28.931: Serial0/0(out): StEnq, myseq 3, yourseen 2, DTE up
*Mar 1 00:09:28.931: datagramstart = 0x7E004B4, datagramsize = 13
*Mar 1 00:09:28.931: FR encap = 0xFCF10309
*Mar 1 00:09:28.931: 00 75 01 01 01 03 02 03 02
*Mar 1 00:09:28.935:
*Mar 1 00:09:28.979: Serial0/0(in): Status, myseq 3, pak size 13
*Mar 1 00:09:28.979: RT IE 1, length 1, type 1
*Mar 1 00:09:28.979: KA IE 3, length 2, yourseq 3 , myseq 3

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.

R1#show frame pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 0 0 0 0
Switched 0 0 0 0
Unused 0 3 0 0
DLCI = 102, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
input pkts 0 output pkts 0 in bytes 0
out bytes 0 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:00:30, last time pvc status changed 00:00:30
DLCI = 103, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
input pkts 0 output pkts 0 in bytes 0
out bytes 0 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:00:32, last time pvc status changed 00:00:32
DLCI = 104, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
input pkts 0 output pkts 0 in bytes 0
out bytes 0 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:00:32, last time pvc status changed 00:00:32

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.

R2(config)#int s0/0
R2(config-if)#encap frame-relay
R2(config-if)#exit
R2(config)#int s0/0.201 point-to-point
R2(config-subif)#^Z
R2#debug frame-relay lmi
Frame Relay LMI debugging is on
Displaying all Frame Relay LMI data
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0
R2(config-if)#no sh

Look at the LMI output below.

*Mar 1 00:20:40.951: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar 1 00:20:40.955: Serial0/0(out): StEnq, myseq 1, yourseen 0, DTE up
*Mar 1 00:20:40.955: datagramstart = 0x7A00714, datagramsize = 14
*Mar 1 00:20:40.955: FR encap = 0x00010308
*Mar 1 00:20:40.959: 00 75 95 01 01 00 03 02 01 00
*Mar 1 00:20:40.963:
*Mar 1 00:20:40.963: Serial0/0(out): StEnq, myseq 1, yourseen 0, DTE up
*Mar 1 00:20:40.963: datagramstart = 0x7A00854, datagramsize = 13
*Mar 1 00:20:40.963: FR encap = 0x00010308
*Mar 1 00:20:40.963: 00 75 51 01 00 53 02 01 00
*Mar 1 00:20:40.967:
*Mar 1 00:20:40.967: Serial0/0(out): StEnq, myseq 1, yourseen 0, DTE up
*Mar 1 00:20:40.971: datagramstart = 0x7A00994, datagramsize = 13
*Mar 1 00:20:40.971: FR encap = 0xFCF10309
*Mar 1 00:20:40.971: 00 75 01 01 00 03 02 01 00
*Mar 1 00:20:40.975:
*Mar 1 00:20:41.091: Serial0/0(in): Status, myseq 1, pak size 21
*Mar 1 00:20:41.091: RT IE 1, length 1, type 0
*Mar 1 00:20:41.091: KA IE 3, length 2, yourseq 1 , myseq 1
*Mar 1 00:20:41.091: PVC IE 0x7 , length 0x6 , dlci 201, status 0x2 , bw 0
*Mar 1 00:20:50.951: Serial0/0(out): StEnq, myseq 2, yourseen 1, DTE up
*Mar 1 00:20:50.951: datagramstart = 0x7DFF6F4, datagramsize = 13
*Mar 1 00:20:50.951: FR encap = 0xFCF10309
*Mar 1 00:20:50.951: 00 75 01 01 01 03 02 02 01
*Mar 1 00:20:50.955:
*Mar 1 00:20:50.991: Serial0/0(in): Status, myseq 2, pak size 21
*Mar 1 00:20:50.991: RT IE 1, length 1, type 0
*Mar 1 00:20:50.991: KA IE 3, length 2, yourseq 2 , myseq 2
*Mar 1 00:20:50.995: PVC IE 0x7 , length 0x6 , dlci 201, status 0x2 , bw 0
*Mar 1 00:20:51.951: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar 1 00:21:00.951: Serial0/0(out): StEnq, myseq 3, yourseen 2, DTE up
*Mar 1 00:21:00.951: datagramstart = 0x7A00AD4, datagramsize = 13
*Mar 1 00:21:00.951: FR encap = 0xFCF10309
*Mar 1 00:21:00.951: 00 75 01 01 01 03 02 03 02
*Mar 1 00:21:00.955:
*Mar 1 00:21:01.011: Serial0/0(in): Status, myseq 3, pak size 13
*Mar 1 00:21:01.011: RT IE 1, length 1, type 1
*Mar 1 00:21:01.011: KA IE 3, length 2, yourseq 3 , myseq 3

The DLCI 201 is assigned to the physical interface Serial0/0 but
we want to use it on the point-to-point interface.

R2(config-subif)#frame-relay interface-dlci 201
R2(config-subif)#ip add 132.16.0.2 255.255.255.0
R2(config-subif)#^Z

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.

T*Mar 1 04:14:17.846: Serial0/0.201: FR ARP input
*Mar 1 04:14:17.846: Serial0/0.201: inarp received on 201
*Mar 1 04:14:17.846: datagramstart = 0x7A0138E, datagramsize = 34
*Mar 1 04:14:17.850: FR encap = 0x30910300
*Mar 1 04:14:17.850: 80 00 00 00 08 06 00 0F 08 00 02 04 00 08 00 00
*Mar 1 04:14:17.854: 84 10 00 01 18 61 00 00 00 00 01 02 00 00
*Mar 1 04:14:17.858:

R2 responded to R1s ARP request. We can now communicate between R1 and R2.

R1#ping 132.16.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/99/352 ms

Now we configure R3 and R4 as multipoint interfaces.

R3(config)#int s0/0.301
R3(config-subif)#frame-relay interface-dlci 301
R3(config-fr-dlci)#frame-relay interface-dlci 304
R3(config-fr-dlci)#^Z

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#debug frame events
Frame Relay events debugging is on
R1#
*Mar 1 04:22:04.934: Serial0/0: FR ARP input
*Mar 1 04:22:04.938: Serial0/0: inarp received on 103
*Mar 1 04:22:04.938: datagramstart = 0x7A00E8E, datagramsize = 34
*Mar 1 04:22:04.938: FR encap = 0x18710300
*Mar 1 04:22:04.938: 80 00 00 00 08 06 00 0F 08 00 02 04 00 08 00 00
*Mar 1 04:22:04.946: 84 10 00 03 48 D1 00 00 00 00 01 02 00 00
*Mar 1 04:22:04.950:
R1#
*Mar 1 04:23:38.974: Serial0/0: preparing IP inarp on 104
*Mar 1 04:23:39.062: Serial0/0: FR ARP input
*Mar 1 04:23:39.066: Serial0/0: inarp received on 104
*Mar 1 04:23:39.066: datagramstart = 0x7DFF6EE, datagramsize = 34
*Mar 1 04:23:39.066: FR encap = 0x18810300
*Mar 1 04:23:39.066: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00
*Mar 1 04:23:39.074: 84 10 00 04 18 81 84 10 00 01 01 02 00 00
*Mar 1 04:23:39.078:

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
statements instead.

R3(config)#int s0/0.301
R3(config-subif)#no frame-relay interface-dlci 301
R3(config-subif)#no frame-relay interface-dlci 304
R3(config-subif)#frame-relay map ip 132.16.0.1 301
R3(config-subif)#frame-relay map ip 132.16.0.4 304
R3(config-subif)#^Z
R3#sh frame map
Serial0/0.301 (up): ip 132.16.0.1 dlci 301(0x12D,0x48D0), static,
CISCO, status defined, active
Serial0/0.301 (up): ip 132.16.0.4 dlci 304(0x130,0x4C00), static,
CISCO, status defined, active
R3#ping 132.16.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.16.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/62/152 ms
R3#ping 132.16.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 132.16.0.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/55/96 ms
R3#

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.

Categories: CCIE Tags: , ,

Don’t forget ip routing on switches

April 18, 2011 Leave a comment

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.

RSRack10SW1#show ip route eigrp
Default gateway is not set
Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty

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.

RSRack10SW1#show ip eigrp topo
EIGRP-IPv4 Topology Table for AS(10)/ID(150.10.7.7)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status
P 161.10.5.0/24, 1 successors, FD is 2563072
via 161.10.78.8 (2563072/2560512), FastEthernet0/15
P 161.10.10.0/24, 1 successors, FD is 2563072
via 161.10.78.8 (2563072/2560512), FastEthernet0/15
P 161.10.34.0/24, 1 successors, FD is 2563072
via 161.10.78.8 (2563072/2560512), FastEthernet0/15
P 204.12.10.0/24, 1 successors, FD is 2563072
via 161.10.78.8 (2563072/2560512), FastEthernet0/15
P 150.10.9.0/24, 1 successors, FD is 2563072
via 161.10.78.8 (2563072/2560512), FastEthernet0/15
P 150.10.3.0/24, 1 successors, FD is 2563072
via 161.10.78.8 (2563072/2560512), FastEthernet0/15
P 161.10.12.0/24, 1 successors, FD is 2563072
via 161.10.78.8 (2563072/2560512), FastEthernet0/15
P 150.10.6.0/24, 1 successors, FD is 156160
via 161.10.67.6 (156160/128256), FastEthernet0/21
P 161.10.45.0/24, 1 successors, FD is 2563072
via 161.10.78.8 (2563072/2560512), FastEthernet0/15

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.

RSRack10SW1(config)#ip routing
RSRack10SW1(config)#^Z
RSRack10SW1#

The routes are now getting installed.

RSRack10SW1#show ip route eigrp
51.0.0.0/32 is subnetted, 1 subnets
D EX 51.51.51.51 [170/2563072] via 161.10.78.8, 00:05:01, FastEthernet0/15
54.0.0.0/24 is subnetted, 1 subnets
D 54.10.1.0 [90/2172416] via 161.10.67.6, 00:05:01, FastEthernet0/21
D EX 204.12.10.0/24 [170/2563072] via 161.10.78.8, 00:05:01, FastEthernet0/15
161.10.0.0/16 is variably subnetted, 13 subnets, 3 masks
D EX 161.10.45.0/24
[170/2563072] via 161.10.78.8, 00:05:01, FastEthernet0/15
D EX 161.10.34.0/24
[170/2563072] via 161.10.78.8, 00:05:01, FastEthernet0/15
output edited for brevity

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.

Categories: CCIE, Routing Tags: , ,

Reflexive access-lists

April 15, 2011 2 comments

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.

R3#telnet 133.16.12.1
Trying 133.16.12.1 … Open
User Access Verification
Password:
R1>

R1#telnet 133.16.23.3
Trying 133.16.23.3 … Open
User Access Verification
Password:
R3>

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.

ip access-list extended OUTBOUND
permit tcp any any reflect MYREFLECT
permit icmp any any reflect MYREFLECT

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.

ip access-list extended INBOUND
permit eigrp any any
permit icmp any any echo-reply
permit icmp any any time-exceeded
permit icmp any any port-unreachable
evaluate MYREFLECT

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.

R2(config)#int fa0/0
R2(config-if)#ip access-group INBOUND in
R2(config-if)#ip access-group OUTBOUND out

If our configuration is correct telnet from R3 to R1 should work but not
the other way around.

R3#telnet 133.16.12.1
Trying 133.16.12.1 … Open
User Access Verification
Password:
R1>

Still working. We can also see matches in the ACL.

R2#sh ip access-lists OUTBOUND
Extended IP access list OUTBOUND
    10 permit tcp any any reflect MYREFLECT (20 matches)
    20 permit icmp any any reflect MYREFLECT

Now lets try from R1 to R3.

R1#telnet 133.16.23.3
Trying 133.16.23.3 …
% Destination unreachable; gateway or host down

That was denied. Are we still able to ping R1 from R3?

R3#ping 133.16.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 133.16.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/53/152 ms

There is also matches in the ACL.

R2#sh ip access-lists OUTBOUND
Extended IP access list OUTBOUND
    10 permit tcp any any reflect MYREFLECT (20 matches)
    20 permit icmp any any reflect MYREFLECT (7 matches)

Traceroute from R1.

R1#traceroute 133.16.23.3
Type escape sequence to abort.
Tracing the route to 133.16.23.3
  1 133.16.12.2 !A  *  !A

Can R1 form an EIRGP peering?

*Mar  1 01:26:23.351: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 133.16.12.1
(FastEthernet0/0) is up: new adjacency
*Mar  1 01:26:24.355: %SYS-5-CONFIG_I: Configured from console by console
R2#sh ip access-lists INBOUND
Extended IP access list INBOUND
    10 permit eigrp any any (33 matches)
    20 permit icmp any any echo-reply (5 matches)
    30 permit icmp any any time-exceeded
    40 permit icmp any any port-unreachable
    50 evaluate MYREFLECT

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.

Categories: CCIE, Security Tags: , ,

Conditional BGP, showing status

April 6, 2011 Leave a comment

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.

Rack7R3#show bgp ipv4 uni nei 155.7.37.7 | i Condition
Condition-map NON_EXIST, Advertise-map ADVERTISE, status: Advertise

The prefix is currently being advertised. Then we bring up the interface.

Rack7R3(config)#int s1/2
Rack7R3(config-if)#no sh

Rack7R3#show bgp ipv4 uni nei 155.7.37.7 | i Condition
Condition-map NON_EXIST, Advertise-map ADVERTISE, status: Withdraw

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.

Categories: BGP, CCIE Tags: ,

Timers used in OSPF

April 6, 2011 2 comments

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.

Router(config-router)# timers pacing flood 50

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.

Router(config-router)# timers pacing retransmission 100

Controls how long to wait to send LSAs that are unacknowledged using the same grouping
principle.

Router(config-router)# timers pacing lsa-group 75

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.

timers throttle spf spf-start spf-hold spf-max-wait

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.

timers throttle lsa all start-interval hold-interval max-interval

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.

timers lsa arrival milliseconds

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.

ip ospf transmit-delay seconds

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
being sent.

ip ospf retransmit-interval seconds

How long to wait before transmitting unacknowledged LSAs.

Categories: CCIE, OSPF Tags: ,

Conditional BGP advertisement with advertise-map

April 5, 2011 1 comment

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.

Cust:

interface Loopback1
ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
ip address 3.3.3.3 255.255.255.0
!
interface Loopback4
ip address 4.4.4.4 255.255.255.0
!
interface FastEthernet0/0
ip address 136.1.13.3 255.255.255.0
no shut
!
interface Serial0/0
ip address 136.1.23.3 255.255.255.0
clock rate 2000000
no shut
!
router bgp 300
no synchronization
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.0
network 2.2.2.0 mask 255.255.255.0
network 3.3.3.0 mask 255.255.255.0
network 4.4.4.0 mask 255.255.255.0
network 136.1.13.0 mask 255.255.255.0
neighbor 136.1.13.1 remote-as 100
neighbor 136.1.23.2 remote-as 200
no auto-summary

ISP1:

interface FastEthernet0/0
ip address 136.1.12.1 255.255.255.0
no shut
!
interface FastEthernet0/1
ip address 136.1.13.1 255.255.255.0
no shut
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 136.1.12.0 mask 255.255.255.0
neighbor 136.1.12.2 remote-as 200
neighbor 136.1.13.3 remote-as 300
no auto-summary

ISP2:

interface FastEthernet0/0
ip address 136.1.12.2 255.255.255.0
no shut
!
interface Serial0/0
ip address 136.1.23.2 255.255.255.0
clock rate 2000000
no shut
!
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 136.1.12.1 remote-as 100
neighbor 136.1.23.3 remote-as 300
no auto-summary

If we look at ISP2 we have two active BGP session with four prefixes over each.

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
136.1.12.1      4   100       6       7                       9              0       0            00:01:47        4
136.1.23.3      4   300       5       6                       9              0       0            00:00:33        4

ISP2#sh ip bgp
BGP table version is 9, local router ID is 136.1.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24    136.1.23.3             0                          0         300 i
*                       136.1.12.1                                         0        100 300 i
*> 2.2.2.0/24   136.1.23.3              0                          0        300 i
*                       136.1.12.1                                        0          100 300 i
*> 3.3.3.0/24    136.1.23.3             0                         0          300 i
*                       136.1.12.1                                         0         100 300 i
*> 4.4.4.0/24    136.1.23.3             0                         0          300 i
*                       136.1.12.1                                       0           100 300 i
 

Lets do a ping and traceroute to verify reachability first.

ISP2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/38/88 ms
ISP2#trace
ISP2#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
  1 136.1.23.3 44 msec *  84 msec

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.

Cust(config)#router bgp 300
Cust(config-router)#network 136.1.13.0 mask 255.255.255.0

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 1.1.1.0/24 if the Ethernet link is down.

Cust#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cust(config)#ip prefix-list 1-NETWORK seq 5 permit 1.1.1.0/24
Cust(config)#ip prefix-list 13-NETWORK seq 5 permit 136.1.13.0/24
Cust(config)#route-map ADVERTISE permit 10
Cust(config-route-map)#match ip address prefix-list 1-NETWORK
Cust(config-route-map)#exit
Cust(config)#route-map NON_EXIST permit 10
Cust(config-route-map)#match ip address prefix-list 13-NETWORK
Cust(config-route-map)#exit
Cust(config)#router bgp 300
Cust(config-router)#neighbor 136.1.13.1 advertise-map ADVERTISE non-exist-map NON_EXIST
Cust(config-router)#^Z

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.

Cust#sh bgp ipv4 uni nei 136.1.23.2 advertised-routes
BGP table version is 7, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i
*> 4.4.4.0/24       0.0.0.0                  0         32768 i
*> 136.1.13.0/24    0.0.0.0                0         32768 i
Total number of prefixes 4

We can see that 1.1.1.0/24 is no longer being announced. Ping from ISP2 confirms reachability and a traceroute shows that traffic is passing through ISP1.

ISP2#ping 1.1.1.1      
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/76/108 ms
ISP2#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
  1 136.1.12.1 100 msec 96 msec 44 msec
  2 136.1.13.3 [AS 300] 92 msec *  116 msec

We then do a shutdown of the Ethernet link on Cust and look at the results.

Cust#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cust(config)#int f0/0
Cust(config-if)#sh
Cust(config-if)#
*Mar  1 00:27:22.007: %BGP-5-ADJCHANGE: neighbor 136.1.13.1 Down Interface flap
Cust(config-if)#
*Mar  1 00:27:23.983: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar  1 00:27:24.983: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Cust(config-if)#
Cust#sh bgp ipv4 uni nei 136.1.23.2 advertised-routes
BGP table version is 12, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i
*> 4.4.4.0/24       0.0.0.0                  0         32768 i
Total number of prefixes 4

BGP table on ISP2. Ping working and traffic now going the direct path.

ISP2#sh ip bgp
BGP table version is 15, local router ID is 136.1.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network                      Next Hop  Metric LocPrf Weight Path
*> 1.1.1.0/24            136.1.23.3 0                              0         300 i
*                                136.1.12.1                                 0         100 300 i
*> 2.2.2.0/24            136.1.23.3 0                               0         300 i
*                                136.1.12.1                                 0           100 300 i
*> 3.3.3.0/24           136.1.23.3  0                               0          300 i
*                               136.1.12.1                                  0            100 300 i
*> 4.4.4.0/24            136.1.23.3  0                             0           300 i
*                               136.1.12.1                                  0             100 300 i
r> 136.1.12.0/24        136.1.12.1 0                            0           100 i
*> 136.1.13.0/24       136.1.12.1                                 0            100 300 i
ISP2#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/40/80 ms
ISP2#tra
ISP2#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
1 136.1.23.3 92 msec * 24 msec

If we debug BGP updates we will se entries like this.

*Mar  1 01:05:03.067: BPG(0): Condition NON_EXIST changes to Withdraw
*Mar  1 01:05:03.067: BPG(0): Condition NON_EXIST changes to Withdraw
*Mar  1 01:06:03.079: BPG(0): Condition NON_EXIST changes to Advertise
*Mar  1 01:06:03.079: BPG(0): Condition NON_EXIST changes to Advertise

Categories: BGP, CCIE Tags: , ,