CCIE TO BE

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 

Sweet!

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.

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)

I used to think think this was a pretty difficult topic, but now it seems a lot easier once you break it down the right way. When dealing with even and odd filtering we are only concerned with 1 bit! That is the right-most bit of whatever octet the question is having you focus on. Sometimes questions can be vague so I would say it's a good idea to ask a proctor what octet you need to filter if it's ambiguous.

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

4) and so on, you should get the idea by now :)

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)

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.

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.

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.

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.

Here's the topology:

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.

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.

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 :)

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.

Atom

Atom