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

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

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

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

SaugcenterV3

SaugcenterV3

Cisco IOS hints and tricks: EIGRP load balancing based on interface load

Cisco IOS hints and tricks: EIGRP load balancing based on interface load

Cisco IOS hints and tricks: IP Event Dampening

Cisco IOS hints and tricks: IP Event Dampening

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

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:

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