Jan 22, 2010

Context-Based Access Control (CBAC)


Introduction

The Context-Based Access Control (CBAC) feature of the Cisco IOS® Firewall Feature Set actively inspects the activity behind a firewall. CBAC specifies what traffic needs to be let in and what traffic needs to be let out by using access lists (in the same way that Cisco IOS uses access lists). However, CBAC access lists include ip inspect statements that allow the inspection of the protocol to make sure that it is not tampered with before the protocol goes to the systems behind the firewall.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Background Information

CBAC can also be used with Network Address Translation (NAT), but the configuration in this document deals primarily with pure inspection. If you perform NAT, your access lists need to reflect the global addresses, not the real addresses.
Prior to configuration, consider these questions.

What Traffic Do You Want to Let Out?

What traffic you want to let out depends on your site security policy, but in this general example everything is permitted outbound. If your access list denies everything, then no traffic can leave. Specify outbound traffic with this extended access list:
access-list 101 permit ip [source-network] [source-mask] any
access-list 101 deny ip any any

What Traffic Do You Want to Let In?

What traffic you want to let in depends on your site security policy. However, the logical answer is anything that does not damage your network.
In this example, there is a list of traffic that seems logical to let in. Internet Control Message Protocol (ICMP) traffic is generally acceptable, but it can allow some possibilities for DOS attacks. This is a sample access list for incoming traffic:

Extended IP Access List 101

permit tcp 10.10.10.0 0.0.0.255 any (84 matches)
permit udp 10.10.10.0 0.0.0.255 any
permit icmp 10.10.10.0 0.0.0.255 any (3 matches)
deny ip any any

Extended IP Access List 102

permit eigrp any any (486 matches)
permit icmp any 10.10.10.0 0.0.0.255 echo-reply (1 match)
permit icmp any 10.10.10.0 0.0.0.255 unreachable
permit icmp any 10.10.10.0 0.0.0.255 administratively-prohibited
permit icmp any 10.10.10.0 0.0.0.255 packet-too-big
permit icmp any 10.10.10.0 0.0.0.255 echo (1 match)
permit icmp any 10.10.10.0 0.0.0.255 time-exceeded
deny ip any any (62 matches)

access-list 101 permit tcp 10.10.10.0 0.0.0.255 any
access-list 101 permit udp 10.10.10.0 0.0.0.255 any
access-list 101 permit icmp 10.10.10.0 0.0.0.255 any
access-list 101 deny ip any any

access-list 102 permit eigrp any any
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 echo-reply
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 unreachable
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 administratively-prohibited
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 packet-too-big
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 echo
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 time-exceeded
access-list 102 deny ip any any
Access list 101 is for the outbound traffic. Access list 102 is for the inbound traffic. The access lists permit only a routing protocol, Enhanced Interior Gateway Routing Protocol (EIGRP), and specified ICMP inbound traffic.
In the example, a server on the Ethernet side of the router is not accessible from the Internet. The access list blocks it from establishing a session. To make it accessible, the access list needs to be modified to allow the conversation to occur. To change an access list, remove the access list, edit it, and reapply the updated access list.
Note: The reason that you remove the access-list 102 before edit and reapply, is due to the "deny ip any any" at the end of the access list. In this case, if you were to add a new entry before you remove the access-list, the new entry appears after the deny. Therefore, it is never checked.
This example adds the Simple Mail Transfer Protocol (SMTP) for 10.10.10.1 only.

Extended IP Access List 102

permit eigrp any any (385 matches)
permit icmp any 10.10.10.0 0.0.0.255 echo-reply
permit icmp any 10.10.10.0 0.0.0.255 unreachable
permit icmp any 10.10.10.0 0.0.0.255 administratively-prohibited
permit icmp any 10.10.10.0 0.0.0.255 packet-too-big
permit icmp any 10.10.10.0 0.0.0.255 echo
permit icmp any 10.10.10.0 0.0.0.255 time-exceeded
permit tcp any host 10.10.10.1 eq smtp (142 matches)

!--- In this example, you inspect traffic that has been
!--- initiated from the inside network.

What Traffic Do You Want to Inspect?

The CBAC within Cisco IOS supports:
Keyword Name
Protocol
cuseeme
CUSeeMe Protocol
ftp
File Transfer Protocol
h323
H.323 Protocol (for example Microsoft NetMeeting or Intel Video Phone)
http
HTTP Protocol
rcmd
R commands (r-exec, r-login, r-sh)
realaudio
Real Audio Protocol
rpc
Remote Procedure Call Protocol
smtp
Simple Mail Transfer Protocol
sqlnet
SQL Net Protocol
streamworks
StreamWorks Protocol
tcp
Transmission Control Protocol
tftp
TFTP Protocol
udp
User Datagram Protocol
vdolive
VDOLive Protocol

Each protocol is tied to a keyword name. Apply the keyword name to an interface that you want to inspect. For example, this configuration inspects FTP, SMTP, and Telnet:
router1#configure
Configuring from terminal, memory, or network [terminal]? Enter configuration
commands, one per line. End with CNTL/Z.
router1(config)#ip inspect name mysite ftp
router1(config)#ip inspect name mysite smtp
router1(config)#ip inspect name mysite tcp
router1#show ip inspect config
Session audit trail is disabled
one-minute (sampling period) thresholds are [400:500]connections
max-incomplete sessions thresholds are [400:500]
max-incomplete tcp connections per host is 50.
Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
dns-timeout is 5 sec
Inspection Rule Configuration
Inspection name mysite

ftp timeout 3600
smtp timeout 3600
tcp timeout 3600
This document addresses what traffic you want to let out, what traffic you want to let in, and what traffic you want to inspect. Now that you are prepared to configure CBAC, complete these steps:
  1. Apply the configuration.
  2. Enter the access lists as configured above.
  3. Configure the inspection statements.
  4. Apply the access lists to the interfaces.
After this procedure, your configuration appears as shown in this diagram and configuration.
32.gif
Context-Based Access Control Configuration
!
version 11.2
no service password-encryption
service udp-small-servers
service tcp-small-servers
!
hostname router1
!
!
no ip domain-lookup
ip inspect name mysite ftp
ip inspect name mysite smtp
ip inspect name mysite tcp
!
interface Ethernet0
ip address 10.10.10.2 255.255.255.0
ip access-group 101 in
ip inspect mysite in


no keepalive
!
interface Serial0
no ip address
encapsulation frame-relay
no fair-queue
!
interface Serial0.1 point-to-point
ip address 10.10.11.2 255.255.255.252
ip access-group 102 in
frame-relay interface-dlci 200 IETF
!
router eigrp 69
network 10.0.0.0
no auto-summary
!
ip default-gateway 10.10.11.1
no ip classless
ip route 0.0.0.0 0.0.0.0 10.10.11.1
access-list 101 permit tcp 10.10.10.0 0.0.0.255 any
access-list 101 permit udp 10.10.10.0 0.0.0.255 any
access-list 101 permit icmp 10.10.10.0 0.0.0.255 any
access-list 101 deny ip any any
access-list 102 permit eigrp any any
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 echo-reply
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 unreachable
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 administratively-prohibited
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 packet-too-big
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 echo
access-list 102 permit icmp any 10.10.10.0 0.0.0.255 time-exceeded
access-list 102 permit tcp any host 10.10.10.1 eq smtp
access-list 102 deny ip any any
!
line con 0
line vty 0 4
login
!
end


Multicast VLAN Registration (MVR)


Introduction

In multicast VLAN networks, subscribers to a multicast group can exist in more than one VLAN. If the VLAN boundary restrictions in a network consist of Layer 2 switches, it might be necessary to replicate the multicast stream to the same group in different subnets, even if they are on the same physical network. Multicast VLAN Registration (MVR) routes packets received in a multicast source VLAN to one or more receive VLANs. Clients are in the receive VLANs and the multicast server is in the source VLAN. Multicast routing has to be disabled when MVR is enabled. Refer to the configuration guide at Understanding Multicast VLAN Registration for more information on MVR.
This document provides a simple topology: a stack of Catalyst 3750 Switches with multicast source/receivers connected to it, a working configuration, and output of commands to verify whether the MVR works or not when a stream is sending.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on output from the Catalyst 3750 Switch.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Related Products

This configuration can also be used with these switch types:
  • Catalyst 3550, 2940, 2950, 2970, 3500/2900XL Series Switches
Catalyst 3750, 35XX, 29XX Switches support MVR since code version 12.1(11)AX. For Catalyst 3500/2900 XL Switches, the minimum Cisco IOS® Software Release required is 12.0(5)WC(1).

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Configure

In this section, you are presented with the information to configure the features described in this document.
Note: Use the Command Lookup Tool ( registered customers only) to obtain more information on the commands used in this section.

Network Diagram

This document uses this network setup:
mvr-3750-config1.gif

Configuration

You must complete these steps in order to configure MVR:
  1. Issue this command in order to disable multicast routing globally on the switch or switch stack:
    switch(config)#no ip multicast-routing distributed
    
  2. Issue this command in order to enable MVR globally:
    mixed(config)#mvr
    
  3. Issue this command in order to specify the multicast group where the stream is sending:
    mixed(config)#mvr group 239.9.0.1
    
  4. Issue this command in order to specify the VLAN where the source is located:
    mixed(config)#mvr vlan 1200
    
  5. Although multicast routing is disabled, you need to issue these commands in order to enable the peripheral interface manager (PIM) on the routed interface.
    This is to maintain multicast group status so that the general query can be sent.
    Note: WARNING messages are received from Cisco IOS after PIM is enabled.
    mixed(config)#int vlan 1200
    
    mixed(config-if)#ip pim dense-mode
    
    WARNING: "ip multicast-routing distributed" is not configured,
    
                       IP Multicast packets will not be forwarded.
    
    WARNING: "ip multicast-routing distributed" is not configured, 
                       
                       IP Multicast packets will be fast-switched.
    
    mixed(config-if)#int vlan 1100
    
    mixed(config-if)#ip pim dense-mode
    
    WARNING: "ip multicast-routing distributed" is not configured,
    
                       IP Multicast packets will not be forwarded.
    
    WARNING: "ip multicast-routing distributed" is not configured, 
    
                       IP Multicast packets will be fast-switched.
  6. Issue these commands:
    mixed(config-if)#int port-channel 20
    
    mixed(config-if)#mvr type source
    
    The mvr type source command should specify on the interface where the multicast stream comes from.
  7. Issue these commands:
    mixed(config-if)#int g6/0/1
    
    mixed(config-if)#mvr type receiver
    
    The mvr type receiver command should specify on the other interface where the subscribers are attached.
3750 Switch
maui-soho-01#show running-config 
 Building configuration...

!

mvr vlan 1200

mvr

mvr group 239.9.0.1

!

!

vlan 1,1100,1200 

!

interface Port-channel20

 switchport trunk encapsulation isl

 switchport mode trunk

 mvr type source

!

interface GigabitEthernet6/0/1

 switchport access vlan 1100

 mvr type receiver

 spanning-tree portfast      

!

interface GigabitEthernet7/0/49

 switchport trunk encapsulation isl

 switchport mode trunk

 channel-group 20 mode active

!

interface GigabitEthernet7/0/50

 switchport trunk encapsulation isl

 switchport mode trunk

 channel-group 20 mode active

!

interface Vlan1100

 ip address 116.100.1.1 255.255.0.0

 ip pim sparse-dense-mode

!

interface Vlan1200

 ip address 115.200.1.1 255.255.0.0

 ip pim sparse-dense-mode

!

ation interface Gi7/0/2

 !
 end

Verify

Use this section to confirm that your configuration works properly.
The Output Interpreter Tool ( registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.
Issue the show mvr command in order to display the MVR status and values for the switch.
mixed#show mvr

MVR Running: TRUE

MVR multicast VLAN: 1200

MVR Max Multicast Groups: 256

MVR Current multicast groups: 1

MVR Global query response time: 5 (tenths of sec)

MVR Mode: compatible
Issue the show mvr interface command in order to verify the flow of the multicast stream.
mixed#show mvr interfaces

Port      Type     Status       Immediate Leave

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

Gi6/0/1   RECEIVER   ACTIVE/UP   DISABLED  

Po21      SOURCE     ACTIVE/UP   DISABLED
Issue the show mvr member command in order to find out who subscribes to the multicast group.
mixed#show mvr member

MVR Group IP     Status          Members

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

239.009.000.001 ACTIVE        Gi6/0/1(d), Po20(s)

Multicast Routing Monitor (MRM)


MRM

Multicast Routing Monitor (MRM) facilitates automated fault detection in a large multicast routing infrastructure. MRM is designed to alert a network administrator of multicast routing problems near to real-time.
MRM has two components: MRM tester and MRM manager. MRM tester is a sender or receiver.
MRM is available in Cisco IOS Software Release 12.0(5)T and later. Only the MRM testers and managers need to be running the MRM-supported Cisco IOS version.
mcast11.gif
Test Sender Configuration
interface Ethernet0 
  ip mrm test-sender 

Test Receiver Configuration
interface Ethernet0 
  ip mrm test-receiver 

Test Manager Configuration
ip mrm manager test1 
 manager e0 group 239.1.1.1 
 senders 1 
 receivers 2 sender-list 1 


 access-list 1 permit 10.1.1.2 
 access-list 2 permit 10.1.4.2 

Output from the show ip mrm manager command on Test Manager is shown here:
Test_Manager# show ip mrm manager 
   Manager:test1/10.1.2.2 is not running 
     Beacon interval/holdtime/ttl:60/86400/32 
     Group:239.1.1.1, UDP port test-packet/status-report:16384/65535 
     Test sender: 
       10.1.1.2 
     Test receiver: 
       10.1.4.2
Start the test with the command shown here. The test manager sends control messages to the test sender and the test receiver as configured in the test parameters. The test receiver joins the group and monitors test packets sent from the test sender.
Test_Manager# mrm start test1 
 *Feb  4 10:29:51.798: IP MRM test test1 starts ......  
Test_Manager#
In order to display a status report for the test manager, enter this command:
Test_Manager# show ip mrm status  

IP MRM status report cache:  
Timestamp        Manager          Test Receiver   Pkt Loss/Dup (%)       Ehsr  
*Feb  4 14:12:46 10.1.2.2         10.1.4.2        1            (4%)      29  
*Feb  4 18:29:54 10.1.2.2         10.1.4.2        1            (4%)      15  
Test_Manager#
The output shows that the receiver sent two status reports (one line each) at a given time stamp. Each report contains one packet loss during the interval window (default of one second). The "Ehsr" value shows the estimated next sequence number value from the test sender. If the test receiver sees duplicate packets, it shows a negative number in the "Pkt Loss/Dup" column.
In order to stop the test, enter this command:
Test_Manager# mrm stop test1 
*Feb  4 10:30:12.018: IP MRM test test1 stops  
Test_Manager# 
While running the test, the MRM sender starts sending RTP packets to the configured group address at the default interval of 200 ms. The receiver monitors (expects) the same packets at the same default interval. If the receiver detects a packet loss in the default window interval of five seconds, it sends a report to the MRM manager. You can display the status report from the receiver if you issue the show ip mrm status command on the manager.

Pragmatic General Multicast (PGM)

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and retransmissions or can detect unrecoverable data packet loss.

There are no PGM global commands. PGM is configured per interface with the ip pgm command. You must enable Multicast routing on the router with PIM on the interface.

Jan 21, 2010

c-BPDU(configuration BPDU) vs tcn-BPDU(topology change BPDU)

There are two types of BPDU's: configuration BPDU's (c-BPDU) and topology change BPDU's (tcn-BPDU).

Designated Bridges generate c-BPDU's. Root Ports and BLocked Ports listen for c-BPDU's.

c-BPDU's originate from the root bridge and flow out towards the edge of the spanning tree, c-BPDU's are re-generated at every bridging device that receives them.

tcn-BPDU's originate from root ports and flow towards the Root Bridge.

c-BPDU's are the heartbeat of the Spanning Tree,
tcn-BPDU's are the heart attack of the spanning tree.