Networking Concepts

Multicast - Basics

2009-11-24T12:44:00.001+05:30

What is Promiscuous Mode

2009-07-21T12:47:00.001+05:30

1) In a network, promiscuous mode allows a network device to intercept and read each network packet that arrives in its entirety. This mode of operation is sometimes given to a network snoop server that captures and saves all packets for analysis (for example, for monitoring network usage).
2) In an Ethernet local area network (LAN), promiscuous mode is a mode of operation in which every data packet transmitted can be received and read by a network adapter. Promiscuous mode must be supported by each network adapter as well as by the input/output driver in the host operating system. Promiscuous mode is often used to monitor network activity.

Promiscuous mode is the opposite of non-promiscuous mode. When a data packet is transmitted in non-promiscuous mode, all the LAN devices "listen to" the data to determine if the network address included in the data packet is theirs. If it isn't, the data packet is passed onto the next LAN device until the device with the correct network address is reached. That device then receives and reads the data.

Multicast TTL-Threshold

2009-02-12T18:14:00.001+05:30

ip multicast ttl-threshold

Usage Guidelines

"Only multicast packets with a TTL value greater than the threshold are forwarded out the interface."

Oh yeah?! I guess it depends on when you look at the TTL. Consider the network:

R1----R2----R3----R4

PIM-DM is enabled everywhere.
R4 has joined 239.0.0.1
R1 is sending pings which have 255 TTL when sent from R1.
R2 receives the PING, decrements the TTL to 254 before sending to R3.

So if we set TTL threshold to 254 on R2's interface to R3, it should block it right? No:


R2(config)#int s1/0
R2(config-if)#ip multicast ttl-threshold 254

R1#ping 239.0.0.1  

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.34.4, 164 ms
R1#

The router will still pass packets that have a TTL equal to the threshold if it was the router that decremented the TTL to reach that value. Here we see 255 will fail:


R2(config)#int s1/0
R2(config-if)#ip multicast ttl-threshold 255

R1#ping 239.0.0.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
.
R1#

WCCP notes

2009-02-12T18:11:00.001+05:30

WCCPv1
---------
-Single router serves a cluster
-Cache engine is configured with ip address of control router (max 32)
-Cache engines send ip's to router via control port udp 2048
-Control creates a cluster view, sends to cache engines
-Lead cache engine selected, decides how traffic is redirected.
-HTTP only

WCCPv2
---------
-Multiple routers can server a cluster
-Service group: routers + cache engines
-Unicast or multicast control (ip wccp group-listen)
-Non-HTTP support, TCP and UDP
-MD5 security
-Error handling keeps track of cache misses
-Load distribution (hot spot handling, load balancing, load shedding)
-IP only
-Multicast TTL must be 15 or lower
-32 cache engines and 32 routers max per service group
-Dynamic services are defined by the cache engines

Configuration
--------------
Router(config)# ip wccp version 2
Router(config)# ip wccp {web-cache | service-number} [group-address groupaddress] [redirect-list access-list] [group-list access-list] [password password]
Router(config)# interface type number
Router(config-if)# ip wccp {web-cache | service-number} redirect {out | in}

Exclude an interface from redirecting inbound traffic:
Router(config-if)# ip wccp redirect exclude in

Troubleshooting OSPF over Frame-Relay

2009-02-12T18:09:00.000+05:30

Scenario:
Full mesh of PVCs between 3 routers: R4 R5 and R6
Frame-relay map statements DO NOT have broadcast statement
Adjacencies do not form.

This is from debug ip packet on R6:

R6#debug ip packet
IP packet debugging is on
*Mar 1 01:00:26.367: IP: s=172.12.45.6 (local), d=224.0.0.5 (Serial1/1), len 76, sending broad/multicast
*Mar 1 01:00:26.371: IP: s=172.12.45.6 (local), d=224.0.0.5 (Serial1/1), len 76, encapsulation failed

After enabling broadcast on the frame maps, adjacencies came up

Solution:
Point-to-multipoint ospf networks need broadcast keyword on frame-relay map.
Without it you will see "encapsulation failed" when the router tries to send multicast hellos.

Frame-relay Compression

2009-02-12T18:08:00.001+05:30

Compression must be configured on both ends for it to be enabled:

R5 --- FR CLOUD --- R6

R6(config)#interface s1/1
R6(config-if)#frame-relay map ip 172.14.45.5 605 payload-compression FRF9 stac

R6#ping 172.14.45.5

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

R6#show compress
Serial1/1 - DLCI: 605
Compression not active
uncompressed bytes xmt/rcv 0/0
compressed bytes xmt/rcv 0/0
Compressed bytes sent: 0 bytes 0 Kbits/sec
Compressed bytes recv: 0 bytes 0 Kbits/sec
1 min avg ratio xmt/rcv 0.000/0.000
5 min avg ratio xmt/rcv 0.000/0.000
10 min avg ratio xmt/rcv 0.000/0.000
no bufs xmt 0 no bufs rcv 0
resyncs 0
Additional Stac Stats:
Transmit bytes: Uncompressed = 0 Compressed = 0
Received bytes: Compressed = 0 Uncompressed = 0

Now on R5:

R6(config)#interface s1/0
R6(config-if)#frame-relay map ip 172.14.45.6 506 payload-compression FRF9 stac

Check R6 and see compression is enabled:

R6#ping 172.14.45.5

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

R6#show compress
Serial1/1 - DLCI: 605
Software compression enabled
uncompressed bytes xmt/rcv 1232/1232
compressed bytes xmt/rcv 381/382
Compressed bytes sent: 381 bytes 0 Kbits/sec ratio: 3.233
Compressed bytes recv: 382 bytes 0 Kbits/sec ratio: 3.225
1 min avg ratio xmt/rcv 0.055/0.057
5 min avg ratio xmt/rcv 0.113/0.118
10 min avg ratio xmt/rcv 0.113/0.118
no bufs xmt 0 no bufs rcv 0
resyncs 0
Additional Stac Stats:
Transmit bytes: Uncompressed = 0 Compressed = 290
Received bytes: Compressed = 291 Uncompressed = 0

Frame-relay Fragmentation

2009-02-12T18:04:00.001+05:30

R4 --- FR CLOUD --- R6

Both ends configured:

R6(config)#int s1/1
R6(config-if)#frame-relay fragment 200 end-to-end
R6(config-if)#^Z

R6#ping 172.14.45.4 size 8000

Type escape sequence to abort.
Sending 5, 8000-byte ICMP Echos to 172.14.45.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 676/756/796 ms

R6#show frame-relay fragment
interface dlci frag-type size in-frag out-frag dropped-frag
Se1/1 604 end-to-end 200 220 220 0
Se1/1 605 end-to-end 200 0 0 0

Configuring multipoint subinterface so the interface status reflects status of the PVC

2009-02-12T18:03:00.000+05:30

On a physical frame-relay interface, if the opposite end goes down, the local interface will remain up/up. When using multipoint subinterfaces this is not the case. When the remote interface goes down (taking the dlci with it), the local ends puts its interface in a down/down state.

R1, R3 and R5 connect via full mesh frame-relay, subnet 190.1.135.0/24

R1 dlci 103 maps to R3 dlci 301
R1 dlci 105 maps to R5 dlci 501
R3 dlci 305 maps to R5 dlci 503

Configure all routers on the physical interfaces.

Here is the outlook so far from R3:

R3#show ip int brief serial 1/0
Interface IP-Address OK? Method Status Protocol
Serial1/0 190.1.135.1 YES manual up up
R3#

Now Let's shut the physical interfaces On R5 and R1:

R5(config)#int s0/0
R5(config-if)#shut

R1(config)#int s0/0
R1(config-if)#shut

R3 still has its interface up/up:

R3#show ip int brief serial 1/0
Interface IP-Address OK? Method Status Protocol
Serial1/0 190.1.135.1 YES manual up up

If we want R3's interface to go down when R5 and R1 are no longer available we need to use multipoint subinterface. Let's create one on R3 and move the config over:

R3(config)#interface Serial1/0
R3(config-if)# no ip address 190.1.135.1 255.255.255.0
R3(config-if)# no frame-relay map ip 190.1.135.1 301
R3(config-if)# no frame-relay map ip 190.1.135.5 305
R3(config-if)#int s1/0.3 multipoint
R3(config-subif)# ip address 190.1.135.1 255.255.255.0
R3(config-subif)# frame-relay map ip 190.1.135.1 301 broadcast
R3(config-subif)# frame-relay map ip 190.1.135.5 305 broadcast
R3(config-subif)# no frame-relay inverse-arp

Bring up R5 and R1 again and now we have:

R3#show ip int brief s1/0.3
Interface IP-Address OK? Method Status Protocol
Serial1/0.3 190.1.135.1 YES manual up up

Shut down R5 and R3 is stil up but look at the debug frame-relay lmi. The status of PVC 305 is 0x0 which is inactive

R3#show ip int brief s1/0.3
Interface IP-Address OK? Method Status Protocol
Serial1/0.3 190.1.135.1 YES manual up up

Back to Back Multilink Frame-Relay

2009-02-12T18:01:00.000+05:30

I had this task on a recent lab. I was surprised I actually got it to work (with some help from the DocCD). Sometimes I skip these boring WAN technology tasks, but sometimes they can be fun if you get them to work :)

R6 ==== R9

R6 and R6 are connected via two serial links, serial 0/2/0 and serial 0/2/1. The task says to configure these with a /31 on the subnet 172.30.96.0 network. R6 should use DLCI 609 and R9 should use DLCI 906. Now let me say the PG was mistaken in its answer, it didn't have any frame-relay whatsoever - still waiting to hear via email what the deal was. So this is my "tentative" solution, which works great.

Here is my R6 config:

interface MFR1
ip address 172.30.96.0 255.255.255.254
no keepalive
frame-relay map ip 172.30.96.0 609
frame-relay map ip 172.30.96.1 906 broadcast
frame-relay interface-dlci 609
!
interface Serial0/2/0
no ip address
encapsulation frame-relay MFR1
clock rate 2000000
no arp frame-relay
!
interface Serial0/2/1
no ip address
encapsulation frame-relay MFR1
clock rate 2000000
no arp frame-relay

Here is the R9 config:

interface MFR1
ip address 172.30.96.1 255.255.255.254
no keepalive
frame-relay map ip 172.30.96.0 609 broadcast
frame-relay map ip 172.30.96.1 906
frame-relay interface-dlci 609
!
interface Serial0/2/0
no ip address
encapsulation frame-relay MFR1
no arp frame-relay
!
interface Serial0/2/1
no ip address
encapsulation frame-relay MFR1
no arp frame-relay

ip subnetting

2009-02-10T19:46:00.000+05:30

IP subnetting is a fundamental subject that's critical for any IP network engineer to understand, yet students have traditionally had a difficult time grasping it. Over the years, I've watched students needlessly struggle through school and in practice when dealing with subnetting because it was never explained to them in an easy-to-understand way. I've helped countless individuals learn what subnetting is all about using my own graphical approach and calculator shortcuts, and I've put all that experience into this article.

IP addresses and subnets

Although IP stands for Internet Protocol, it's a communications protocol used from the smallest private network to the massive global Internet. An IP address is a unique identifier given to a single device on an IP network. The IP address consists of a 32-bit number that ranges from 0 to 4294967295. This means that theoretically, the Internet can contain approximately 4.3 billion unique objects. But to make such a large address block easier to handle, it was chopped up into four 8-bit numbers, or "octets," separated by a period. Instead of 32 binary base-2 digits, which would be too long to read, it's converted to four base-256 digits. Octets are made up of numbers ranging from 0 to 255. The numbers below show how IP addresses increment.

0.0.0.0

0.0.0.1
...increment 252 hosts...
0.0.0.254
0.0.0.255
0.0.1.0
0.0.1.1
...increment 252 hosts...
0.0.1.254
0.0.1.255
0.0.2.0
0.0.2.1
...increment 4+ billion hosts...
255.255.255.255

The word subnet is short for sub network--a smaller network within a larger one. The smallest subnet that has no more subdivisions within it is considered a single "broadcast domain," which directly correlates to a single LAN (local area network) segment on an Ethernet switch. The broadcast domain serves an important function because this is where devices on a network communicate directly with each other's MAC addresses, which don't route across multiple subnets, let alone the entire Internet. MAC address communications are limited to a smaller network because they rely on ARP broadcasting to find their way around, and broadcasting can be scaled only so much before the amount of broadcast traffic brings down the entire network with sheer broadcast noise. For this reason, the most common smallest subnet is 8 bits, or precisely a single octet, although it can be smaller or slightly larger.

Subnets have a beginning and an ending, and the beginning number is always even and the ending number is always odd. The beginning number is the "Network ID" and the ending number is the "Broadcast ID." You're not allowed to use these numbers because they both have special meaning with special purposes. The Network ID is the official designation for a particular subnet, and the ending number is the broadcast address that every device on a subnet listens to. Anytime you want to refer to a subnet, you point to its Network ID and its subnet mask, which defines its size. Anytime you want to send data to everyone on the subnet (such as a multicast), you send it to the Broadcast ID. Later in this article, I'll show you an easy mathematical and graphical way to determine the Network and Broadcast IDs.

The graphical subnet ruler

Over the years, as I watched people struggle with the subject of IP subnetting, I wanted a better way to teach the subject. I soon realized that many students in IT lacked the necessary background in mathematics and had a hard time with the concept of binary numbers. To help close this gap, I came up with the graphical method of illustrating subnets shown in Figure A. In this example, we're looking at a range of IP addresses from 10.0.0.0 up to 10.0.32.0. Note that the ending IP of 10.0.32.0 itself is actually the beginning of the next subnet. This network range ends at the number right before it, which is 10.0.31.255.

Figure A

Note that for every bit increase, the size of the subnet doubles in length, along with the number of hosts. The smallest tick mark represents 8 bits, which contains a subnet with 256 hosts--but since you can't use the first and last IP addresses, there are actually only 254 usable hosts on the network. The easiest way to compute how many usable hosts are in a subnet is to raise 2 to the power of the bit size minus 2. Go up to 9 bits ,and we're up to 510 usable hosts, because 2 to the 9th is 512, and we don't count the beginning and ending. Keep on going all the way up to 13 bits, and we're up to 8,190 usable hosts for the entire ruler shown above.

Learning to properly chop subnets

Subnets can be subdivided into smaller subnets and even smaller ones still. The most important thing to know about chopping up a network is that you can't arbitrarily pick the beginning and ending. The chopping must be along clean binary divisions. The best way to learn this is to look at my subnet ruler and see what's a valid subnet. In Figure B, green subnets are valid and red subnets are not.

Figure B

The ruler was constructed like any other ruler, where we mark it down the middle and bisect it. Then, we bisect the remaining sections and with shrinking markers every time we start a new round of bisecting. In the sample above, there were five rounds of bisections. If you look carefully at the edge of any valid (green) subnet blocks, you'll notice that none of the markers contained within the subnet is higher than the edge's markers. There is a mathematical reason for this, which we'll illustrate later, but seeing it graphically will make the math easier to understand.

The role of the subnet mask

The subnet mask plays a crucial role in defining the size of a subnet. Take a look at Figure C. Notice the pattern and pay special attention to the numbers in red. Whenever you're dealing with subnets, it will come in handy to remember eight special numbers that reoccur when dealing with subnet masks. They are 255, 254, 252, 248, 240, 224, 192, and 128. You'll see these numbers over and over again in IP networking, and memorizing them will make your life much easier.

Figure C

I've included three class sizes. You'll see the first two classes, with host bit length from 0 to 16, most often. It's common for DSL and T1 IP blocks to be in the 0- to 8-bit range. Private networks typically work in the 8- to 24-bit range.

Note how the binary mask has all those zeros growing from right to left. The subnet mask in binary form always has all ones to the left and all zeros to the right. The number of zeros is identical to the subnet length. I showed only the portion of the binary subnet in the octet that's interesting, since all octets to the right consist of zeros and all octets to the left consist of ones. So if we look at the subnet mask where the subnet length is 11 bits long, the full binary subnet mask is 11111111.11111111.11111000.00000000. As you can see under mask octet, the subnet mask transitions from 1 to 0 in the third octet. The particular binary subnet mask translates directly to base-256 form as 255.255.248.0.

The "mask" in subnet mask

The subnet mask not only determines the size of a subnet, but it can also help you pinpoint where the end points on the subnet are if you're given any IP address within that subnet. The reason it's called a subnet "mask" is that it literally masks out the host bits and leaves only the Network ID that begins the subnet. Once you know the beginning of the subnet and how big it is, you can determine the end of the subnet, which is the Broadcast ID.

To calculate the Network ID, you simply take any IP address within that subnet and run the AND operator on the subnet mask. Let's take an IP address of 10.20.237.15 and a subnet mask of 255.255.248.0. Note that this can be and often is written in shorthand as 10.20.237.15/21 because the subnet mask length is 21. Figure D and Figure E show the Decimal and Binary versions of the AND operation.

Figure D

Decimal math

Figure E

Binary math

The binary version shows how the 0s act as a mask on the IP address on top. Inside the masking box, the 0s convert all numbers on top into zeros, no matter what the number is. When you take the resultant binary Network ID and convert it to decimal, you get 10.20.232.0 as the Network ID.

One thing that's always bothered me about the way subnetting is taught is that students are not shown a simple trick to bypass the need for binary conversions when doing AND operations. I even see IT people in the field using this slow and cumbersome technique to convert everything to binary, run the AND operation, and then convert back to decimal using the Windows Calculator. But there's a really simple shortcut using the Windows Calculator, since the AND operator works directly on decimal numbers. Simply punch in 237, hit the AND operator, and then 248 and [Enter] to instantly get 232, as shown in Figure F. I'll never understand why this isn't explained to students, because it makes mask calculations a lot easier.

Figure F

Since there are 11 zeros in the subnet mask, the subnet is 11 bits long. This means there are 2^11, or 2,048, maximum hosts in the subnet and the last IP in this subnet is 10.20.239.255. You could compute this quickly by seeing there are three zeros in the third octet, which means the third octet of the IP address can have a variance of 2^3, or 8. So the next subnet starts at 10.20.232+8.0, which is 10.20.240.0. If we decrease that by 1, we have 10.20.239.255, which is where this subnet ends. To help you visualize this, Figure G shows it on my subnet ruler.

Figure G

IP classes made simple

For an arbitrary classification of IP subnets, the creators of the Internet chose to break the Internet into multiple classes. Note that these aren't important as far as your subnet calculations are concerned; this is just how the Internet is "laid out." The Internet is laid out as Class A, B, C, D, and E. Class A uses up the first half of the entire Internet, Class B uses half of the remaining half, Class C uses the remaining half again, Class D (Multicasting) uses up the remaining half again, and whatever is left over is reserved for Class E. I've had students tell me that they struggled with the memorization of IP classes for weeks until they saw this simple table shown in Figure H. This is because you don't actually need to memorize anything, you just learn the technique for constructing the ruler using half of what's available.

Figure H

Remember that all subnets start with EVEN numbers and all subnet endings are ODD. Note that 0.0.0.0/8 (0.0.0.0 to 0.255.255.255) isn't used and 127.0.0.0/8 (127.0.0.0 to 127.255.255.255) is reserved for loopback addresses.

All Class A addresses have their first octet between 1 to 126 because 0 and 127 are reserved. Class A subnets are all 24 bits long, which means the subnet mask is only 8 bits long. For example, we have the entire 3.0.0.0/8 subnet owned by GE, since GE was lucky enough to get in early to be assigned 16.8 million addresses. The U.S. Army owns 6.0.0.0/8. Level 3 Communications owns 8.0.0.0/8. IBM owns 9.0.0.0/8. AT&T owns 12.0.0.0/8. Xerox owns 13.0.0.0/8. HP owns 15.0.0.0/8 and 16.0.0.0/8. Apple owns 17.0.0.0/8.

All Class B addresses have their first octet between 128 and 191. Class B subnets are all 16 bits long, which means the subnet masks are 16 bits long. For example, BBN Communications owns 128.1.0.0/16, which is 128.1.0.0 to 128.1.255.255. Carnegie Mellon University owns 128.2.0.0/16.

All Class C addresses have their first octet between 192 and 223. Class C subnets are all 8 bits long, so the subnet mask is only 24 bits long. Note that ARIN (the organization that assigns Internet addresses) will sell blocks of four Class C addresses only to individual companies and you have to really justify why you need 1,024 Public IP addresses. If you need to run BGP so you can use multiple ISPs for redundancy, you have to have your own block of IP addresses. Also note that this isn't the old days, where blocks of 16.8 million Class A addresses were handed out for basically nothing. You have to pay an annual fee for your block of 1,024 addresses with a subnet mask of /22, or 255.255.252.0.

The concept of subnet classes can cause harm in actual practice. I've actually seen people forget to turn classes off in their old Cisco router and watch large subnet routes get hijacked on a large WAN configured for dynamic routing whenever some routes were added. This is because a Cisco router will assume the subnet mask is the full /8 or /16 or /24 even if you define something in between. All newer Cisco IOS software versions turn off the concept of subnet classes and uses classless routing by default. This is done with the default command "IP Classless."

Public versus private IP addresses

Besides the reserved IP addresses (0.0.0.0/8 and 127.0.0.0/8) mentioned above, there are other addresses not used on the public Internet. These private subnets consist of private IP addresses and are usually behind a firewall or router that performs NAT (network address translation). NAT is needed because private IP addresses are nonroutable on the public Internet, so they must be translated into public IP addresses before they touch the Internet. Private IPs are never routed because no one really owns them. And since anyone can use them, there's no right place to point a private IP address to on the public Internet. Private IP addresses are used in most LAN and WAN environments, unless you're lucky enough to own a Class A or at least a Class B block of addresses, in which case you might have enough IPs to assign internal and external IP addresses.

The following blocks of IP addresses are allocated for private networks:

10.0.0.0/8 (10.0.0.0 to 10.255.255.255)
172.16.0.0/12 (172.16.0.0 to 172.31.255.255)
192.168.0.0/16 (192.168.0.0 to 192.168.255.255)
169.254.0.0/16 (169.254.0.0 to 169.254.255.255)*

*Note that 169.254.0.0/16 is a block of private IP addresses used for random self IP assignment where DHCP servers are not available.

10.0.0.0/8 is normally used for larger networks, since there are approximately 16.8 million IP addresses available within that block. They chop it up into lots of smaller groups of subnets for each geographic location, which are then subdivided into even smaller subnets. Smaller companies typically use the 172.16.0.0/12 range, chopped up into smaller subnets, although there's no reason they can't use 10.0.0.0/8 if they want to. Home networks typically use a /24 subnet within the 192.168.0.0/16 subnet.

The use of private IP addresses and NAT has prolonged the life of IPv4 for the foreseeable future because it effectively allows a single public IP address to represent thousands of private IP addresses. At the current rate that IPv4 addresses are handed out, we have enough IPv4 addresses for approximately 17 years. ARIN is much more stingy now about handing them out, and small blocks of IP addresses are relatively expensive compared to the old days, when companies like Apple were simply handed a block of 16.8 million addresses. The next version of IP addresses, called IPv6, is 128 bits long--and there are more than 79 thousand trillion trillion times more IP addresses than IPv4. Even if you assigned 4.3 billion people on the planet with 4.3 billion IP addresses each, you would still have more than 18 million trillion IPv6 addresses left!

CBAC with APPFW

2009-02-08T15:58:00.000+05:30

I have begun my goal of reading the entire 12.4 Security Configuration Guide. I likely won't read it all because many things are probably unrelated to CCIE R&S, but you never really can tell. Especially since the blueprint has "Other Security Features" on it. This configuration is part of CBAC and so I thought I would test a small scenario.

R4----s1/0 R5----R6

R4 is the http server and R6 is the client. Here is how I set them up to verify it's working:

R4#copy run test.html
Destination filename [test.html]?
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of flash: complete
Verifying checksum... OK (0x7071)
1942 bytes copied in 4.628 secs (420 bytes/sec)
R4#
R4#dir
Directory of flash:/

1 -rw- 1942 test.html

7864316 bytes total (7862308 bytes free)
R4#conf t
R4(config)#ip http path flash:

R4 is setup, let's test R6 the client:

R6#copy http://192.168.45.4/test.html flash:
Destination filename [test.html]?
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of flash: complete
Loading http://192.168.45.4/test.html !
Verifying checksum... OK (0x7071)
1942 bytes copied in 0.688 secs (2823 bytes/sec)
R6#

Good, so we know that works. Now we can configure R5 as the HTTP Application FW. This does require CBAC as well as some new appfw commands which I have never used. There are MANY more options besides this, so I suggest you read the DocCD for a more in depth explanation. I just wanted to get the gist of it here:

ip inspect name APPFW appfw HTTPFW
ip inspect name APPFW http
!
appfw policy-name HTTPFW
application http
strict-http action allow alarm
content-length minimum 1945 action reset alarm
port-misuse tunneling action reset

interface Serial1/0
description TO R4
ip inspect APPFW out

Notice the minimum content length is 1945 byes. This will prevent R6 from copying the file via HTTP (test.html is 1942 bytes as we can see above):

6#copy http://192.168.45.4/test.html flash:
Destination filename [test.html]?
Erase flash: before copying? [confirm]n
%Error opening http://192.168.45.4/test.html (I/O error)
R6#

Jump to R5 and see the message:

R5#
*Mar 2 05:34:02.708: %APPFW-4-HTTP_CONT_TYPE_SIZE: Sig:11 Content size 1942 out of range - Reset - Content size out-of-bounds from 192.168.56.6:25101 to 192.168.45.4:80

If we change the minimum content legth to 1942, everything works as expected:

R5(config)#appfw policy-name HTTPFW
R5(cfg-appfw-policy)#application http
R5(cfg-appfw-policy-http)#content-length minimum 1942 action reset alarm

R6#copy http://192.168.45.4/test.html flash:
Destination filename [test.html]?
%Warning:There is a file already existing with this name
Do you want to over write? [confirm]y
Erase flash: before copying? [confirm]n
Loading http://192.168.45.4/test.html !
Verifying checksum... OK (0x7071)
1942 bytes copied in 0.396 secs (4904 bytes/sec)
R6#

BGP aggregation with suppress-map

2009-02-08T15:55:00.000+05:30

This scenario involves use of the suppress-map with BGP aggregate-address command. It is fairly simple to understand but I could use the practice.

R1 is getting the following routes from R2 in AS 200:

R1#show ip bgp | Begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.12.12.22 0 0 200 i
r> 2.2.2.3/32 172.12.12.22 0 0 200 i
*> 200.1.1.2/32 172.12.12.22 0 0 200 i
*> 200.2.2.2/32 172.12.12.22 0 0 200 i
*> 200.3.3.2/32 172.12.12.22 0 0 200 i

On R2 we can configure aggregation with the following command:

R2(config-router)#aggregate-address 200.0.0.0 255.0.0.0

Without clearing BGP, here is R1's BGP table with the aggregate 200.0.0.0/8:

R1#show ip bgp | Begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.12.12.22 0 0 200 i
r> 2.2.2.3/32 172.12.12.22 0 0 200 i
*> 200.0.0.0/8 172.12.12.22 0 0 200 i
*> 200.1.1.2/32 172.12.12.22 0 0 200 i
*> 200.2.2.2/32 172.12.12.22 0 0 200 i
*> 200.3.3.2/32 172.12.12.22 0 0 200 i

Suppose we wanted to suppress only some of the "component routes", but not all. With the summary-only keyword we would suppress all, but with a suppress-map we can supress a few.

on R2 we add the following:

access-list 50 permit 200.1.1.2
access-list 50 permit 200.3.3.2
!
route-map BLOCK permit 10
match ip address 50
!
router bgp 200
aggregate-address 200.0.0.0 255.0.0.0 suppress-map BLOCK
!

Note that the access-list "permits" the networks and the supress-map matches whatever networks are permitted by the ACL and suppresses them.

Now on R1 we have:

R1#show ip bgp | Begin Network
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.12.12.22 0 0 200 i
r> 2.2.2.3/32 172.12.12.22 0 0 200 i
*> 200.0.0.0/8 172.12.12.22 0 0 200 i
*> 200.2.2.2/32 172.12.12.22 0 0 200 i

BGP aggregation with unsuppress-map option

2009-02-08T15:54:00.002+05:30

R1 [AS 100] connects to R2 [AS 200]

R1 is currently summarizing a bunch of subnets in the 1.0.0.0/8 range.

R1# show ip route | in C
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
C 1.1.1.1/32 is directly connected, Loopback0
C 1.3.3.3/32 is directly connected, Loopback3
C 1.2.2.2/32 is directly connected, Loopback2
C 1.5.5.5/32 is directly connected, Loopback5
C 1.4.4.4/32 is directly connected, Loopback4
C 1.7.7.7/32 is directly connected, Loopback7
C 1.6.6.6/32 is directly connected, Loopback6

R1 is configured as such:

router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
network 1.2.2.2 mask 255.255.255.255
network 1.3.3.3 mask 255.255.255.255
network 1.4.4.4 mask 255.255.255.255
network 1.5.5.5 mask 255.255.255.255
aggregate-address 1.0.0.0 255.0.0.0 summary-only
neighbor 172.12.12.2 remote-as 200
neighbor 172.12.14.4 remote-as 100

The following route shows up on R2:

R2#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0 172.12.23.3 0 300 100 i
*> 172.12.12.1 0 100 i

As you can see we are supressing all of the 1.0.0.0 subnets. Suppose we wanted to advertise one of the subnets as well, to do so we can use the unsuppress-map option on the neighbor command.

On R1:

R1(config)#access-list 12 permit 1.1.1.1
R1(config)#access-list 12 permit 1.2.2.2
R1(config)#access-list 12 permit 1.3.3.3
R1(config)#route-map ALLOW
R1(config-route-map)#match ip address 12
R1(config-route-map)#exit
R1(config)#router bgp 100
R1(config-router)#neighbor 172.12.12.2 unsuppress-map ALLOW

Clear BGP:

R1#clear ip bgp *
R1#
00:41:47: %BGP-5-ADJCHANGE: neighbor 172.12.12.2 Down User reset
00:42:28: %BGP-5-ADJCHANGE: neighbor 172.12.12.2 Up

Now on R2 we have "unsuppressed" 3 routes:

R2#show ip bgp | inc 1\.
* 1.0.0.0 172.12.23.3 0 300 100 i
*> 1.1.1.1/32 172.12.12.1 0 0 100 i
*> 1.2.2.2/32 172.12.12.1 0 0 100 i
*> 1.3.3.3/32 172.12.12.1 0 0 100 i

BGP no-export community

2009-02-08T15:54:00.001+05:30

This is gonna be short and hopefully sweet. I'll leave some blanks in here so you can fill in the rest...

R4 (AS3) connects to R1 via EBGP
R1 connects to R2 via IBGP (AS 2)
R2 connects to R5 (AS1) via EBGP

We don't want AS2 to become a transit AS between R4 and R5 so we can use the no-export community to accomplish this. There are several ways to do is but here is a way with using the as-path access-lists. AS-path access-lists are awesome because they use regexp.

So on R1 we create an AS-path access list to match any routes originating in R4 AS:

ip as-path access-list 1 permit _3$

Then we create a route-map and apply it to the R2 neighbor going outbound:

route-map noexport permit 10
match as-path 1
set community no-export

route-map noexport permit 20

router bgp 2
neighbor 155.1.23.2 send-community
neighbor 155.1.23.2 route-map noexport out

Now on R2 we have this:

R2#show ip bgp 204.12.1.0 | inc Community
Community: no-export

R5 does not have the route!

R5#show ip bgp 204.12.1.0
% Network not in table
R5#

You can do the reverse on R2 to accomplish the two way restriction. Also note that R4 can bypass this by prepending an AS# to its routes! A better way would be to add the no-export community to all routes learned from R4 not just the ones originating in R4's AS. But I just wanted to see the flexibility of route-maps and as-path access lists with communities.

BGP - External confedration peers

2009-02-08T15:53:00.000+05:30

It is important to remember when doing confederations that although external confederation peers behave like EBGP peers in several ways, they do NOT modify the next hop without manual configuration.

Example:

R4 --- [[R1---R3]---[R2]]---R5

R1, R2 and R3 are in AS#2 as far as R4 and R5 are concerned. But R1 and R3 share sub-AS 65013, and R2 is in sub-AS 65002. Confederations allow R3 to advertise routes learned from R1 to R2 and vice-versa. Without confederations, this would not happen because routes learned from IBGP neighbors do not get advertise to other IBGP neighbors.

Confederations allow this to happen but be careful with the next hop attribute. When R2 passes routes learned from R5 to R3, it will not modify the next hop, but instead leave it pointing to R5. You must use the next-hop-self argument on the neighbor command to allow R3 to install these routes (unless R3 has a route to the R2-R5 network).

Suppose the network in questions is 155.1.5.0/24. Here is the output of show ip bgp before the change:

R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 5
Paths: (1 available, no best path)
Flag: 0x208
Not advertised to any peer
(65002) 1
155.1.0.5 (inaccessible) from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external

And after the change:

R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x208
Advertised to non peer-group peers:
155.1.13.1
(65002) 1
155.1.23.2 from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external, best

BGP - Troubleshooting AS Paths with confederations

2009-02-08T15:52:00.002+05:30

I ran into an issue while doing BGP confederations today. In the topology below, I was seeing sub-AS 65013 in the AS PATH on R5 for routes to VLAN4. I found out the problem but I decided to post this so if you ever see this issue, you can tell what it looks like.

VLAN4--R4---[[R1---R3]---[R2]]---R5--VLAN5 and 58

R4 = AS 3
R1,R3 = sub-AS 65013, AS 2
R2 = sub-AS 65002, AS 2
R5 = AS 1

VLAN4 = 204.1.12.0
VLAN5 = 155.1.5.0
VLAN58 = 155.1.58.0

Study the outputs below. Notice that R5 still sees sub-AS 65013 in it's routes to R4. The AS PATH should be: 2 3. What is the error I made?

-------------------------------------------------------------------------------

In the below output, R4 sees R5's VLAN coming from AS 1 and AS 2. There is no way of telling these come from condeferations.

R4#show ip bgp
BGP table version is 20, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 155.1.146.1 0 2 1 i
*> 155.1.58.0/24 155.1.146.1 0 2 1 i
*> 204.12.1.0 0.0.0.0 0 32768 i
R4#

-------------------------------------------------------------------------------

R1 sees both of R5's VLANS as coming from AS 1 and sub-AS 65002. R1 is confederation peer with sub-AS 65002.

R1#show ip bgp
BGP table version is 8, local router ID is 155.1.146.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*>i155.1.5.0/24 155.1.23.2 0 100 0 (65002) 1 i
*>i155.1.58.0/24 155.1.23.2 0 100 0 (65002) 1 i
*> 204.12.1.0 155.1.146.4 0 0 3 i
R1#

-------------------------------------------------------------------------------

R3 sees the same thing as R1.

R3#show ip bgp
BGP table version is 8, local router ID is 155.1.37.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 155.1.23.2 0 100 0 (65002) 1 i
*> 155.1.58.0/24 155.1.23.2 0 100 0 (65002) 1 i
*>i204.12.1.0 155.1.13.1 0 100 0 3 i
R3#

-------------------------------------------------------------------------------

R2 sees R5's vlan as originating from AS 1. It also sees R4's VLAN as coming from AS 3 and AS 65013 - not sure why there isn't parenthesis around 65013 in this case...

R2#sho ip bgp
BGP table version is 4, local router ID is 155.1.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 155.1.0.5 0 0 1 i
*> 155.1.58.0/24 155.1.0.5 0 0 1 i
*> 204.12.1.0 155.1.13.1 0 100 0 65013 3 i
R2#

-------------------------------------------------------------------------------

Here are R5 sees R4's VLAN as coming throigh AS 3 65013 and then from AS 2. Why is 65013 appearing?

R5#show ip bgp
BGP table version is 22, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 0.0.0.0 0 32768 i
*> 155.1.58.0/24 0.0.0.0 0 32768 i
*> 204.12.1.0 155.1.0.2 0 2 65013 3 i
R5#

-------------------------------------------------------------------------------

It turns out the error was on R3:

router bgp 65013
no synchronization
bgp log-neighbor-changes
bgp confederation peers 65002
neighbor 155.1.13.1 remote-as 65013
neighbor 155.1.23.2 remote-as 65002

I dont have a bgp confederation identifier!

Let's fix it:

R3(config)#router bgp 65013
R3(config-router)#bgp confederation identifier 2

That's much better:

R5#show ip bg
BGP table version is 24, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 155.1.5.0/24 0.0.0.0 0 32768 i
*> 155.1.58.0/24 0.0.0.0 0 32768 i
*> 204.12.1.0 155.1.0.2 0 2 3 i

BGP - Aggregation with advertise-map

2009-02-08T15:52:00.001+05:30

R1,R2 and R3 connect to R5 via Frame-relay

R1-\
R2---R5
R3-/

These 3 spokes are EBGP peers with R5.
These routes are advertised into bgp:

R1, loopback 150.1.1.1 AS1
R2, loopback 150.1.2.2 AS2
R3, loopback 150.1.3.3 AS3
R5, loopback 150.1.5.5 AS5

Here are R3's and R5's BGP table before any aggregation:

R5#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 150.1.1.0/24 155.1.0.1 0 0 1 i
*> 150.1.2.0/24 155.1.0.2 0 0 2 i
*> 150.1.3.0/24 155.1.0.3 0 0 3 i
*> 150.1.5.0/24 0.0.0.0 0 32768 i

R3#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 150.1.1.0/24 155.1.0.1 0 5 1 i
*> 150.1.2.0/24 155.1.0.2 0 5 2 i
*> 150.1.3.0/24 0.0.0.0 0 32768 i
*> 150.1.5.0/24 155.1.0.5 0 0 5 i

Suppose R5 wants to advertise a summary-only aggregate to R3:

R5(config)#router bgp 5
R5(config-router)#aggregate-address 150.1.0.0 255.255.248.0 as-set summary-only

R3 will deny the route because of the as-set option which forces R5 to include the AS numbers as an unordered set in the AS PATH:

R3#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 150.1.3.0/24 0.0.0.0 0 32768 i

R3#debug ip bgp updates
00:37:37: BGP(0): 155.1.0.5 rcv UPDATE w/ attr: nexthop 155.1.0.5, origin i, aggregated by 5 150.1.5.5, originator 0.0.0.0, path 5 {1,2,3}, community , extended community
00:37:37: BGP(0): 155.1.0.5 rcv UPDATE about 150.1.0.0/21 -- DENIED due to: AS-PATH contains our own AS;
R3#

We can have R5 remove R3's attributes (AS PATH) in the aggregate by using an advertise-map. This will allow R3 to recieve the aggregate.

First we create a prefix-list to match the route:

R5(config)#ip prefix-list R3 permit 150.1.3.0/24

The we create a route-map, note that we are denying the prefix. This means any matches will NOT have their attributes populated to the aggregate's attributes:

R5(config)#route-map DENY3 deny 10
R5(config-route-map)#match ip address prefix-list R3
R5(config-route-map)#exit
R5(config)#route-map DENY3 permit 20
R5(config-route-map)#exit

Finally, we apply the advertise-map to the aggregate-address command under the bgp process:

R5(config)#router bgp 5
R5(config-router)#aggregate-address 150.1.0.0 255.255.248.0 as-set summary-only advertise-map DENY3

Here are the final results:

R5#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 150.1.0.0/21 0.0.0.0 32768 {1,2} i
s> 150.1.1.0/24 155.1.0.1 0 0 1 i
s> 150.1.2.0/24 155.1.0.2 0 0 2 i
s> 150.1.3.0/24 155.1.0.3 0 0 3 i
s> 150.1.5.0/24 0.0.0.0 0 32768 i
R5#

R3#
00:46:26: BGP(0): 155.1.0.5 update run completed, afi 0, ran for 4ms, neighbor v
ersion 35, start version 38, throttled to 38
00:46:26: BGP(0): 155.1.0.5 rcvd UPDATE w/ attr: nexthop 155.1.0.5, origin i, at
omic-aggregate, aggregated by 5 150.1.5.5, path 5 {1,2}
00:46:26: BGP(0): 155.1.0.5 rcvd 150.1.0.0/21
00:46:26: BGP(0): Revise route installing 150.1.0.0/21 -> 155.1.0.5 to main IP t
able
R3#

R3#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 150.1.0.0/21 155.1.0.5 0 5 {1,2} i
*> 150.1.3.0/24 0.0.0.0 0 32768 i
R3#

Notice that the aggregate only has AS1 and AS2 in the AS PATH. This allows R3 to install the aggregate in it's BGP table.

BGP - Conditional Advertisement with non-exist-map

2009-02-08T15:51:00.001+05:30

It took me awhile to get this going for some reason but here is the doc that helped me out:

Configuring and Verifying the BGP Conditional Advertisement Feature

Here's my example

[R1]---[R4]---[R5]

Each router is in its own AS.

R1 is advertising 10.1.0.0/16 to R4.
if this route should fail, then R4 should advertise 4.4.4.0/24 to R5.
If 10.1.0.0/16 appears in R4's BGP table, then it should stop advertising 4.4.4.0/24.

R4 is where the action is so let's have a look:

!
interface Loopback0
ip address 4.4.4.4 255.255.255.0
!
router bgp 4
no synchronization
bgp log-neighbor-changes
network 4.4.4.0 mask 255.255.255.0
neighbor 155.1.45.5 remote-as 5
neighbor 155.1.45.5 advertise-map ADV non-exist-map NON
neighbor 155.1.146.1 remote-as 1
no auto-summary
!
access-list 10 permit 10.1.0.0 0.0.255.255
access-list 40 permit 4.4.4.0 0.0.0.255
!
route-map NON permit 10
match ip address 10
!
route-map ADV permit 10
match ip address 40

10.1.0.0 is actually the loopback network on R1 so we can test easy by shutting/no shutting the interface. Right now it is up. Let's check the BGP tables on R4 and R5:

R4#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/16 155.1.146.1 0 0 1 i

R5#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 10.1.0.0/16 155.1.45.4 0 4 1 i

Now let's shut the interface on R1:

R1(config)#int lo 1
R1(config-if)#shut

Now check R4 and R5 again:

R4#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.0/24 0.0.0.0 0 32768 i

R5#debug ip bgp updates
BGP updates debugging is on for address family: IPv4 Unicast
*Mar 1 01:59:35.787: BGP(0): 155.1.45.4 rcvd UPDATE w/ attr: nexthop 155.1.45.4, origin i, metric 0, path 4
*Mar 1 01:59:35.791: BGP(0): 155.1.45.4 rcvd 4.4.4.0/24
*Mar 1 01:59:35.799: BGP(0): Revise route installing 1 of 1 routes for 4.4.4.0/24 -> 155.1.45.4(main) to main IP table

R5#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.0/24 155.1.45.4 0 0 4 i

BGP - expanded community-lists

2009-02-08T15:50:00.000+05:30

BGP expanded community-lists are more flexible than their standard counterparts because they can match on regexp instead of just a community string. Here you can see the differences:

R4(config)#ip community-list standard STANDARD permit ?
<1-4294967295> community number
aa:nn community number
internet Internet (well-known community)
local-AS Do not send outside local AS (well-known community)
no-advertise Do not advertise to any peer (well-known community)
no-export Do not export to next AS (well-known community)

R4(config)#ip community-list expanded EXPANDED permit ?
LINE An ordered list as a regular-expression

Now for a little lab. R1 and R2 are both going to EBGP peer with R4. R4 will then EBGP peer with R3. R1 and R2 will each send routes with different community strings to R4, along with routes without a community. We will use an expanded list to match certain community values. Hopefully, we can get it done with one permit statement.

R1 has 4 loopback networks:
1.0.0.0/24
1.0.1.0/24
1.0.2.0/24
1.0.3.0/24

R2 has 4 loopback networks:
2.0.0.0/24
2.0.1.0/24
2.0.2.0/24
2.0.3.0/24

R1 is sending community 100 with its first two loopbacks
R2 is sending community 200 with its first two loopbacks
The other loopbacks do not have a community attached.
Here is how we do it on R1, R2 is similar:

R1(config)#ip prefix-list LOOP1 permit 1.0.0.0/24
R1(config)#ip prefix-list LOOP1 permit 1.0.1.0/24
R1(config)#route-map setcom
R1(config-route-map)#match ip address prefix LOOP1
R1(config-route-map)#set commu 100
R1(config-route-map)#exit
R1(config)#route-map setcom perm 20
R1(config-route-map)#exit
R1(config)#router bgp 65000
R1(config-router)#neighbor 172.12.14.4 send-community
R1(config-router)#neighbor 172.12.14.4 route-map setcom out

Verify on R4 (this shows R4 is receiving all loopbacks)

R4#sho ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.14.1 0 0 65000 i
*> 1.0.1.0/24 172.12.14.1 0 0 65000 i
*> 1.0.2.0/24 172.12.14.1 0 0 65000 i
*> 1.0.3.0/24 172.12.14.1 0 0 65000 i
*> 2.0.0.0/24 172.12.24.2 0 0 65000 i
*> 2.0.1.0/24 172.12.24.2 0 0 65000 i
*> 2.0.2.0/24 172.12.24.2 0 0 65000 i
*> 2.0.3.0/24 172.12.24.2 0 0 65000 i

Here are the loopbacks with community attributes:

R4#show ip bgp community 100 | begin Net
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0/24 172.12.14.1 0 0 65000 i
* 1.0.1.0/24 172.12.14.1 0 0 65000 i
R4#show ip bgp community 200 | begin Net
Network Next Hop Metric LocPrf Weight Path
* 2.0.0.0/24 172.12.24.2 0 0 65000 i
* 2.0.1.0/24 172.12.24.2 0 0 65000 i

Here is R3:

R3#show ip bgp

Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 1.0.2.0/24 172.12.34.4 0 400 65000 i
*> 1.0.3.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.2.0/24 172.12.34.4 0 400 65000 i
*> 2.0.3.0/24 172.12.34.4 0 400 65000 i

Now we will configure R4 to send only routes with community 100 or 200 to R3:

R4(config)#ip community-list expanded EXPANDED permit [1-2]00
R4(config)#route-map filtercom
R4(config-route-map)#match community ?
<1-99> Community-list number (standard)
<100-500> Community-list number (expanded)
WORD Community-list name
R4(config-route-map)#match community EXPANDED
R4(config-route-map)#exit
R4(config)#router bgp 400
R4(config-router)#neighbor 172.12.34.3 route-map filtercom out

Let's check on R3:

R3#show ip bgp
BGP table version is 66, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i

In this example the regexp string [1-2]00 matched either 100 or 200 an only allowed these routes through to R3.

BGP - prefix-based outbound route filtering

2009-02-08T15:49:00.001+05:30

Prefix-based outbound route filtering is used so a local router can tell it's peer what routes it should send/filter. This prevents unnecessary resources from being used. There is no sense in a router sending a bunch of route updates, if they are only going to get filtered anyway.

In this example we have EBGP peers R4 and R3:

[R4]---[R3]

R3 is receiving a bunch of routes from R4:

R3#show ip bgp Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 1.0.2.0/24 172.12.34.4 0 400 65000 i
*> 1.0.3.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.2.0/24 172.12.34.4 0 400 65000 i
*> 2.0.3.0/24 172.12.34.4 0 400 65000 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
*> 4.0.0.0/24 172.12.34.4 0 0 400 i
*> 4.0.1.0/24 172.12.34.4 0 0 400 i
*> 4.0.2.0/24 172.12.34.4 0 0 400 i
*> 4.0.3.0/24 172.12.34.4 0 0 400 i

R3 only wants to receive 3 routes:

1.0.0.0/24
2.0.0.0/24
4.0.0.0/24

R3 can create a prefix-list allowing these 3 routes only and advertise this to R4. R4 will use this list as a outbound filter. Let's configure it. First you need enable the advertisement of the orf capability. R3 is the one sending the prefix-list so use the send keyword. R4 is receiving the prefix-list.

R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 capability orf prefix-list send

R4(config)#router bgp 400
R4(config-router)#neighbor 172.12.34.3 capability orf prefix-list receive

Now configure the prefix-list and apply it to the neighbor:

R3(config)#ip prefix-list ZERO seq 5 permit 1.0.0.0/24
R3(config)#ip prefix-list ZERO seq 10 permit 2.0.0.0/24
R3(config)#ip prefix-list ZERO seq 15 permit 4.0.0.0/24
R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 prefix-list ZERO in

R3#clear ip bgp * soft in prefix-filter

Here is the final result:

R3#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
*> 4.0.0.0/24 172.12.34.4 0 0 400 i

Here are some captures I took in dynamips. The first shows the advertisement of the orf capability. The second shows the actually prefix-list R3 is sending. Wireshark shows this as "route-refresh" message. Pretty cool, eh?

Restrictions:

I used the bgp upgrade-cli command to configure these neighbors in AF mode.
Also, prefix-lists must be used, not ACL or distribute lists

BGP - changing cluster-id

2009-02-08T15:48:00.001+05:30

The network:

[R3]---[R5]---[R4]---[EXTERNAL AS]

R3 is IBGP peer with R5
R5 is IBGP peer with R4
R5 is the route reflector

Here is the bgp entry for a route learned initially from R4:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 5.5.5.5

Changing the cluster-id:

R5(config)#router bgp 345
R5(config-router)#bgp cluster-id ?
<1-4294967295> Route-Reflector Cluster-id as 32 bit quantity
A.B.C.D Route-Reflector Cluster-id in IP address format
R5(config-router)#bgp cluster-id 5

Here's how the change looks on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 0.0.0.5

BGP - set clauses are ignored on reflected routes

2009-02-08T15:47:00.000+05:30

Network:

R4,R5,R6 have serial interfaces connected to Frame cloud 172.14.45.0/24
R3,R4,R5 have LAN interfaces connected to 172.12.34.0/24

R6 has EBGP peering with R5 and R4, however R5 has R6 neighbor shutdown for now.
R4 is connected to R5 via IBGP.
R5 then connects to R3 via IBGP.
R5 has R3 configured as a route-reflector client.
R5 reflects routes learned from R4 to R3.
R5 has the following config:

router bgp 345
bgp cluster-id 5
neighbor 3.3.3.3 remote-as 345
neighbor 3.3.3.3 update-source Loopback0
!
address-family ipv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community
neighbor 3.3.3.3 route-reflector-client
neighbor 3.3.3.3 route-map SET out
!
ip prefix-list SIX seq 5 permit 6.0.0.0/24
!
route-map LOOPBACK permit 10
match ip address 5
!
route-map SET permit 10
match ip address prefix-list SIX
set community 500
!
route-map SET permit 20
!

The community does not show up on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 0.0.0.5

Now let's peer R5 directly with R6 and see what happens:

R5(config)#router bgp 345
R5(config-router)#neighbor 4.4.4.4 shutdown
R5(config-router)#no neighbor 172.14.45.6 shutdown

Immediately the community shows up on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 13
Paths: (1 available, no best path)
Flag: 0x820
Not advertised to any peer
65000
172.14.45.6 (inaccessible) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 200, localpref 100, valid, internal
Community: 500

I got this info while browsing the DocCD:

Configuring a Route Reflector

"The use of set clauses in outbound route maps can modify attributes and possibly create routing loops. To avoid this behavior, set clauses of outbound route maps are ignored for routes reflected to iBGP peers."

BGP - deterministic-med and always-compare-med

2009-02-08T15:46:00.001+05:30

How the bgp deterministic-med Command Differs from the bgp always-compare-med Command

In order to get the various routes to look right in the bgp table, it took some work. Here is a picture that helps explain it. I'm not gonna put addressing on it. If you want configs, let me know.

Our focus is on R1, it has 3 bgp entries to 3.3.3.0:

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 24
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.12.2 172.12.14.4
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external, best
R1#

Tiebreaker:
1. entry1 and entry2 are compared, entry2 is picked because external > internal
2. entry2 and entry3 are compared, entry 3 picked because RID 3.3.3.3

Now let's configre always-compare-med:

R1(config)#router bgp 65000
R1(config-router)#bgp always-compare-med

This command should allow entry1 to be picked over entry2 (lower MED), then entry1 will be preferred over entry3 (also lower MED):

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 41
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to non peer-group peers:
172.12.13.3 172.12.14.4
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external

It works!

Notice that entries are compared in pairs. To get the pairs reordered you may have shut peers down and enable them accordingly. Example: I wanted the peers to appear in this order 4.0.3.4, 3.3.3.3, and 2.2.2.2. So I brought them up in reverse order: 2.2.2.2, 3.3.3.3, and finally 4.0.3.4. I just did a shut/no shut on the interface. Now I have:

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 47
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.13.3 172.12.14.4
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best

Notice the best route is still from 2.2.2.2 because always-compare-med is enabled. Let's try bgp deterministic-med, without always compare-med. First reset bgp, then continue.

R1(config)#router bgp 65000
R1(config-router)#no bgp always-compare-med
R1(config-router)#bgp deterministic-med

In this case entry2 should be compared to entry3 with entry 2 winning based on lower MED (they are in the same AS so MED is compared). Then entry2 is compared to entry1, with entry1 winning because external bgp is preferred over internal. MED is not compared between these entries.

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 11
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.12.2 172.12.14.4
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external, best
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external

Notice in the above example that the entries are ordered in groups based on AS. I brough up 4.4.4.4 last, but it is showing up last with the other entry from AS400.

The last example uses both bgp deterministic-med and bgp always-compare-med. In this case, entry2 should win with the lowest MED. This is the same as the last example except MED is used for comparison between entry1 and entry2.

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 12
Paths: (3 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.13.3 172.12.14.4
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external

BGP - maximum-prefix command

2009-02-08T15:44:00.000+05:30

The network: [R5]---[R6]

R5 connects to R6 via EBGP
R5 is 172.14.45.5
R6 is 172.45.45.6

R6 is advertising 10 networks to R5:

R5#show ip bgp | inc 45\.6
*> 6.0.0.0/24 172.14.45.6 0 0 65000 i
*> 6.0.1.0/24 172.14.45.6 0 0 65000 i
*> 6.0.2.0/24 172.14.45.6 0 0 65000 i
*> 6.0.3.0/24 172.14.45.6 0 0 65000 i
*> 6.0.4.0/24 172.14.45.6 0 0 65000 i
*> 6.0.5.0/24 172.14.45.6 0 0 65000 i
*> 6.0.6.0/24 172.14.45.6 0 0 65000 i
*> 6.0.7.0/24 172.14.45.6 0 0 65000 i
*> 6.0.8.0/24 172.14.45.6 0 0 65000 i
*> 6.0.9.0/24 172.14.45.6 0 0 65000 i

I am going to play with a few options of the maximum-prefix command and see the effect. First let's configure a maximum of 8 routes:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8
R5(config-router)#
.Jul 14 20:45:41.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Maximum-Prefix restart timeout
.Jul 14 20:46:10.519: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:46:11.919: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:46:11.927: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:46:11.931: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:46:11.931: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
R5(config-router)# FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0058 0200 0000 1940 0
101 0040 0204 0201 FDE8 4003 04AC 0E2D 0680 0404 0000 0000 1806 0009 1806 0008 1
806 0007 1806 0006 1806 0005 1806 0004 1806 0003 1806 0002 1806 0001 1806 0000

Notice that the nighbor tried to come up after I configured the max. It never tried to come up again after going down the second time. Now the neighbor has the following output (much of the output is omitted):

R5#show clock
.20:50:26.655 UTC Mon Jul 14 2008
R5#

R5#show ip bgp neighbor 172.14.45.6
...
Peer had exceeded the max. no. of prefixes configured.
Maximum prefixes allowed 8
Threshold for warning message 75%
Reduce the no. of prefix and clear ip bgp 172.14.45.6 to restore peering

We can also configure the router to try and establush the connection again after the max limit is reached and the connection is brought down:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 restart 1

Here is a sample of the output, the connection tries to re-establish but then drops because the max-prefix limit is reached:

R5#
.Jul 14 20:53:16.779: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:53:16.811: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:53:16.819: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:53:16.823: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:53:16.827: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
.Jul 14 20:54:15.999: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:54:16.011: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:54:16.015: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:54:16.023: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:54:16.023: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
.Jul 14 20:55:41.311: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:55:41.355: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:55:41.359: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:55:41.363: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:55:41.367: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes

We can also configure a percentage to give us a warning. Here we configure the percantge to 75 of 8 (6) while disabling 3 of the loopbacks on R6:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 7

.Jul 14 21:00:08.226: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 21:00:08.234: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8

The connection stays up:

R5#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 186 177 224 0 0 00:00:33 7

Lastly, we can configure a warning-only which doesn't bring down the connection:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 75 warning-only

.Jul 14 21:01:53.614: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 8, max 8
.Jul 14 21:02:24.046: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8

The connection stays up:

R5#show ip bgp summary | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 190 181 226 0 0 00:02:41 9

BGP - local-as option

2009-02-08T15:43:00.002+05:30

BGP local-as option allows a router to appear as if it is in another AS. Suppose we have a frame-relay cloud with 3 routers all EBGP peers with each other:

R6: 172.14.45.6 (AS 65000)
R5: 172.14.45.5 (AS 65005)
R4: 172.14.45.4 (AS 345)

We can configure R6 to use the local-as option to appear to be from AS 65006 to R5, but remain in AS65000 for R4. Here's how:

R6(config-router)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006

On R5:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 remote-as 65006

Let's take a look at the neighbor summary:

R5# show ip bgp summary | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65006 220 221 244 0 0 00:03:39 9

R4#show ip bgp summary | be Ne
172.14.45.6 4 65000 176 146 69 0 0 00:00:08 11

Notice the different AS numbers. Also notice the AS path from R5's view:

R5# show ip bgp | inc 172.14.45.6
*> 6.0.3.0/24 172.14.45.6 0 0 65006 65000 i
*> 6.0.4.0/24 172.14.45.6 0 0 65006 65000 i
*> 6.0.5.0/24 172.14.45.6 0 0 65006 65000 i

And the AS path from R6's view also includes the local-AS number:

R6#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.14.45.5 0 65006 65005 65002 i
*> 5.5.5.5/32 172.14.45.5 0 0 65006 65005 i

The routes appear to magically pass through 65006. We can prevent R6 from prepending the local-as number on routes received from R6 with the no-prepend option

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend

65006 is no longer in the AS Path:

R6#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.14.45.5 0 65005 65002 i
*> 5.5.5.5/32 172.14.45.5 0 0 65005 i

With the replace-AS we can prevent R5's real BGP AS number from appearing in the AS path on routes from R6 to R5:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-as

R5# show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 6.0.3.0/24 172.14.45.6 0 0 65006 i
*> 6.0.4.0/24 172.14.45.6 0 0 65006 i
*> 6.0.5.0/24 172.14.45.6 0 0 65006 i

Lastly, we can configure R6 to accept connections to either AS 65000 or AS 65006 with the dual-as option:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-as dual-as

R5#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65006 268 284 343 0 0 00:00:08 9

R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 remote-as 65000
R5(config-router)#
.Jul 14 21:34:34.273: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Remote AS changed
R5(config-router)#
.Jul 14 21:34:36.505: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
R5(config-router)#
R5(config-router)#^Z
R5#show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 270 286 0 0 0 00:00:09 0

BGP - TTL security

2009-02-08T15:43:00.001+05:30

Suppose R5 and R6 are EBGP peers. Each send BGP packets with TTL of 1 to each other. They process any BGP packet with a TTL value of 1 or higher. So if an attacker wants to cause mayhem he can send tons of BGP packets to an edge router in a type of DoS attack and these packets will be processed no matter how far away the attacker is. With BGP TTL Security we can configure the router to expect to receive packets with higher TTL values. That way, an attacker more than the configured number of hops away, will never be able to DoS the router.

Example:

On R6 we configure:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 ttl-security hops 5

After 3 minutes (BGP default time) without a keepalive, R6 drops the neighbor:

Mar 1 03:16:55.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.5 Down BGP Notification sent
Mar 1 03:16:55.467: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.5 4/0 (hold time expired) 0 bytes

The reason this happens is because after the TTL security command is configured, R6 will silently drop any packet with a TTL lower of 250 or lower. If it receives a packet with TTL 250, I think it will drop it according to my testing. How can we make R5 send packets with a TTL of 251? We can use TTL-security on that router to or use ebgp-multihop.

In this case I use ebgp-multihop:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 ebgp-multihop 251

.Jul 14 23:01:46.740: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up

In this case we use TTL security on R5:

R5(config)#router bgp 65005
R5(config-router)#no neighbor 172.14.45.6 ebgp-multihop 251
R5(config-router)#neighbor 172.14.45.6 ttl-security hops 5

After clearing the session:

.Jul 14 23:05:15.131: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up

You can verify like this:

R6#show ip bgp neighbors 172.14.45.5 | inc TTL
(output omitted)
External BGP neighbor may be up to 5 hops away.
Connection is ECN Disabled, Mininum incoming TTL 250, Outgoing TTL 255

I don't know why ebgp-multihop didn't work with 250. Perhaps the router decrements it before processing and then sees 249 as the TTL.

BGP - Neighbor discovery protocol

2009-02-08T15:42:00.001+05:30

R9 is connected to the same LAN as BB3. We need to peer with BB3 but we don't know the IP or the AS number of BB3.

First, we can ping the broadcast address on the ethernet segment between R9 and BB3. This works best with only 1 other host. Otherwise we would have to resort to trial and error or some other means, maybe debug ip packet.

R9#ping 100.100.250.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.250.255, timeout is 2 seconds:

Reply to request 0 from 100.100.250.250, 4 ms
Reply to request 1 from 100.100.250.250, 1 ms
Reply to request 2 from 100.100.250.250, 1 ms

R9#

Now we know our peer ip, but we need to know the AS number. If you peer to the wrong AS, you can see the BB AS in message debug:

R9(config)#router bgp 19999
R9(config-router)#neighbor 100.100.250.250 remote-as 1

*Aug 12 02:57:05.411: %BGP-3-NOTIFICATION: sent to neighbor 100.100.250.250 2/2 (peer in wrong AS) 2 bytes 0DE9
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 0DE9 00B4 6E0F 90C8 1002 0601 0400 0100 0102 0280 0002 0202 00

Here the neighbor is in AS 0DE9 (3561)

R9(config)#router bgp 19999
R9(config-router)#neighbor 100.100.250.250 remote-as

*Aug 12 02:59:12.359: %BGP-5-ADJCHANGE: neighbor 100.100.250.250 Up

BGP - regexp practice part 1

2009-02-08T15:41:00.001+05:30

Using regexp with as-path access-list are one of the coolest features of BGP. The show ip bgp regexp command is good way to test your regular expression.

Here is what I have currently on R1's bgp table:

R1#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 100.3.0.0/24 172.12.123.3 0 0 300 i
*> 100.3.1.0/24 172.12.123.3 0 0 300 i
*> 100.3.2.0/24 172.12.123.3 0 0 300 i
*> 100.6.0.0/24 172.12.123.3 0 300 600 i
*> 100.6.1.0/24 172.12.123.3 0 300 600 i
*> 100.6.2.0/24 172.12.123.3 0 300 600 i
*> 100.6.3.0/24 172.12.123.3 0 300 600 1000 1200 i
*> 100.6.4.0/24 172.12.123.3 0 300 600 1000 1200 i

Suppose I want to match routes that contain one AS or two AS but no more. I could do this:

R1#show ip bgp regexp ^[0-9]*$|^[0-9]*_[0-9]*$

Network Next Hop Metric LocPrf Weight Path
*> 100.3.0.0/24 172.12.123.3 0 0 300 i
*> 100.3.1.0/24 172.12.123.3 0 0 300 i
*> 100.3.2.0/24 172.12.123.3 0 0 300 i
*> 100.6.0.0/24 172.12.123.3 0 300 600 i
*> 100.6.1.0/24 172.12.123.3 0 300 600 i
*> 100.6.2.0/24 172.12.123.3 0 300 600 i

How about paths that only contain at least one 4-digit AS# (why? i have no clue but here's how)

R1#show ip bgp regexp _[0-9][0-9][0-9][0-9]_

Network Next Hop Metric LocPrf Weight Path
*> 100.6.3.0/24 172.12.123.3 0 300 600 1000 1200 i
*> 100.6.4.0/24 172.12.123.3 0 300 600 1000 1200 i
R1#

BGP - Allowas-in with number of occurrences

2009-02-08T15:40:00.001+05:30

I ran into this BGP issue on IPexpert volume 2 Lab 4 today. Cat 1 is in AS 500. There are 3 other ASes, but CAT1 needs to see all of these as AS8888. Confederations right? For 2 of the ASes that is right, but the task says NOT to use a sub-as for AS78. Here is the AS map:

As500----As100----AS2456====AS78

AS2456 has 2 connections (R5 and R6) to AS78 (R7).

On R5 and R6 I have this ( I am allowed to use confederations on AS 2456):

router bgp 2456
bgp confederation identifier 8888
neighbor 150.20.56.7 remote-as 8888

on R7 I have this:

router bgp 78
neighbor 150.20.56.5 remote-as 8888
neighbor 150.20.56.5 local-as 8888
neighbor 150.20.56.5 allowas-in
neighbor 150.20.56.6 remote-as 8888
neighbor 150.20.56.6 local-as 8888
neighbor 150.20.56.6 allowas-in

Works great so far:

R7#show ip bgp sum | be Neigh
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
150.10.8.8 4 78 55 64 64 0 0 00:35:46 1
150.20.56.5 4 8888 112 121 64 0 0 00:01:07 5
150.20.56.6 4 8888 109 116 64 0 0 00:01:10 5

But notice the prefix I am learning from R8 (ibgp peer with R7). That prefix does not get installed by R5 and R6 because it has AS 8888 in the path. Here is the debug from R6:

R6#debug ip bgp update
*Oct 18 17:46:11.270: BGP(0): 150.20.56.7 rcv UPDATE about 200.200.200.0/24 -- DENIED
R6(config-rout due to: AS-PATH contains our own AS;

How do we allow R6 and R5 to accept this route? By using "allowas-in" option of the neighbor command. However, because we don't want R6 to learn routes that passed from R5 to R7 we set a maximum on the number of occurrences of the AS, which is 1.

R5 and R6:

router bgp 2456
neighbor 150.20.56.7 allowas-in 1

Now here is the same debug on R6:

*Oct 18 17:56:48.366: BGP(0): Revise route installing 1 of 1 routes for 200.200.200.0/24 -> 150.20.56.7(main) to main IP table

Let's take a look at CAT1 in AS 500

Cat1#show ip bgp | begin Net

Network Next Hop Metric LocPrf Weight Path
*> 200.200.200.0 150.20.110.1 0 8888 8888 78 ?

This is not good! We can get rid of AS 78 by doing this on R7:

R7(config)#router bgp 78
R7(config-router)#neighbor 150.20.56.5 local-as 8888 no-prepend replace-as
R7(config-router)#neighbor 150.20.56.6 local-as 8888 no-prepend replace-as

Now let's take a look:

Cat1#show ip bgp | beg Net

Network Next Hop Metric LocPrf Weight Path
*> 200.200.200.0 150.20.110.1 0 8888 8888 ?

BGP - peer session templates

2009-02-08T15:39:00.000+05:30

I had a task to configure bgp timers on R2 for the peering session to R1. I was not to use "timers bgp" or any neighbor commands withe the word "timers". I immediately thought of peer-session templates which was something I came across while reading the DocCD one day. Here is how it works. We are on R2:

R2(config)#router bgp 2456

R2(config-router)#template ?
peer-policy Template configuration for policy parameters
peer-session Template configuration for session parameters

R2(config-router)#template peer-session TEMPLATE-R1

R2(config-router-stmp)#timers 30 90
R2(config-router-stmp)#exit

R2(config-router)#neighbor 150.21.21.1 inherit ?
peer-policy Inherit a peer-policy template
peer-session Inherit a peer-session template

R2(config-router)#neighbor 150.21.21.1 inherit peer-session TEMPLATE-R1

Debugging an E-BGP multihop

2009-02-08T15:37:00.000+05:30

Debugging an E-BGP multihop scenario

R5----R2----R6

R2 is the hub, all routers are in the 150.100.100.0/24 subnet.

R2 = 150.100.100.2
R5 = 150.100.100.5
R6 = 150.100.100.6

Please note that R2 has one multipoint subinterface connected to R5 and R6. Blogspot doesn't like text drawings so I must draw it like above.

All routers are in sub-AS bgp confederations. R2 can only peer with one, and R5 and R6 must peer with each other.

The peers will not come up without ebgp-multihop configured, but suppose we forgot that. What kind of debugging could we do to lead us to that conclusion?

1) debug ip bgp

R6#
*May 25 04:46:18.587: BGP: 150.100.100.5 open active, local address 150.100.100.6
*May 25 04:46:48.587: BGP: 150.100.100.5 open failed: Connection timed out; remote host not responding, open active delayed 29387ms (35000ms max, 28% jitter)

This debug command shows us that BGP never completes the Active state. RFC 1771 tells us this about the Active state:

"In this state BGP is trying to acquire a peer by initiating a transport protocol connection."

So our TCP connection is not completing. Do you we have IP connectivity to R5? Sure:

R6#ping 150.100.100.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.100.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/102/108 ms
R6#

So now we can look higher up the protocol stack (e.g. filtering), or maybe the problem is still in the IP layer. In this case we have no ACL's applied.

2) debug ip packet detail

What I am looking for here is some packets from R5, sourced from 150.100.100.5. Debugging shows that I am getting none! However it also shows that I am getting ICMP type 11 messages from R2 immediately after I send a packet to R5:

R6#
*May 25 04:51:44.539: IP: tableid=0, s=150.100.100.6 (local), d=150.100.100.5 (Serial0/1/0), routed via FIB
*May 25 04:51:44.539: IP: s=150.100.100.6 (local), d=150.100.100.5 (Serial0/1/0), len 44, sending
*May 25 04:51:44.539: TCP src=24713, dst=179, seq=1584149779, ack=0, win=16384 SYN
*May 25 04:51:44.563: IP: tableid=0, s=150.100.100.2 (Serial0/1/0), d=150.100.100.6 (Serial0/1/0), routed via RIB
*May 25 04:51:44.563: IP: s=150.100.100.2 (Serial0/1/0), d=150.100.100.6 (Serial0/1/0), len 56, rcvd 3
*May 25 04:51:44.563: ICMP type=11, code=0

Seems that R2 is telling us something about our packet sent to R5.

3) debug ip icmp

*May 25 04:53:23.839: ICMP: time exceeded rcvd from 150.100.100.2

Here we get our answer. At this point we realize that our tcp syn packets sent to R5 have an IP TTL of 1, and thus are getting dropped by R2.

Do you know any other commands that would help you come to this conclusion?

BGP - RIP failures and suppress-inactive

2009-02-08T15:35:00.001+05:30

R1 [AS10] ----- R2 [AS256]------R6[AS256]

The network between R2 and R6 is 150.100.100.0/24. This network is advertised into BGP on R6 but not R2. Because this is a connected route, R2 does not install it as a BGP route. It does receive the advertisement however and propagate it to R1.

Here is the R2 config:

R2#show run | sec router bgp
router bgp 256
no synchronization
bgp log-neighbor-changes
network 150.100.25.0 mask 255.255.255.0
neighbor 150.100.12.1 remote-as 10
neighbor 150.100.100.6 remote-as 256
neighbor 150.100.100.6 route-reflector-client
no auto-summary

Here is the R6 config:

R6#show run | sec router bgp
router bgp 256
no synchronization
bgp log-neighbor-changes
network 150.100.69.0 mask 255.255.255.0
network 150.100.96.0 mask 255.255.255.0
network 150.100.100.0 mask 255.255.255.0
neighbor 150.100.100.2 remote-as 256
no auto-summary

Here is R2's BGP table:

R2#show ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 150.100.25.0/24 0.0.0.0 0 32768 i
*>i150.100.69.0/24 150.100.100.6 0 100 0 i
*>i150.100.96.0/24 150.100.100.6 0 100 0 i
r>i150.100.100.0/24 150.100.100.6 0 100 0 i

Notice the last entry has an 'r' next to it. This is not installed in the route table as a BGP route. It is already installed as connected. This is known as a RIB failure.

But the route is advertised to R1:

R1#show ip route bgp
150.100.0.0/16 is variably subnetted, 7 subnets, 2 masks
B 150.100.96.0/24 [20/0] via 150.100.12.2, 00:05:25
B 150.100.100.0/24 [20/0] via 150.100.12.2, 00:05:25
B 150.100.69.0/24 [20/0] via 150.100.12.2, 00:05:25
B 150.100.25.0/24 [20/0] via 150.100.12.2, 00:05:25

Now here's the tricky part. You can use the BGP suppress-inactive command to prevent RIB failures from getting advertised. But when I use it on R2 and R6 it doesn't work quite like I expected.

R2#show run | inc inac
bgp suppress-inactive
R2#

R6#show run | inc inac
bgp suppress-inactive
R6#

Notice here that R1 still has the 150.100.100.0 route from R2:

R1#clear ip bgp *
R1#
*Nov 23 13:59:37.379: %BGP-5-ADJCHANGE: neighbor 150.100.12.2 Down User reset
*Nov 23 13:59:38.039: %BGP-5-ADJCHANGE: neighbor 150.100.12.2 Up
R1#
R1#show ip bgp
BGP table version is 5, local router ID is 200.0.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 150.100.25.0/24 150.100.12.2 0 0 256 i
*> 150.100.69.0/24 150.100.12.2 0 256 i
*> 150.100.96.0/24 150.100.12.2 0 256 i
*> 150.100.100.0/24 150.100.12.2 0 256 i

Anybody know how this command is supposed to work in preventing RIB failures from getting advertised in BGP?

BGP - Local AS notes

2009-02-08T15:34:00.001+05:30

R6[AS256]-----R9[AS9999]=====BB3[AS3561]

We will be looking at the BGP tables of R6 and BB3 as we test each option of the local-as neighbor configuration.

1) LOCAL-AS

R9 has local-as configured with as 19999. R6 sees routes as follows, with 19999 in between BB2 and R9 real AS number.

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999
R9#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?

BB3 sees routes from R9 in the same way, as if AS19999 was connected between itself and R9:

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 9999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 9999 256 i

2) LOCAL-AS NO-PREPEND

With the no-prepend option, R6 does not see 19999 in the path:

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999 no-prepend
R9#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?

This command has no impact on the routes BB3 receives. They look the same.

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 9999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 9999 256 i

3) LOCAL-AS NO-PREPEND REPLACE-AS

With the Replace-as, everything looks the same as the last command on R6.

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999 no-prepend replace-as
R9#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?

However on BB3 we now see a difference as 9999 is no longer in the path.

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 256 i

BGP - Conditional route injection

2009-02-08T15:32:00.000+05:30

R5----R7

R5 is advertising 10.34.19.0/26 to R7
Configure R7 to inject 10.34.19.48/28

1) MAKE PREFIX-LISTS

ip prefix-list EXIST seq 5 permit 10.34.19.0/26
ip prefix-list INJECT 5 permit 10.34.19.48/28
ip prefix-list SOURCE seq 5 permit 192.168.5.5/32

2) MAKE ROUTE-MAPS

route-map INJECT permit 10
set ip address prefix-list INJECT

route-map EXIST permit 10
match ip address prefix-list EXIST
match ip route-source prefix-list SOURCE

3) CONFIGURE BGP

route bgp 567
bgp inject-map INJECT exist-map EXIST

4) VERIFY

R5#show ip bgp nei 192.168.7.7 advertised-routes | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 10.34.19.0/26 192.168.2.2 0 200 0 24 1 i

R7#show ip bgp injected-paths | begin Net
Network Next Hop Metric LocPrf Weight Path
*>i10.34.19.48/28 192.168.5.5 0 200 0 24 1 i

Things to remember:

- Must use Prefix-lists, NOT ACLs
- Injected route must a subset of am aggregate already in the table
- Use "set" command for inject-map, not "match"
- I commonly forget the "prefix-list" argument when configuring the maps
- inject-map Command is a bgp command, not per-neighbor

BGP - fast-external-fallover

2009-02-08T15:31:00.000+05:30

This feature allows the router to bring a BGP session down when the interface to that peer goes down. If you don't want this or are asked to not allow this to happen, you can disable it:

R1 has a neighbor:

R1#show ip bgp sum | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
136.10.12.2 4 200 188 188 38 0 0 01:56:59 4

R1(config)#int f0/0
R1(config-if)#shut

*Dec 7 03:16:21.270: %BGP-5-ADJCHANGE: neighbor 136.10.12.2 Down Interface flap

We can prevent R1 from tearing the session down by disabling fast-external-fallover:

R1#show ip bgp sum | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
136.10.12.2 4 200 196 194 50 0 0 00:00:03 4

R1(config)#router bgp 100
R1(config-router)#no bgp fast-external-fallover
R1(config-router)#int f0/0
R1(config-if)#shut
R1(config-if)#

*Dec 7 03:19:41.386: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Dec 7 03:19:42.386: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
R1(config-if)#^Z

R1#show ip bgp sum | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
136.10.12.2 4 200 196 194 54 0 0 00:00:50 4

Still up:

R1#show ip bgp sum | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
136.10.12.2 4 200 196 195 54 0 0 00:01:29 4

Now the session will come down when the hold time expires. Some things to remember:

-Only works for directly-connected EBGP peers (hence the word "external" in the command)
-I tested with ebgp-multihop peers and it does not have any effect
-Keepalives are use to bring session down
-Also configurable per-interface with ip bgp fast-external-fallover

AS_SET not used in AS Path length comparison

2009-02-08T15:27:00.000+05:30

Routing TCP/IP says that AS_SET is not considered when determining shortest AS_PATH. So I decided to lab it and see for myself. R4 is learning the 192.168.0.0/16 aggregate from R5 and R7 each with differing AS_SET lengths.


R4#sho ip bgp | be Net
   Network          Next Hop     Metric LocPrf Weight Path
*  192.168.0.0/16   192.168.47.7      0             0 7 {8,900} i
*>                  192.168.45.5      0             0 5 {6,600,6000,3033} i

The longest one is winning! AS_SET does count as 1 AS by the way.


R4#sho ip bgp 192.168.0.0
BGP routing table entry for 192.168.0.0/16, version 4
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1         
  7 {8,900}, (aggregated by 7 192.168.78.7)
    192.168.47.7 from 192.168.47.7 (192.168.78.7)
      Origin IGP, metric 0, localpref 100, valid, external
  5 {6,600,6000,3033}, (aggregated by 5 192.168.56.5)
    192.168.45.5 from 192.168.45.5 (192.168.56.5)
      Origin IGP, metric 0, localpref 100, valid, external, best
R4#

All other things being equal it looks like the most recent path is winning. If we clear BGP on R5, R7 would be the most recent:


R5#clear ip bgp *
R5#
R5#
*Mar  1 01:34:11.475: %BGP-5-ADJCHANGE: neighbor 192.168.45.4 Down User reset
*Mar  1 01:34:11.479: %BGP-5-ADJCHANGE: neighbor 192.168.56.6 Down User reset
*Mar  1 01:34:11.667: %BGP-5-ADJCHANGE: neighbor 192.168.56.6 Up 
*Mar  1 01:34:12.287: %BGP-5-ADJCHANGE: neighbor 192.168.45.4 Up 

R4#sho ip bgp | be Net   
   Network          Next Hop     Metric LocPrf Weight Path
*  192.168.0.0/16   192.168.45.5      0             0 5 {6,600,6000,3033} i
*>                  192.168.47.7      0             0 7 {8,900} i
R4#

NTP authentication

2009-02-08T15:26:00.000+05:30

This is scenario 3 dealing with NTP and in this post I will set up NTP authentication. Remember that the purpose is for the client to authenticate the server. First will make sure NTP is synchronized on the client. Next, we will turn on authentication on the client only until the clocks become unsynchronized. Finally, we will configure the server with the appropriate key and make sure the client is synchronized again.

We use the same topology as the other NTP scenarios:
R4, R5 and R6 connected via full mesh frame-relay on subnet 172.12.45.0/24

Let's make sure R6, the master, is synchronized first:

R6#show clock
20:14:37.215 MDT Mon Jun 2 2008

R6#show ntp status | inc Clock is
Clock is synchronized, stratum 2, reference is 127.127.7.1

R4:

R4#show ntp status | in Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

and R5:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

Let's configure authentication on R4:

R4(config)#ntp authenticate
R4(config)#ntp authentication-key 1 md5 cisco
R4(config)#ntp trusted-key 1
R4(config)#ntp server 172.12.45.6 key 1

R4#debug ntp validity
NTP peer validity debugging is on
R4#debug ntp authentication
NTP authentication debugging is on

In a few moments we get these debug messages:

R4(config)#
Jun 3 03:24:49.759: NTP: packet from 172.12.45.6 failed validity tests 10
Jun 3 03:24:49.763: Authentication failed
R4(config)#

What's strange is that R4 is still synchronized with R6:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6

So I waited about 10 minutes (it seemed that long) and now R4 is unsynchronized:

R4#show ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock

Now let's configure NTP authentication on R6:

R6(config)#ntp authenticate
R6(config)#ntp authentication-key 1 md5 cisco

On R4 I will set up some debugging, a lot of the output doesn't make much sense, but here it is:

R4#debug ntp packets
NTP packets debugging is on

!! HERE R4 TRANSMITS A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.711: NTP: xmit packet to 172.12.45.6:
.Jun 3 03:36:10.715: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Jun 3 03:36:10.715: rtdel 0D4E (51.971), rtdsp 05CD (22.659), refid AC0C2D06 (172.12.45.6)
.Jun 3 03:36:10.719: ref CBEF37C1.C8A9606E (20:23:45.783 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.719: org CBEF3A6A.BF8D3204 (20:35:06.748 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: rec CBEF3A6A.C784D317 (20:35:06.779 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: xmt CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.727: Authentication key 1

!! HERE R4 RECEIVES A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.771: NTP: rcv packet from 172.12.45.6 to 172.12.34.4 on FastEthernet0/1:
.Jun 3 03:36:10.775: leap 0, mode 4, version 3, stratum 2, ppoll 64
.Jun 3 03:36:10.779: rtdel 0000 (0.000), rtdsp 0002 (0.031), refid 7F7F0701 (127.127.7.1)
.Jun 3 03:36:10.779: ref CBEF3A89.50E1C8AB (20:35:37.315 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: org CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: rec CBEF3AAA.C3941C78 (20:36:10.763 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.787: xmt CBEF3AAA.C39DD400 (20:36:10.764 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: inp CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: Authentication key 1

R4 is now synchronized:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6
nominal freq is 250.0000 Hz, actual freq is 250.0004 Hz, precision is 2**18
reference time is CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
clock offset is 22.8825 msec, root delay is 59.68 msec
root dispersion is 15897.92 msec, peer dispersion is 15875.02 msec

Let's check R5 to see if it is still synchronized:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

As you can see, R5 is still synchronized because it is not requesting authentication from R6. R4 on the other sends the request with an authentication key and requires that the time-source, R6, does so as well.

Allowing telnet to a non-standard port

2009-02-08T15:25:00.000+05:30

I didn't have time for any of the security tasks in Mock Lab 1. There were 3 for a total of 9 points. Again, the lab sessions run 7:45 and I had to load initial configs and eat dinner! Had I been able to use the full 8 hours, I am sure I would have gotten 1 or 2 of these tasks.

Here is the gist of the first security task, 9.1:

R9 should accept telnet on port 3005.
It should not allow telnet on port 23.
Configure a local user cisco with password of cisco and privilege level 15.
Telnet should require a login, but console access should not

I am going to use R5 as an example since I already have it up in Dynamips. First, to allow telnet on port 3005 use the rotary command:

R5(config)#username cisco privilege 15 password cisco
R5(config-line)#line vty 5
R5(config-line)#rotary 5
R5(config-line)#login local

Next we create an ACL to block telnet to port 23:

R5(config)#access-list 101 deny tcp any any eq telnet
R5(config)#access-list 101 permit ip any any
R5(config)#line vty 0 ?
<1-935> Last Line number

R5(config)#line vty 0 935
R5(config-line)#access-class 101 in

Let's try from R4:

R4#telnet 141.141.45.5
Trying 141.141.45.5 ...
% Connection refused by remote host

R4#telnet 141.141.45.5 3005
Trying 141.141.45.5, 3005 ... Open

User Access Verification

Username: cisco
Password:
R5#

Now we have already satisfied the last requirement right? "Telnet should require a login, but console access should not." But for some reason the proctor guide goes a step further and creates an aaa method for VTY while console uses the default. Here's what they have:

R5(config)#aaa new-model
R5(config)#aaa authentication login VTY local
R5(config)#aaa authentication login default none
R5(config)#line vty 5
R5(config-line)#login authentication VTY

The first command tells the router to enable the aaa commands. The second command defines a login list called VTY. Note that this is not used anywhere until it is applied in the last command. The third command configures that default login method to be "none" or no authentication. This method is applied to the console by default.

PPP Authentication with MD5

2009-02-08T15:24:00.000+05:30

I had a task this weekend that asked to authenticate PPP via Md5. I did a context sensitive help and saw this:


R2(config-if)#ppp authentication ?
chap        Challenge Handshake Authentication Protocol (CHAP)
eap         Extensible Authentication Protocol (EAP)
ms-chap     Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
ms-chap-v2  Microsoft CHAP Version 2 (MS-CHAP-V2)
pap         Password Authentication Protocol (PAP)

Doesn't look like there is an Md5 option...or is there? I looked up the ppp authentication commands in the DocCD:

-12.4 Mainline
-Master Index
-Cisco IOS Master Command List, All Releases
-ppp authentication MWP-147, SEC-1481

Click the SEC-1481 link

Now is where I used the browser search to look for "Md5." Not sure if this is possible in the lab so you may have to quickly scan with your eyes. The only hit comes up under "ppp eap local" command. You will see this phrase:

"In local mode, the EAP session is authenticated using the MD5 algorithm and obeys the same authentication rules as does Challenge Handshake Authentication Protocol (CHAP)."

Voila!

So now that we know what mode we need everything else is easy, and it works just like CHAP. On both sides:


username R5 password cisco

interface Serial1/1
ip address 150.100.25.2 255.255.255.0
encapsulation ppp
ppp authentication eap
ppp eap password 0 cisco
ppp eap local

Always verify just to make sure it's working:


R2#debug ppp authentication

BGP distance command's 3 arguments

2009-02-08T15:23:00.000+05:30

In BGP configuration mode, the distance command has 3 arguments:

R6(config-router)#distance bgp ?
<1-255> Distance for routes external to the AS

R6(config-router)#distance bgp 13 ?
<1-255> Distance for routes internal to the AS

R6(config-router)#distance bgp 13 26 ?
<1-255> Distance for local routes

R6(config-router)#distance bgp 13 26

External BGP and Internal BGP routes are easy enough to understand, but what exactly is the third option "local routes" for and when do you see it?

Here is an example:

R1#show run
!
interface Loopback10
ip address 10.10.10.1 255.255.255.0
!
interface Loopback11
ip address 11.11.11.11 255.255.255.0
!
router bgp 65000
no synchronization
distance bgp 13 26 8
network 10.10.10.0 mask 255.255.255.0
aggregate-address 10.0.0.0 254.0.0.0
!
R1#show ip route

C 172.12.15.0 is directly connected, Serial1/1
C 172.12.123.0 is directly connected, Serial1/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Loopback10
11.0.0.0/24 is subnetted, 1 subnets
C 11.11.11.0 is directly connected, Loopback11
B 10.0.0.0/7 [8/0] via 0.0.0.0, 00:02:02, Null0

The null route gets the "local route" distance when you configure aggregate routes.

IP Accounting for traffic violations

2009-02-08T15:22:00.001+05:30

R6 <---FRAME---> R5 <----ETHERNET---> R3

First step is to create the ACL that blocks traffic. Here will block traffic (and configure accounting) for packets from R6 to R3. IP address 6.6.6.10 is a loopback on R6 being advertised into OSPF to R5 and on to R3. 3.3.3.3 is the loopback on R3.

R5#show run | section access-list 101
access-list 101 deny ip host 6.6.6.10 host 3.3.3.3
access-list 101 permit ip any any

Apply the ACL to the interface where traffic is to be restricted. FastEthernet0/0 is the interface connected to R3's LAN interface. Enable accounting for access-violations on that interface with the command "ip accounting access-violations"

R5#show run int f0/0
Building configuration...

Current configuration : 153 bytes
!
interface FastEthernet0/0
ip address 172.12.34.5 255.255.255.0
ip access-group 101 out
ip accounting access-violations
speed 100
full-duplex
end

Ping from R6 to verify that traffic is blocked:

R6#ping 3.3.3.3 source 6.6.6.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.10
U.U.U
Success rate is 0 percent (0/5)

Verify accounting on R5:

R5#show ip accounting access-violations
Source Destination Packets Bytes ACL
6.6.6.10 3.3.3.3 6 600 101

Accounting data age is 4

The output of the command shows how many packets (6) and bytes (600) were blocked as well as the ACL (101) that blocked them.

IP Accounting for traffic violations

2009-02-08T15:20:00.000+05:30

NTP Access group

2009-02-08T15:19:00.001+05:30

I will call this NTP blog NTP Scenario 2: NTP with access-group filtering.

R4, R5, and R6 are connected via full mesh frame-relay
R6 will be the NTP server.

In scenario 1 we set up R4 to sync to R6. In this scenario we
will prevent R5 from syncing with R6 by using ntp access-group command.

I have never used this command before, so I hope I am understanding it correctly. If not, please let me know how else to test this command.

On R6 we have the following ACL:

access-list 1 permit 172.12.45.4
access-list 1 permit 127.127.7.1

172.12.45.4 is the address of R4. 127.127.7.1 is the IP address that a cisco router uses as it's reference when you make the router an NTP master. This must be added to the ACL or it will become unsynchronized with itself.

In global config mode we enter:

ntp access-group serve-only 1

Let's check the current times:

R5#show clock
16:15:04.031 UTC Sat May 31 2008

R6#show clock
16:31:45.687 UTC Sat May 31 2008

R5 is about 15 minutes behind. I don't know a way to debug on R6 to make sure it's working, so what I will do is wait about 10 minutes then add R5's IP address to ACL. I think 10 minutes is sufficient to prove that R6 is not allowing R5 to sync to it.

...
...

Well it's almost 20 minutes now. Let's check if R4 is synchronized:

R4#show ntp status | inc Cloc
Clock is synchronized, stratum 3, reference is 172.12.45.6

How about R5:

R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock

Some quick show clocks:

R4#show clock
16:49:06.505 UTC Sat May 31 2008

R5#show clock
16:32:29.755 UTC Sat May 31 2008

R6#show clock
16:49:12.335 UTC Sat May 31 2008

R5 is still unsynchronized and more than 15 minutes behind R6. Let's add R5's address to ACL 1 on R6 and see how long it takes to sync...

R6(config)#access-list 1 permit 172.12.45.5

We'll debug on R5:

R5#debug ntp sync
NTP clock synchronization debugging is on
R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock
R5#
May 31 16:33:54.039: NTP: synced to new peer 172.12.45.6

Took less than a minute!

This is the second of many NTP scenarios to come. It really seems so simple, but I have always had problems understanding NTP server/peer relationships and authentication configurations. So these will be the topics of future NTP blogs. Hopefully I (and you!) will become NTP masters in time for CCIE :)

Priority-queuing in Action

2009-02-08T15:18:00.001+05:30

Too see how priotiy-queuing impacts traffic flows, I set up a small lab. R2, R3 and R4 connect to the same LAN as R5. R5 connects to R6. Each router has a loopback x.x.x.x where x is the router number.

R2
\
R3-------f0/0 R5 s1/1 ----R6
/
R4

On R5 we make 3 ACLs:

R5(config)#access-list 102 permit icmp host 2.2.2.2 host 6.6.6.6
R5(config)#access-list 103 permit icmp host 3.3.3.3 host 6.6.6.6
R5(config)#access-list 104 permit icmp host 4.4.4.4 host 6.6.6.6

Now we assign each ACL to a priority-list

R5(config)#priority-list 1 protocol ip high list 102
R5(config)#priority-list 1 protocol ip medium list 103
R5(config)#priority-list 1 protocol ip normal list 104

Assign the priority-list to the interface with the priority-group command:

R5(config)#int s1/1
R5(config-if)#priority-group 1

Now let's verify the priority queuing is working.

Below we get a baseline and see that R3 normally gets an average round trip time of 34-38 ms for 200 pings. When R2 starts sending traffic, we can see the R3 round trip average (and max time) increase about 50%.

R3 pings, R2 is silent:

R3#ping 6.6.6.6 source 3.3.3.3 repeat 200

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Success rate is 100 percent (200/200), round-trip min/avg/max = 4/34/188 ms

R3#ping 6.6.6.6 source 3.3.3.3 repeat 200

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Success rate is 100 percent (200/200), round-trip min/avg/max = 4/38/104 ms

R3 and R2 both send pings (I started sending 250 1200-byte packets from R2 first, then quickly hopped over to R3 and started the ping)

R3#ping 6.6.6.6 source 3.3.3.3 repeat 200

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Success rate is 100 percent (200/200), round-trip min/avg/max = 4/57/220 ms

R3#ping 6.6.6.6 source 3.3.3.3 repeat 200

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Success rate is 100 percent (200/200), round-trip min/avg/max = 8/66/368 ms

Notice how much higher the avg and max times are for R3 when R2 is pinging R6. We can see directly how priority-queuing impacts traffic flows.

R.E.F.L.E.C.T

2009-02-08T15:17:00.002+05:30

R1 --INSIDE--> R4 --OUTSIDE--> R5

We are going to apply a reflexive ACL on R4 to permit outgoing telnet, web and ping traffic.

Let's go to R4 and create our outbound ACL with the keyword "reflect" used to create our reflexive ACL.

R4(config)#ip access-list extended OUTBOUND
R4(config-ext-nacl)#permit tcp any any eq 23 reflect ?
WORD Access-list name
R4(config-ext-nacl)#permit tcp any any eq 23 reflect MIRROR
R4(config-ext-nacl)#permit tcp any any eq 80 reflect MIRROR
R4(config-ext-nacl)#permit icmp any any echo reflect MIRROR
R4(config-ext-nacl)#exit

Next we "evaluate" the reflexive ACL on our inbound ACL (note that I am doing OSPF between R4 and R5 and I don't want the adjacency to break).

R4(config)#ip access-list extended INBOUND
R4(config-ext-nacl)#evaluate MIRROR
R4(config-ext-nacl)#permit ospf any any
R4(config-ext-nacl)#deny ip any any log
R4(config-ext-nacl)#exit
R4(config)#

Apply these ACLs inbound and outbound on your outside interface, in my case S1/0:

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

Let's do some telnetting from R1 to R5

R1#telnet 155.1.5.5
Trying 155.1.5.5 ... Open

User Access Verification

Username: cisco

Flip over to R4 for Verification:

R4#show ip access-lists MIRROR
Reflexive IP access list MIRROR
permit tcp host 155.1.5.5 eq telnet host 155.1.4.4 eq 58347 (51 matches) (time left 298)
R4#

Let's examine the ACL MIRROR, The source is our telnet destination (the device we are telnetting to). This ACL is being used inbound on our outside interface to allow return traffic. Also I should note that R4 is doing NAT, with 155.1.4.4 being the translated address of R1's actual interface address (10.0.0.1). So you can see reflexive ACL's are very neat because they automatically allow for return traffic while we filter inbound and outbound.

CBAC Example

2009-02-08T15:17:00.001+05:30

Context-Based access control is another way to dynamically modify access-lists on the fly to allow return traffic. Here we configure a simple example that allows FTP traffic as well as PING from inside to outside. First let's apply an ACL inbound on R4 serial 1/0 and see what happens we ping from R1 to R5:

R1 --INSIDE--> R4 s1/0 --OUTSIDE--> R5

On R4:

ip access-list extended INBOUND
permit ospf any any
deny ip any any log
interface Serial1/0
ip access-group INBOUND in

Now from R1:

R1#ping 155.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.5.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#

Now on R4 we add the following CBAC configuration:

ip inspect name CBAC ftp
ip inspect name CBAC tcp router-traffic
ip inspect name CBAC icmp router-traffic

interface Serial1/0
ip inspect CBAC out

Now back to R1:

R1#ping 155.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/115/268 ms
R1#

Verify on R4 (Do this quick or the session will be gone)

R4#show ip inspect sessions
Established Sessions
Session 659A79DC (10.0.0.1:8)=>(155.1.5.5:0) icmp SIS_OPEN
R4#

I tried testing ftp but for some reason the "ftp-server enable" doesn't seem to exist in my IOS with is 12.4 ADVENT. Anyways, that should give you a quick idead of how CBAC is used to punch holes in ACLs for return traffic.

Also remember that we DENY traffic INBOUND on the OUTSIDE interface if we want to inspect it in the OUTBOUND direction.

TCP Intercept - Watch vs Intercept

2009-02-08T15:16:00.001+05:30

TCP Intercept is used to prevent DoS attacks where the attacker tries to use up all the TCP resources by sending SYN packets and then never replying to the SYN-ACK (the source is spoofed which is why the attacker doesn't respond). Here we configure R4 to detect this attack and prevent it by dropping these "half-open" connections. I am not sure how to spoof an address from a Cisco router, so we'll just configure TCP intercept and do some monitoring.

[R5]---[R4]---[R1]

10.0.0.0 is the LAN address range between R1 and R4. We'll create an ACL that matches telnet traffic from R5 to R1. R1 in this case is the server we want to protect from the SYN Attack.

R4(config)#access-list 100 permit tcp any 10.0.0.0 0.0.0.255 eq 23

R4(config)#ip tcp intercept ?
connection-timeout Specify timeout for connection info
drop-mode Specify incomplete connection drop mode
finrst-timeout Specify timeout for FIN/RST
list Specify access-list to use
max-incomplete Specify maximum number of incomplete connections before clamping
mode Specify intercepting mode
one-minute Specify one-minute-sample watermarks for clamping
watch-timeout Specify timeout for incomplete connections in watch mode

R4(config)#ip tcp intercept list 100
R4(config)#ip tcp intercept max-incomplete high 200
R4(config)#ip tcp intercept max-incomplete low 150
R4(config)#ip tcp intercept connection-timeout 60
R4(config)#ip tcp intercept drop-mode random

Debugging and Verification:

R4#debug ip tcp intercept
TCP intercept debugging is on

*Mar 1 06:28:33.866: INTERCEPT: new connection (155.1.45.5:31039 SYN -> 10.0.0.1:23)
*Mar 1 06:28:33.874: INTERCEPT(*): (155.1.45.5:31039 <- ACK+SYN 10.0.0.1:23)
*Mar 1 06:28:33.954: INTERCEPT: 1st half of connection is established (155.1.45.5:31039 ACK -> 10.0.0.1:23)
*Mar 1 06:28:33.958: INTERCEPT(*): (155.1.45.5:31039 SYN -> 10.0.0.1:23)
*Mar 1 06:28:34.034: INTERCEPT: 2nd half of connection established (155.1.45.5:31039 <- ACK+SYN 10.0.0.1:23)
*Mar 1 06:28:34.038: INTERCEPT(*): (155.1.45.5:31039 ACK -> 10.0.0.1:23)
*Mar 1 06:28:34.042: INTERCEPT(*): (155.1.45.5:31039 <- WINDOW 10.0.0.1:23)

I don't like the output above. I expected to see R4's address somewhere in the output since it is "intercepting" the connections. Perhaps I am misunderstanding this...both "halves" look the same to me.

Anyways, here's a show command:

R4#show tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode

Established:
Client Server State Create Timeout Mode
155.1.45.5:31039 10.0.0.1:23 ESTAB 00:00:49 00:59:14 I
R4#

Now let's see what it looks like in watch mode:

R4(config)#ip tcp intercept mode watch

R4#
*Mar 1 06:30:58.082: INTERCEPT: new connection (155.1.45.5:12568 SYN -> 10.0.0.1:23)
*Mar 1 06:30:58.182: INTERCEPT: (155.1.45.5:12568 <- ACK+SYN 10.0.0.1:23)
*Mar 1 06:30:58.310: INTERCEPT: (155.1.45.5:12568 ACK -> 10.0.0.1:23)
R4#show tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode

Established:
Client Server State Create Timeout Mode
R4#

Notice that "show tcp intercept connections" only gives output when the router is in intercept mode.

Prefix-lists vs ACLs

2009-02-08T15:14:00.000+05:30

Many people prefer prefixes-lists over ACLs because they give you more preciseness over which routes to allow. This blogs goes over some examples between the two methods using RIP and distribute-lists.

The Network:

R1----R2----R3

Each router is connected to its own LAN, call them LAN1,LAN2 and LAN3

Addressing:

R1-R2 = 12.0.0.0/8
R2-R3 = 13.0.0.0/8
LAN1 = 1.0.0.1/8
LAN2 = 2.0.0.2/8
LAN3 = 3.0.0.0/16

R3 also has 4 loopbacks:

3.1.0.3/16
3.2.0.3/16
3.3.0.3/16
3.4.0.3/16

RIP is enabled everywhere so that R1 has the following route table:

R1#show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
R 2.0.0.0/8 [120/2] via 13.0.0.3, 00:00:06, Serial1/1
3.0.0.0/16 is subnetted, 5 subnets
R 3.3.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 3.2.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 3.1.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 3.0.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 3.4.0.0 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 23.0.0.0/8 [120/1] via 13.0.0.3, 00:00:06, Serial1/1
R 12.0.0.0/8 [120/2] via 13.0.0.3, 00:00:06, Serial1/1
C 13.0.0.0/8 is directly connected, Serial1/1

Let's say I create a prefix-list like this:

R3(config)#ip prefix-list NET3 permit 3.0.0.0/8

Then apply the distribute list:

R3(config)#router rip
R3(config-router)#distribute-list prefix NET3 out

R1 will have no routes to any of the 3 networks:

R1# show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
C 13.0.0.0/8 is directly connected, Serial1/1

But if we use the same matching principle (3.0.0.0/8) in an ACL, then R3 has all the 3.0.0.0 routes:

R3(config)#router rip
R3(config-router)#no distribute-list prefix NET3 out
R3(config-router)#exit
R3(config)#access-list 3 permit 3.0.0.0 0.255.255.255
R3(config)#router rip
R3(config-router)#distribute-list 3 out

R1#clear ip route *
R1# show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
3.0.0.0/16 is subnetted, 5 subnets
R 3.3.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
R 3.2.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
R 3.1.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
R 3.0.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
R 3.4.0.0 [120/1] via 13.0.0.3, 00:00:01, Serial1/1
C 13.0.0.0/8 is directly connected, Serial1/1

The reason this happens is because prefix-lists match on the exact route subnet length unless the ge or le arguments are added. To make the prefix-list perform like the ACL we can do this:

R3(config)#router rip
R3(config-router)#no distribute-list 3 out
R3(config-router)#exit
R3(config)#no ip prefix-list NET3 permit 3.0.0.0/8
R3(config)#ip prefix-list NET3 permit 3.0.0.0/8 ge 9
R3(config)#router rip
R3(config-router)#distribute-list prefix NET3 out

R1#clear ip route *
R1# show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
3.0.0.0/16 is subnetted, 5 subnets
R 3.3.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
R 3.2.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
R 3.1.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
R 3.0.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
R 3.4.0.0 [120/1] via 13.0.0.3, 00:00:00, Serial1/1
C 13.0.0.0/8 is directly connected, Serial1/1

The prefix-lists matches the first 8 bits of a prefix and then matches any of those prefixes that have masks of 9 bits or longer. If we wanted the ACL to perform like the prefix-list we could do this:

R3(config)#access-list 13 permit 3.0.0.0 0.0.0.0
R3(config)#router rip
R3(config-router)#no distribute-list prefix NET3 out
R3(config-router)#distribute-list 13 out

R1# show ip route | begin Ga
Gateway of last resort is not set

1.0.0.0/16 is subnetted, 1 subnets
C 1.0.0.0 is directly connected, FastEthernet0/0
3.0.0.0/16 is subnetted, 1 subnets
R 3.0.0.0 [120/1] via 13.0.0.3, 00:00:02, Serial1/1
C 13.0.0.0/8 is directly connected, Serial1/1

Now R1 has the route to 3.0.0.0, but notice it has no regard for the subnet length as the prefix-lists does. In other words, the above ACL 13 would match 3.0.0.0/8, 3.0.0.0/9, etc.

ACL Allowing telnet to a non-standard port

2009-02-08T15:13:00.000+05:30

Here is the gist of the first security task, 9.1:

R9 should accept telnet on port 3005.
It should not allow telnet on port 23.
Configure a local user cisco with password of cisco and privilege level 15.
Telnet should require a login, but console access should not

I am going to use R5 as an example since I already have it up in Dynamips. First, to allow telnet on port 3005 use the rotary command:

R5(config)#username cisco privilege 15 password cisco
R5(config-line)#line vty 5
R5(config-line)#rotary 5
R5(config-line)#login local

Next we create an ACL to block telnet to port 23:

R5(config)#access-list 101 deny tcp any any eq telnet
R5(config)#access-list 101 permit ip any any
R5(config)#line vty 0 ?
<1-935> Last Line number

R5(config)#line vty 0 935
R5(config-line)#access-class 101 in

Let's try from R4:

R4#telnet 141.141.45.5
Trying 141.141.45.5 ...
% Connection refused by remote host

R4#telnet 141.141.45.5 3005
Trying 141.141.45.5, 3005 ... Open

User Access Verification

Username: cisco
Password:
R5#

Now we have already satisfied the last requirement right? "Telnet should require a login, but console access should not." But for some reason the proctor guide goes a step further and creates an aaa method for VTY while console uses the default. Here's what they have:

R5(config)#aaa new-model
R5(config)#aaa authentication login VTY local
R5(config)#aaa authentication login default none
R5(config)#line vty 5
R5(config-line)#login authentication VTY

The first command tells the router to enable the aaa commands. The second command defines a login list called VTY. Note that this is not used anywhere until it is applied in the last command. The third command configures that default login method to be "none" or no authentication. This method is applied to the console by default.

ACL - Lock and Key

2009-02-08T15:08:00.000+05:30

Here is the example I am following, pretty much to a T, except I am doing BGP for routing protocol and the topology is different.

Lock-and-Key: Dynamic Access Lists

Here is my topology:

[R1]----[R2]----[R3]

The goal is to prevent R1 from telnetting to R3 (172.12.23.3) unless it has authenticated to R2 first, via telnet. All configuration is on R2, but remember to configure your vty on R3.

First create a username and password on R2

R2(config)#username test password test

Next setup the router to allow access once telnet session is established:

R2(config)#line vty 0 4
R2(config-line)#autocommand access-enable
R2(config-line)#login local

Next create and apply the the ACL. Note that I am using BGP for a routing protocol and I need to allow that before anything else is configured.

R2(config)#access-list 120 permit tcp any any eq bgp
R2(config)#access-list 120 permit tcp any eq bgp any eq bgp
R2(config)#access-list 120 dynamic testlist timeout 15 permit ip any any
R2(config)#access-list 120 permit tcp any host 172.12.12.2 eq telnet
R2(config)#int s1/0
R2(config-if)#ip access-group 120 in

Let's try to telnet to R1 from R3:

R1#telnet 172.12.23.3
Trying 172.12.23.3 ...
% Destination unreachable; gateway or host down

R1#

Now let's telnet to R2 first, notice that our session gets dropped immediately:

R1#telnet 172.12.12.2
Trying 172.12.12.2 ... Open

User Access Verification

Username: test
Password:
[Connection to 172.12.12.2 closed by foreign host]
R1#

Now let's try and telnet to R3:

R1#telnet 172.12.23.3
Trying 172.12.23.3 ... Open

User Access Verification

Password:
R3>

Perfect! Some things to remember about lock and key are:

1) always allow your routing protocol at the top (lines 1 and 2 of the ACL)
2) allow telnet to the local router interface (line 4 of the above ACL)

Even and Odd matching in ACLs

2009-02-08T15:07:00.000+05:30

The rest of this blog will just be examples with short explanations. I will use the word "match" as opposed to "permit" or "deny." Once you now the correct bit pattern you can just insert it into your ACL as necessary.

1) Match the networks with an odd numbered 3rd octet.

Starting off, we don't care about the first, second or third octets so we have:

0.0.x.0 255.255.x.255

The x will be for matching odd numbered networks. All odd numbered networks have one thing in common, they have a 1 in the right-most bit. So now we have:

0.0.1.0 255.255.x.255

Now we need to make sure our wildcard mask matches all networks with a 1 in the right-most bit. In other words, we "care" to match this bit. We don't care about any other bits in this octet so we set them to 1. Now we have:

0.0.1.0 255.255.254.255

2) Match all even networks in the 3rd octect.

What do all even-numbered networks have in common? A 0 in the right-most bit. So we have:

0.0.0.0 255.255.254.255

3) Match odd numbered-networks in the second octet.

Same as example 1 except we are in the 2nd octet.

0.1.0.0 255.254.255.255

Extended ping with TOS byte

2009-02-08T15:06:00.000+05:30

Here is the scenario:

R2---R6---R7

R6 is only supposed to allow traffic with an IP precedence level of critical to R7. Easy right? Well with extended ping you can verify that it is working.

On R6 we the following ACL applied to the interface towards R7:

access-list 101 permit ospf any any
access-list 101 permit ip any any precedence critical log
access-list 101 deny ip any any log

The only traffic being allowed is ospf to maintain the adjacency with R7 and "critical" IP traffic.

For our extended ping we need to find the hex value of the critical precedence. Critical is precedence 5 which in the ToS byte would break out to 101 000 00. We can align it like this:

1010 0000

This is equal to hex value 0xA0 (the first four bits are 10 which is A, the last 4 are 0). So here is our first ping which fails:

R2#ping 150.100.220.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.220.7, timeout is 2 seconds:
U.U.
Success rate is 0 percent (0/4)

Now we send the extended ping with ToS value 0xA0

R2#ping
Protocol [ip]:
Target IP address: 150.100.220.7
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 0xA0
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.220.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms
R2#

On R6 we can verify the matches:

R6#show access-lists 101
Extended IP access list 101
10 permit ospf any any (1 match)
20 permit ip any any precedence critical log (5 matches)
30 deny ip any any log (44 matches)

Making a VLAN IPv6

2009-02-08T15:05:00.001+05:30

Here is the simple topology for this lab. R1 and R2 are on VLAN 12. VLAN12 needs to be IPv6 only. We test this my assigning IPv4 and IPv6 addresses to both routers and then pinging.

R1---SW1---SW2---R2

R1:

IPv4: 192.168.12.1/24
IPv6: 2001::1/64

R2:

IPv4: 192.168.12.2/24
IPv6: 2001::2/64

Making a vlan IPv6 only requires more configuration than I previously thought. This was my first attempt. On all switches:

mac access-list extended IPv6
permit any any 0x86DD 0x0
vlan access-map IPv6only 10
action forward
match mac address IPv6
vlan filter IPv6only vlan-list 12

So R1 pings R2:

R1#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 192.168.12.2

But wait, let's remove the filter, ping, add the filter back, and ping again.

SW1(config)#no vlan filter IPv6only vlan-list 12

R1#ping 192.168.12.2

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

SW1(config)#vlan filter IPv6only vlan-list 12

R1#ping 192.168.12.2

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

R1 can still ping. What happened? Well the original filter wasn't blocking IP, it was only blocking ARP packets. Remember MAC access-lists do not have an implicit deny for the IP ethertype but they do have an implicit deny for all the other ethertypes. So once we removed the filter and allowed ARP through, R1 was able to ping R2 when the filtered was applied.

To make the vlan IPv6 only I had to specify a drop action in an empty access-map statement:

SW1(config)#vlan access-map IPv6only 20
SW1(config-access-map)# action drop

R1#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#

But wait, let's check out spanning-tree:

SW1#sho spanning-tree vlan 12 | inc root
This bridge is the root
SW2#show spanning-tree vlan 12 | inc root
This bridge is the root

This is bad because both switches forward out all ports when they think they are root. If we had multiple links between these switches, we would have a loop. You may start seeing these messages:

SW2#
01:28:49: %SW_MATM-4-MACFLAP_NOTIF: Host 00b0.6410.3901 in vlan 12 is flapping between port Fa0/13 and port Fa0/14
01:28:49: %SW_MATM-4-MACFLAP_NOTIF: Host 0007.eb14.4f81 in vlan 12 is flapping between port Fa0/13 and port Fa0/14

We need to allow STP bpdu's in our original MAC access-list. Do this now:

SW1(config)#mac access-list extended IPv6
SW1(config-ext-macl)#permit any any lsap 0xAAAA 0x0

Now we see SW2 blocking on the port f0/14 (for VLANs 1 and 12):

SW2#sho span | inc BLK
Fa0/14 Altn BLK 19 128.16 P2p
Fa0/14 Altn BLK 19 128.16 P2p

Verify R1 can ping R2 via IPv6 and not IPv4:

R1#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 2001::2

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

I used 0xAAAA because this what lsap type PVST uses. I don't know where I got this but I think I saw it on GS somehwere. I have also seen 0x4242 used but I think this is for normal STP (802.1d). In any case, only the 0xAAAA worked for me.

Finding out port numbers with NBAR show commands

2009-02-08T15:02:00.000+05:30

I had a filtering task that said to allow H323 Traffic to a specific vlan. Well...what ports does H323 use? I could not find it on the DocCD but I remembered a show command that will let us know:


R1#sho ip nbar port-map h323 
port-map h323       udp 1300 1718 1719 1720 11720 
port-map h323       tcp 1300 1718 1719 1720 11000 - 11999

3560 QoS DSCP mutation

2009-02-08T14:58:00.000+05:30

Here is the topology (it's a mutated iewb topology)

R4====SW2====SW1====SW3---[int vlan 201,202]

R4 is trunk link carrying vlan 201,202:

interface Ethernet0/0.201
encapsulation dot1Q 201
ip address 155.1.201.4 255.255.255.0
!
interface Ethernet0/0.202
encapsulation dot1Q 202
ip address 155.1.202.4 255.255.2550

SW3 has two SVIs:

interface Vlan201
ip address 155.1.201.9 255.255.255.0

interface Vlan202
ip address 155.1.202.9 255.255.255.0

Other links are all dot1q trunks passing vlan 201 and 202.

1. SET UP SW2 TO CLASSIFY AND MARK

mls qos

access-list 1 permit 155.1.201.0 0.0.0.255
access-list 2 permit 155.1.202.0 0.0.0.255

class-map match-all VLAN202
match access-group 2
class-map match-all VLAN201
match access-group 1

policy-map MARK
class VLAN201
set precedence 1
class VLAN202
set precedence 2

interface FastEthernet0/4
service-policy input MARK

2. ON SW3 TRUST AND MONITOR QOS

mls qos

int f0/13
mls qos trust dscp
mls qos monitor dscp 0 8 16 24 32

SW3# show mls qos int f0/13 st
FastEthernet0/13
Ingress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 19 19 200 0 0
8 : 200 100 0 0 0
16: 200 100 0 0 0
24: 0 0 0 0 0
32: 0 0 0 0 0
Others: 0 0 0 0 0
Egress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 200 n/a n/a 0 0
8 : 100 n/a n/a 0 0
16: 100 n/a n/a 0 0
24: 0 n/a n/a 0 0
32: 0 n/a n/a 0 0
Others: 283 n/a n/a 0 0

You can see that we already have traffic coming in as DSCP 8 and 16. We will be mutating these on SW1.

3. CONFIGURE DSCP-to-DSCP MUTATION ON SW1

mls qos
mls qos map dscp-mutation MAP1 8 to 24
mls qos map dscp-mutation MAP1 16 to 32
int f0/13
mls qos trust dscp
mls qos dscp-mutation MAP1

4. PING FROM R4 to SVI on SW3

R4#ping 155.1.202.9 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 155.1.202.9, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms
R4#ping 155.1.201.9 re 100

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

5. VERIFY MUTATION ON SW3

SW3# show mls qos int f0/13 st
FastEthernet0/13
Ingress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 194 194 200 0 0
8 : 600 500 0 0 0
16: 700 600 0 0 0
24: 100 100 0 0 0
32: 100 100 0 0 0
Others: 0 0 0 0 0
Egress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 200 n/a n/a 0 0
8 : 500 n/a n/a 0 0
16: 600 n/a n/a 0 0
24: 100 n/a n/a 0 0
32: 100 n/a n/a 0 0
Others: 2674 n/a n/a 0 0

3560 QoS VLAN-Based Classification

2009-02-08T14:57:00.000+05:30

Comparing Traffic Policing Features in the 3550 and 3560 switches

I have the following topology:

R1----|
R3---SW1---SW2---R2
R5----|

R1,R3 are in vlan 100, 192.168.100.0/24
R5 is in vlan 200, 192.168.200.0/24

R2 is on a trunked port with the following configuration:


interface Ethernet0/0.100
 encapsulation dot1Q 100
 ip address 192.168.100.2 255.255.255.0
 ip accounting precedence input
 no snmp trap link-status
!
interface Ethernet0/0.200
 encapsulation dot1Q 200
 ip address 192.168.200.2 255.255.255.0
 ip accounting precedence input
 no snmp trap link-status

On SW2 we will enable vlan-based qos and then mark traffic based on ACLs. First we make the ACLs:


ip access-list extended ICMP
 permit icmp any any
ip access-list extended TCP
 permit tcp any any

Next we make our class-maps and policy-maps:


class-map match-all ICMP
  match access-group name ICMP
class-map match-all TCP
  match access-group name TCP

policy-map VLAN
  class TCP
   set ip precedence 5
  class ICMP
   set ip precedence 3

Next enable mls qos, vlan-based qos and apply the policy to an SVI. Note that the SVI does not need an IP address:


mls qos

int f0/13
 interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 50
 switchport mode trunk
 mls qos vlan-based

int vlan 100
 service-policy input VLAN
int vlan 200
 service-policy input VLAN

Now run some tests. Here I Ping and Telnet from R5, telnet from R1 and then ping from R3:


R5#ping 192.168.200.2 rep 100

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

R5#telnet 192.168.200.2
Trying 192.168.200.2 ... Open

R2>exit

[Connection to 192.168.200.2 closed by foreign host]
R5#

R1#telnet 192.168.100.2 
Trying 192.168.100.2 ... Open

R2>exit

[Connection to 192.168.100.2 closed by foreign host]
R1#

R3#ping 192.168.100.2 re 50

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 1/3/4 ms
R3#

Verify on R2:


R2#sho int precedence 
Ethernet0/0.100 
  Input
    Precedence 3:  50 packets, 5900 bytes
    Precedence 5:  46 packets, 2953 bytes
Ethernet0/0.200 
  Input
    Precedence 3:  100 packets, 11800 bytes
    Precedence 5:  15 packets, 969 bytes
R2#

3560 QoS Per-port per-vlan policing

2009-02-08T14:55:00.000+05:30

Per-van policing in the 3560s is different from the 3550s because there is no "match VLAN" clause available. Instead you create hierarchical policies and attach them to the SVI.

Here is the scenario:

VLAN100 will be policed to 64k (192.168.100.0/24)
VLAN200 Will be policed to 128k (192.168.200.0/24)

Because of bursts, I was not able to get these exact rates, but you will see how these policies are applied and the effect they have on traffic flow. Plus you can always play with the burst sizes on your own :)

Here is the tracker I created on R2:


access-list 1 permit 192.168.100.1
access-list 1 permit 192.168.100.3
access-list 2 permit 192.168.200.5
!
class-map match-any VLAN100
 match access-group 1
class-map match-any VLAN200
 match access-group 2
!
policy-map TRACKER
 class VLAN100
 class VLAN200
!
interface Ethernet0/0
 no ip address
 load-interval 30
 full-duplex
!
interface Ethernet0/0.100
 encapsulation dot1Q 100
 ip address 192.168.100.2 255.255.255.0
 service-policy input TRACKER
!
interface Ethernet0/0.200
 encapsulation dot1Q 200
 ip address 192.168.200.2 255.255.255.0
 service-policy input TRACKER

All configuration is being done on SW2. There really is not an order of operations to follow, but basically you just need to make sure class-maps and policy-maps are created before you apply them. The logical flow is what you want to get used to. Otherwise you will be jumping into and out of classes and policies, reconfiguring them like I did :)

At our child (aka "second") level we have a class-map that matches the interface and we have our policer. The interface matching here is whats is referred into in the first clause of "per-port per-vlan" policing.


class-map match-all TRUNK
  match input-interface  FastEthernet0/13
!
policy-map VLAN100-POLICER
  class TRUNK
    police 64000 12000 exceed-action drop
policy-map VLAN200-POLICER
  class TRUNK
    police 128000 24000 exceed-action drop

As far as I know, this "bottom" or "second" level class-map can only match input-interface. And this second level policy must be a policer.

Now, at the parent level we create a new class to match IP traffic and then apply our child polices below that. This top-level class must match an ACL (match protocol ip gave me errors when applying the policy).


access-list 100 permit ip any any
!
class-map match-all IP
  match access-group 100
!
policy-map VLAN100-PARENT
  class IP
   set ip precedence 1
   service-policy VLAN100-POLICER
policy-map VLAN200-PARENT
  class IP
   set ip precedence 2
   service-policy VLAN200-POLICER

Notice that I have the "set ip precedence" clause in our parent policies. These first level policies are required to have an action. You will get an error message stating this if you try to apply it to the SVI without an action:

SW2(config)#int vlan 100
SW2(config-if)#service-policy input VLAN100-PARENT
%QoS: No action is configured in the policymap VLAN100-PARENT classmap IP, or it is being modified.

So make sure you have set or trust clause in there. Now we can apply them to the SVIs:


mls qos
!
interface FastEthernet0/13
 mls qos vlan-based
!
interface Vlan100
 no ip address
 service-policy input VLAN100-PARENT
!
interface Vlan200
 no ip address
 service-policy input VLAN200-PARENT

From R1, R3 and R5 I will send a bunch of pings to R2:


R1#ping 192.168.100.2 re 1000000
R3#ping 192.168.100.2 re 1000000
R5#ping 192.168.200.2 re 1000000

Let's look at R2 after a few minutes.


R2#sho policy-map interface e0/0.100 | section VLAN100
    Class-map: VLAN100 (match-any)
      107819 packets, 12722642 bytes
      30 second offered rate 50000 bps
      Match: access-group 1
        107819 packets, 12722642 bytes
        30 second rate 50000 bps

R2#sho policy-map interface e0/0.200 | section VLAN200
    Class-map: VLAN200 (match-any)
      156873 packets, 18511014 bytes
      30 second offered rate 107000 bps
      Match: access-group 2
        156873 packets, 18511014 bytes
        30 second rate 107000 bps

We don't see the limits of 64k and 128k being reached, but the drops on the senders indicate that policing is working. And we can also tell VLAN 200 is getting roughly twice the bandwidth that VLAN 100 is getting. We could get closer to the limit by adjusting the burst sizes appropriately.

Key things to remember:

Child classes use match input-interface
Child policies use police
Parent classes match ACL (I think you can also match dscp, maybe others)
Parent policies must have an action (e.g. set or trust)
Apply parent policies to SVI

I strongly recommend getting your hands dirty with these configurations if you want to master them. I read a lot about switch qos, but it wasn't until I started playing around with scenarios like this that I got a better understanding of how to do it and what is required. If we truly understand what each QoS method does, then we should have no trouble deciphering what we are asked to do on the lab :)

3550 QoS - Trusting, Mapping and Override

2009-02-08T14:52:00.000+05:30

Here's the network:

[R2]---[SW3]---[trunk, native vlan 1]---[SW4]---[R4 ]

R2 sets ip-prec to 2:

interface FastEthernet0/0
ip address 192.168.0.2 255.255.255.0
rate-limit output 16000 8000 8000 conform-action set-prec-transmit 2 exceed-action set-prec-transmit 2

Packet capture show packets still marked when they reach R4 (using Dyngen for routers, binding them to NICs on the PC and then connecting them to the 3550's).

As soon as I enable mls qos on SW3, packets are no longer marked:

SW3(config)#mls qos

To get the 3550 to keep the marking I configure qos trust on the incoming ports:

SW3(config)#int f0/2
SW3(config-if)#mls qos trust

To get the switch to remark the packets, configure cos override:

SW3(config)#int f0/2
SW3(config-if)#mls qos cos override
SW3(config-if)#mls qos cos 4

These packets show up as CS4 on R4. Note that the override command removes the trust command and vice versa:

SW3(config)#int f0/2
SW3(config-if)#mls qos trust

SW3#show run int f0/2
!
interface FastEthernet0/2
switchport mode dynamic desirable
mls qos cos 4
mls qos trust dscp
end

If the trust and "mls qos cos 4" commands exist, the trust takes effect and will not override the DSCP. So the COS4 override mapped to CS4...where does this mapping take place? Here:

SW3#show mls qos maps cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 48 56

Suppose we want COS4 to be mapped to AF41...which is DSCP 34. We can do this:

SW3(config)#mls qos map cos-dscp ?
<0-63> 8 dscp values separated by spaces
SW3(config)#mls qos map cos-dscp 0 8 16 24 34 40 48 56

Here's part of my wireshark capture in plain text:

Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.2 (192.168.0.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x88 (DSCP 0x22: Assured Forwarding 41; ECN: 0x00)
1000 10.. = Differentiated Services Codepoint: Assured Forwarding 41 (0x22)

Ok here's an interesting one: what happens if I configure QoS on SW4 and set it to trust the COS instead of the DSCP value?

SW4(config)#int f0/24
SW4(config-if)#mls qos trust ?
cos Classify by packet COS
device trusted device class
dscp Classify by packet DSCP
ip-precedence Classify by packet IP precedence

SW4(config-if)#mls qos trust cos

It remarks the packet to CS4 based on the cos-dscp map, of course!