Frame-relay switching/bridging/back-to-back

Routing over frame-relay is pretty straightforward. Once you work out the differences between point to point and point to multipoint you’re pretty much set.

But what happens when you get to the lab and they require you to switch over frame-relay? Or have a point-to-point link through another router, but not running frame-relay switching? Or what about back to back frame-relay where no frame-relay switch is involved?

All of the above are actually not difficult, as long as you configure them each as least once.
Consider the following simply topology:
FR SWITCH Frame relay switching/bridging/back to back
The task we’ve been given is for R1 to be a frame-relay switch. R2 and R3 need to communicate over a point to point link. The DLCI for R2 will be 203 and the DLCI for R3 will be 302. Let’s first configure R2 and R3 as a basic point-to-point:
R2:

R2#sh run | sec Serial0/0
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
interface Serial0/0.203 point-to-point
 ip address 10.23.23.2 255.255.255.0
 frame-relay interface-dlci 203

R3:

R3#sh run | sec Serial0/0
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
interface Serial0/0.302 point-to-point
 ip address 10.23.23.3 255.255.255.0
 frame-relay interface-dlci 302

At this point, let’s have a look at the PVCs from R2′s perspective:

R2#show frame pvc | include DLCI
DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0.203

Remember DELETED means that the frame-switch has no idea about the DLCI that R2 is talking about. So let’s now configure R1 as a frame-relay switch. It’s a 3 step process. Tell the device it’s going to be a frame-relay switch. Tell the router which interfaces are going to be DCEs. And finally tell the router which DLCIs are going to be switched from one interface to another.
R1:

frame-relay switching
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 128000
 frame-relay intf-type dce
 frame-relay route 203 interface Serial0/1 302
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 clock rate 128000
 frame-relay intf-type dce
 frame-relay route 302 interface Serial0/0 203

Let’s take a look at R2 again:
R2:

R2#show frame pvc | include DLCI
DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.203
R2#ping 10.23.23.3 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.23.23.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/11/132 ms

To quickly see what routes are configured on the frame-switch, just do this:

R1#show frame-relay route
Input Intf      Input Dlci      Output Intf     Output Dlci     Status
Serial0/0       203             Serial0/1       302             active
Serial0/1       302             Serial0/0       203             active

You can of course have multiple map statements referencing different DLCIs under each DCE interface like you would expect!

Now let’s change the topology:
FR BROAD Frame relay switching/bridging/back to back
This time they want to run OSPF between R2 and R3. They want the OSPF network type to be broadcast. These broadcasts need to go through R1, but R1 is NOT a frame-relay switch this time. To make sure we don’t somehow bounce things of R1′s IP address, we’ll configure a /31 between R2 and R3. Essentially we’ll be bridging through R1′s frame-relay interfaces.

Let’s create the bridge-group on R2 first. R3′s will almost match, just the DLCI and IP will change:
R2:

bridge irb
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 frame-relay map bridge 201 broadcast
 bridge-group 1
!
interface BVI1
 ip address 10.23.23.2 255.255.255.254
 ip ospf network broadcast
 ip ospf 1 area 0
!
bridge 1 protocol ieee
bridge 1 route ip

The important part to notice about this is the frame-relay map bridge command. As noted above, the config on R3 is pretty identical. This is R1′s config:
R1:

bridge irb
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 frame-relay map bridge 102 broadcast
 frame-relay interface-dlci 102
 bridge-group 1
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 frame-relay map bridge 103 broadcast
 frame-relay interface-dlci 103
 bridge-group 1
!
bridge 1 protocol ieee

Does it all work?

R2#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.23.23.3        1   FULL/DR         00:00:32    10.23.23.3      BVI1
R2#ping 10.23.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.23.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 132/152/192 ms

Let’s move onto the last topic, back to back frame-relay. You have the following topology:
FRAME B2B Frame relay switching/bridging/back to back
The tasks states that you need to run frame-relay, but there is no frame-relay switch involved. We don’t even get DLCI numbers on the diagram.
For back-to-back frame-relay to work we essentially turn off our keepalives. The keepalives will be looking for the LMI messages which simply don’t exist. We then hard code the DLCI number on both sides. These DLCI numbers need to MATCH however.
Let’s configure it up:
R1:

interface Serial0/0
 ip address 10.23.23.3 255.255.255.0
 encapsulation frame-relay
 no keepalive
 clock rate 2000000
 frame-relay map ip 10.23.23.2 100
 no frame-relay inverse-arp

R1#ping 10.23.23.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.23.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/28/72 ms

R1#show frame pvc | include DLCI
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = Serial0/0

You can see the PVC is static, and communication is working just fine.

Using an extended ACL as a prefix-list

This will be a short post.

I’ve mentioned it before, but let’s say you have a task which requires you to filters updates through a route-map. For some reason the task states you’re only allowed to use an ACL, not a prefix-list.

You are able to use an extended ACL as a prefix list.

Let’s use this simple topology:
extended ACL Using an extended ACL as a prefix list

R1 has a bunch of loopbacks. R1 and R2 are running EIGRP with each other. I’ve configured R1 to redistribute all connected routes into EIGRP.

R1′s loopbacks:

interface Loopback2
 ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
 ip address 3.3.3.3 255.255.255.248
!
interface Loopback4
 ip address 4.4.4.4 255.255.255.0
!
interface Loopback5
 ip address 5.5.5.5 255.255.255.255
!
interface Loopback6
 ip address 5.5.5.50 255.255.255.248

R2 sees all of these EIGRP routes in it’s RIB:

R2#show ip route eigrp
     2.0.0.0/24 is subnetted, 1 subnets
D EX    2.2.2.0 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0
     3.0.0.0/29 is subnetted, 1 subnets
D EX    3.3.3.0 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0
     4.0.0.0/24 is subnetted, 1 subnets
D EX    4.4.4.0 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0
     5.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D EX    5.5.5.5/32 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0
D EX    5.5.5.48/29 [170/2560002816] via 1.1.1.1, 00:00:06, FastEthernet0/0

Now the task states that I need to ensure 5.5.5.48/29 is redistributed, but not 5.5.5.5/32 – I’m not allowed to use a prefix-list and I’m not allowd to use a route-map that matches an interface.

If we then use a regular ACL, we’ll end up redistributing 5.5.5.5/32 as well if we’re not careful. What actually happens if the tasks says we need to redistribute all subnets that are /29 only. This would be 3.3.3.3/29 and 5.5.5.5.48/29

The simple answer is the extended list. Let’s do all /29s:

access-list 150 permit ip host 3.3.3.0 host 255.255.255.248
access-list 150 permit ip host 5.5.5.48 host 255.255.255.248
!
route-map SLASH29 permit 10
 match ip address 150
!
router eigrp 1
 redistribute connected metric 1 1 1 1 1 route-map SLASH29

Basically the ‘source’ becomes the IP address and the ‘destination’ becomes the subnet mask.

Does it work? Let’s take a look:
R2:

R2#sh ip route eigrp
     3.0.0.0/29 is subnetted, 1 subnets
D EX    3.3.3.0 [170/2560002816] via 1.1.1.1, 00:02:12, FastEthernet0/0
     5.0.0.0/29 is subnetted, 1 subnets
D EX    5.5.5.48 [170/2560002816] via 1.1.1.1, 00:01:30, FastEthernet0/0

So yes it works just fine. But really in the real world you would be using the far more powerful prefix-list…

CCIE R&S QoS notes

Legacy custom queueing:

  • queue-list 1 [options]
  • custom-queue-list [x]
  • Can use ACLs to match traffic in queue list
  • Can be attached to an interface or frame-relay map-class

Legacy priority queueing:

  • priority-list 1 [options]
  • priority-group 1
  • Can use ACLs as above
  • Can be attached to an interface or frame-relay map-class

Legacy RED:

  • configured directly under the interface
  • uses FIFO, so can’t use RED and priority/custom queueing at the same time

Serial compression:

  • Compression you can use will depend on the encapsulation of the link.
  • PPP and HDLC use compression under the interface as these are point-to-pint
  • Frame-relay’s compression is configured under the frame-relay map command. This allows different compression types to different DLCIs

TCP/RTP header compression:

  • You need 2 connections for each session. So 8 sessions needs 16 connections
  • Both types of compression can be called in an MQC policy

Legacy generic traffic shaping:

  • interface x/x
  • traffic-shape group [acl] [settings]

CAR limiting:

  • Can use regular or special mac/ip prec/mpls exp ACLs
  • If using special ACL, must specify rate-limit option and can only contain a SINGLE line

MQC:

  • You can match on a lot of things, including the DLCI

Frame-relay fragmentation:

  • Can only do fragmentation on an interface or in a map-class

GRE:

  • Use QoS pre-classify on the tunnel interface in order to be able to do QoS on the inner markings

RSVP:

  • For the most part, ip rsvp bandwidth is the only command you need under the interface
  • Can still use MQC and tell classes to use remaining unreserved percents of bandwidth

3560 aggregate policer:

  • mls qos aggregate-policer [name] [bps] [burst] exceed-action drop
  • policy-map [name]
  • class [name]
  • police aggregate [name]
  • etc

3560 srr-queue:

  • srr-queue bandwidth shape uses 1/x as the calculation
  • srr-queue bandwidth share uses weights as the calculation
  • Both of the above are based on the physical speed of the interface. So take note if you’re limiting via srr-queue bandwidth limit
  • srr-queue bandwidth limit is an outbound limiter. To limit inbound you need to police

Lab 12, 13, 14, 17, 18, and 20

So I completed these labs and this is where I got no points:

Lab 12 – difficulty rating 7/10 (69/79)

  • 1.1; 3.5; and 8.3

Lab 13 – difficult rating 9/10 – (57/79)

  • 2.3; 2.4; 6.4; 7.1; 7.2; 7.4; and 8.5

Lab 14 – difficult rating 9/10 – (51/79)

  • 1.1; 1.5; 2.3; 2.4; 2.11; 5.2; 5.3; 6.2; 6.3; and 7.2

Lab 17 – difficulty rating 8/10 (57/79)

  • 2.4; 6.3; 6.7; 6.8; 8.3; 8.4; and 8.5

Lab 18 – difficulty rating 7/10 (57/79)

  • 2.8; 7.1; 7.4; 7.5; 7.6; 7.7; and 8.6

Lab 20 – difficulty rating 8/10 (60/79)

  • 2.7; 2.8; 2.10; 6.4; 7.1; and 7.2

So once again if we count the sections together where I get a zero I get this:

  • Layer2 – 3
  • IGP and BGP – 10
  • IPv6 – 1
  • MPLS – 0
  • Multicast – 2
  • Security – 7
  • Services – 11
  • QoS – 6

These labs are pretty service heavy. Hence the heavy numbers on this side. In fact there are hardly any MPLS labs at all, so the fact I got 0 wrong is not a good indication. I want to do the 7-11 run again with one of these labs thrown into the mix each time to mix it up a bit.

My layer2 is still good. Again the majority of the IGP and BGP questions I got wrong were down to silly mistakes! I need to read the questions and be 100% what exactly is being asked! A good thing is that I’m starting to get very good at multicast, which used to be my worst subject of all!

I’ll shortly be starting INE Vol1′s QoS section and will be busy with that until I complete all the vol1 labs for QoS. Once completed it’s back to vol 2 again.