Jun 27, 2008

Configuring RMON Alarm and Event Settings from the Command Line Interface (CLI)

Introduction
This document describes how to set up Remote Monitoring (RMON) Alarms and Events on a router from the command line interface (CLI).

Background Information
RMON is a method similar to Simple Network Management Protocol (SNMP) to track statistics on network device interfaces or ports.

The RMON feature typically is useful in a LAN switch environment, but is available on access routers (for example, the 2x00 Series) in Cisco IOS® Software Release 11.1 or later. Sometimes, you need to set up RMON on remote routers only when you can not get access to the LAN equipment (such as hubs) to view the traffic. RMON does not require you to actively poll for SNMP variables on a regular basis. The devices store the needed information, and then it is dumped periodically to a RMON network management station.

Note: By default all switches support mini-rmon, so that alarms, events, stats and history are directly received from the switches. In order to receive all other detailed information from switches, you require Network Analysis Module (NAM).

Syntax To Set Up An Event

Cisco IOS software allows you to set up RMON alarms and events from the CLI. This section and the next one provide the syntax of the required commands, with the same names that are used for the eventTable and the alarmTable.

1.3.6.1.2.1.16.9.1
eventTable OBJECT-TYPE

SYNTAX SEQUENCE OF EventEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of events to be generated."
::= { event 1 }

.1.3.6.1.2.1.16.3.1
alarmTable OBJECT-TYPE

SYNTAX SEQUENCE OF AlarmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of alarm entries."
::= { alarm 1 }

Syntax
rmon event eventIndex [log] [trap eventCommunity] [description eventDescription] [owner eventOwner]

Syntax Description

1. event—Configure an RMON event.
2. eventIndex— Event number (1–65535)
3. log—(Optional) Generate an RMON log when the event fires.
4. trap eventCommunity —(Optional) Generate an SNMP trap when the event fires, for the specified SNMP community string.
5. description eventDescription —(Optional) Specify a WORD or a description of the event.
6. owner eventOwner —(Optional) Specify an owner for the event.

  • If you do not specify either the log or the trap option, the alarmTable object eventType (1.3.6.1.2.1.16.9.1.1.3) is set to none.
  • If you only specify log, eventType is set to log.
  • If you only specify trap, the eventType is set to snmp-trap.
  • If you specify both log and trap, eventType is set to log-and-trap.

Syntax To Set Up An Alarm
rmon alarm alarmIndex alarmVariable alarmInterval {absolute delta} rising-threshold alarmRisingThreshold [alarmRisingEventIndex] falling-threshold alarmFallingThreshold [alarmFallingEventIndex] [owner alarmOwner]

Syntax Description

1. alarm—Configure an RMON alarm.
2. alarmIndex—Alarm number (1–65535)
3. alarmVariable—MIB object to monitor (WORD)
4. alarmInterval—Sample interval (1–4294967295)
5. absolute—Test each sample directly.
6. delta—Test delta between samples.
7. rising-threshold—Configure the rising threshold.
8. alarmRisingThreshold—Rising threshold value (-2147483648–2147483647)
9. alarmRisingEventIndex—(optional) Event to fire when the rising threshold is crossed (1–65535)
10. falling-threshold—Configure the falling threshold.
11. alarmFallingThreshold—Falling threshold value (-2147483648–2147483647)
12. alarmFallingEventIndex—(Optional) Event to fire when the falling threshold is crossed (1–65535)
13. owner alarmOwner —(Optional) Specify an owner for the alarm (WORD).


The alarmVariable is specified one of these ways:

  • As the entire dotted decimal Abstract Syntax Notation One (ASN.1) object identifier (OID) for the object (such as .1.3.6.1.2.1.2.2.1.10.1)
  • With the table entry name followed by the table object number and the instance

For example, to specify ifInOctets for the first instance, use ifEntry.10.1 for the alarmVariable.

Examples
In the examples in this section, “public” is the Read-Only (RO) SNMP community string and 171.68.118.100 is the host that receives the trap.

In order to set up an event to send a trap when triggered, issue these commands:
!--- Enter these commands on one line each.
rmon event 3 log trap public
description "Event to create log entry and SNMP notification"
owner "jdoe 171.68 118.100 2643"

rmon alarm 2 ifEntry.10.12 30 delta
rising-threshold 2400000 3 falling-threshold 1800000 3
owner "jdoe 71.68 118.100 2643"


In this example, a Cisco 2500 is configured to send a trap and to log an event, when the alarm threshold that monitors its own ifInOctets (ifEntry.10.1) exceeds an absolute value of 90000:
snmp-server host 171.68.118.100 public
SNMP-server community public RO
rmon event 1 log trap public description "High ifInOctets" owner jdoe
!--- Enter this command on one line:
rmon alarm 10 ifEntry.10.1 60 absolute
rising-threshold 90000 1 falling-threshold 85000 owner jdoe


The monitoring occurs every 60 seconds, and the falling-threshold is 85000. In this case, the NetView management station received this trap:
router.rtp.cisco.com:
A RMON Rising Alarm:
Bytes received exceeded
threshold 90000;

VALUE=483123 (sample TYPE=1; alarm index=10)


Issue these commands to view logged alarms and events:

  • show rmon events—Displays the contents of the RMON event table of the router. This command has no arguments or keywords.


Router#show rmon events

Event 12 is active, owned by manager 1
Description is interface-errors
Event firing causes log and trap to community public, last fired 00:00:00

  • Event 12 is active, owned by manager1—Unique index into the eventTable, which shows the event status as active and shows the owner of this row, as defined in the eventTable of RMON.
  • Description is interface-errors—Type of event; in this case, an interface error.
  • Event firing causes log and trap—Type of notification that the router will make about this event. Equivalent to eventType in RMON.
  • community public—If an SNMP trap is to be sent, it is sent to the SNMP community that is specified by this octet string. Equivalent to eventCommunity in RMON.
  • last fired—The last time that the event was generated.

  • show rmon alarms—Displays the contents of the RMON alarm table of the router. This command has no arguments or keywords.
    Router#show rmon alarms
    Alarm 2 is active, owned by manager1
    Monitors ifEntry.1.1 every 30 seconds
    Taking delta samples, last value was 0
    Rising threshold is 15, assigned to event 12
    Falling threshold is 0, assigned to event 0
    On startup enable rising or falling alarm
  • Alarm2 is active, owned by manager1—Unique index into the alarmTable, which shows the alarm status as active and shows the owner of this row, as defined in the alarmTable of RMON.
  • Monitors ifEntry.1.1—OID of the particular variable to be sampled. Equivalent to alarmVariable in RMON.
  • every 30 seconds—Interval in seconds over which the data is sampled and compared with the rising and falling thresholds. Equivalent to alarmInterval in RMON.
  • Taking delta samples—Method to sample the selected variable and calculate the value to be compared against the thresholds. Equivalent to alarmSampleType in RMON.
  • Last value was—Value of the statistic during the last sampling period. Equivalent to alarmValue in RMON.
  • Rising threshold is—Threshold for the sampled statistics. Equivalent to alarmRisingThreshold in RMON.
    assigned to event—Index of the EventEntry that is used when a rising threshold is crossed. Equivalent to alarmRisingEventIndex in RMON.
  • Falling threshold is—Threshold for the sampled statistic. Equivalent to alarmFallingThreshold in RMON.
    Assigned to event—Index of the EventEntry that that is used when a falling threshold is crossed.
  • Equivalent to alarmFalllingEventIndex in RMON.
  • On startup enable rising or falling alarm—Alarm that may be sent when this entry is first set to valid. Equivalent to alarmStartupAlarm in RMON.

用路由器過濾特定MAC的主機流量

 當你針對一個MAC地址進行過濾的時候,這一動作發生在第二層。而路由器一般執行的是第三層路由的任務,只有很少情況下做橋接的時候才對進入的MAC地址進行過濾,所以這樣的過濾最好設置在二層交換設備上。

  方法一、但這個要求對路由器來說也不是不可能的任務,使用以下配置達到了要求的效果︰

Router(config)#ip cef
Router(config)#interface Ethernet0/0
Router(config-if)#ip address 192.168.1.254 255.255.255.0 rate-limit input access-group rate-limit 100 8000 1500 2000 conform-action drop exceed-action drop
Router(config)#access-list rate-limit 100 0001.0001.abcd


  方法二、也可以使用橋接(IRB)的方法來解決,這種方法只需要12.0(2)T以上標準IOS即可。配置如下︰

Router(config)#bridge irb
Router(config)#interface Ethernet0/0
Router(config-if)#no ip address
Router(config-if)#bridge-group 1
Router(config-if)#interface BVI1
Router(config-if)#ip address 192.168.1.254 255.255.255.0
Router(config)#bridge 1 protocol ieee
Router(config)#bridge 1 route ip
Router(config)#bridge 1 address 0001.0001.abcd discard

Jun 26, 2008

Enabling Tag Switching on the ATM Interface

Note:Configure all parallel interfaces between ATM switch routers for either IP unnumbered or with a specific IP address. Unnumbering some parallel interfaces and assigning specific IP addresses to others might cause TDP sessions to restart on some parallel interfaces when another parallel interface is shut down. Therefore, we highly recommend that you unnumber all parallel interfaces to loopback.

To enable tag switching on the ATM interface, perform the following steps, beginning in global configuration mode:

1. interface atm card/subcard/port
2. ip unnumbered type number or
ip address ip-address mask
3. tag-switching ip

Examples
In the following example, ATM interface 1/0/1 is configured for IP unnumbered to loopback interface 0:

Switch(config-if)# interface atm 1/0/1
Switch(config-if)# ip unnumbered loopback 0
Switch(config-if)# tag-switching ip
Switch(config-if)# exit


In the following example, ATM interface 0/0/3 is configured with a specific IP address and subnet mask (1.3.11.3 255.255.0.0):

Switch(config)# interface atm 0/0/3
Switch(config-if)# ip address 1.3.11.3 255.255.0.0
Switch(config-if)# tag-switching ip
Switch(config-if)# exit


The following example shows that tag switching is configured on ATM interfaces 0/0/3 and 1/0/1:

Switch# show tag-switching interfaces
Interface IP Tunnel Operational
ATM0/0/3 Yes No Yes (ATM tagging)
ATM1/0/1 Yes No Yes (ATM tagging)


Configuring OSPF
Enable OSPF on the ATM switch router so that it can create routing tables, which identify routes through the network. Then add the addresses and associated routing areas to the OSPF process so that it can propagate the addresses to other ATM switch routers:

1. router ospf process_number
2. network address wildcard-mask {area area-id}
Note:With this release of the software, addressing the interface on the route processor (CPU) has changed. The ATM interface is now called atm0, and the Ethernet interface is now called ethernet0. Old formats (atm 2/0/0 and ethernet 2/0/0) are still supported.

Example
The following is an example of OSPF enabled and assigned process number 10000. All addresses are in area 0:

Note:An IP address of 1.1.1.1 with a subnet mask of 255.255.255.0 is entered as an IP network prefix of 1.1.1.0 with a subnet mask of 0.0.0.255. Likewise, an IP address of 1.2.1.1 with a subnet mask of 255.255.255.0 is entered as an IP network prefix of 1.2.1.0 with a subnet mask of 0.0.0.255.

Switch(config)# router ospf 10000
Switch(config-router)# network 1.1.1.0 0.0.0.255 area 0
Switch(config-router)# network 1.2.1.0 0.0.0.255 area 0
Switch(config-router)# network 1.3.0.0 0.0.255.255 area 0
Switch(config-router)# network 200.2.2.0 0.0.0.255 area 0
Switch(config-router)# network 1.0.1.0 0.0.0.255 area 0
Switch(config-router)# network 1.18.0.0 0.0.255.255 area 0


Displaying the OSPF Configuration
To display the OSPF configuration, use the following privileged EXEC command:
The following example shows the OSPF configuration using the show ip ospf privileged EXEC command:

Switch# show ip ospf
Routing Process "ospf 10000" with ID 1.0.1.11
Supports only single TOS(TOS0) routes
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Number of DCbitless external LSA 0
Number of DoNotAge external LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Area BACKBONE(0) (Inactive)
Number of interfaces in this area is 4
Area has no authentication
SPF algorithm executed 2 times
Area ranges are
Link State Update Interval is 00:30:00 and due in 00:14:42
Link State Age Interval is 00:20:00 and due in 00:14:10
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0


Configuring a VPI Range (Optional)
Although not necessary for most configurations, you might need to change the default tag virtual path identifier (VPI) range on the switch if:

  • It is an administrative policy to use a VPI value other than 1, the default VPI.
  • There is a large number of TVCs on an interface.

Note:You cannot enter a VPI range on a VP tunnel. On VP tunnels, the VPI is the permanent virtual path (PVP) number of the tunnel.

To change the default tag VPI range, perform the following steps, beginning in global configuration mode:



1. interface atm card/subcard/port
2. tag-switching atm vpi vpi [- vpi]
Example
The following example shows how to select a VPI range from 5 to 6 (a range of two), an acceptable range if the TDP neighbor is a router:

Switch(config)# interface atm 3/0/1
Switch(config-if)# tag-switching ip
Switch(config-if)# tag-switching atm vpi 5 - 6


The following example shows how to select a VPI range from 5 to 7 (a range of three), an acceptable range if the TDP neighbor is a switch:

Switch(config)# interface atm 3/0/1
Switch(config-if)# tag-switching ip
Switch(config-if)# tag-switching atm vpi 5 - 7


Note:Although the example shows a VPI range of three, you are not limited to a range of three if the TDP neighbor is a switch. The maximum VPI range is 0 to 255 if the TDP neighbor is a switch.

Displaying the Tag Switching VPI Range
To display the tag switching VPI range, use the following EXEC command:

show tag-switching interfaces detail

Example
The following example shows the tag switching VPI range on interface ATM 1/0/1:

Switch# show tag-switching interfaces detail
Interface ATM0/0/3:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 4470
ATM tagging: Tag VPI = 1, Control VC = 0/32
Interface ATM1/0/1:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 4470
ATM tagging: Tag VPI range = 5 - 6, Control VC = 6/32


Configuring TDP Control Channels (Optional)
Although not necessary for most configurations, you can change the default TDP control channel VPI and virtual channel identifier (VCI) if you want to use a nondefault value. The default TDP control channel is on VPI 0 and VCI 32. TDP control channels exchange TDP HELLOs and Protocol Information Elements (PIEs) to establish two-way TDP sessions. Tag virtual channels (TVCs) are created by the exchange of PIEs through TDP control channels.

To change the TDP control channel, perform the following steps, beginning in global configuration mode:

1. interface atm card/subcard/port
2. ip address ip-address mask
3. tag-switching ip
4. tag-switching atm control-vc vpi vci
shows an example TDP control channel configuration between a source switch and destination switch on ATM interface 0/0/1. Note that the VPI and VCI values match on the source switch and destination switch.



Examples
In the following example, a TDP control channel is configured on the source switch:

Switch(config)# interface atm 0/0/1
Switch(config-if)# ip address 1.2.0.11 255.255.255.0
Switch(config-if)# tag-switching ip
Switch(config-if)# tag-switching atm control-vc 6 32
Switch(config-if)# exit


In the following example, a TDP control channel is configured on the destination switch:

Switch(config)# interface atm 0/0/1
Switch(config-if)# ip address 1.2.0.12 255.255.255.0
Switch(config-if)# tag-switching ip
Switch(config-if)# tag-switching atm control-vc 6 32
Switch(config-if)# exit


If you are having trouble establishing a TDP session, verify that the VPI and VCI values match on the TDP control channels of the source switch and destination switch.

Displaying the TDP Control Channels
To display the TDP control channel configuration, use the following EXEC command:

show tag-switching interfaces detail
The following example shows the TDP control channel configuration on interface ATM 0/0/3:

Switch# show tag-switching interfaces detail
Interface ATM0/0/3:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
MTU = 4470
ATM tagging: Tag VPI = 1, Control VC = 0/32

mpls ldp discovery transport-address

To specify the transport address advertised in Label Distribution Protocol (LDP) Discovery Hello messages sent on an interface, use the mpls ldp discovery transport-address command in interface configuration mode. To remove the transport address advertised, use the no form of this command.


mpls ldp discovery transport-address {interface ip-address}
no mpls ldp discovery transport-address


Defaults
The default behavior when this command has not been issued for an interface depends on the interface type.

Unless the interface is a label-controlled ATM (LC-ATM) interface, LDP advertises its LDP router ID as the transport address in LDP Discovery Hello messages sent from the interface.

If the interface is an LC-ATM interface, no transport address is explicitly advertised in LDP Discovery Hello messages sent from the interface.

Usage Guidelines
Establishing an LDP session between two routers requires a session TCP connection by which label advertisements can be exchanged between the routers. To establish the session TCP connection, each router must know the transport address (IP address) of the other router.

The LDP discovery mechanism provides the means for a router to advertise the transport address for its end of a session TCP connection. The transport address advertisement itself may be explicit, in which case it appears as part of the contents of Discovery Hello messages sent to the peer, or implicit, in which case it does not, and the peer uses the source IP address of received Hello messages for the peer's transport address.

The mpls ldp discovery transport-address command provides the means to modify the default behavior described above. When the interface keyword is specified, LDP advertises the IP address of the interface in LDP Discovery Hello messages sent from the interface. When the ip-address argument value is specified, LDP advertises the specified IP address in LDP Discovery Hello messages sent from the interface.

Note: When a router has multiple links connecting it to its peer device, the router must advertise the same transport address in the LDP Discovery Hello messages it sends on all such interfaces.

Examples
The following example specifies that LDP should advertise the IP address of interface POS2/0 in LDP Hello messages sent from that interface.


Router(config#) interface pos2/0
Router(config-if)# mpls ldp discovery transport-address interface


The following example specifies that the LDP should advertise IP address 145.22.0.56 in the LDP Hellow messages sent from interface POS3/1.


Router(config#) interface pos3/1
Router(config-if)# mpls ldp discovery transport-address 145.22.0.56

Proxy Auto Config(PAC)

什麼是 Proxy Auto Config ?

首先,我們一定要知道什麼是 Proxy?他的功用是什麼?如果還不知道,可以參照這份文件。
而 PAC(Proxy Auto Config) 又是什麼呢?它實際上是一個 Script;經由編寫這個 Script,我們可以讓系統判斷在怎麼樣的情形下,要利用哪一台 Proxy 來進行連線。這樣做主要的好處有:

分散 Proxy 的流量,避免 Proxy Server 負載過高
針對個別條件設定、加快瀏覽速度
設定要求順序,在某台 Proxy 無法連線時,可自動嘗試別種連線方式

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

Proxy Auto Config File 的格式

基本上 Proxy Auto Config File(以下簡稱 PAC)是一個純文字檔,他的語法採用 JavaScript;所以建議要學習編寫 PAC 的人,最好先學習基本的 JavaScript。一個 PAC 檔必需是單獨的 JavaScript,其中不能包含任何 HTML 標籤。

在 PAC 檔中,一定要定義 Function FindProxyForURL 如下:

function FindProxyForURL( url, host ) { ... } 如果使用了 PAC 檔,則瀏覽器在接受我們要求的網址後,會去執行

ret = FindProxyForURL( url, host );這樣的指令。其中,url 是所要求網址的完整路徑,host 是對方的電腦名稱(就是在 :// 和 / 之中的部份);而 return 值 ret 則是 Proxy 的組態,它的格式有下列三種:

DIRECT 直接連線而不透過 Proxy
PROXY host:port 使用指定的 Proxy 伺服機
SOCKS host:port 使用指定的 Socks 伺服機
比如說當瀏覽器得到的是 Proxy proxy.ncu.edu.tw:3128; Proxy proxy.csie.ncu.edu.tw:3128; DIRECT 的話,那瀏覽器會先嘗試透過 proxy.ncu.edu.tw 來開啟網頁,如果無法使用,則嘗試 proxy.csie.ncu.edu.tw,還是不行的話,就直接連線。


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

PAC 中特別的 Function

在 PAC 中,除了可以使用一般 JavaScript 的 Function 外,它還定義了一些特別的 Function 可以使用:


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

isPlainHostName( host )

host 由網址取得的主機名稱。

此 Function 會判斷 host 是否為不包含網域 (Domain)。如果是,則 return true;如果包含,則 return false。

範例:

isPlainHostName("www") 會 return true
isPlainHostName("www.netscape.com") 會 return false

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

dnsDomainIs( host, domain )

host 由網址取得的主機名稱。
domain 指定的網域。

此 Function 會判斷 host 是否屬於網域 domain。如果是,則 return true;否,則 return false。

範例:

dnsDomainIs("www.netscape.com", ".netscape.com") 會 return true
dnsDomainIs("www", ".netscape.com") 會 return false
dnsDomainIs("www.mcom.com", ".netscape.com") 會 return false

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

localHostOrDomainIs( host, hostdom )

host 由網址取得的主機名稱。
hostdom 完整的網域名稱。

此 Function 會判斷 host 是否為 hostdom,或 host 是否為 hostdom 的主機名稱。如果是,則 return true;否,則 return false。

範例:

localHostOrDomainIs("www.netscape.com", "www.netscape.com") 會 return true (完全相同)
localHostOrDomainIs("www", "www.netscape.com") 會 return true (主機名稱相同)
localHostOrDomainIs("www.mcom.com", "www.netscape.com") 會 return false (網域不同)
localHostOrDomainIs("home.netscape.com", "www.netscape.com") 會 return false (主機名稱不同)

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

isResolvable( host )

host 由網址取得的主機名稱。

此 Function 會嘗試透過 DNS 去解析 host,如果解析成功,則 return true;否則 return false。

範例:

isResolvable("www.netscape.com") 會 return true (除非 DNS 無法正常運作)
isResolvable("bogus.domain.foobar") 會 return false (除非真的冒出這個 domain 出來…)

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

isInNet( host, pattern, mask )

host 主機名稱,可以是 Domain Name 或 IP。如果是 Domain Name,則會透過 DNS 查出 IP。
pattern IP。
mask對應於 pattern 的遮罩。

此 Function 會 host 是否在指定的 IP 範圍內,如果是,則 return true;否則 return false。

範例:

isInNet(host, "198.95.249.79", "255.255.255.255") 當 host 為 198.95.249.79 時,會 return true。
isInNet(host, "140.115.0.0", "255.255.0.0") 當 host 為 140.115.*.* 時,會 return true。

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

dnsResolve( host )

host 要透過 DNS 解晰的主機名稱。


此 Function 會透過 DNS 去解析 host,return 值即為解析之結果。

範例:

dnsResolve("www.math.ncu.edu.tw") 會 return "140.115.25.9"。

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

myIpAddress()

此 Function 會 return 瀏覽器所在電腦之 IP 位址。


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

dnsDomainLevels( host )

host 由網址取得的主機名稱。

此 Function 會 return host 的 Domain 層數(點的數目)。

範例:

dnsDomainLevels("www") 會 return 0。
dnsDomainLevels("www.netscape.com") 會 return 2。

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

shExpMatch( str, shexp )

str 要進行比對的字串。
shexp 比對的條件。

此 Function 會比對 str 是否符合 shexp 的表示式(此表示式為 shell expression 而非 regular expressions)。如果是,則 return true;否則 return false。

範例:

shExpMatch("http://home.netscape.com/people/ari/index.html", "*/ari/*") 會 return true
shExpMatch("http://home.netscape.com/people/montulli/index.html", "*/ari/*") 會 return false

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

weekdayRange()、dateRange()、timeRange()

這三個 Function 的功用都是檢查線在時間是否在指定範圍內,用這些 Function 就可以設定分時段使用 Proxy Server。但由於較為繁瑣,如有興趣或需要,請參考原始文件。

範例:


function FindProxyForURL( url, host ){
if ( dnsDomainIs( host, "locahost" ) || dnsDomainIs( host, ".edu.tw" ) || isInNet( host, "140.0.0.0", "255.0.0.0" ) || isPlainHostName( host ) )
{
return "DIRECT; PROXY proxy.csie.ncu.edu.tw:3128;" + " PROXY cache.math.ncu.edu.tw:3128";
//localhost、 domain 是 .edu.tw、IP 為 140.*.*.* 或只有 Host Name
//則直接連線;如果直接連線不行,則嘗試使用 proxy.csie 和 cache.math
}else if ( dnsDomainIs( host, ".tw" ) )
{
return "PROXY proxy.edu.tw:8080;" + " PROXY cache.edu.tw:8080;" + " DIRECT";
//如果網域是 .tw,則依序嘗試 proxy or cache or 直接連線
}else
return "PROXY cache.edu.tw:8080;" + " PROXY proxy.edu.tw:8080;" + " DIRECT";
//其他:依序嘗試 cache or proxy or 直接連線

Web Proxy Auto-Discovery(WPAD)

Web Proxy Auto-Discovery (WPAD) 功能可以不必透過設定,讓網站客戶端自動偵測代理伺服器所在。WPAD 所使用的演算法是利用一個叫 "wpad" 的主機名稱(hostname)映對到完整的網域名稱(full-qualified domain name)後面,然後逐漸移除子網域的部份名稱,直到找到一台 WPAD 伺服器或是剩下三層網域為止。

惡意使用者可以架設一台WPAD伺服器並偽裝為代理伺服器,藉此針對那些次級網域發動中間人攻擊(man-in-the-middle attacks)。當使用者設定了主要的DNS尾碼時(DNS suffix),Windows的解析器會嘗試利用所有次網域進行解析。舉例來說,如果DNS尾碼為corp.contoso.co.us,當試著解析wpad名稱時,DNS解析器會送出wpad.corp.contoso.co.us ,如果找不到,接著會嘗試wpad.contoso.co.us請求,如果還是找不到,接著會嘗試wpad.co.us,即使它不屬於contoso.co.us網域。

Jun 24, 2008

Juniper EX Series Switch Workshop 筆記分享 Part II

這一份是大部份我在上課作Lab時Dump下來的指令,其中比較複雜的部份我加上了些許的註釋,希望對各位會有所幫助!

Initial Configuration with DHCP

system {
root-authentication {
encrypted-password "$1$2Ssh2j.s$0vlh/Jv7fu5xpueSmG8O1/"; ## SECRET-DATA
! 設定 root 登入密碼
}
login {
user juniper {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$AGAzBQkY$QWZ8BSLezx0d7Oh0j.NFw."; ## SECRET-DATA
! 設定使用者登入帳號密碼
}
}
}
services {
ssh {
root-login allow;
! 設定ssh telnet
}
web-management {
http;
! 設定J-web access
}
dhcp {
pool 192.168.200.0/24 {
address-range low 192.168.200.101 high 192.168.200.110;
router {
192.168.200.10;
}
}
pool 192.168.3.0/24 {
address-range low 192.168.3.101 high 192.168.3.105;
router {
192.168.3.2;
}
}
}
! 設定 DHCP Server
}


VLAN

root# set vlans Test vlan-id 100
! 設定VLAN 'Test' VLAN id 100

root# run show vlans
Name Tag Interfaces
Test 100
ae0.0, ae1.0, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0,
ge-0/0/3.0
(* 代表實體port有connection)
Trust 300
ae0.0, ae1.0, ge-0/0/12.0, ge-0/0/13.0, ge-0/0/14.0,
ge-0/0/15.0
default
ge-0/0/16.0, ge-0/0/17.0, ge-0/0/21.0, ge-0/0/23.0
vlab 200
ae0.0, ae1.0, ge-0/0/4.0, ge-0/0/5.0, ge-0/0/6.0,
ge-0/0/7.0, ge-0/0/8.0, ge-0/0/9.0, ge-0/0/10.0,
ge-0/0/11.0

# run show system service dhcp
# run show vlans


LAG

root# set chassis aggregated-devices ethernet device-count 2
! 設定LAG有兩個groups

root# set interfaces ge-0/0/20 ether-options 802.3ad ae1
! 設定 GE-0/0/20 成為LAG Group "ae1"的成員

root# set interfaces ae1 unit 0 family ethernet-switching port-mode trunk
! 設定LAG interface "ae1" 成為 Trunk Port

root# set interfaces ae1 unit 0 family ethernet-switching native-vlan-id 100
! 設定LAG interface ae1 Trunk native-vlan-id 100

root# set interfaces ae1 unit 0 family ethernet-switching vlan members 200
! 設定LAG interface ae1 Trunk 可通過VLAN id 200


IEEE 802.1d/802.1w/802.1s Spanning Tree

root#set protocol stp bridge-priority
root#set protocol stp hello-time
root#set protocol stp max-age

root#set protocol rstp bridge-priority
root#set protocol rstp hello-time
root#set protocol rstp max-age

#set protocols mstp bridge-priority 32k
#set protocols mstp interface ae0.0 cost 1000
#set protocols mstp interface ae0.0 mode point-to-point
#set protocols mstp interface ae1.0 cost 1000
#set protocols mstp interface ae1.0 mode point-to-point
#set protocols mstp msti 1 bridge-priority 8k
#set protocols mstp msti 1 vlan 100
#set protocols mstp msti 2 bridge-priority 4k
#set protocols mstp msti 2 vlan 200 3

>show spanning-tree bridge
>show spanning-tree mstp configuration
>show spanning-tree interface msti

mstp {
bridge-priority 32k;
! 設定本機priority 32000
interface ae0.0 {
cost 1000;
mode point-to-point;
! 設定LAG group1
}
interface ae1.0 {
cost 1000;
mode point-to-point;
! 設定LAG group1
}
msti 1 {
bridge-priority 8k;
vlan 100;
! 設定MSTP Instance 1 priority 8192, including VLAN 100
}
msti 2 {
bridge-priority 4k;
vlan [ 200 3 ];
! 設定MSTP Instance 2 priority 4096, including VLAN 200, 3

}
}


RTG

#ethernet-switching options redundant-group group-name TEST interface ge-0/0/0.0 primary

#ethernet-switching options redundant-group group-name TEST interface ge-0/0/0.0 (non-active)
#ethernet-switching options redundant-group group-name TEST interface ge-0/0/1.0 (active)

#ethernet-switching options redundant-group group-name TEST interface ge-0/0/0.0
#ethernet-switching options redundant-group group-name TEST interface ge-0/0/1.0 primary (with pre-emption)

>show redundant-trunk-group

>edit protocol mstp


Virtual Chassis

>show virtual-chassis protocol interface

#set preprovisioned member 1 role line-card
#run request virtual-chassis vc-port set pic-slot 1 port 1 member 0


IEEE 802.1x Authentication

access {
radius-server {
192.168.1.10 {
secret "$9$hymcK8-ds4JDwY"; ## SECRET-DATA
timeout 3;
retry 1;
}
}
profile dot1x-lab {
authentication-order radius;
radius {
authentication-server 192.168.1.10;
}
}
}

protocols {
lldp {
interface all;
}
dot1x {
traceoptions {
! trace debug output
file dotxlog;
flag dot1x-debug;
flag eapol;
}
authenticator {
static {
00:16:d3:33:aa:11 {
vlan-assignment 200;
}
}
interface {
ge-0/0/16.0 {
supplicant single-secure;
guest-vlan 3;
}
ge-0/0/17.0 {
supplicant single-secure;
retries 2;
maximum-requests 2;
guest-vlan 3;
}
ge-0/0/21.0 {
supplicant single-secure;
guest-vlan 3;
}
ge-0/0/23.0 {
supplicant single-secure;
guest-vlan 3;
}
}
}
}
}



juniper# run show vlans
Name Tag Interfaces
Test 100
ae0.0, ae1.0, ge-0/0/0.0, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0
Trust 3
ae0.0, ae1.0, ge-0/0/12.0, ge-0/0/13.0, ge-0/0/14.0, ge-0/0/15.0, ge-0/0/23.0*
default
ge-0/0/16.0, ge-0/0/17.0, ge-0/0/21.0, ge-0/0/23.0*
! because ge-0/0/23.0 IEEE 802.1x authentication fail so change vlan membership to guest vlan 3
vlab 200
ae0.0, ae1.0, ge-0/0/4.0*, ge-0/0/5.0, ge-0/0/6.0, ge-0/0/7.0, ge-0/0/8.0, ge-0/0/9.0,
ge-0/0/10.0, ge-0/0/11.0


IEEE 802.1x

# set protocol dot1x transactions file dotxlog
# set protocol dot1x transactions flag dot1
# run show log
# run monitor start
# run monitor stop

juniper# show ethernet-switching-options
analyzer VLANSPAN {
input {
ingress {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
vlan Trust;
}
egress {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
}
output {
interface {
ge-0/0/5.0;
}
}
}


OSPF

juniper# show protocols ospf
area 0.0.0.0 {
interface vlan.100;
interface ge-0/0/15.0;
}


Loopback interface

juniper# set interfaces lo0 unit 0 family inet address 1.1.1.1/32


LLDP

juniper# run show lldp neighbors
LocalInterface Chassis Id Port info System Name
ge-0/0/14.0 00:1f:12:31:c1:40 ge-0/0/14.0 SW-R1
ge-0/0/15.0 00:1f:12:31:c1:40 ge-0/0/15.0 SW-R1


QoS

# set class-of-service forwarding-classes class FF queue-num 5
# set class-of-service forwarding-classes class AF queue-num 1
# set class-of-service forwarding-classes class BE queue-num 0
! 先定義Traffic Class對應的Queue Number

# set firewall family ethernet-switching filter QoS_Class term EF from source-address 192.168.3.200/32
# set firewall family ethernet-switching filter QoS_Class term EF from protocol udp destination-port 1234
# set firewall family ethernet-switching filter QoS_Class term EF then forwarding-class EF loss-priority low
# set firewall family ethernet-switching filter QoS_Class term AF from protocol tcp destination-port 80
# set firewall family ethernet-switching filter QoS_Class term AF then forwarding-class AF loss-priority low
# set firewall family ethernet-switching filter QoS_Class term BE then forwarding-class BE loss-priority high
! 再定義Filter QoS_Class整合不同的的Class,依據條件分別Assign至這些Class

# set interfaces ge-0/0/10 unit 0 family ethernet-switching filter input QoS_Class
# set interfaces ge-0/0/11 unit 0 family ethernet-switching filter input QoS_Class
! 在Physical Interface上套用Filter QoS_Class來進行Traffic Classification

# set class-of-service schedulers EF_Schedule priority strict-high
# set class-of-service schedulers AF_Schedule transmit-rate percent 30
# set class-of-service schedulers AF_Schedule priority low
# set class-of-service schedulers BE_Schedule transmit-rate percent 60
# set class-of-service schedulers BE_Schedule priority high
! 準備接下來的scheduler(queueing)將會進行的動作

# set class-of-service scheduler-maps QoS_SCH_MAP forwarding-class EF scheduler EF_Schedule
# set class-of-service scheduler-maps QoS_SCH_MAP forwarding-class AF scheduler AF_Schedule
# set class-of-service scheduler-maps QoS_SCH_MAP forwarding-class BE scheduler BE_Schedule
! 依據不同的Traffic Class套用之前定義好的scheduler,整合在同一個scheduler-maps QoS_SCH_MAP中

# set class-of-service interfaces ge-0/0/12 scheduler-map QoS_SCH_MAP
# set class-of-service interfaces ge-0/0/13 scheduler-map QoS_SCH_MAP
! 將整合後的scheduler-map套用至physical interface


Final Configuration

juniper# show
## Last changed: 2008-03-06 19:13:27 UTC
version 9.0R2.10;
system {
root-authentication {
encrypted-password "$1$ZlxV3U3G$llcI3VguUsmlwhqbto546."; ## SECRET-DATA
}
radius-server {
192.168.1.10 {
secret "$9$OIDZBcl8LNbYo7-"; ## SECRET-DATA
timeout 5;
}
}
login {
user juniper {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$AGAzBQkY$QWZ8BSLezx0d7Oh0j.NFw."; ## SECRET-DATA
}
}
}
services {
ssh {
root-login allow;
}
web-management {
http;
}
dhcp {
pool 192.168.200.0/24 {
address-range low 192.168.200.101 high 192.168.200.110;
router {
192.168.200.10;
}
}
pool 192.168.3.0/24 {
address-range low 192.168.3.101 high 192.168.3.105;
router {
192.168.3.2;
}
}
}
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
}
chassis {
aggregated-devices {
ethernet {
device-count 2;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/1 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/2 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/3 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/4 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/5 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/6 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/7 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/8 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/9 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/10 {
unit 0 {
family ethernet-switching {
filter {
input QoS_Class;
}
}
}
}
ge-0/0/11 {
unit 0 {
family ethernet-switching {
filter {
input QoS_Class;
}
}
}
}
ge-0/0/12 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/13 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/14 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members 100;
}
}
}
}
ge-0/0/15 {
unit 0 {
family inet {
address 172.16.15.2/29;
}
}
}
ge-0/0/16 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/17 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/18 {
ether-options {
802.3ad ae0;
}
}
ge-0/0/19 {
ether-options {
802.3ad ae0;
}
}
ge-0/0/20 {
ether-options {
802.3ad ae1;
}
}
ge-0/0/21 {
unit 0 {
family ethernet-switching {
port-mode access;
}
}
}
ge-0/0/22 {
ether-options {
802.3ad ae1;
}
}
ge-0/0/23 {
unit 0 {
family ethernet-switching;
}
}
ge-0/1/0 {
unit 0 {
family ethernet-switching;
}
}
xe-0/1/0 {
unit 0 {
family ethernet-switching;
}
}
ge-0/1/1 {
unit 0 {
family ethernet-switching;
}
}
xe-0/1/1 {
unit 0 {
family ethernet-switching;
}
}
ge-0/1/2 {
unit 0 {
family ethernet-switching;
}
}
ge-0/1/3 {
unit 0 {
family ethernet-switching;
}
}
ae0 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ Test vlab Trust ];
}
}
}
}
ae1 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ 100 3 ];
}
native-vlan-id 200;
}
}
}
vlan {
unit 3 {
family inet {
address 192.168.3.2/24;
}
}
unit 100 {
family inet {
address 192.168.100.2/24;
}
}
unit 200 {
family inet {
address 192.168.200.10/24;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface vlan.100;
interface ge-0/0/15.0;
}
}
lldp {
interface all;
}
dot1x {
traceoptions {
file dotxlog;
flag dot1x-debug;
flag eapol;
}
authenticator {
authentication-profile-name dot1x-lab;
static {
00:16:d3:33:aa:11 {
vlan-assignment 200;
}
}
interface {
ge-0/0/16.0 {
supplicant single-secure;
guest-vlan 3;
}
ge-0/0/17.0 {
supplicant multiple;
retries 2;
maximum-requests 2;
guest-vlan 3;
}
ge-0/0/21.0 {
supplicant single-secure;
guest-vlan 3;
}
ge-0/0/23.0 {
supplicant single-secure;
supplicant-timeout 10;
guest-vlan 3;
}
}
}
}
mstp {
bridge-priority 32k;
interface ae0.0 {
cost 1000;
mode point-to-point;
}
interface ae1.0 {
cost 1000;
mode point-to-point;
}
msti 1 {
bridge-priority 8k;
vlan 100;
}
msti 2 {
bridge-priority 4k;
vlan [ 200 3 ];
}
}
}
class-of-service {
forwarding-classes {
class EF queue-num 5;
class AF queue-num 1;
class BE queue-num 0;
class NC queue-num 7;
}
interfaces {
ge-0/0/12 {
scheduler-map QoS_SCH_MAP;
}
ge-0/0/13 {
scheduler-map QoS_SCH_MAP;
}
}
scheduler-maps {
QoS_SCH_MAP {
forwarding-class EF scheduler EF_Schedule;
forwarding-class AF scheduler AF_Schedule;
forwarding-class BE scheduler BE_Schedule;
}
}
schedulers {
EF_Schedule {
priority strict-high;
}
BE_Schedule {
transmit-rate percent 60;
priority low;
}
AF_Schedule {
transmit-rate percent 30;
priority low;
}
}
}
firewall {
family ethernet-switching {
filter QoS_Class {
term EF {
from {
source-address {
192.168.3.200/32;
}
protocol udp;
destination-port 1234;
}
then {
forwarding-class EF;
loss-priority low;
}
}
term AF {
from {
protocol tcp;
destination-port 80;
}
then {
forwarding-class AF;
loss-priority low;
}
}
term BE {
then {
forwarding-class BE;
loss-priority high;
}
}
}
}
}
access {
radius-server {
192.168.1.10 {
secret "$9$hymcK8-ds4JDwY"; ## SECRET-DATA
timeout 3;
retry 1;
}
}
profile dot1x-lab {
authentication-order radius;
radius {
authentication-server 192.168.1.10;
}
}
}
ethernet-switching-options {
secure-access-port {
interface ge-0/0/4.0 {
dhcp-trusted;
}
}
analyzer VLANSPAN {
input {
ingress {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
vlan Trust;
}
egress {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
}
output {
interface {
ge-0/0/5.0;
}
}
}
}
vlans {
Test {
vlan-id 100;
interface {
ge-0/0/0.0;
ge-0/0/1.0;
ge-0/0/2.0;
ge-0/0/3.0;
}
l3-interface vlan.100;
}
Trust {
vlan-id 3;
interface {
ge-0/0/12.0;
ge-0/0/13.0;
}
l3-interface vlan.3;
}
vlab {
vlan-id 200;
interface {
ge-0/0/4.0;
ge-0/0/5.0;
ge-0/0/6.0;
ge-0/0/7.0;
ge-0/0/8.0;
ge-0/0/9.0;
ge-0/0/10.0;
ge-0/0/11.0;
}
l3-interface vlan.200;
}
}
poe {
interface all;
}

[edit]
juniper#

Juniper EX Series Switch Workshop 筆記分享 Part I

上星期參加了Juniper原廠所舉辦的EX Series Switch Workshop,內容很多再加上時間有限,因此我利用打字的方式邊聽邊記錄重點下來,在此分享給各位,不過前提是最好對JUNOS有基本的認識不然可能看不太懂我筆記裏面的各項指令(事實上這也是我的JUNOS初體驗,不過如果有Cisco IOS指令的基礎,只要多花一點點時間很快就可以將JUNOS上手)

如果小弟的筆記有誤,還請各方大德給予指教修正,謝謝!

===============================================================================
Juniper Switch:
Model
3200
4200 (virtual chassis - 128G/redundant power)
8200 Q4
(all layer 3)

48 Port PoE need 930W

10G XFP can be virtual chassis
unsupport EtherChannel now
One Active/One Standby

USB - internal storage / firmware upgrade

Virtual Management Ethernet (VME)

IPv6/MPLS in the future(hardware ready)

NSM(all platform will use this interface)

PFE(Packer Forward Engine)

EX-PFE control 24 port

2 * VCP(Virtual chassis port)/64G(32G TX/32G RX) = 128G VCB(Virtual Chassis Backplane)

EX3200-24x/48x last 4 ports share with SPF

Extract Layer 2 Header then re-write Layer 2 with original packet

================================================================================

aka MAC address table/FDB(Forwarding Database)

"default" VLAN = NULL vlan-id

>family ethernet-switching(layer 2)
>family inet(layer 3)


>show ethernet-switching interface => check trunk and switch port status
>show ethernet-switching table => MAC table
>show vlans


RVI(Routed Virtual Interface) = VLAN interface

LAG(Link Aggregation Group)/aka Aggregated Ethernet(ae)
802.3ad LACP(Dynamic Bundling Protocol)

Up to 8 ports per group
.EX3200 32 groups
.EX4200 64 groups

Does not have to be contiguous ports

SW: Hashing(unconfigured now)


>show interface ae0

===============================================================================

IEEE Reserved MAC Address for BPDU - 01:80:C2:00:00:00

Juniper support CST(Common Spanning Tree)

ESWD(Enterprise Switch Daemon)

PVST+ VLAN 1 always advertises BPDU to IEEE STP multicast addresss(01:80:c2:00:00:00)
- interoperates with IEEE 802.1d

PVST+ advertised BPDUs on other VLANs with Cisco's reserved multicast address(01:00:0c:cc:cc:cd)

IEEE 802.1w(Rapid Spanning Tree Protocol, RSTP)
- BPDU Ver field = 0x02
- Alternet Port
- Backup Port

If a switch does not support RSTP will ignore RSTP BPDU, else it will reverts to 802.1d BPDU.

IEEE 802.1s(Multiple Spanning Tree Protocol, MST)
- map multiple VLANs to one or multiple instances
- Max of 64 instances
- Backward compatible with STP, RSTP via CST(Common Spanning Tree)
- CST across all MST regions
- MSTI(Multiple Spanning Tree Instance)


>edit protocol mstp

===============================================================================
Redundant Trunk Group(RTG)

RTG and STP are mutually exclusive on a given port

Maximum number of RTG per system/virtual chassis are 16

===============================================================================
Virtual Chassis:

Master Route Engine(RE0)
Backup Route Engine(RE1)

Virtual Chassis Control Protocol Daemons(VCCPd)

Master(Highest Priority)
Backup(Lower Priority)
Linecard(Lowest Priority)

Member ID(0~9)

Individual Ethernet management ports(me0)
- on member switches

Single L3 virtual management interface(vme)
- always follows the Master RE

GRES(Graceful Route Engine Switchover)

NSR(Non-stop Routing)(System Default)

Field Research Software (FRS)

Not support GRE tunnel port mirror now

===============================================================================
Power over Ethernet(PoE)
- IEEE 802.3af
- Power Sourcing Equipment(PSE)
- Powered Device(PD)
- class 0(15.4 watts)
- class 1(4 watts)
- class 2(7 watts)
- class 3(15.4 watts)
- class 4(Future Expansion)

If redundant power spec. are mismatch switch will use the lower one spec. output

Voice VLAN
- support CoS(IEEE 802.1p)
- Native VLAN(untagged VLAN) transport Data
- Voice VLAN(tagged VLAN) transport Voice

LLDP(Link Layer Discovery Protocol)
IEEE 802.1AB-2005
The Link Layer Discovery Protocol or LLDP is a vendor-neutral Layer 2 protocol that allows a network device to advertise its identity and capabilities on the local network.

LLDP-MED(Link Layer Discovery Protocol - Media Endpoint Discovery)
LLDP-MED is an enhancement to the Link Layer Discovery Protocol (LLDP) that is designed to allow for things such as:
- Auto-discovery of LAN policies (such as VLAN, Layer 2 Priority and Diffserv settings) leading to "plug and play" networking.
- Device location discovery to allow creation of location databases and, in the case of VoIP, E911 services.
- Extended and automated power management of Power over Ethernet endpoints.
- Inventory management, allowing network administrators to track their network devices, and determine their characteristics (manufacturer, software and hardware versions, serial / asset number).


The LLDP-MED protocol was formally approved and published as the standard ANSI/TIA-1057 by the Telecommunications Industry Association (TIA) in April 2006.

Multicast MAC Address:01-80-C2-00-00-0E
ethertype:88-CC

CDP(Cisco Discovery Protocol)
Multicast MAC Address:0100.0ccc.cccc

===============================================================================
DHCP snooping
- All access ports are untrusted by default
- All trunk ports are trusted by default

DAI(Dynamic ARP Inspection)
- Trunk port will bypass DAI
- DHCP snooping is required
- enabled/disable per VLAN

EAPOL(Extensible Authenticaion Protocol over LAN)

IEEE 802.1x
- Single
- Single-Secure
- Multiple

Guest VLAN
- when 802.1x authentication fail
- wehn client not response for 802.1x

VSA(Vendor Specific Attributes)

Firewall ACLs
- Port-based ACL
- VLAN-based
- Router-based

Firewall Filter(FF)
- nput
Port FF => VLAN FF => Router FF
- Output
Router FF => VLAN FF => Port FF(Port FF not supported now)
===============================================================================
Port Mirror

- Physical ports(ingress/egress)
- VLANs(ingress only)
- Tunnel interface (in the future)

- Local Analyzer(L2 header will not be modified)
- Remote Analyzer(Original VLAN ID tag will be added with the intermediate VLAN used to transport the mirrored packets)

one port-mirroring session per system (so far)
- 1 destionation port
- 1 vlan
- 1 tunnel (in the future)

===============================================================================
QoS(Quality of Service)
- L2 CoS(Class of Service)
- L3 ToS(Tyoe of Service)

FC(Forwarding Class)
LP(Lost Priority)

Support 8 queues per port(Network, CPU & VCP(Virtual chassis port))

16 FCs
Default :
4FC
BE(Best-Effort)(Queue 0),
AF(Assure-Forwarding)(Queue 1),
EF(Expedited-Forwarding)(Queue 5),
NC(Network Control)(Queue 7)

PFEM(Packet Forwarding Engine)

>show cos forwarding-class table
>show halp-cos qos-attribs profile all


BA(Behavior Aggregate)

- L2 Access port: default is "untrust"
- L2 Trunk port: default is "trust 802.1p"
- L3 Physcial interface: default is "trust DSCP"


#set class-of-service classifiers
>show class-of-service classifier name
>show cos classifier


CoS Traffic Policing
- Limits inbound transmission
- ACL-based traffic policing
- 1-rate 2-color policers
. Single token bucket
. CIR(Commit Information Rate) + CBS(Commit Burst Size) "in-profile" are passed through
. CIR + CBS "out-profile" are dropped


# set firewall policer QOS if-exceeding bandwidth-limit 64000 burst-size-limit 128
# set interfaces ge-0/0/16.0 family inet filter ..


PFE(Packet Forwarding Engine)
- Packet memory consists of fixed-length 256 bytes buffers

Egress Queueing and Scheduling
SP(Strict-Priority)
SDWRR(Shaped Deficit Weighted Round Robin)
- SP queue must always be the highest numbered
- Tail-drop


>set class-of-service drop-profiles ..
>set class-of-service shcedulers ..



#run show class-of-service scheduler-map
>show halp-cos scheduler dev 0 port 21


VC Port Remapping/Scheduling
- Not user-configurable - fixed

PPP Over Frame Relay

Feature Summary
The PPP over Frame Relay feature allows a router to establish end-to-end Point-to-Point Protocol (PPP) sessions over Frame Relay. IP datagrams are transported over the PPP link using RFC 1973 compliant Frame Relay framing. This feature is useful for remote users running PPP to access their Frame Relay corporate networks as shown in . shows a connectivity scenario using the Cisco 90i D4 channel card, which is capable of supporting Integrated Services Digital Network (ISDN) Digital Service Loop (DSL), PPP, or Frame Relay, which connects to an Internet Service Provider (ISP) or corporate network.

Figure 1


PPP Over Frame Relay Scenario

Figure 2 PPP over Frame Relay Using the Cisco 90i D4 Channel Unit



Benefits
PPP over Frame Relay provides the following benefits:
‧Allows end-to-end PPP sessions over Frame Relay.
‧Supports the 90i IDSL Channel Unit that supports both Frame Relay and Point-to-Point Protocol (PPP) on an ISDN DSL.

List of Terms
data-link connection identifier (DLCI)— A value that specifies a PVC or SVC in a Frame Relay network. In the basic Frame Relay specification, DLCIs are locally significant (connected devices might use different values to specify the same connection). In the LMI extended specification, DLCIs are globally significant (DLCIs specify individual end devices).
Integrated Services Digital Network (ISDN)—Communication protocols offered by telephone companies that permit telephone networks to carry data, voice, and other source traffic.
Link Control Protocol (LCP)—A protocol that establishes, configures, and tests data link connections used by PPP.
permanent virtual circuit (PVC)—Virtual circuit that is permanently established. PVCs save bandwidth associated with circuit establishment and tear down in situations where certain virtual circuits must exist all the time.
Point-to-Point Protocol (PPP)—A protocol that encapsulates network layer protocol information over point-to-point links. The RFC for PPP is RFC 1661.
virtual circuit (VC)—A logical circuit created to ensure reliable communication between two network devices. A virtual circuit can be either permanent (a PVC) or switched (an SVC). Virtual circuits are used in Frame Relay and X.25.

Restrictions
The following restrictions apply when using PPP over Frame Relay:
‧Only Frame Relay PVCs are supported.
‧Only the Internet Protocol (IP) is supported.

Platforms
This feature is supported on these platforms:
‧Cisco 1600 series
‧Cisco 2500 series
‧Cisco 2600 series
‧Cisco 3600 series
‧Cisco 4000 series (Cisco 4000, 4000-M, 4500, 4500-M, 4700, 4700-M)
‧Cisco 7200 series
‧Cisco 7500 series

Prerequisites
Before you can configure PPP over Frame Relay, Frame Relay must be enabled on the router using the encapsulation frame-relay command.

Functional Description
PPP over Frame Relay is compliant to the functionality and encapsulation specifications as outlined in RFC 1973. The frame format is shown in .
A PPP connection is established over the Frame Relay permanent virtual circuit (PVC). The PPP session does not occur unless the associated Frame Relay PVC is in an "active" state. The Frame Relay VC can coexist with other circuits using different Frame Relay encapsulation methods, such as RFC 1490 and Cisco proprietary, over the same Frame Relay link. There can be multiple PPP-in-Frame Relay circuits existing on one Frame Relay link.
One PPP connection resides on one virtual access interface, which is internally created from a virtual template interface. A virtual access interface is cloned from a virtual template interface. The virtual access interfaces is coexistent with the creation of the Frame Relay circuit when the corresponding DLCI is configured. One virtual template interface, containing all the necessary PPP and network protocol information is shared by multiple virtual access interfaces. Hardware compression and fancy queuing algorithms, such as weighted fair queuing, custom queuing, and priority queuing, are not applied to virtual access interfaces. Once a Frame Relay circuit is established using PPP over Frame Relay, all incoming and outgoing packets on this circuit are under RFC 1973 PPP-in-Frame-Relay encapsulation compliance until this DLCI is removed from the configuration. Refer to the Cisco IOS Release 11.3 Wide Area Configuration Guide and Command Reference documents for information about Frame Relay configuration options.

Figure 3 PPP over Frame Relay Frame Format


The breakdown of the Frame Relay frame format components is listed in .

Configuration Task
The only task required to implement PPP over Frame Relay is to configure the interface with the locally terminated PVC and the associated virtual template for PPP and IP, as described in the following section.

Enable PPP over Frame Relay
After you configure the Cisco router or access server for Frame Relay encapsulation, you must configure the physical interface with the PVC and apply a virtual template with PPP encapsulation to the DLCI that it applies to. To configure the physical interface that will carry the PPP session and link it to the appropriate virtual template interface, perform the following task in interface configuration mode:


Configuration Examples
This section provides the following examples:
PPP over Frame Relay DTE Example
PPP over Frame Relay DCE Example

PPP over Frame Relay DTE Example
The following example configures a router as a data terminating equipment (DTE) device for PPP over Frame Relay. Subinterface 2.1 contains the necessary DLCI and virtual template information. The virtual template interface (interface virtual-template 1) contains the PPP information that is applied to the PPP session associated with DLCI 32 on serial subinterface 2.1. Refer to the Cisco IOS Release 11.3 Wide-Area Configuration Guide and Wide-Area Networking Command Reference for information about Frame Relay configuration options.

interface serial 2
no ip address
encapsulation frame-relay
frame-relay lmi-type ansi
!
interface serial 2.1 point-to-point
frame-relay interface-dlci 32 ppp virtual-template1
!
interface Virtual-Template1
ip unnumbered ethernet 0
ppp authentication chap pap

Note:By default, the encapsulation type for a virtual template interface is PPP encapsulaiton; therefore, encapsulation ppp will not show up when viewing the router's configuration.

PPP over Frame Relay DCE Example
The following example configures a router to act as a data communications equipment (DCE) device. Typically, a router is configured for a DCE if connecting directly to another router or if connected to a 90i D4 channel unit, which is connected to a telco channel bank. The three commands required for this type of configuration are the frame-relay switching, frame-relay intf-type dce, and frame-relay route commands. In this configuration

frame-relay switching
!
interface Serial2/0:0
no ip address
encapsulation frame-relay IETF
frame-relay lmi-type ansi
frame-relay intf-type dce
frame-relay route 31 interface Serial1/2 100
frame-relay interface-dlci 32 ppp Virtual-Template1
!
interface Serial2/0:0.2 point-to-point
no ip address
frame-relay interface-dlci 40 ppp Virtual-Template2
!
interface Virtual-Template1
ip unnumbered Ethernet0/0
peer default ip address pool default
ppp authentication chap pap
!
interface Virtual-Template2
ip address 100.1.1.2 255.255.255.0
ppp authentication chap pap

Note:By default, the encapsulation type for a virtual template interface is PPP encapsulaiton; therefore, encapsulation ppp will not show up when viewing the router's configuration.

ip pim bsr-border

To prevent bootstrap router (BSR) messages from being sent or received through an interface, use the ip pim bsr-border command in interface configuration mode. To disable this configuration, use the no form of this command.

ip pim bsr-border
no ip pim bsr-border

Usage Guidelines
When this command is configured on an interface, no Protocol Independent Multicast (PIM) Version 2 BSR messages will be sent or received through the interface. Configure an interface bordering another PIM domain with this command to avoid BSR messages from being exchanged between the two domains. BSR messages should not be exchanged between different domains, because routers in one domain may elect rendezvous points (RPs) in the other domain, resulting in protocol malfunction or loss of isolation between the domains.

Note This command does not set up multicast boundaries. It sets up only a PIM domain BSR message border.

Examples
The following example configures the interface to be the PIM domain border:

interface ethernet 1
ip pim bsr-border

Multicast-VPN/IP Multicast Support for MPLS VPNs

Feature Overview
This Multicast-VPN—IP Multicast Support for MPLS VPNs feature allows a service provider to configure and support multicast traffic in a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) environment. This feature supports routing and forwarding of multicast packets for each individual VPN routing and forwarding (VRF) instance, and it also provides a mechanism to transport VPN multicast packets across the service provider backbone.
The Multicast-VPN feature in Cisco IOS software provides the ability to support the multicast feature over a Layer 3 VPN. As enterprises extend the reach of their multicast applications, service providers can accommodate these enterprises over their MPLS core network. IP multicast is used to stream video, voice, and data to a MPLS VPN network core.
A VPN is network connectivity across a shared infrastructure, such as an internet service provider (ISP). Its function is to provide the same policies and performance as a private network, at a reduced cost of ownership, thus creating many opportunities for cost savings through operations and infrastructure.
Historically, IP in IP generic route encapsulation (GRE) tunnels was the only way to connect through a service provider network. Although such tunneled networks tend to have scalability issues, they represent the only means of passing IP multicast traffic through a VPN.
MPLS was derived from tag switching and various other vendor methods of IP-switching support enhancements in the scalability and performance of IP-routed networks by combining the intelligence of routing with the high performance of switching. MPLS is now used for VPNs, which is an appropriate combination because MPLS decouples information used for forwarding of the IP packet (the label) from the information carried in the IP header.
A Multicast-VPN allows an enterprise to transparently interconnect its private network across the network backbone of a service provider. The use of a Multicast-VPN to interconnect an enterprise network in this way does not change the way that enterprise network is administered, nor does it change general enterprise connectivity.
Because MPLS VPNs support only unicast traffic connectivity, deploying the Multicast-VPN feature in conjunction with MPLS VPN allows service providers to offer both unicast and multicast connectivity to MPLS VPN customers.

Multicast-VPN Routing and Forwarding and Multicast Domains
Multicast-VPN introduces multicast routing information to the VPN routing and forwarding table. When a provider-edge (PE) router receives multicast data or control packets from a customer-edge (CE) router, forwarding is performed according to the information in the Multicast VRF (MVRF).
A set of Multicast-VPN Routing and Forwarding that can send multicast traffic to each other constitutes a multicast domain. For example, the multicast domain for a customer that wanted to send certain types of multicast traffic to all global employees would consist of all CE routers associated with that enterprise.

Multicast Distribution Trees
Multicast-VPN establishes a static default multicast distribution tree (MDT) for each multicast domain. The default MDT defines the path used by PE routers to send multicast data and control messages to every other PE router in the multicast domain.
Multicast-VPN also supports the dynamic creation of MDTs for high-bandwidth transmission. Data MDTs are a feature unique to Cisco IOS software. Data MDTs are intended for high-bandwidth sources such as full-motion video inside the VPN to ensure optimal traffic forwarding in the MPLS VPN core. The threshold at which the data MDT is created can be configured on a per-router or a per-VRF basis. When the multicast transmission exceeds the defined threshold, the sending PE router creates the data MDT and sends a User Datagram Protocol (UDP) messages, which contains information about the data MDT to all routers in the default MDT. The statistics to determine whether a multicast stream has exceeded the data MDT threshold are examined once every 10 seconds. If multicast distributed switching is configured, the time period can be up to twice as long.
Data MDTs are created only for (S, G) multicast route entries within the VRF multicast routing table. They are not created for (*, G) entries regardless of the value of the individual source data rate.
In the following example, a service provider has a multicast customer with offices in San Jose, New York, and Dallas. A one-way multicast presentation is occurring in San Jose. The service provider network supports all three sites associated with this customer, in addition to the Houston site of a different enterprise customer.
The default MDT for the enterprise customer consists of provider routers P1, P2, and P3 and their associated PE routers. PE4 is not part of the default MDT, because it is associated with a different customer. Figure 1 shows that no data flows along the default MDT, because no one outside of San Jose has joined the multicast.

Figure 1 Default Multicast Distribution Tree Overview




An employee in New York joins the multicast session. The PE router associated with the New York site sends a join request that flows across the default MDT for the multicast domain of the customer. PE1, the PE router associated with the multicast session source, receives the request. Figure 2 depicts that the PE router forwards the request to the CE router associated with the multicast source (CE1a).

Figure 2 Initializing the Data MDT




The CE router (CE1a) begins to send the multicast data to the associated PE router (PE1), which sends the multicast data along the default MDT. Immediately sending the multicast data, PE1 recognizes that the multicast data exceeds the bandwidth threshold as which a data MDT should be created. Therefore, PE1 creates a data MDT, sends a message to all routers using the default MDT that contains information about the data MDT, and, three seconds later, begins sending the multicast data for that particular stream using the data MDT. Only PE2 has interested receivers for this source, so only PE2 will join the data MDT and receive traffic on it.
PE routers maintain a PIM relationship with other PE routers over the default MDT as well as a PIM relationship with its directly attached PE routers.

Multicast Tunnel Interface
For every multicast domain of which an MVRF is a part, the PE router creates a multicast tunnel interface. A multicast tunnel interface is an interface the MVRF uses to access the multicast domain. It can be thought of as a conduit that connects an MVRF and the global MVRF. One tunnel interface is created per multicast VRF.

Multicast Distributed Switching Support
Multicast distributed switching (MDS) is supported for Multicast-VPN on the Cisco 7500 series routers. When MDS is configured, ensure that all interfaces enabled for IP multicast have MDS enabled correctly—verify that no interface has the no ip mroute-cache command configured (including loopback interfaces).
Use the following commands to enable MDS for a particular VRF:

ip multicast-routing distributed
ip multicast-routing vrf vrf-name distributed


The following example shows how to configure MDS on Ethernet interface 1/1/1:
interface ethernet 1/1/1
ip mroute-cache distributed


Benefits
‧Provides a scalable solution to dynamically send information to multiple locations.
‧Provides high-speed information delivery.
‧Provides connectivity through a shared infrastructure.

Restrictions
‧If the core multicast routing is using Source Specific Multicast (SSM), then the data and default MDT groups must be configured within the SSM range of IP addresses by default.
‧The update source interface for the Border Gateway Protocol (BGP) peerings must be the same for all BGP peerings configured on the router in order for the default MDT to be configured properly. If you use a loopback address for BGP peering, then PIM sparse mode must be enabled on the loopback address.
‧The ip mroute-cache command must be enabled on the loopback interface used as the BGP peering interface in order for distributed multicast switching to function on the platforms that support it. The no ip mroute-cache command must not be present on these interfaces.
‧MPLS Multicast does not support multiple BGP peering update sources.
‧Data MDTs are not created for VRF PIM dense mode multicast streams because of the flood and prune nature of dense mode multicast flows and the resulting periodic bring-up and tear-down of such data MDTs.
‧Multiple BGP update sources are not supported and configuring them can break Multicast-VPN RPF checking. The source IP address of the Multicast-VPN tunnels is determined by the highest IP address used for the BGP peering update source. If this IP address is not the IP address used as the BGP peering address with the remote PE router, Multicast-VPN will not function properly.

Configuration Tasks
See the following sections for configuration tasks for this feature. Each task in the list is identified as either required or optional.
Enabling a VPN for Multicast Routing (required)
Enabling PIM on Interfaces (required)
Configuring a Default MDT Group for a VPN VRF (required)
Configuring the Multicast Group Address Range for Data MDT Groups (optional)
Recording Data MDT Reuse (optional)
Configuring the IP Source Address of Register Messages (required)
Storing IP Multicast Packet Headers (required)
Configuring an MSDP Peer (optional)
Limiting the Number of Multicast Routes (optional)
Filtering Multicast Router Information Request Packets (optional)

Enabling a VPN for Multicast Routing
To enable IP multicast routing, use the following command in global configuration mode:

Router(config)# ip multicast-routing vrf vrf-name


Enabling PIM on Interfaces
Configure Protocol Independent Multicast (PIM) on all interfaces used for IP multicast. We recommend configuring PIM sparse mode on all physical interfaces of Provider Edge (PE) routers connecting to the backbone. We also recommend configuring PIM sparse mode on all loopback interfaces if they are used for BGP peering or if their IP address is used as an RP address for PIM.
To configure PIM on an interface to be in sparse mode, use the following command in interface configuration mode:

Router(config-if)# ip pim sparse-mode


Configuring a Default MDT Group for a VPN VRF
To configure a default MDT group for a VRF, use the following commands beginning in global configuration mode:

Router(config)# ip vrf vrf-name
Router(config-vrf)# mdt default group-address


Configuring the Multicast Group Address Range for Data MDT Groups
To configure the multicast group address range for data MDT groups, use the following commands beginning in global configuration mode:

Router(config)# ip vrf vrf-name
Router(config-vrf)# mdt data group-address-range wildcard-bits [threshold threshold-value] [list access-list]


Recording Data MDT Reuse
To enable the recording of data MDT reuse, use the following commands beginning in global configuration mode.

Router(config)# ip vrf vrf-name
Router(config-vrf)# mdt log-reuse


Configuring the IP Source Address of Register Messages
Register messages are unicast messages sent by the designated router (DR) to the RP router when a multicast packet needs to be sent on a rendezvous point tree (RPT). By default, the IP source address (SA) of the register message is set to the address of the outgoing interface of the DR leading toward the RP. To configure the IP source address of a register message to an interface address other than the outgoing interface address of the DR leading toward the RP, use the following command in global configuration mode. The optional vrf vrf-name argument has been added to ip pim register-source commands to define the VPN routing instance by assigning a VRF name.

Router(config)# ip pim [vrf vrf-name] register-source type interface-number


Storing IP Multicast Packet Headers
You can store IP multicast packet headers in a cache and then display them to determine any of the following information:
‧Who is sending IP multicast packets to what groups
‧Interpacket delay
‧Duplicate IP multicast packets (if any)
‧Multicast forwarding loops in your network (if any)
‧Scope of the group
‧UDP port numbers
‧Packet length
To allocate a circular buffer to store IP multicast packet headers that the router receives, use the following command in global configuration mode. The optional vrf vrf-name argument has been added to ip multicast commands to define the VPN routing instance by assigning a VRF name:

Router(config)# ip multicast [vrf vrf-name] cache-headers [rtp]


Configuring an MSDP Peer
To configure a Multicast Source Discovery Protocol (MSDP) peer, use the following command in global configuration mode. The optional vrf vrf-name argument has been added to ip msdp commands to define the VPN routing instance by assigning a VRF name:

Router(config)# ip msdp [vrf vrf-name] peer {peer-name peer-address} [connect-source type number] [remote-as as-number]


Limiting the Number of Multicast Routes
To limit the number of multicast routes that can be added in a router, use the following command in global configuration mode.

Router(config)# ip multicast route-limit limit threshold


Filtering Multicast Router Information Request Packets
To limit the number of multicast routes that can be added in a router, use the following command in global configuration mode.

Router(config)# ip multicast mrinfo-filter acl


Verifying the MSDP Peer
To display detailed information about and to verify information regarding the MSDP peer, perform the following steps.

Step 1 Enter the show ip msdp peer command to verify detailed information about MSDP peer

Router# show ip msdp peer 224.135.250.116


Step 2 Enter the show ip msdp summary to display MSDP peer status:

Router# show ip msdp summary


Verifying Information for the MDT Default Group
To display information about and to verify information about the BGP advertisement of the route distinguisher (RD) for the MDT default group, use the show ip pim mdt bgp command in EXEC mode.

Router# show ip pim mdt bgp


Verifying Information for the MDT Data Group
To display detailed information about and to verify information regarding the MDT data group, perform the following steps.

Step 1 Enter the show ip pim mdt receive command to show the data MDT advertisements received by a specified router:

Router# show ip pim vrf vpn8 mdt receive detail


Step 2 Enter the show ip pim mdt send command to show the MDT advertisements that a specified router has made:

Router# show ip pim mdt send


Step 3 Enter the show ip pim mdt history command to display the data MDTs that have been reused during the past configured interval.

Configuration Examples
This section provides the following configuration examples:
Enabling a VPN for Multicast Routing Example
Configuring the Multicast Group Address Range for Data MDT Groups Example
Configuring the IP Source Address of Register Messages Example
Storing IP Multicast Packet Headers Example
Configuring an MSDP Peer Example
Limiting the Number of Multicast Routes Example

Enabling a VPN for Multicast Routing Example
In the following example, Multicast routing is enabled with a VPN routing instance named of vrf1:

Router(config)#ip multicast-routing vrf1


Configuring the Multicast Group Address Range for Data MDT Groups Example
In the following example, the VPN routing instance is assigned a VRF name of blue. The MDT default group for a VPN VRF is 239.1.1.1, and the multicast group address range for MDT groups is 239.1.2.0 with wildcard bits of 0.0.0.3:

Router(config)# ip vrf blue
Router(config-vrf)# rd 55:1111
Router(config-vrf)# route-target both 55:1111
Router(config-vrf)# mdt default 239.1.1.1
Router(config-vrf)# mdt data 239.1.2.0 0.0.0.3
Router(config-vrf)# end


Configuring the IP Source Address of Register Messages Example
In the following example, the IP source address of the register message is configured to the E1 interface of a DR:

Router(config)# ip pim register-source E1/0/1
Router> show running-config incl register
ip pim register-source Ethernet1/0/1



Storing IP Multicast Packet Headers Example
In the following example, a circular buffer is allocated to store IP multicast packet headers that the router receives. The VPN routing instances in this example are named vrf1 and vrf2:

Router(config)# ip multicast vrf vrf1 cache-headers
Router(config)# ip multicast vrf vrf2 cache-headers
Router> show running-config
Building configuration...
Current configuration :3552 bytes
!
Last configuration change at 16:52:30 UTC Fri May 31 2002
!
Version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
no service single-slot-reload-enable
!
hostname Router
!
.
.
.
ip vrf vrf1
rd 55:111
route-target export 55:111
route-target import 55:111
mdt default 232.1.1.1
!
ip vrf vrf2
rd 55:112
route-target export 55:112
route-target import 55:112
mdt default 232.2.2.2
!
ip multicast-routing distributed
ip multicast-routing vrf vrf1 distributed
ip multicast-routing vrf vrf2 distributed
ip multicast vrf vrf1 cache-headers
ip multicast vrf vrf2 cache-headers
ip cef distributed
.
.
.
interface Ethernet1/0/3.1
encapsulation dot1Q 1 native
ip vrf forwarding vrf1
ip address 20.1.1.1 255.255.255.0
no ip redirects
no ip proxy-arp
ip pim sparse-dense-mode
no keepalive
no cdp enable
!
interface Ethernet1/0/3.2
encapsulation dot1Q 2
ip vrf forwarding vrf2
ip address 20.1.1.2 255.255.255.0
no ip redirects
no ip proxy-arp
ip pim sparse-dense-mode
no keepalive
no cdp enable
.
.
address-family ipv4 vrf vrf2
redistribute connected
redistribute static
redistribute rip metric 50
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf vrf1
redistribute connected
redistribute static
redistribute rip metric 50
no auto-summary
no synchronization
exit-address-family
.
.
.
end



Configuring an MSDP Peer Example
In the following example, an MSDP peer is configured with a VPN routing instance named of vrf1 and a source of 10.10.0.1 from E1 interface:

ip msdp vrf vrf1 peer 10.10.0.1 connect-source E1/0/1



Limiting the Number of Multicast Routes Example
In the following example, the number of multicast routes that can be added in to a multicast routing table is set to 200,000 and the threshold value of the number of mroutes that will cause a warning message to occur is set to 20,000:

Router# show running-config
ip multicast-routing distributed
ip multicast-routing vrf cisco distributed
ip multicast cache-headers
ip multicast route-limit 200000 20000
ip multicast vrf cisco route-limit 200000 20000
no mpls traffic-eng auto-bw timers frequency 0
!
.
.
.