Sunday, February 24, 2008

Configuring Sinkholes (Cisco Systems)

Worm Mitigation Technical Details - Cisco Systems

Sinkholes
A sinkhole is a multifaceted security tool-essentially, a portion of the network that is designed to accept and analyze attack traffic. Sinkholes were originally used by ISPs to engulf attack traffic, in many cases drawing attacks away from a customer or other target. In more recent times, sinkholes have been used in enterprise environments to monitor attacks, detect scanning activity from infected machines, and generally monitor for other malicious activity.
This document illustrates how a sinkhole can be used in diverting attack traffic, monitoring for worm propagation, and monitoring other potentially malicious traffic.
Traditional Sinkhole - Diverting Attack Traffic
In the first sinkhole application, a publicly accessible Web server is the target of either a DoS or DDoS attack. Figure 1 illustrates how server WWW1 is unavailable due to the attack. Additionally, the extremely high traffic volume has saturated links and routers, making server WWW2 unavailable as well.


The Attack

The Diversion

Monitoring for Worm Propagation

Backscatter Traffic



First Sinkhole Design Option

Second Sinkhole Design Option

Routing Techniques

Again using an attack scenario as an example, there are many cases where it will not be desirable or feasible to shift the attack stream to a sinkhole. In these cases, it might be preferable to simply drop the stream as close to ingress as possible.

As such, a technique called remote-triggered black hole routing (also known as remote-triggered black hole filtering) can be used. Although the technique was originally developed for dealing with attacks in ISP environments, it can also be used effectively in an enterprise network for preventing worm spread. Additionally, this technique can be used for "black holing" any internal hosts participating in outbound DoS attacks, in the event that a host (such as a roaming laptop) has been compromised in this way.

This technique performs multiple functions:

  • Black hole traffic at the line rate
  • Provide remote trigger capability to multiple routers
  • Process a large number of addresses if required
  • Drop traffic based on both destination and source address, if required

To explain the technique, we will initially illustrate how it is used to mitigate an Internet-based DoS or DDoS attack. We will then explain how it can be adapted in an enterprise network.

Black Hole Routing

Remote-Triggered Black Hole Routing

Configuration for Announcing Prefixes to Send to Black Hole

router bgp 999
...
redistribute static route-map STATIC-TO-BGP
...
!
route-map STATIC-TO-BGP permit 10
match tag 66
set ip next-hop 192.0.2.1
set local-preference 50
set community no-export 999:000
set origin igp
!
Route-map STATIC-TO-BGP permit 20
!
...
ip route 171.xxx.xxx.1 255.255.255.255 Null0 Tag 66
!



Mapping of a Prefix to Null0


Internal Routing Operation of Remote-Triggered Black Hole Routing (Filtering)


Dropping on Source Address
One of the criteria for remote-triggered black hole routing to be effective as a security tool is the ability to drop traffic based on both destination address and source addresses. For example, if a host is infected with a worm, it will be identified by its source address. To prevent the spread of the worm, it is necessary to have the capability to drop any traffic originating from that source address.

A second scenario requiring a mitigation technique is one in which spoofed source addresses are used. With recent worms, such as SQL Slammer and Blaster, the host’s real IP address is used to propagate the worm. This is not to say that other worms might not use spoofed addresses. As such, the scenario needs to be accommodated. There is no reason that any host should ever send out a packet with an address other than what was assigned to it. Any packets being sent out with illegitimate source addresses should be dropped at the first router hop.

The feature that enables both of these requirements is Unicast Reverse Path Forwarding (Unicast RPF). Information about Unicast RPF is available at:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fothersf/scfrpf.htm

Unicast RPF in the traditional strict mode. If a packet is received on an interface, a route to that packet’s source address must be available back through the same interface on which the packet was received. If this route does not exist, the packet fails the RPF check and is dropped. It is recommended that this technique be deployed on all user-facing interfaces. This technique is an effective way to drop any spoofed packets from hosts on the local network at the first router hop.


Unicast RPF in Strict Mode

!
interface FastEthernet2/0
ip address 192.xxx.xxx.50 255.255.255.0
ip verify unicast reverse-path
...
speed 100
full-duplex
!


Unicast RPF in Loose Check Mode

!
interface FastEthernet2/0
ip address 192.xxx.xxx.50 255.255.255.0
ip verify unicast source reachable-via any
...
speed 100
full-duplex
!

Selective Remote Traffic Dropping

Friday, February 22, 2008

How to Quickly Analyze your Windows Performance Monitor Logs

Monitoring your server for performance issues and finding performance bottlenecks is one of the administrative tasks I like the least and I suspect you feel the same way. Luckily for us, a new tool called PAL (Performance Analysis of Logs) reads a performance monitor counter log and analyzes it using known thresholds. Check it out!

read more | digg story

Thursday, February 21, 2008

Wuala: Combining the Best of P2P Storage & Sharing

Wua.la is offering a free online storage and sharing service that combines the best of Pando and Grouper. It is elegant, clever, and easy to use, and its sharing features alone are worthy of giving it a whirl. (...) You can drag and drop files - images, videos, music, document - onto the client. (...) If you would like to try the service, visit...

read more | digg story

Wednesday, February 20, 2008

How to Quickly Analyze your Windows Performance Monitor Logs

Monitoring your server for performance issues and finding performance bottlenecks is one of the administrative tasks I like the least and I suspect you feel the same way. Luckily for us, a new tool called PAL (Performance Analysis of Logs) reads a performance monitor counter log and analyzes it using known thresholds. Check it out!

read more | digg story

Saturday, February 16, 2008

GUI based firewall configuration tool

Firewall Builder is multi-platform firewall configuration and management tool. It consists of a GUI and set of policy compilers for various firewall platforms.

read more | digg story

mencoder encoding samples

mencoder source.avi -vf crop=576:432::0,scale -zoom -xy 464 -sws 2 -ovc x264 -x264encopts subq=4:bframes=2:b_pyramid:weight_b:bitrate=650:threads=2 -ffourcc h264 -oac mp3lame -lameopts preset=128 -o result.avi


mencoder source.avi -vf crop=576:432::0,scale -zoom -xy 368 -sws 2 -ovc x264 -x264encopts subq=4:bframes=2:b_pyramid:weight_b:bitrate=650:threads=2:pass=1:turbo -ffourcc h264 -oac mp3lame -lameopts preset=128 -o "/nul"
mencoder.exe" source.avi -vf crop=576:432::0,scale -zoom -xy 368 -sws 2 -ovc x264 -x264encopts subq=4:bframes=2:b_pyramid:weight_b:bitrate=650:threads=2:pass=1:turbo -ffourcc h264 -oac mp3lame -lameopts preset=128 -o result.avi


mencoder source.avi -o result.avi -oac mp3lame -lameopts vbr=3:br=128:vol=0 -ovc xvid -ffourcc DX50 -vf crop=576:432::0,pp=lb,scale -zoom -xy 368 -sws 2 -info artist="created by ..." -xvidencopts turbo:vhq=0:bitrate=700:threads=2

mencoder source.avi -o result.avi -oac mp3lame -lameopts vbr=3:br=128:vol=0 -ovc xvid -vf crop=576:432::0,pp=lb,scale -zoom -xy 368 -sws 2 -info artist="created by ..." -xvidencopts turbo:vhq=2:bvhq=1:chroma_opt:quant_type=mpeg:bitrate=700:threads=2

Thursday, February 14, 2008

Question Regarding Backbone Router Access in the CCIE Lab

 

Brian,
Ihave a question regarding the R&S Lab exam. Can I telnet to the back bone routers
totest routing?

For our rack rentals we allow access to the backbone routers but in the real CCIE lab you will not have access to them. You will have to understand how to verify your solutions without access to the backbone routers.

ShareThis

How To Use A Cisco Access Server

 

Hi Brian,

Howdo I switch between devices when using a Cisco access server?

Thereare two ways to connect to devices attached to an access server, you can terminate your exec session on the access server itself (one terminal window for all sessions), or you can terminate your exec session on the device connected to the access server (one terminal window for each session). In the CCIE Lab Exam you will have the option to do either, so pick whichever method works best for you and stick with it during your preparation.

Whenyou terminate your exec session on the access server you then “reverse telnet” to the individual devices connected to the access server. Normally to do this you first login to the access server and then issue the “show hosts” command to see the host mappings. Next, reverse telnet to them by typing the hostname and pressing enter. To get back to the access server issue the escape sequence CTRL-SHIFT-6-X. To do so hold ctrl and shift, hit 6, release all keys, then hit X. From the access server you can then open new connections or resume connections that you already have open.

Whenyou terminate your exec session on the device connected to the access server, i.e. by telnetting to the access server at port 2001, you cannot issue the escape sequence to reconnect to the access server. In this situation you would open multiple terminal windows if you wanted to connect to multiple devices.

Formore information watch this class-on-demand video on using an access server.

ShareThis

How do I compute complex wildcard masks for access-lists?

 

Access-list address and wildcard pair calculations are based
aroundthe AND and XOR logic gates.

AND: The output is high only when both inputs A and B are high.

A AND B 
______________|A | B | out |
| 0 | 0 | 0 ||0 | 1 | 0 |
| 1 | 0 | 0 ||1 | 1 | 1 |
--------------

XOR: The output is high when either of inputs A or B is high, but not if
bothA and B are high.

AXOR B 
______________|A | B | out |
| 0 | 0 | 0 ||0 | 1 | 1 |
| 1 | 0 | 1 ||1 | 1 | 0 |
--------------

To find the most specific address and wildcard pair that will
match two addresses, A and B, we use the gates AND and XOR. The address
wewill check in the access-list is A AND B. The wildcard used to check
in this list will be A XOR B.

access-list 1 permit [address_to_check] [wildcard_used_to_check] 

Takethe following example:

We have two IP addresses, 10.20.30.40, and 40.30.20.10. How do we
createan access-list that is the most specific match for these two
addresses? First, write both addresses out in binary:

10.20.30.40 = 00001010.00010100.00011110.00101000 
40.30.20.10 = 00101000.00011110.00010100.00001010

To find the address_to_check, take the logical AND of these addresses.

   00001010.00010100.00011110.00101000 
&& 00101000.00011110.00010100.00001010-------------------------------------- 00001000.00010100.00010100.00001000

Thisis our address_to_check: 8.20.20.8

To find the matching wildcard_used_to_check, we take the logical XOR of
theseaddresses.

    00001010.00010100.00011110.00101000 
XOR 00101000.00011110.00010100.00001010--------------------------------------- 00100010.00001010.00001010.00100010

Thisis our wildcard_used_to_check: 34.10.10.34

Therefore, the most specific match for both 10.20.30.40 and 40.30.20.10
wouldbe:

access-list 1 permit 8.20.20.8 34.10.10.34

Here’sone more:

A = 1.2.3.4
B= 5.6.7.8

1.2.3.4= 00000001.00000010.00000011.00000100 
5.6.7.8 = 00000101.00000110.00000111.00001000A && B = 00000001.00000010.00000011.00000000
A XOR B = 00000100.00000100.00000100.00001100

Therefore the access-list would read:

access-list 1 permit 1.2.3.0 4.4.4.12

ShareThis

How do prefix-lists work?

 

Prefix-lists are used to match on prefix and prefix-length pairs. Normal prefix-list syntax is as follows:

ip prefix-list LIST permit w.x.y.z/len 

Wherew.x.y.z is your exact prefix
And where len is your exact prefix-length

“ipprefix-list LIST permit 1.2.3.0/24″ would be an exact match for the prefix 1.2.3.0 with a subnet mask of 255.255.255.0. This does not match 1.2.0.0/24, nor does it match 1.2.3.4/32, nor anything in between.

Whenyou add the keywords “GE” and “LE” to the prefix-list, the “len” value changes its meaning. When using GE and LE, the len value specifies how many bits of the prefix you are checking, starting with the most significant bit.

ip prefix-list LIST permit 1.2.3.0/24 le 32 

Thismeans:
Check the first 24 bits of the prefix 1.2.3.0
Thesubnet mask must be less than or equal to 32

This equates to the access-list syntax:

access-list1 permit 1.2.3.0 0.0.0.255
ip prefix-list LIST permit 0.0.0.0/0 le 32

Thismeans:
Check the first 0 bits of the prefix 0.0.0.0
Thesubnet mask must be less than or equal to 32
This equates to anything

ipprefix-list LIST permit 0.0.0.0/0

This means:
Theexact prefix 0.0.0.0, with the exact prefix-length 0.
This is matching a default route.

ipprefix-list LIST permit 10.0.0.0/8 ge 21 le 29

This means:
Checkthe first 8 bits of the prefix 10.0.0.0
The subnet mask must be greater than or equal to 21, and less than or
equalto 29.

ip prefix-list CLASS_A permit 0.0.0.0/1 ge 8 le 8

Thismatches all class A addresses with classful masks. It means:
Check the first bit of the prefix, it must be a 0.
Thesubnet mask must be greater than or equal to 8, and less than or equal to 8. ( It is exactly 8 )

Whenusing the GE and LE values, you must satisfy the condition:

Len < GE <= LE

Therefore“ip prefix-list LIST permit 1.2.3.0/24 ge 8″ is not a valid list.

What you can not do with the prefix-list is match on arbitrary bits like you can in an access-list. Prefix-lists cannot be used to check if a number is even or odd, nor check if a number is divisible by 15, etc… Bit checking in a prefix-list is sequential, starting with the most significant (leftmost) bit.

ShareThis

How does the “ppp chap password” command work?

 

Unlike PAP, CHAP does not actually send a password over the line. Instead, a hash value made up of the password and magic number is sent. Unless the hash matches from both authenticating parties, authentication is not successful.

By default, the router sends it’s hostname for authentication when using chap. The router on the other side does a lookup in its local database, radius server, or tacacs server, and finds the password that is paired with that username. If there is no matching username in the database, the password specified with the interface level command ‘ppp chap password’ is used as the default password.
Suppose you have a central office that has many remote clients dialing into it. If you don’t want to create an entry in the user database for each remote client, you can just specify a default password with ‘ppp chap password’. As long as the remote clients have an entry for the central site in their user database, authentication will be successful.

ShareThis

How do I control which interfaces run EIGRP vs. RIP?

 

Hi Brian,

Ihave a router with two interfaces running both RIP and EIGRP as follows:

Interface  IP-Address      OK? Method Status  Prot 
Serial0 172.16.5.5 YES manual up upSerial1172.16.1.5 YES manual up up

router rip network 172.16.0.0
!
router eigrp 2001 network 172.16.0.0

S0 should be RIP only, and S1 should be EIGRP only. RIP should not listen to broadcasts on S1
andEIGRP should not listen to multicasts on S0. How do I do that?


SinceEIGRP uses periodic hellos to establish adjacency, passive-interface is sufficient in this case. Since passive-interface in EIGRP suppresses the generation of hellos out an interface, adjacency cannot be established, and therefore there can be no exchange of routes.

Aneven easier method of choosing which specific interfaces are running EIGRP is to use a wildcard mask when you use the network statement. The ‘network’ statement in IGP does not actually mean what networks you are advertising, it means what interfaces you are running the protocol on. If you only want to run EIGRP on your Serial 1 interface with an address of 172.16.1.5, use the following syntax:

router eigrp 2001 
network 172.16.1.5 0.0.0.0

This means that only the interface 172.16.1.5 is running EIGRP. The opposite of this most specific syntax would be:

router eigrp 2001 
network 0.0.0.0 255.255.255.255

This means that all interfaces are running EIGRP.

With RIP, the case is different than EIGRP. Since RIP does not use periodic hellos like EIGRP, OSPF, or IS-IS, passive-interface simply means that you will not send any routing updates out an interface. This does not mean that you will not receive routing updates in that interface. To prevent learning routes in an interface using RIP, you could use a distribute-list that denies everything (which would also work for EIGRP), or use an access-list that denies RIP altogether. Take the following examples:

access-list 1 deny any 
!
router rip network 172.16.0.0
distribute-list 1 in serial 1

or

access-list 100 deny udp any eq rip any eq rip 
access-list 100 permit ip any any!interface serial 1
ip access-group 100 in

Both would accomplish the same goal.

ShareThis

What’s the difference between a dialer profile and a rotary group?

 

HiBrian,

I am using dialer profiles for ISDN and I want protocol broadcasts such as RIP to be sent out accross the ISDN link. I tried to find the command that allows me to configure broadcast but the dialer interfaces do not accept the dialer map command. How do I accomplish this?

When using dialer profiles, dialer interfaces are point-to-point, therefore there is no need for protocol mappings. IP broadcasts should not have any trouble being sent across the interface as long as you have an IP address configured on the interface. Dialer maps are only used on dialer interfaces when using rotary groups. Dialer profiles are for when you have a single physical interface, but multiple destinations to dial. Rotary groups are for when you have multiple physical interfaces, but one destination to dial.

ShareThis

Understanding the OSPF Point-to-Multipoint Non-broadcast Network Type

 

OSPF point-to-multipoint non-broadcast was designed to allow for the assignment of the cost on a per neighbor basis as opposed to using the interface’s cost. This
isuseful on a multipoint Frame Relay interface where there are two neighbors advertising the same route but the CIRs for the DLCIs to reach each neighbor is different or these two neighbors that are advertising the same route have different port speeds to the Frame Relay network. Remember that the cost is based on your “incoming” interface’s bandwidth and not the bandwidth of the neighbor’s interface that connects to you.

Asan example say we have two remote routers over Frame Relay and the remote routers are both connected to and advertising the same Ethernet segment. Our router is connected to these two routers via Frame Relay. One of the remote routers has a T1 Frame Relay connection and the other has a 64k Frame Relay connection. Since our cost to the Ethernet segment advertised by these two routers will be calculated based on the cost of the Ethernet segment plus the cost of our incoming interface, both routes appear to be equal cost. Obviously this is not what we would want. We would want to prefer the route from the router with the T1 connection over the 64k connection.

Hereis an example with two remote routers advertising the same network (loopback interfaces):

Rack2R4#showip ospf interface s0/0 | include Cost 
Process ID 1, Router ID 150.1.4.4, Network Type POINT_TO_MULTIPOINT,
Cost: 64Rack1R4#sho run int s0/0
interface Serial0/0 ip address 154.1.0.4 255.255.255.0
encapsulation frame-relay ip ospf network point-to-multipoint
frame-relay map ip 154.1.0.3 403 broadcast frame-relay map ip 154.1.0.5 405 broadcast
no frame-relay inverse-arpendRack2R4#sho ip route 150.1.0.0 255.255.255.0
Routing entry for 150.1.0.0/24 Known via "ospf 1", distance 110, metric 65, type intra area
Last update from 154.1.0.3 on Serial0/0, 00:00:30 ago Routing Descriptor Blocks:
* 154.1.0.3, from 150.1.3.3, 00:00:30 ago, via Serial0/0 Route metric is 65, traffic share count is 1
154.1.0.5, from 150.1.5.5, 00:00:30 ago, via Serial0/0 Route metric is 65, traffic share count is 1

As you can see both 154.1.0.3 (router-ID 150.1.3.3) and 154.1.0.5 (router-ID 150.1.5.5) are advertising the 150.1.0.0/24 network with an OSPF cost of 1 (total cost minus our interface’s cost, 65-64=1). If both of these routers have the same port speed to the Frame Relay network then this is what we would want to see, two equal cost paths. But if they have different port speeds, then we would want to prefer the route from the router with the higher port speed, theoretically. The problem is that OSPF does not take into account the cost of the remote router’s interface to us. We only take into account the cost of the loopback and our interface’s cost to reach the remote neighbor.

Toprefer the route from the router with the higher port speed, we are going to use OSPF point-to-multipoint non-broadcast to specify the cost on a per neighbor basis. In this example we are going to add a cost of 25 to the routes from 154.1.0.5 and 50 to the routes from 154.1.0.3.

Rack1R4#shorun | be router ospf 
router ospf 1 network 154.1.0.0 0.0.255.255 area 0
neighbor 154.1.0.5 cost 25 neighbor 154.1.0.3 cost 50

Rack1R4#sho run int s0/0interfaceSerial0/0
ip address 154.1.0.4 255.255.255.0 encapsulation frame-relay
ip ospf network point-to-multipoint non-broadcast frame-relay map ip 154.1.0.3 403 broadcast
frame-relay map ip 154.1.0.5 405 broadcast no frame-relay inverse-arp
endRack1R4#sho ip route 150.1.0.0 255.255.255.0
Routing entry for 150.1.0.0/24 Known via "ospf 1", distance 110, metric 26, type intra area
Last update from 154.1.0.5 on Serial0/0, 00:06:13 ago Routing Descriptor Blocks:
* 154.1.0.5, from 150.1.5.5, 00:06:13 ago, via Serial0/0 Route metric is 26, traffic share count is 1
^^^^^^^^^^^^^^^^^^^

Nowwe can see that we prefer the route from 154.1.0.5 (router-ID 150.1.5.5).

ShareThis

Troubleshooting Multicast RPF Failure

 

Hi Brian,

Ienjoy the new blog feature. Lots of valuable information condensed in a small space. Could you explain in a nutshell how to troubleshoot multicast RPF failures? I understand the concept, just figuring out what shows and/or debugs to use always seems to take me 30 minutes rather than 5 minutes.

Firstlet’s talk briefly about what the RPF check, or Reverse Path Forwarding check, is for multicast. PIM is known as Protocol Independent Multicast routing because it does not exchange its own information about the network topology. Instead it relies on the accuracy of an underlying unicast routing protocol like OSPF or EIGRP to maintain a loop free topology. When a multicast packet is received by a router running PIM the device first looks at what the source IP is of the packet. Next the router does a unicast lookup on the source, as in the “show ip route w.x.y.z”, where “w.x.y.z” is the source. Next the outgoing interface in the unicast routing table is compared with the interface in which the multicast packet was received on. If the incoming interface of the packet and the outgoing interface for the route are the same, it is assumed that the packet is not looping, and the packet is candidate for forwarding. If the incoming interface and the outgoing interface are *not* the same, a loop-free path can not be guaranteed, and the RPF check fails. All packets for which the RPF check fails are dropped.

Nowas for troubleshooting the RPF check goes there are a couple of useful show and debug commands that are available to you on the IOS. Suppose the following topology:

multicast.rpf.failure.gif

Wewill be running EIGRP on all interfaces, and PIM dense mode on R2, R3, R4, and SW1. Note that PIM will not be enabled on R1. R4 is a multicast source that is attempting to send a feed to the client, SW1. On SW1 we will be generating an IGMP join message to R3 by issuing the “ip igmp join” command on SW1’s interface Fa0/3. On R4 we will be generating multicast traffic with an extended ping. First let’s look at the topology with a successful transmission:

SW1#conf t 
Enter configuration commands, one per line. End with CNTL/Z.SW1(config)#intfa0/3
SW1(config-if)#ip igmp join 224.1.1.1SW1(config-if)#endSW1#R4#pingProtocol [ip]:
Target IP address: 224.1.1.1Repeatcount [1]: 5
Datagram size [100]:Timeoutin seconds [2]:
Extended commands [n]: yInterface[All]: Ethernet0/0
Time to live [255]:Sourceaddress: 150.1.124.4
Type of service [0]:SetDF bit in IP header? [no]:
Validate reply data? [no]:Datapattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:Sweeprange of sizes [n]:
Type escape sequence to abort.Sending5, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.124.4Reply to request 0 from 150.1.37.7, 32 ms
Reply to request 1 from 150.1.37.7, 28 msReplyto request 2 from 150.1.37.7, 28 ms
Reply to request 3 from 150.1.37.7, 28 msReplyto request 4 from 150.1.37.7, 28 ms

Now let’s trace the traffic flow starting at the destination and working our way back up the reverse path.

SW1#show ip mroute 224.1.1.1 
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data groupOutgoinginterface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/ExpiresInterfacestate: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:03:05/stopped, RP 0.0.0.0, flags: DCLIncominginterface: Null, RPF nbr 0.0.0.0
Outgoing interface list:FastEthernet0/3,Forward/Dense, 00:03:05/00:00:00

(150.1.124.4, 224.1.1.1), 00:02:26/00:02:02, flags: PLTXIncominginterface: FastEthernet0/3, RPF nbr 150.1.37.3
Outgoing interface list: Null

SW1’sRPF neighbor for (150.1.124.4,224.1.1.1) is 150.1.37.3, which means that SW1 received the packet from R3.

R3#show ip mroute 224.1.1.1 
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winnerTimers:Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:03:12/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0Outgoinginterface list:
Serial1/3, Forward/Dense, 00:03:12/00:00:00Serial1/2,Forward/Dense, 00:03:12/00:00:00
Ethernet0/0, Forward/Dense, 00:03:12/00:00:00(150.1.124.4, 224.1.1.1), 00:02:33/00:01:46, flags: T
Incoming interface: Serial1/3, RPF nbr 150.1.23.2Outgoinginterface list:
Ethernet0/0, Forward/Dense, 00:02:34/00:00:00Serial1/2,Prune/Dense, 00:02:34/00:00:28

R3’s RPF neighbor is 150.1.23.2, which means the packet came from R2.

R2#show ip mroute 224.1.1.1 
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winnerTimers:Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:02:44/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0Outgoinginterface list:
FastEthernet0/0, Forward/Dense, 00:02:44/00:00:00Serial0/1,Forward/Dense, 00:02:44/00:00:00

(150.1.124.4, 224.1.1.1), 00:02:44/00:01:35, flags: TIncominginterface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:Serial0/1,Forward/Dense, 00:02:45/00:00:00

R2 has no RPF neighbor, meaning the source is directly connected. Now let’s compare the unicast routing table from the client back to the source.

SW1#show ip route 150.1.124.4 
Routing entry for 150.1.124.0/24Knownvia "eigrp 1", distance 90, metric 20540160, type internal
Redistributing via eigrp 1Lastupdate from 150.1.37.3 on FastEthernet0/3, 00:11:23 ago
Routing Descriptor Blocks:*150.1.37.3, from 150.1.37.3, 00:11:23 ago, via FastEthernet0/3
Route metric is 20540160, traffic share count is 1Totaldelay is 21100 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytesLoading1/255, Hops 2

R3#show ip route 150.1.124.4Routingentry for 150.1.124.0/24
Known via "eigrp 1", distance 90, metric 20514560, type internalRedistributingvia eigrp 1
Last update from 150.1.13.1 on Serial1/2, 00:11:47 agoRoutingDescriptor Blocks:
* 150.1.23.2, from 150.1.23.2, 00:11:47 ago, via Serial1/3Routemetric is 20514560, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 128 KbitReliability255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1150.1.13.1,from 150.1.13.1, 00:11:47 ago, via Serial1/2
Route metric is 20514560, traffic share count is 1Totaldelay is 20100 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytesLoading1/255, Hops 1

R2#show ip route 150.1.124.4Routingentry for 150.1.124.0/24
Known via "connected", distance 0, metric 0 (connected, via
interface)Redistributingvia eigrp 1
Routing Descriptor Blocks:*directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1

Basedon this output we can see that SW1 sees the source reachable via R3, which was the neighbor the multicast packet came from. R3 sees the source reachable via R1 and R2 due to equal cost load-balancing, with R2 as the neighbor that the multicast packet came from. Finally R2 sees the source as directly connected, which is where the multicast packet came from. This means that the RPF check is successful as traffic is transiting the network, hence we had a successful transmission.

Nowlet’s modify the routing table on R3 so that the route to R4 points to R1. Since the multicast packet on R3 comes from R2 and the unicast route will going back towards R1 there will be an RPF failure, and the packet transmission will not be successful. Again note that R1 is not routing multicast in this topology.

R3#conf t 
Enter configuration commands, one per line. End with CNTL/Z.R3(config)#iproute 150.1.124.4 255.255.255.255 serial1/2
R3(config)#endR3#R4#pingProtocol [ip]:
Target IP address: 224.1.1.1Repeatcount [1]: 5
Datagram size [100]:Timeoutin seconds [2]:
Extended commands [n]: yInterface[All]: Ethernet0/0
Time to live [255]:Sourceaddress: 150.1.124.4
Type of service [0]:SetDF bit in IP header? [no]:
Validate reply data? [no]:Datapattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:Sweeprange of sizes [n]:
Type escape sequence to abort.Sending5, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.124.4.....R4#

We can now see that on R4 we do not receive a response back from the final destination… so where do we start troubleshooting? First we want to look at the first hop away from the source, which in this case is R2. On R2 we want to look in the multicast routing table to see if the incoming interface list and the outgoing interface list is correctly populated. Ideally we will see the incoming interface as FastEthernet0/0, which is directly connected to the source, and the outgoing interface as Serial0/1, which is the interface downstream facing towards R3.

R2#show ip mroute 224.1.1.1 
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data groupOutgoinginterface flags: H - Hardware switched
Timers: Uptime/ExpiresInterfacestate: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:07:27/stopped, RP 0.0.0.0, flags: DIncominginterface: Null, RPF nbr 0.0.0.0
Outgoing interface list:Serial0/1,Forward/Dense, 00:07:27/00:00:00
FastEthernet0/0, Forward/Dense, 00:07:27/00:00:00(150.1.124.4, 224.1.1.1), 00:07:27/00:01:51, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0Outgoinginterface list:
Serial0/1, Forward/Dense, 00:04:46/00:00:00

Thisis the correct output we should see on R2. Two more verifications we can do are with the “show ip mroute count” command and the “debug ip mpacket” command. “show ip mroute count” will show all currently active multicast feeds, and whether packets are getting dropped:

R2#show ip mroute count 
IP Multicast Statistics3routes using 1864 bytes of memory
2 groups, 0.50 average sources per groupForwardingCounts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)Group: 224.1.1.1, Source count: 1, Packets forwarded: 4, Packets received:
4
Source: 150.1.124.4/32, Forwarding: 4/1/100/0, Other: 4/0/0Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets
received: 0

“debugip mpacket” will show the packet trace in real time, similar to the “debug ip packet” command for unicast packets. One caveat of using this verification is that only process switched traffic can be debugged. This means that we need to disable fast or CEF switching of multicast traffic by issuing the “no ip mroute-cache” command on the interfaces running PIM. Once this debug is enabled we’ll generate traffic from R4 again and we should see the packets correctly routed through R2.

R4#ping 224.1.1.1 repeat 100 

Type escape sequence to abort.Sending100, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:


R2(config)#int f0/0R2(config-if)#noip mroute-cache
R2(config-if)#int s0/1R2(config-if)#noip mroute-cache
R2(config-if)#endR2#debugip mpacket
IP multicast packets debugging is onR2#IP(0): s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=231,
prot=1, len=100(100), mforwardIP(0):s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=232, prot=1,
len=100(100), mforwardIP(0):s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=233, prot=1,
len=100(100), mforwardIP(0):s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=234, prot=1,
len=100(100), mforwardIP(0):s=150.1.124.4 (FastEthernet0/0) d=224.1.1.1 (Serial0/1) id=235, prot=1,
len=100(100), mforwardR2#undebugall

Now that we see that R2 is correctly routing the packets let’s look at all three of these verifications on R3.

R3#show ip mroute 224.1.1.1 
IP Multicast Routing TableFlags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winnerTimers:Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:00:01/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0Outgoinginterface list:
Serial1/3, Forward/Dense, 00:00:01/00:00:00Ethernet0/0,Forward/Dense, 00:00:01/00:00:00

(150.1.124.4, 224.1.1.1), 00:00:01/00:02:58, flags:Incominginterface: Null, RPF nbr 0.0.0.0
Outgoing interface list:Ethernet0/0,Forward/Dense, 00:00:02/00:00:00
Serial1/3, Forward/Dense, 00:00:02/00:00:00

FromR3’s show ip mroute output we can see that the incoming interface is listed as Null. This is an indication that for some reason R3 is not correctly routing the packets, and is instead dropping them as they are received. For more information let’s look at the “show ip mroute count” output.

R3#show ip mroute count 
IP Multicast Statistics3routes using 2174 bytes of memory
2 groups, 0.50 average sources per groupForwardingCounts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits
per secondOthercounts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received:
15Source:150.1.124.4/32, Forwarding: 0/0/0/0, Other: 15/15/0

Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets
received: 0

Fromthis output we can see that packets for (150.1.124.4,224.1.1.1) are getting dropped, and specifically the reason they are getting dropped is because of RPF failure. This is seen from the “Other: 15/15/0” output, where the second field is RPF failed drops. For more detail let’s look at the packet trace.

R3#conf t 
Enter configuration commands, one per line. End with CNTL/Z.R3(config)#inte0/0
R3(config-if)#no ip mroute-cacheR3(config-if)#ints1/3
R3(config-if)#no ip mroute-cacheR3(

Editing Numbered Access-Lists On The Fly

 

Hi Brian,

I’veheard that items in a numbered ACL can be deleted without taking down the entire ACL. Is it true and how?

Innewer IOS versions sequence numbers can be used to quickly edit, add, and remove entries from a named extended access-list. However in all IOS versions that support named extended access-lists, numbered extended access-lists can actually be treated like named lists where their name is the number. Without sequence numbers you can’t add or edit lines, but if you need to remove a single line from somewhere in the list without deleting it you can. Take the following example:

R1#conf t 
Enter configuration commands, one per line. End with CNTL/Z.R1(config)#access-list100 permit tcp any any
R1(config)#access-list 100 permit udp any anyR1(config)#access-list100 permit ospf any any
R1(config)#access-list 100 permit eigrp any anyR1(config)#doshow access-list 100
Extended IP access list 100 permit tcp any any
permit udp any any permit ospf any any
permit eigrp any any

Nowlet’s suppose that we want to remove the second line that permits udp. Normally we would have to say “no access-list 100″, then recreate the list without line number two. However by treating this like a named access-list we have a second option:

R1(config)#ip access-list extended 100 
R1(config-ext-nacl)#no permit udp any anyR1(config-ext-nacl)#endR1#show access-list 100
Extended IP access list 100 permit tcp any any
permit ospf any any permit eigrp any any

Tada! The list stays intact but the second line has been removed.

ShareThis

Using Extended Access-Lists In A Distribute-List

 

HiBrian,

I’m trying to create a distribute-list in RIP to allow only even routes to be received. I can do it successfully with a standard ACL, however if I use an extended ACL I can’t get any routes at all. I’ve heard that extended ACLs are better because they also check the netmask. What am I doing wrong?

Using an extended access-list with a distribute-list is supported, however the syntax can be a little confusing because it means different things for different applications. When using an extended ACL for a distribute-list in BGP it acts like a prefix-list. This means that you can match on both the address of the prefix and the subnet mask. In other words if you have prefixes 10.0.0.0/8 and 10.0.0.0/16 you can distinguish between them by saying not only must the address be 10.0.0.0 but the subnet mask must be /8. In prefix-list syntax this is very straightforward, as to match this prefix we would use the following:

ip prefix-list PREFIX1 permit 10.0.0.0/8 

Whenusing an extended access-list in BGP the syntax of the list changes in that we are not matching source and destination pairs, but instead are matching the address and netmask. In extended ACL syntax the above prefix-list would read:

access-list 100 permit ip host 10.0.0.0 host 255.0.0.0 

Thismeans that the address must be exactly 10.0.0.0 and the subnet mask must be exactly 255.0.0.0. By changing the “host” keyword to a wildcard mask we can do fuzzy binary matches. For example the following syntax means check any address that starts with “192.168” and has a subnet mask of /24:

access-list 101 permit ip 192.168.0.0 0.0.255.255 host 255.255.255.0 

Inother words this list matches 192.168.0.0/24, 192.168.100.0/24, 192.168.200.0/24, etc.

Thisextended access-list syntax can also be used in a route-map for redistribution filtering in both IGP and BGP. For example if we took the previous access-list 101 and matched it in a route-map as follows:

route-map OSPF_TO_RIP permit 10 
match ip address 100!router rip
redistribute ospf 1 metric 1 route-map OSPF_TO_RIP

This syntax would say that we want to redistribute OSPF routes into RIP, but only those which are 192.168.X.X/24.

Theconfusion for this extended access-list implementation is that when it is called as a distribute-list in IGP the syntax changes. In the previous examples the normal “source” field in the ACL represents the network address, where the “destination” field represents the subnet mask. In IGP distribute-list application the “source” field in the ACL matches the update source of the route, and the “destination” field represents the network address. This implementation allows us to control which networks we are receiving, but more importantly who we are receiving them from. Take the following topology:

R1,R2, and R3 share an Ethernet network 123.0.0.0/8 that is running RIP. Both R1 and R2 are advertising the identical prefixes 10.0.0.0/8 and 20.0.0.0/8 to R3. Their configurations are as follows:

R1#show ip int brief | exclude unassigned 

Interface IP-Address OK? Method Status ProtocolFastEthernet0/0123.0.0.1 YES manual up up
Loopback0 10.0.0.1 YES manual up upLoopback120.0.0.2 YES manual up up

R1#show run | begin router riprouterrip
version 2 network 10.0.0.0
network 20.0.0.0 network 123.0.0.0

R2# show ip int brief | exclude unassignedInterface IP-Address OK? Method Status Protocol
FastEthernet0/0 123.0.0.2 YES manual up upLoopback010.0.0.1 YES manual up up
Loopback1 20.0.0.2 YES manual up upR2#sh run | begin router rip
router rip version 2
network 10.0.0.0 network 20.0.0.0
network 123.0.0.0R3#show ip route rip
R 20.0.0.0/8 [120/1] via 123.0.0.2, 00:00:00, Ethernet0/0 [120/1] via 123.0.0.1, 00:00:00, Ethernet0/0
R 10.0.0.0/8 [120/1] via 123.0.0.2, 00:00:00, Ethernet0/0 [120/1] via 123.0.0.1, 00:00:00, Ethernet0/0

Fromthis output we can see that R3 has the two prefixes installed twice, once from R1 and once from R2. Now let’s suppose that prefix 10.0.0.0/8 we only want to receive from R1, while prefix 20.0.0.0/8 we only want to receive from R2. We can accomplish this with an extended access-list as follows:

R3#conf t 
Enter configuration commands, one per line. End with CNTL/Z.R3(config)#access-list 100 permit ip host 123.0.0.1 host 10.0.0.0
R3(config)#access-list 100 permit ip host 123.0.0.2 host 20.0.0.0R3(config)#routerrip
R3(config-router)#distribute-list 100 in Ethernet0/0R3(config-router)#endR3#clear ip route *
R3#show ip route ripR20.0.0.0/8 [120/1] via 123.0.0.2, 00:00:00, Ethernet0/0
R 10.0.0.0/8 [120/1] via 123.0.0.1, 00:00:00, Ethernet0/0

We can see now R3 only has one entry for each prefix, with the 10.0.0.0/8 coming only from R1 and the 20.0.0.0/8 coming only from R2. The disadvantage of this application however is that we cannot distinguish prefixes based on their netmask. For example we could not say that we want to receive prefix 172.16.0.0/16 from only R1 and prefix 172.16.0.0/24 only from R2. For this implementation in IGP we would use a prefix-list that is called from a distribute-list with the “distribute-list prefix” syntax under the routing process.

ShareThis

Understanding BGP Regular Expressions

 

HiBrian,

Can you explain the easiest way to construct a regular expression in BGP?

Thanks,

Rowan

Hi Rowan,

Regular expressions are strings of special characters that can be used to search and find character patterns. Within the scope of BGP in Cisco IOS regular expressions can be used in show commands and AS-Path access-lists to match BGP prefixes based on the information contained in their AS-Path.

Inorder to understand how to build regular expressions we first need to know what the character definitions are for the regex function of IOS. The below table illustrates the regex characters and their usage. This information is contained in the Cisco IOS documentation under the Appendix of Cisco IOS Terminal Services Configuration Guide, Release 12.2.

+------------------------------------------------------+| CHAR | USAGE                                         | 
+------------------------------------------------------||^ | Start of string |
|------|-----------------------------------------------||$ | End of string |
|------|-----------------------------------------------||[] | Range of characters |
|------|-----------------------------------------------|| - | Used to specify range ( i.e. [0-9] ) |
|------|-----------------------------------------------||( ) | Logical grouping |
|------|-----------------------------------------------||. | Any single character |
|------|-----------------------------------------------||* | Zero or more instances |
|------|-----------------------------------------------||+ | One or more instance |
|------|-----------------------------------------------||? | Zero or one instance |
|------|-----------------------------------------------||_ | Comma, open or close brace, open or close |
| | parentheses, start or end of string, or space |+------------------------------------------------------+

Some commonly used regular expressions include:

+-------------+---------------------------+| Expression  | Meaning                   | 
|-------------+---------------------------||.* | Anything |
|-------------+---------------------------||^$ | Locally originated routes |
|-------------+---------------------------||^100_ | Learned from AS 100 |
|-------------+---------------------------||_100$ | Originated in AS 100 |
|-------------+---------------------------||_100_ | Any instance of AS 100 |
|-------------+---------------------------||^[0-9]+$ | Directly connected ASes |
+-------------+---------------------------+

Let’s break some of the above expressions down step-by-step. The first one “.*” says to match any single character (“.”), and then find zero or more instances of that single character (“*”). This means zero or more instances or any character, which effectively means anything.

Thenext string “^$” says to match the beginning of the string (“^”), and then immediately match the end of the string (“$”). This means that the string is null. Within the scope of BGP the only time that the AS-Path is null is when you are looking at a route within your own AS that you or one of your iBGP peers has originated. Hence this matches locally originated routes.

Thenext string “^100_” says to match the beginning of the string (“^”), the literal characters 100, and then a comma, an open or close brace, an open or close, a parentheses, the start or end of the string, or a space (“_”). This means that the string must start with the number 100 followed by any non-alphanumeric character. In the scope of BGP this means that routes which are learned from the AS 100 will be matched, as 100 will be the first AS in the path when AS 100 is sending us routes.

Thenext string “_100$” is the exact opposite of the previous one. This string says to start with any non-alphanumeric character (“_”), followed by the literal characters 100, followed by the end of the string (“$”). This means that AS 100 is the last AS in the path, or in other words that the prefix in question was originated by AS 100.

Thenext string “_100_” is the combination of the two previous strings with some extra matches. This string means that the literal characters 100 are set between any two non-alphanumeric characters. The first of these could be the start of the string, which would match routes learned from AS 100, while the second of these could be the end of the string, which would match routes originated in AS 100. Another case could be that the underscores represent spaces, in which the string would match any other AS path information as long as “ 100 ” is included somewhere. This would match any routes which transit AS 100, and therefore “_ASN_” is generally meant to match routes that transit a particular AS as defined by the number “ASN”.

Thefinal string “^[0-9]+$” is a little more complicated match. Immediately we can see that the string starts (“^”), and we can see later that it ends (“$”). In the middle we see a range of numbers 0-9 in brackets, followed by the plus sign. The numbers in brackets mean that any number from zero to nine can be matched, or in other words, any number. Next we have the plus sign which means one or more instances. This string “[0-9]+” therefore means one or more instance of any number, or in other words any number including numbers with multiple characters (i.e. 1, 12, 123, 1234, 12345678, etc.). When we combine these all together this string means routes originated in any directly connected single AS, or in other words, the routes directly originated by the peers of your AS.

Nowlet’s look at a more complicated match, and using the above character patterns we will see how we can construct the expression step by step. Suppose we have the following topology below, where we are looking at the network from the perspective of AS 100.

+--------+ +--------+ +--------+ +--------+ 
| AS 200 |-| AS 201 |-| AS 202 |-| AS 203 |\+--------++--------+ +--------+ +--------+ \
\ +--------+ +--------+ +--------+\ \
| AS 300 |-| AS 301 |-| AS 302 | \ \ +--------+ +--------+ +--------+ \ -+--------+
>--| AS 100 | +--------+ +--------+ / -+--------+
| AS 400 |-| AS 401 | / / +--------+ +--------+/ /
/ +--------+ /
| AS 500 |/ +--------+

AS100 peers with ASes 203, 302, 401, and 500, who each have peers as diagramed above. AS 100 wants to match routes originated from its directly connected customers (ASes 203, 302, 401, and 500) in addition to routes originated from their directly connected customers (ASes 202, 301, and 400). The easiest way to create this regular expression would be to think about what we are first trying to match, and then write out all possibilities of these matches. In our case these possibilities are:

203203 202 
302302301
401401400
500

Now we could simply create an expression with multiple lines (7 lines to be exact) that would match all of the possible AS paths, but suppose that AS 100 wants to keep this match as flexible as possible so that it will apply to any other ASes in the future. Now let’s try to generalize the above AS-Path information into a regex.

Firstoff we know that each of the matches is going to start and going to end. This means that the first character we will have is “^” and the last character is “$”. Next we know that between the “^” and “$” there will be either one AS or two ASes. We don’t necessarily know what numbers these ASes will be, so for the time being let’s use the placeholder “X”. Based on this our new possible matches are:

^X$^X X$ 

Nextlet’s reason out what X can represent. Since X is only one single AS, there will be no spaces, commas, parentheses, or any other special type characters. In other words, X must be a number. However, since we don’t know what the exact path is, we must take into account that X may be a number with more than one character (i.e. 10, 123, or 10101). This essentially equates to one or more instance of any number zero through nine. In regular expression syntax our two matches would therefore now read:

^[0-9]+$^[0-9]+ [0-9]+$ 

Thisexpressions reads that we either have a number consisting of one or more characters zero through nine, or a number consisting of one or more characters zero through nine followed by a space and then another number consisting of one or more characters zero through nine. This brings our expression down to two lines as opposed to our original seven, but let’s see how we can combine the above two as well. To combine them, first let us compare what is different between them.

^[0-9]+$^[0-9]+ [0-9]+$ 

Fromlooking at the expressions it is evident that the sequence “ [0-9]+” is the difference. In the first case “ [0-9]+” does not exist in the expression. In the second case “ [0-9]+” does exist in the expression. In other words, “ [0-9]+” is either true or false. True or false (0 or 1) is represented by the character “?” in regex syntax. Therefore we can reduce our expression to:

^[0-9]+ [0-9]+?$ 

Atthis point we run into a problem with the order of operations of the regex. As denoted above the question mark will apply only to the plus sign, and not to the range [0-9]. Instead, we want the question mark to apply to the string “ [0-9]+” as a whole. Therefore this string needs to be grouped together using parentheses. Parentheses are used in regular expressions as simply a logical grouping. Therefore our final expression reduces to:

^[0-9]+( [0-9]+)?$ 

Notethat to match a question mark in IOS, the escape sequence CTRL-V or ESC-Q must be entered first, otherwise the IOS parser will interpret the question mark as an attempt to invoke the context sensitive help.

ShareThis

Understanding PPP over Frame Relay (PPPoFR)

 

Hello Brian,Can you explain how PPP over Frame Relay works? Also what are the advantages and disadvantages of using it over normal Frame Relay configuration?Thanks and regards,

Yaser

Hi Yaser,

Frame Relay does not natively support features such as authentication, link quality monitoring, and reliable transmission. Based on this it is sometimes advantageous to encapsulate an additional PPP header between the normal layer 2 Frame Relay encapsulation and the layer 3 protocol. By running PPP over Frame Relay (PPPoFR) we can then implement authentication of Frame Relay PVCs, or even bind multiple PVCs together using PPP Multilink.

PPPoFRis configure in Cisco IOS through the usage of a Virtual-Template interface. A Virtual-Template is a PPP encapsulated interface that is designed to spawn a “template” of configuration down to multiple member interfaces. The traditional usage of this interface has been on dial-in access servers, such as the AS5200, to support multiple PPP dialin clients terminating their connection on a single interface running IP.

Thefirst step in configuring PPPoFR is to create the Virtual-Template interface. This interface is where all logical options, such as IP address and PPP authentication will be configured. The syntax is as follows:

interface Virtual-Template1 
ip address 54.1.7.6 255.255.255.0 ppp chap hostname ROUTER6
ppp chap password 0 CISCO

Notethe lack of the “encapsulation ppp” command on the Virtual-Template. This command is not needed as a Virtual-Template is always running PPP. This can be seen by looking at the “show interface virtual-template1” output in the IOS. Additionally in this particular case the remote end of this connection will be challenging the router to authenticate via PPP CHAP. The “ppp chap” subcommands have instructed the router to reply with the username ROUTER6 and an MD5 hash value of the PPP magic number and the password CISCO.

Ournext step is to configure the physical Frame Relay interface, and to bind the Virtual-Template to the Frame Relay PVC. This is accomplished as follows:

interface Serial0/0 
encapsulation frame-relay frame-relay interface-dlci 201 ppp Virtual-Template1

Note that the “no frame-relay inverse-arp” command is not used on this interface. Since our IP address is located on the Virtual-Template interface the Frame Relay process doesn’t actually see IP running over the link. Instead it simply sees a PPP header being encapsulated on the link, while the IPCP protocol of PPP takes care of all the IP negotiation for us. Note that the order that these steps are performed in is significant. If a Virtual-Template interface is applied to a Frame Relay PVC before it is actually created you may see difficulties with getting the link to become active.

Alsowhen using a Virtual-Template interface it’s important to understand that a Virtual-Access “member” interface is cloned from the Virtual-Template interface when the PPP connection comes up. Therefore the Virtual-Template interface itself will always be in the down/down state. This can affect certain network designs such as using the backup interface command on a Virtual-Template. In our particular case we can see from the below output this effect:

R6#show ip interface brief | include 54.1.7.6 
Virtual-Access1 54.1.7.6 YES TFTP up upVirtual-Template154.1.7.6 YES manual down down

Aside from this there is no other configuration that directly relates to Frame Relay for PPP. Other options such as authentication, reliability, and multilink would be configured under the Virtual-Template interface.

ShareThis

OSPF MTU Mismatch Issue

 

This problem is common when running OSPF between a switch (i.e 3550 or 3560) and a router. The error message that is generated when this problem occurs is:

%OSPF-5-ADJCHG: Process 1, Nbr 150.8.5.5 on Vlan258 from DOWN to DOWN, Neighbor Down: Dead timer expired
%OSPF-5-ADJCHG:Process 1, Nbr 150.8.2.2 on Vlan258 from EXSTART to DOWN, Neighbor Down: Too many DBD retransmitions

Theresolution is to either adjust the system MTU on the switch or have OSPF ignore the MTU.

A)Change the system MTU on the switch (system mtu 1500 or system mtu routing 1500)

B)Have the router and/or switch ignore the MTU (ip ospf mtu-ignore)

C) Change the interface MTU on the router (GigE only)

Notethat using the system mtu 1500 option requires a reboot of the switch but the system mtu routing 1500 does not require a reboot.

ShareThis

Frame-Relay DCE vs Physical DCE

 

When configuring a Frame Relay switch layer 1 DCE/DTE is independent of layer 2 DCE/DTE. The “clock rate” command can only be applied on the layer 1 DCE side of the cable. This can be determined by looking at the cable for a DTE/DCE labeling, using the “show controllers serial X/X” command or by just issuing the “clock rate” command on both sides. The side that accepts the command is the layer 1 DCE.

Inregards to Frame Relay layer 2 DCE is independent of the layer 1 DCE. Commonly the layer 1 DCE end of the cable is connected to the FRS and the layer 2 DCE is also configured on the FRS side. The configuration of the Frame Relay DCE can be done by using the “frame-relay intf-type dce” command. By default Frame Relay interfaces are DTE. Also as a point of interest the Frame Relay DCE side is the side that commonly generates LMI. I used the word commonly because although unusual you can have a Frame Relay connection without LMI.

ShareThis

Understanding OSPF Network Types

 

By adjusting the hello/dead timers you can make non-compatible OSPF network types appear as neighbors via the “show ip ospf neighbor” but they won’t become “adjacent” with each other. OSPF network types that use a DR (broadcast and non-broadcast) can neighbor with each other and function properly. Likewise OSPF network types (point-to-point and point-to-multipoint) that do not use a DR can neighbor with each other and function properly. But if you mix DR types with non-DR types they will not function properly (i.e. not fully adjacent). You should see in the OSPF database “Adv Router is not-reachable” messages when you’ve mixed DR and non-DR types.

Hereis what will work:

Broadcast to Broadcast
Non-Broadcastto Non-Broadcast
Point-to-Point to Point-to-Point
Point-to-Multipointto Point-to-Multipoint
Broadcast to Non-Broadcast (adjust hello/dead timers)
Point-to-Pointto Point-to-Multipoint (adjust hello/dead timers)

ShareThis

Using Extended ACLs with IGPs

 

Extended ACLs work with IGP protocols but you can not match on the subnet mask portion of the route. Extended ACLs are used with IGP protocols to match the network portion of the route and the IP address of the router that sent the route. Here is an example of its usage:

Noticethat R1 is receiving the 172.16.0.0/16 network from R2 (10.0.0.2) and R3 (10.0.0.3). We will use ACL 100 and a distribute-list inbound so that R1 only uses the 172.16.0.0/16 route that is being advertised by R2.

Rack2R1#showip route rip
R 172.16.0.0/16 [120/1] via 10.0.0.3, 00:00:06, Ethernet0/0
[120/1]via 10.0.0.2, 00:00:06, Ethernet0/0
R 192.168.0.0/24 [120/1] via 10.0.0.2, 00:00:06, Ethernet0/0
[120/1]via 10.0.0.3, 00:00:06, Ethernet0/0
Rack2R1#conf t
Enterconfiguration commands, one per line. End with CNTL/Z.
Rack2R1(config)#access-list 100 deny ip host 10.0.0.3 host 172.16.0.0
Rack2R1(config)#access-list100 per ip any any
Rack2R1(config)#router rip
Rack2R1(config-router)#distribute-list100 in e0/0

Rack2R1(config-router)#^Z
Rack2R1#
Rack2R1#clear ip route *
Rack2R1#show ip route rip
R172.16.0.0/16 [120/1] via 10.0.0.2, 00:00:02, Ethernet0/0
R 192.168.0.0/24 [120/1] via 10.0.0.2, 00:00:02, Ethernet0/0
[120/1]via 10.0.0.3, 00:00:02, Ethernet0/0
Rack2R1#

Moreexamples:

This would permit any 10.X.X.X/X network from 1.1.1.1 (i.e. 10.5.0.0/16, 10.1.1.4/30, 10.50.6.128/25, 10.1.1.64/26, etc)

access-list100 permit ip host 1.1.1.1 10.0.0.0 0.255.255.255

This would permit any 10.1.X.X/X network from 1.1.1.1 (i.e. 10.1.1.0/24, 10.1.5.4/30, 10.1.50.128/25, 10.1.3.64/26, etc)

access-list100 permit ip host 1.1.1.1 10.1.0.0 0.0.255.255

This would permit any 10.1.1.X/X network from 1.1.1.1 (i.e. 10.1.1.0/24, 10.1.1.0/30, 10.1.1.128/25, 10.1.1.64/26, etc)

access-list100 permit ip host 1.1.1.1 10.1.1.0 0.0.0.255

You can also use the wild card mask on the host:

Thiswould permit any 10.X.X.X/X network from 1.1.1.X (i.e. 10.5.0.0/16, 10.1.1.4/30, 10.50.6.128/25, 10.1.1.64/26, etc)

access-list100 permit ip 1.1.1.0 0.0.0.255 10.0.0.0 0.255.255.255

ShareThis

Using Extended ACLs for BGP Filtering

 

Prior to the support of prefix-lists in the IOS advanced filtering for BGP needed to be done using extended ACLs. The syntax for using extended ACLs is shown below:

access-list<ACL #> permit ip <network> <wildcard mask of network> <subnet mask> <wildcard mask of subnet mask>

Thesource portion of the extended ACL is used to match the network portion of the BGP route and the destination portion of the ACL is used to match the subnet mask of the BGP route. Here are some examples:

access-list100 permit ip 10.0.0.0 0.0.0.0 255.255.0.0 0.0.0.0
Matches 10.0.0.0/16 - Only

access-list100 permit ip 10.0.0.0 0.0.0.0 255.255.255.0 0.0.0.0
Matches 10.0.0.0/24 - Only

access-list100 permit ip 10.1.1.0 0.0.0.0 255.255.255.0 0.0.0.0
Matches 10.1.1.0/24 - Only

access-list100 permit ip 10.0.0.0 0.0.255.0 255.255.255.0 0.0.0.0
Matches 10.0.X.0/24 - Any number in the 3rd octet of the network with a /24 subnet mask.

access-list100 permit ip 10.0.0.0 0.255.255.0 255.255.255.0 0.0.0.0
Matches 10.X.X.0/24 - Any number in the 2nd & 3rd octet of the network with a /24 subnet mask.

access-list100 permit ip 10.0.0.0 0.255.255.255 255.255.255.240 0.0.0.0
Matches 10.X.X.X/28 - Any number in the 2nd, 3rd & 4th octet of the network with a /28 subnet mask.

access-list100 permit ip 10.0.0.0 0.255.255.255 255.255.255.0 0.0.0.255
Matches 10.X.X.X/24 to 10.X.X.X/32 - Any number in the 2nd, 3rd & 4th octet of the network with a /24 to /32 subnet mask.

access-list100 permit ip 10.0.0.0 0.255.255.255 255.255.255.128 0.0.0.127
Matches 10.X.X.X/25 to 10.X.X.X/32 - Any number in the 2nd, 3rd & 4th octet of the network with a /25 to /32 subnet mask

ShareThis

What Networks to Advertise and How to Advertise Them

 

Brian,
Whenworking on some of the Volume II labs I’ve noticed that we are sometimes not told to advertise certain networks. What do I do in this situation and how does this relate to the real lab?

Inour labs we leave some ambiguity as to this issue so this means it’s up to you to recognize that there is an issue and come up with a solution. In the real lab you can expect them to explicitly tell you what to advertise and how to advertise it. That being said if this issue does come up in the real lab don’t hesitate to ask the proctor for clarification.

ShareThis

IOS Egress and Ingress Order of Operations

 

Egress Features
1.WCCP Redirect
2. NAT Inside-to-Outside
3.Network Based Application Recognition (NBAR)
4. BGP Policy Accounting
5.Output QoS Classification
6. Output ACL check
7.Output Flexible Packet Matching (FPM)
8. DoS Tracker
9.Output Stateful Packet Inspection (IOS FW)
10. TCP Intercept
11.Output QoS Marking
12. Output Policing (CAR)
13.Output MAC/Precedence Accounting
14. IPsec Encryption
15.Egress NetFlow
16. Egress Flexible NetFlow
17.Egress RITE
18. Output Queuing (CBWFQ, LLQ, WRED)

IngressFeatures
1. IP Traffic Export (RITE)
2.QoS Policy Propagation through BGP (QPPB)
3. Ingress Flexible NetFlow
4.Network Based Application Recognition (NBAR)
5. Input QoS Classification
6.Ingress NetFlow
7. IOS IPS Inspection
8.Input Stateful Packet Inspection (IOS FW)
9. Input ACL
10.Input Flexible Packet Matching (FPM)
11. IPsec Decryption (if encrypted)
12.Unicast RPF check
13. Input QoS Marking
14.Input Policing (CAR)
15. Input MAC/Precedence Accounting
16.NAT Outside-to-Inside
17. Policy Routing

ShareThis

QoS Order of Operations

 

Inbound
1.QoS Policy Propagation through Border Gateway Protocol (BGP) (QPPB)
2. Input common classification
3.Input ACLs
4. Input marking (class-based marking or Committed Access Rate (CAR))
5.Input policing (through a class-based policer or CAR)
6. IP Security (IPSec)
7.Cisco Express Forwarding (CEF) or Fast Switching

Outbound
1.CEF or Fast Switching
2. Output common classification
3.Output ACLs
4. Output marking
5.Output policing (through a class-based policer or CAR)
6. Queueing (Class-Based Weighted Fair Queueing (CBWFQ) and Low Latency Queueing (LLQ)), and Weighted Random Early Detection (WRED)

ShareThis

BGP Order of Preference

 

For inbound updates the order of preference is:
1.route-map
2. filter-list
3.prefix-list, distribute-list

For outbound updates the order of preference is:
1.prefix-list, distribute-list
2. filter-list
3.route-map

ShareThis

Issues with the “ip default-network” Command

 

Commonly people run into issues with the ip default-network command putting static routes in their configuration when they select a network that can not be considered as the candidate default network. I’ll show the two common mistakes with this command that causes this to happen.

Inthe scenario below R4 is receiving a subnet of the 10.0.0.0/8 network (10.1.1.0/24) and has the 172.16.1.0/24 network directly attached to it’s E0/0 interface. We can also see that the router does not have any static routes configured.

Rack4R4(config)#do show ip route rip 
10.0.0.0/24 is subnetted, 1 subnetsR10.1.1.0 [120/1] via 172.16.1.7, 00:00:10, Ethernet0/0
Rack4R4(config)#Rack4R4(config)#doshow ip interface brief | exclude unassigned
Interface IP-Address OK? Method Status
ProtocolEthernet0/0172.16.1.4 YES manual up up
Rack4R4(config)#Rack4R4(config)#doshow run | include ip route
Rack4R4(config)#

NowI’ll set the default network to a network that I have a connected route for.

Rack4R4(config)#ip default-network 172.16.1.0 
Rack4R4(config)#do show run | include ip default-networkRack4R4(config)#Rack4R4(config)#do show run | include ip route
ip route 172.16.0.0 255.255.0.0 172.16.1.0Rack4R4(config)#

We can see that the ip default-network command put a static route in the configuration since the network I tried to mark as default was directly connected. Now I’ll try to remove it.

Rack4R4(config)#no ip route 172.16.0.0 255.255.0.0 172.16.1.0 
%No matching route to delete

Andas we can see from the error message the static route wasn’t removed. To remove the static route just do a “no” on the ip default-network command.

Rack4R4(config)#no ip default-network 172.16.1.0 
Rack4R4(config)#do show run | include ip routeRack4R4(config)#

Now we’ll try to set the default network to a subnet of a classful network that we have a route for in the routing table (see above)

Rack4R4(config)#ip default-network 10.1.1.0 
Rack4R4(config)#do show run | include ip default-networkRack4R4(config)#Rack4R4(config)#do show run | include ip route
ip route 10.0.0.0 255.0.0.0 10.1.1.0Rack4R4(config)#

Once again a static route was added and I’ll need to remove it.

Rack4R4(config)#noip default-network 10.1.1.0

In order for the ip default-network command to actually work I’ll need to select a classful network. To do this I summarized the 10.1.1.124/30 to 10.0.0.0/8 on the router that was advertising the /30 to R4.

Rack4R4(config)#do show ip route rip 
R 10.0.0.0/8 [120/1] via 172.16.1.7, 00:00:01, Ethernet0/0Rack4R4(config)#Rack4R4(config)#ip default-network 10.0.0.0
Rack4R4(config)#do show run | include ip default-networkipdefault-network 10.0.0.0
Rack4R4(config)#Rack4R4(config)#doshow run | include ip route
Rack4R4(config)#Rack4R4(config)#doshow ip route | include \*
ia - IS-IS inter area, * - candidate default, U - per-user static routeR*10.0.0.0/8 [120/1] via 172.16.1.7, 00:00:02, Ethernet0/0
Rack4R4(config)#

Aswe can see now the 10.0.0.0/8 is flagged as our candidate default network.

ShareThis

Understanding How Route Redistribution Works in IPv6

 

Hi Brians,

Justa quick question about the “include-connected” command when redistributing IPv6 protocols (especially RIPng and OSPFv3). From the DocCD it says that it allows the quote “target protocol to redistribute routes learned by the source protocol and connected prefixes on those interfaces over which the source protocol is running”. Is there any reason why this is now necessary to do with IPv6 routing protocols, whereas IPv4 routing protocols would automatically advertise the networks of the connected interfaces if the source protocol is running on them. By the way, this blog is a fantastic idea/revison tool. Keep up the excellent work.

KindRegards,

Colin

HiColin,

In current IOS versions for IPv4 redistribution is a two step process. Let’s suppose that we are trying to redistribute RIPv2 into OSPFv2 by issuing the “redistribute rip subnets” command under the OSPF process. The first thing the router does is to look at the “show ip route rip” output. All of these prefixes are candidate to be redistributed into OSPF. Next the router looks at the “show ip route connected” output. The routes for any connected interfaces from this output running RIPv2 are also candidate to be redistributed into OSPF. In other words, we don’t have to issue the “redistribute connected subnets” to get connected interfaces that run RIP to be sent into the OSPF process.

Inprevious IOS versions this was not always the case however. In many network designs, especially in service provider environments, transit links themselves are not advertised into the routing domain. Based on this design traffic cannot be sent *to* the network itself, only *through* the network. Over the course of IOS releases however this behavior was mostly updated, and now we see that IPv4 protocols, with the exception of IS-IS, do automatically redistribute their connected interfaces.

ForIPv6 whether or not connected links are included in redistribution is up to you at the time of configuration. If we take the previous case for IPv4 and translate it to IPv6 we’ll see that the behavior is not the same. By this I mean that if we issue the “redistribute rip 1” command under the OSPFv3 process, the router will only look at the output of the routes from the “show ipv6 route rip” command, and not the output from the “show ipv6 route connected”. To get connected interfaces to be included in this redistribution we can either issue a separate “redistribute connected” command under OSPFv3, which will take all connected IPv6 interfaces by default, not those just running RIPng, or we can issue the “redistribute rip 1 include-connected” command. This is the preferred design as it gives us more flexibility as to which particular networks we choose to advertise.

ShareThis

OSPF Point-to-Multipoint Network Type and /32 Routes

 

Brian,

Whydoes the point-to-multipoint OSPF network type generate the /32 routes and how can I stop them from being advertised?

Thebehavior of point-to-multipoint is to advertise each end-point out as a /32 and suppress the advertisement of the network itself. Point-to-multipoint advertises the end points to overcome possible reachability issues between devices that are on the same logical subnet but do not have direct communication (i.e. spoke to spoke communication in a hub and spoke environment). The OSPF point-to-multipoint and loopback network types do not advertise the network itself but advertise a host route for each end-point. This is as per the RFC.

Ifyou want to suppress the /32s and advertise only the network, you would need to use an OSPF network type other than point-to-multipoint or configure the network to be in its own OSPF area. After the network is put in its own OSPF area, use the area range command to summarize the /32s so other routers only see the summarized route.

ShareThis

Example Configurations for PPP over Ethernet (PPPoE)

 

Below are a couple example configurations for PPPoE. Note that you can run into MTU issues when trying to use OSPF over PPPoE. This can easily be resolved by using the “ip ospf mtu-ignore” command as the dialer interface’s MTU is 1492 while the virtual-template’s (virtual-access) MTU is 1500.

*** Client *** 
interface Ethernet0/0 pppoe enable
pppoe-client dial-pool-number 1!interface Dialer1
ip address 142.1.35.5 255.255.255.0 encapsulation ppp
dialer-pool 1 dialer persistent

*** Server ***vpdn enable
!
vpdn-group CISCO accept-dialin
protocol pppoe virtual-template 1
!
interface Ethernet0/0 pppoe enable
!
interface Virtual-Template1 ip address 142.1.35.3 255.255.255.0

The next example is using DHCP to assign the client their IP address:

*** Client *** 

interface Ethernet0/1 pppoe enable
pppoe-client dial-pool-number 1!interface Dialer1
ip address dhcp encapsulation ppp
dialer pool 1 dialer persistent

*** Server ***ip dhcp excluded-address 191.1.45.1 190.12.45.3
!
ip dhcp pool MYPOOL network 191.1.45.0 255.255.255.0
!
vpdn enable!vpdn-group CISCO
accept-dialin protocol pppoe virtual-template 1!interface Ethernet0/0 pppoe enable!interface Virtual-Template1 ip address 191.1.45.5 255.255.255.0 peer default ip address dhcp-pool MYPOOL

ShareThis

Frame Relay Traffic Shaping with GTS

 

As first and very basic option, you may use Generic Traffic Shaping to implement FRTS. This is a common technique, not unique to Frame-Relay, with the following properties:

-Configured by using traffic-shape interface command
- As with standard GTS, internal shaper queue is basic WFQ
-Configured per inteface/subinteface (no PVC granularity)
- GTS may adapt to BECNs & reflect FECNs (BECN received at any interface/subinteface PVC will cause shaper rate to throttle back to minCIR)
-FECN reflection activates sending BECNs in responce to incoming FECN frames. Note, that FECN/BECN responce requires provider to mark frames with FECN/BECN bits
-You can configure Fancy-Queueing (WFQ/PQ/CQ) at physical interface level with GTS.

Example:

!! Physical Interface, fancy-queueing may apply here 
!

interface Serial 0/0/0:0 no ip address
encapsulation frame-relay fair-queue

!
! Subinterface, apply GTS here!interface Serial0/0/0:0.1 point-to-point
ip address 177.0.112.1 255.255.255.0 !
! Shaping rate !
traffic-shape rate 512000 !
! "MinCIR", adapt to BECNs !
traffic-shape adaptive 256000 !
! Reflect FECNs as BECNs !
traffic-shape fecn-adapt frame-relay interface-dlci 112

Verification:

Rack1R1#show traffic-shape 

Interface Se0/0/0:0.1 Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes)
Active-512000 3200 12800 12800 25 1600 BECN

Rack1R1#show traffic-shape statistics Acc. Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed
ActiveSe0/0/0:0.10 157 10500 0 0 no

Rack1R1#show traffic-shape queueTrafficqueued in shaping queue on Serial0/0/0:0.1
Queueing strategy: weighted fair Queueing Stats: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/32 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 512 kilobits/sec

ShareThis

Legacy Frame-Relay Traffic Shaping

 

This is the most well-known FRTS method, which has been available for quite a while on Cisco routers. It is now being outdated by MQC configurations.
Thekey characteristic is that all settings are configured under map-class command mode, and later are applied to a particular set PVCs. The
sameconfiguration concept was used for legacy ATM configuration mode (map-class atm).

LegacyFRTS has the following characteristics:

- Enabled with frame-relay traffic-shaping command at physical interface level
-Incompatible with GTS or MQC commands at subinterfaces or physical interface levels
-With FRTS you can enforce bitrate per-VC (VC-granular, unlike GTS), by applying a map-class to PVC
-When no map-class is explicitly applied to PVC, it’s CIR and Tc are set to 56K/125ms by default
-Shaping parameters are configured under map-class frame-relay configuration submode
-Allows to configure fancy-queueing (WFQ/PQ/CQ) or simple FIFO per-VC
- No option to configure fancy-queueing at interface level: interface queue is forced to FIFO (if no FRF.12 is configured)
-Allows for adaptive shaping (throttling down to minCIR) on BECN reception (just as GTS) and option to reflect incoming FECNs as BECNs
-Option to enable adaptive shaping which responds to interface congestion (non-empty interface queue)

Example:Shape PVC to 384Kbps with minimal Tc (10ms) and WFQ as interface queue

map-class frame-relay SHAPE_384K 
frame-relay cir 384000 frame-relay bc 3840
frame-relay be 0 !
! Adaptive shaping: respond to BECNs and interface congestion !
frame-relay adaptive-shaping becn frame-relay adaptive-shaping interface-congestion
! ! Per-VC fancy-queueing ! frame-relay fair-queue!interface Serial 0/0/0:0 frame-relay traffic-shaping!interface Serial 0/0/0:0.1 ip address 177.0.112.1 255.255.255.0 frame-relay interface-dlci 112 class SHAPE_384K

Verification: Check FRTS settings for the configured PVC

Rack1R1#show frame-relay pvc 112PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =Serial0/0/0:0  cir 384000    bc 3840      be 0         byte limit 480    interval 10<------ Shaping parameters  mincir 192000    byte increment 480   Adaptive Shaping BECN and IF_CONG<---- Adaptive Shaping enabled  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0  shaping inactive  traffic shaping drops 0  Queueing strategy: weighted fair  <---- WFQ is the per-VC queue  Current fair queue configuration:   Discard     Dynamic      Reserved   threshold   queue count  queue count    64          16           0  Output queue size 0/max total 600/drops 0

The other PVC, with no class configured, has CIR set to 56Kbps and usesFIFO as per-VC queue:

Rack1R1#show frame-relay pvc 113PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =Serial0/0/0:0.2  cir 56000     bc 7000      be 0         byte limit 875    interval 125<---- CIR=56K  mincir 28000     byte increment 875   Adaptive Shaping none  pkts 74        bytes 5157      pkts delayed 0         bytes delayed 0  shaping inactive  traffic shaping drops 0  Queueing strategy: fifo <------------------ FIFO  Output queue 0/40, 0 drop, 0 dequeued

Check the physical interface queue:

Rack1R1#show interfaces serial 0/0/0:0 | inc Queue  Queueing strategy: fifo

- Interface queue could be changed to PIPQ (PVCs are assigned to 4pririty groups, with PQ being physical interface queue)
- PIPQ stands for PVC Interface Priority queueing

Example: Map PVC 112 traffic to high interface queue, and PVC 113 tolow interface queue, with WFQ being per-VC queueing

!! Shape to 384K an assign to high interface level queue!map-class frame-relay SHAPE_384K_HIGH frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 ! ! Per-VC fancy-queueing ! frame-relay fair-queue frame-relay interface-queue priority high!! Shape to 256k an assign to low interface level queue!map-class frame-relay SHAPE_256K_LOW frame-relay cir 256000 frame-relay bc 2560 frame-relay be 0 ! ! Per-VC fancy-queueing ! frame-relay fair-queue frame-relay interface-queue priority low!! Enable PIPQ as interface queueing strategy!interface Serial 0/0/0:0 frame-relay traffic-shaping frame-relay interface-queue priority!interface Serial 0/0/0:0.1 ip address 177.0.112.1 255.255.255.0 frame-relay interface-dlci 112  class SHAPE_384K_HIGH!interface Serial 0/0/0:0.2 ip address 177.0.113.1 255.255.255.0 frame-relay interface-dlci 113  class SHAPE_256K_LOW

Verfication: Check PVC interface-level priorities

Rack1R1#show frame-relay pvc 112PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =Serial0/0/0:0.1  cir 384000    bc 3840      be 0         byte limit 480    interval 10  mincir 192000    byte increment 480   Adaptive Shaping none  pkts 1687      bytes 113543    pkts delayed 0         bytes delayed 0  shaping inactive  traffic shaping drops 0  Queueing strategy: weighted fair  Current fair queue configuration:   Discard     Dynamic      Reserved   threshold   queue count  queue count    64          16           0  Output queue size 0/max total 600/drops 0  priority high  ^^^^^^^^^^^^^Rack1R1#show frame-relay pvc 113PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =Serial0/0/0:0.2  cir 256000    bc 2560      be 0         byte limit 320    interval 10  mincir 128000    byte increment 320   Adaptive Shaping none  pkts 1137      bytes 79691     pkts delayed 0         bytes delayed 0  shaping inactive  traffic shaping drops 0  Queueing strategy: weighted fair  Current fair queue configuration:   Discard     Dynamic      Reserved   threshold   queue count  queue count    64          16           0  Output queue size 0/max total 600/drops 0  priority low  ^^^^^^^^^^^^

Verify interface-level queue:

Rack1R1#show interfaces serial 0/0/0:0 | inc (Output|high)  Output queue (queue priority: size/max/drops):     high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0

- With FRF.12 fragmentation configured per any PVC, physical interfacequeue is changed to dual-FIFO
- This is due to the fact that fragmentation is ineffective withoutinterleaving
- Fragment size is calculated based on physical interface speed to allowminimum serialization delay

Example: Enable FRF.12 fragmentation for PVC DLCI 112 and physicalinterface speed 512Kbps

!! PVC shaped to 384Kbps, with physical interface speed 512Kbps!map-class frame-relay SHAPE_384K_FRF12 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 ! ! Per-VC fancy-queueing ! frame-relay fair-queue ! ! Enable FRF.12 per VC. Fragment size = 512Kbps*0,01/8 = 640 bytes ! frame-relay fragment 640!!!interface Serial 0/0/0:0 frame-relay traffic-shaping!interface Serial 0/0/0:0.1 ip address 177.0.112.1 255.255.255.0 frame-relay interface-dlci 112  class SHAPE_384K_FRF12

Verfication: Check PVC settings

Rack1R1#show frame-relay pvc 112PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =Serial0/0/0:0.1  fragment type end-to-end fragment size 640  cir 384000    bc   3840      be 0         limit 480    interval 10  mincir 192000    byte increment 480   BECN response no  IF_CONG no  frags 1999      bytes 135126    frags delayed 0         bytes delayed 0  shaping inactive  traffic shaping drops 0  Queueing strategy: weighted fair  Current fair queue configuration:   Discard     Dynamic      Reserved   threshold   queue count  queue count    64          16           0  Output queue size 0/max total 600/drops 0

Look at physical interface queue:

Rack1R1#show interfaces serial 0/0/0:0 | inc Queu|Output q  Queueing strategy: dual fifo  Output queue: high size/max/dropped 0/256/0  Output queue: 0/128 (size/max)

- You can map up to 4 priority queues to 4 different VCs (inversePIPQ)
- This scenario usually implies multiple PVCs running between two sites(e.g. PVC for voice and PVC for data)

Example: Map voice packets to high interface-level priority queue andsend them over PVC 112

!! Voice bearer!access-list 101 permit udp any any range 16384 32767!! Simple priority list to classify voice bearer to high queue!priority-list 1 protocol ip high list 101interface Serial 0/0/0:0 ip address 177.1.0.1 255.255.255.0 ! ! We apply the priority group twice: first to implement queueing ! priority-group 1 ! ! Next to map priority levels to DLCIs ! frame-relay priority-dlci-group 1 112 112 113 113

Verfication:

Rack1R1#show queueing interface serial 0/0/0:0Interface Serial0/0/0:0 queueing strategy: priorityOutput queue utilization (queue/count)	high/217 medium/0 normal/1104 low/55Rack1R1#show frame-relay pvc 112PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =Serial0/0/0:0  pvc create time 3d01h, last time pvc status changed 3d01h  Priority DLCI Group 1, DLCI 112 (HIGH), DLCI 112 (MEDIUM)  DLCI 113 (NORMAL), DLCI 113 (LOW)

- You can change per-VC queue to CBWFQ/LLQ, and still shape withFRTS
- Note that available bandwidth will be calculated from minCIR value,which is CIR/2 by default

Example: Implement CBWFQ Per-VC

!! Classify voice using NBAR!class-map VOICE match protocol rtp!! Simple LLQ!policy-map CBWFQ class VOICE  priority 64 class class-default  bandwidth 64!! Use CBWFQ as queueing strategy! Note that MinCIR = 384/2=192Kbps!map-class frame-relay SHAPE_384K_CBWFQ frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 service-policy output CBWFQ!!!interface Serial 0/0/0:0 frame-relay traffic-shaping!interface Serial 0/0/0:0.1 ip address 177.0.112.1 255.255.255.0 frame-relay interface-dlci 112  class SHAPE_384K_CBWFQ

Verfication: Check PVC queueing strategy

Rack1R1#show frame-relay pvc 112PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =Serial0/0/0:0  cir 384000    bc 3840      be 0         byte limit 480    interval 10  mincir 192000    byte increment 480   Adaptive Shaping none  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0  shaping inactive  traffic shaping drops 0  service policy CBWFQ Serial0/0/0:0: DLCI 112 -  Service-policy output: CBWFQ    Class-map: VOICE (match-all)      0 packets, 0 bytes      5 minute offered rate 0 bps, drop rate 0 bps      Match: protocol rtp      Queueing        Strict Priority        Output Queue: Conversation 40        Bandwidth 64 (kbps) Burst 1600 (Bytes)        (pkts matched/bytes matched) 0/0        (total drops/bytes drops) 0/0    Class-map: class-default (match-any)      32 packets, 2560 bytes      5 minute offered rate 0 bps, drop rate 0 bps      Match: any      Queueing        Output Queue: Conversation 41        Bandwidth 128 (kbps) Max Threshold 64 (packets)        (pkts matched/bytes matched) 0/0        (depth/total drops/no-buffer drops) 0/0/0  Output queue size 0/max total 600/drops 0

To verify that only MinCIR of bandwidth is allocated to CBWFQ undermap-class do the following:

Rack1R1(config)#policy-map CBWFQRack1R1(config-pmap)# class VOICERack1R1(config-pmap-c)#  priority 64Rack1R1(config-pmap-c)# class class-defaultRack1R1(config-pmap-c)#  bandwidth 192I/f Serial0/0/0:0 DLCI 112 Class class-default requested bandwidth 192(kbps) Only 128 (kbps) available

ShareThis

MQC-based Frame Relay Traffic Shaping

 

This is a “modern” way to configure FRTS, using MQC commands only to accomplish the task. With MQC approach, an unified interface has been introduced to configure all QoS settings, irrelevant of underlying technology.

Insummary:

- Legacy command frame-relay traffic-shaping is incompatible with MQC-based FRTS (you can’t mix them)
-Fancy queueing could not be used as a PVC-queueing strategy: CBWFQ is the only option available
-Per-VC CBWFQ is configured via hierarchical policy-maps configuration: Parent policy sets shaping values, while child policy implements CBWFQ
-You may apply policy-map per-interface (subinterface) or per-VC, using match fr-dlci under class-map submode

Example:Shape PVC to 384Kbps and provide LLQ treatment for voice bearer packets on PVC queue

class-map VOICE 
match ip dscp ef!class-map DATA
match ip dscp cs1!! "Child" policy-map, used to implement CBWFQ
!

policy-map CBWFQ class VOICE
priority 64 class DATA
bandwidth 128 class class-default
fair-queue!! "Parent" policy map, used for PVC shaping
!

policy-map SHAPE_384K class class-default
shape average 384000 shape adaptive 192000
service-policy CBWFQinterface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0 service-policy output SHAPE_384K
frame-relay interface-dlci 112

Verification:check out policy map settings

Rack1R1#show policy-map interface serial 0/0/0:0.1 

Serial0/0/0:0.1

Service-policy output: SHAPE_384K Class-map: class-default (match-any)
1942 packets, 1590741 bytes 5 minute offered rate 48000 bps, drop rate 0 bps
Match: any Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment Rate Limit bits/int bits/int (ms) (bytes)
384000/384000 2400 9600 9600 25 1200

Adapt Queue Packets Bytes Packets Bytes Shaping Active Depth Delayed Delayed Active
- 0 1936 1581717 0 0 no Service-policy : CBWFQ

Class-map: VOICE (match-all) 0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps Match: protocol rtp
Match: ip dscp ef (46) Queueing
Strict Priority Output Queue: Conversation 40
Bandwidth 64 (kbps) Burst 1600 (Bytes) (pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0 Class-map: DATA (match-all)
0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs1 (8) Queueing
Output Queue: Conversation 41 Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any) 1942 packets, 1590741 bytes
5 minute offered rate 48000 bps, drop rate 0 bps Match: any
Queueing Flow Based Fair Queueing
Maximum Number of Hashed Queues 32 (total queued/total drops/no-buffer drops) 0/0/0

The amount of bandwidth, available for allocation to CBWFQ classes, is taken from shape adaptive value. If the latter is not configured, shape average
valueis used instead. Note, that as you configure bandwidth settings for classes, their values are not subtracted from remaining bandwidth. This is in contraty with
“classic”CBWFQ, applied to a physical interface (not subinterface or PVC)

Verification (with the example above):

Rack1R1#conf tEnter configuration commands, one per line.  End with CNTL/Z. 
Rack1R1(config)#policy-map CBWFQRack1R1(config-pmap)#classclass-default
Rack1R1(config-pmap-c)#no fair-queueRack1R1(config-pmap-c)#bandwidth256
I/f shape class class-default requested bandwidth 256 (kbps), available
only 192 (kbps)

Notethat available bandwidth is set to shape adaptive value, even though we have priority configured under class VOICE and bandwidth
settingsunder class DATA

- You can’t apply FRF.12 fragmentation with MQC commands - it should be applied at physical interface level. By doing so, FRF.12 is effectively enabled for all PVCs
-Physical interface queue could be set to any of WFQ/CQ/PQ or CBWFQ (not restricted to FIFO as with FRTS legacy) - though this is rarely needed

Example:Shape PVC DLCI 112 to 384Kpbs and enable FRF.12 fragmentation for all PVCs

class-map VOICE 
match ip dscp ef!class-map DATA
match ip dscp cs1!! Match the specific DLCI
!
class-map DLCI_112 match fr-dlci 112

!
! "Child" policy-map, used to implement CBWFQ!policy-map CBWFQ
class VOICE priority 64
class DATA bandwidth 128
class class-default fair-queue

!
! "Parent" policy map, used for PVC shaping!With multiple classes, we can match different DLCIs
! all at the same physical interface (where they belongs)!policy-map INTERFACE_POLICY
class DLCI_112 shape average 384000
shape adaptive 192000 service-policy CBWFQ

!
! Apply the parent policy map at physical interface level!Also, configure FRF.12 "global" settings here
!

interface Serial 0/0/0:0 service-policy output INTERFACE_POLICY
frame-relay fragment 640 end-to-end

Verification:

Rack1R1#show policy-map interface serial 0/0/0:0 

Serial0/0/0:0

Service-policy output: INTERFACE_POLICY Class-map: DLCI_112 (match-all)
1040 packets, 95287 bytes 5 minute offered rate 0 bps, drop rate 0 bps
Match: fr-dlci 112 Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment Rate Limit bits/int bits/int (ms) (bytes)
384000/384000 2400 9600 9600 25 1200

Adapt Queue Packets Bytes Packets Bytes Shaping Active Depth Delayed Delayed Active
- 0 1040 95287 4 1373 no Service-policy : CBWFQ

Class-map: VOICE (match-all) 0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps Match: protocol rtp
Match: ip dscp ef (46) Queueing
Strict Priority Output Queue: Conversation 40
Bandwidth 64 (kbps) Burst 1600 (Bytes) (pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0 Class-map: DATA (match-all)
0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs1 (8) Match: fr-dlci 112
Queueing Output Queue: Conversation 41
Bandwidth 128 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any)
1040 packets, 95287 bytes 5 minute offered rate 0 bps, drop rate 0 bps
Match: any Queueing
Flow Based Fair Queueing Maximum Number of Hashed Queues 32
(total queued/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any)
2594 packets, 153695 bytes 5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Verifyfragmentation settings:

Rack1R1#show interface serial 0/0/0:0 
Serial0/0/0:0 is up, line protocol is up Hardware is GT96K Serial
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec)
LMI enq sent 21224, LMI stat recvd 21224, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE FR SVC disabled, LAPF state down
Fragmentation type: end-to-end, size 640, PQ interleaves 0
<--------- Fragment Size Broadcast queue 0/64, broadcasts sent/dropped 63160/0, interface broadcasts 56080
Last input 00:00:03, output 00:00:02, output hang never Last clearing of "show interface" counters 2d10h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 6 Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 1152 kilobits/sec
5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 1 packets/sec
272202 packets input, 27557680 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
15 input errors, 15 CRC, 8 frame, 0 overrun, 0 ignored, 5 abort 333676 packets output, 42152431 bytes, 0 underruns
0 output errors, 0 collisions, 16 interface resets 0 output buffer failures, 0 output buffers swapped out
0 carrier transitions Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags

ShareThis