Mar 18, 2010

WiMAX業者下半年擬推VOIP,搶語音電信市場


精實新聞 2010-03-17 19:31:06 記者 方巧文 報導
WiMAX網路電話VOIP(Voice over Internet Protocol)戰火即將在今年下半年展開! 4G WiMAX由於擁有比現有3G3.5G更大的頻寬,業者的服務多強調快速上網。不過,除了行動以及藉由家用路由器將上網範圍擴至室內,WiMAX業者也已計畫推出低價的網路語音電話服務,使WiMAX的業務更為健全,進一步搶食既有3G電信業者的市場。
南區與北區的WiMAX業者大同電信與全球一動,已不約而同宣布可望在今年下半年推出VOIP服務。其中,大同電信將與正文(4906)轉投資持股25.32%的普羅通信的FreePP合作,聚焦在純固網的VOIP服務。
而全球一動總經理蔡木源則大聲宣佈,VOIP將是公司今年的重點項目,預計今年下半年將會開始佈建並提供服務。全球一動與大同電信不同的地方,在於全球一動除了純固網的VOIP外,公司還會推出需要訊號覆蓋率較好的行動VOIP。
VOIP約略可分為2種,一種是採純固網的方式,例如skype,另一種則是行動式的VOIP,即是在外用手機進行語音通話。由於行動VOIP需要較好的訊號覆蓋率,且區域型的WiMAX營運商還須以已有漫遊規範為前提才能提供較完整的全區性服務,因此目前即使是在國外,也還沒有業者正式推出可通行全國的行動WiMAX語音VOIP服務。
大同電信表示,公司之前在M-Taiwan計畫時,已有推出固網VOIP服務,今年下半年則會讓該服務正式商轉,預計將搭配indoor CPE推出相關方案;搭配硬體則將包括由精英(2331)製造、可將WiMAX訊號轉換成WiFI的可攜式路由器(暱稱方塊酥)。
至於行動VOIP方面,大同電信認為,若是在訊號覆蓋率還不夠完善、無法與既有2G3G匹敵的狀況下就推出該服務,可能反而會有負面效果。不過,大同電信對於全球一動擬推出行動VOIP一事仍表樂觀其成。目前WiMAX業者多已拿到由主管機關分配的電話號碼,如大同是09006。
在全球一動方面,目前宏達電(2498)與採聯發科(2454)解決方案的手機都已通過測試。惟目前因WiMAX手機單價仍高,一支採購價高達2萬元,蔡木源認為,手機採購價要降到1.5萬元左右時,才可能有消費者較能接受的終端售價。為解決此狀況,全球一動有可能會在近期與美國WiMAX業者Clearwire商討共同採購的可能。
業者指出,新傳輸技術(如WiMAX)要成功,要有DNA的配合,D即是device,N是network,A是application。目前國內的WiMAX業者在N與A方面都已漸上軌道,而D的關鍵則在於相關終端廠的產品單價何時可以降至可拓增普及率的水準。而市場認為,WiMAX終端要降價到消費者可接受的範圍,最快的時間點應還是要等到今年第4季。
蔡木源指出,目前既有電信業者的主要營收來源,還是來自於語音通話,估計每年語音收入約有1,000~2,000億元的規模。從這樣的市場看來,不難了解WiMAX業者積極佈局語音業務的考量。他也強調,全球一動未來推出的行動VOIP資費一定是很大眾化的,「將會引起市場風暴」。

Mar 16, 2010

Cisco 360 Learning Program Core Knowledge Waiver


Beginning April 1, 2010, Cisco will allow Cisco 360 Learning Program students who attend a Cisco CCIE® Routing and Switching or CCIE Voice workshop to request a waiver and skip the Core Knowledge Section of the CCIE lab exam.  All waiver requests must be approved by the workshop instructor.  No end date for the Core Knowledge Waiver has been announced, but Cisco will provide at least 60 days’ notice before discontinuing the waiver.

During a Cisco 360 Learning Program workshop, students complete a series of performance assessments that demonstrate their understanding of the CCIE material and serve the same purpose as the Core Knowledge section of the exam.  Therefore, Cisco 360 Learning Program students who use the waiver will not be required to type out answers to the Core Knowledge questions and will be allowed to move immediately to the next section of the lab exam.

To qualify for the waiver, workshop students should contact their instructor 45 days in advance of their scheduled lab exam and provide the following information:

  • Student's name
  • Student's email address
  • Student’s Cisco.com username
  • Name, date, and location of workshop attended
  • Student’s scheduled lab date and location

Feb 23, 2010

ip wccp redirect exclude in

The ip wccp redirect exclude in command should be used on interfaces facing WAAS devices when outbound redirection is configured on other interfaces on the device.  Let's say you have a simple configuration where the router has three interfaces - one LAN facing, one WAN facing, and one used for the WAAS device:

!
interface FastEthernet0/0

  description ** LAN Interface **
  ip address 10.10.10.1 255.255.255.0

  duplex auto
  speed auto
!
interface FastEthernet0/1
  description ** WAAS Interface **
  ip address 11.11.11.1 255.255.255.248

  duplex auto
  speed auto
!        
interface FastEthernet1/0
  description ** WAN Interface **
  ip address 10.88.81.99 255.255.255.248
  duplex auto
  speed auto
!


You have two choices for how to apply WCCP here:

  1. Configure inbound redirection on the LAN (FastEthernet0/0) and WAN (FastEthernet1/0) interfaces.
  2. Configure WCCP inbound and outbound on the WAN (FastEthernet1/0) interface.

With option #2, you also need to configure the ip wccp redirect exclude in command on the WAAS interface (FastEthernet0/1).  Otherwise WCCP will not be able to distinguish between traffic coming from the LAN (FastEthernet0/0) and WAAS (FastEthernet0/1) interfaces.  Your final configuration for option #2 would look like this:

!
ip wccp 61
ip wccp 62
!
interface FastEthernet0/0

  description ** LAN Interface **
  ip address 10.10.10.1 255.255.255.0

  duplex auto
  speed auto
!
interface FastEthernet0/1
  description ** WAAS  Interface **
  ip address 11.11.11.1 255.255.255.248

  ip wccp redirect exclude in
  duplex  auto
  speed auto
!        
interface FastEthernet1/0
  description  ** WAN Interface **
  ip address 10.88.81.99 255.255.255.248

  ip wccp 61 redirect in
  ip wccp 62 redirec out
  duplex  auto
  speed auto

Feb 20, 2010

Cisco Announces New Service Provider Operations Track

Built on the growing demand for dedicated professionals who can manage, maintain and troubleshoot complex service provider IP NGN core network infrastructures, Cisco is introducing a new Service Provider (SP) Operations track. This new track is focused on developing associate, professional and expert-level capabilities to operate large, complex SP networks. These new, first of their kind certifications are designed specifically for Cisco Service Provider Customers, Partners and Cisco Networking Engineers.


Over the coming months Cisco will release new CCIE, CCNP, and CCNA SP Operations courses and exams. In addition, the written exam topics for the CCIE SP Operations certification are now available on the Cisco Learning Network. The CCIE SP Operations written exam is scheduled for release in the second quarter of 2010.



CCIE SP Operations Certification

The Cisco CCIE SP Operations certification assesses and validates core IP NGN service provider operations expertise.  Candidates who pass the CCIE SP Operations certification exams demonstrate skills required of a expert-level (Tier III or Tier IV support) operations engineer to troubleshoot and maintain complex service provider IP NGN core (PE-PE and PE-CE) network infrastructures in both IOS and IOS XR operating environments, plus validate broad theoretical knowledge of operations management processes, frameworks, and network management systems.

CCIE SP Operations Certification benefits:
  • Certification helps qualify personnel for customer’s Operations (NOC) Centers
  • Provides a credential (certification) that a person holds significant knowledge in SP Operations
  • Provides expert level certification to network operations (i.e. NOC) personnel to validate they are qualified to support various Build-Operate Transfer operation models

The CCIE SP Operations written exam is scheduled for release in the second quarter of 2010. The practical exam is scheduled for release in the third quarter of 2010.


CCNP SP Operations Certification

The Cisco Certified Network Professional  in Service Provider Operations (CCNP SP Operations) validates knowledge and skills required (of a Tier II or Tier III support engineer) to troubleshoot and maintain service provider IP NGN core (PE-PE and PE-CE) network infrastructures.  With a CCNP SP Operations certification, a network professional demonstrates the knowledge and skills required to isolate network performance problems, implement proactive fault measures using operations management processes, frameworks, and network management systems. The CCNP SP Operations curriculum includes maintaining carrier class routing protocol environments, MPLS VPN and TE deployments, and QoS mechanisms using Cisco IOS and IOS XR.

CCNP SP Operations Certification benefits:
  • Certification helps qualify personnel for customers Operations Centers
  • Certification classes provide a developmental path for personnel in Operations
  • Provides advanced level training and certification to network operations (i.e. NOC) personnel

The Cisco CCNP SP Operations certification will be made available in the third quarter of 2010.


CCNA SP Operations Certification

Cisco Certified Network Associate in Service Provider Operations (CCNA SP Operations) validates basic knowledge and skills (of a Tier I support engineer) in a prescriptive troubleshooting environment within carrier class IP NGN core network infrastructure.  CCNA SP Operations curriculum includes incident (event), fault, configuration, change, and performance management procedures, along with NMS tools and protocols.

CCNA SP Operations Certification benefits:
  • Provides students with a foundation of network operations skills for SP NGN environments
  • Provides training and certifications around Network Operations job role
  • Provides entry level training and certification to entry level network operations (i.e. NOC) personnel

The CCNA SP Operations certification is scheduled to be released in the second quarter of 2010.

Feb 11, 2010

Cisco's Plan for Service Providers in the Mobile Internet Age

Cisco's Plan for Service Providers in the Mobile Internet Age

As mobile networks feel the strain, Cisco's Pankaj Patel says the company's newly fortified mobile Internet portfolio can help service providers prepare for the future

February 9, 2010
Weeks after its recently completed acquisition of Starent Networks, Cisco Systems is holding its first show-and-tell, revealing why the mobile infrastructure supplier was a must-have item last Christmas.

At Mobile World Congress in Barcelona, Spain this month, Cisco will unveil the first product to come from the acquisition – a mobile multimedia platform now branded the Cisco ASR 5000, which Cisco says will play an increasingly key role for service providers as mobile data traffic mushrooms in the coming years. Cisco is also announcing the new business group it formed in the wake of the Starent acquisition to focus specifically on mobility and its importance for Cisco's service provider customers. The Cisco Mobile Internet Technology Group is led by former Starent CEO Ashraf Dahod.
For a greater understanding of what the Starent acquisition and the ASR 5000 mean for Cisco and the telecom industry, News@Cisco spoke with Pankaj Patel, senior vice president and general manager of Cisco's service provider business.

How do the Starent acquisition and the Cisco ASR 5000 round out Cisco's mobility portfolio, and what competitive advantage do they bring?
Pankaj Patel: The mobile Internet has reached a major turning point with the proliferation of smart devices, greater availability of broadband, high growth of data traffic, and a movement of applications away from the wired world onto mobile networks, as in the case of apps for smart phones. At the same time, with the large scale deployment of third-generation (3G) and the emergence of high-speed fourth-generation (4G) cellular wireless standards such as Long Term Evolution (LTE), networks must shift toward Internet protocol (IP). This is obviously very timely for Cisco, because anything on Internet protocol plays to Cisco's strength.

It's also where Starent comes into play in a major way. The Cisco ASR 5000 is now the centerpiece of our offerings in the mobile packet core of the wireless network which is really the edge of the mobile IP network. Purpose-built for mobility, it's a robust, carrier-class, multimedia services platform that offers a host of benefits to service providers, including the ability to work seamlessly with a range of networks, be they CDMA2000, HSPA, femtocell, Wi-Fi or WiMAX, or, in the future, LTE. The ASR 5000 will also allow service providers to efficiently migrate their networks to LTE through software, thus extending their investment in the hardware. These are very important attributes that make the ASR 5000 an industry benchmark offering from Cisco.

What is Cisco's overall mobility strategy for service providers and their networks?
Pankaj Patel: Our mobile Internet strategy falls into four main categories: applications; selective radio; mobile packet core; and the "unified service delivery" offering we introduced last year, which is part of our data center strategy designed to help service providers build a foundation for Web-based services. It's really in the third bucket – mobile packet core – that the Starent portfolio is most relevant and dominant, both for the current third-generation (3G) networks and as we go to 4G. Also our data center initiative is very nicely geared to service providers both because of Cisco's offerings and what Starent brings. Taken together, Cisco's and Starent's offerings form a very compelling portfolio that allows us to provide mobile IP-based subscriber services reliably, intelligently and on a very large scale.

What trends in the communications industry make the ASR 5000 necessary?
Pankaj Patel: Some of the most important trends are highlighted in the Cisco Visual Networking Index Mobile Forecast for 2009-2014, which we're also announcing in Barcelona. Over the five-year forecast period, it projects that global mobile Internet traffic will increase nearly 40 times over, reaching 3.6 exabytes per month by 2014. An exabyte is a billion gigabytes; that's a lot of zeros. Video is going to play a huge role in mobility, as we're already seeing today. As the 4G networks get deployed, you'll see people using even more video over a mobile network. The forecast predicts mobile video will account for 66 percent of the global mobile data traffic by 2014 – that's the highest growth of any mobile application category. There are numerous other remarkable stats, but the point is that the ASR 5000 is coming at an absolutely critical time for service providers.

What main challenges do these trends represent for communications service providers?
Pankaj Patel: The explosion in mobile Internet traffic has very interesting implications for the way service providers need to design their networks. A lot of the networks today were built from the ground up to handle voice phone calls, but those will have to change to handle all of these new dominant traffic types coming into play in the next few years – mobile video, mobile Web and data, mobile gaming, mobile peer-to-peer, mobile VoIP and so on. Video solutions in a mobile network must be different from those that are designed for fixed networks since the user is on the move and could have a variety of screens operating in a dynamic network environment.  This presents a tremendous challenge for service providers, which will have to invest in network upgrades in order to ensure fidelity of service for their customers in the face of this onslaught. The Visual Networking Index provides them the opportunity to be proactive in this effort, and the ASR 5000 can play a major role in helping offset the associated operating and capital expenditures.  Another key benefit of the ASR 5000 is its ability to provide service providers with a wealth of data about their customers and the network itself in business-to-business and business-to-consumer transactions. On the customer level, that means subscriber information, device type, service type, location, brand and billing relationship, session information and so on. On the network level, it means things like quality of service (QoS), security, packet filtering, packet insertion and ad insertion. All of this intelligence is aimed at helping service providers create new revenue streams and monetize new services to offset their investment on the infrastructure side. The ASR 5000 helps them do this.

What additional challenges are communications service providers facing?
Pankaj Patel: I always put myself in our customers' shoes. Whatever their challenges are, those will be our challenges – to make sure we can keep up with all the growth and deliver all the products and services that they need in time. Monetization of investment is the big challenge on their minds, so we have to be sure that we bring the fiscal reality to the top of mind. While the IP infrastructure is still a pretty small percentage of the overall mobile carrier wireless infrastructure spending, the scalability and the intelligence in the IP infrastructure provide the greatest potential impact on overall network profitability through generation of new services and cost savings.

By the way, mobility is where service providers actually make decent money. Nonetheless, we're hearing about the significant investment required by customers like AT&T because of all the growth in iPhone data traffic, and now you have the Apple iPad on the heels of it. Certainly, it's a great opportunity for Cisco to be able to work with the large service providers to help build their networks, but at the same time I don't think we can focus only on what's good for Cisco. We have to look out for what's best for our customers. This is why we're engaging with them to define new services, to figure out how to exploit the intelligence in the network and their customer data, and turn that intelligence into personalized experiences that their customers will be willing to pay for. That's what our goal has to be.

How will the changes in mobile networks affect the user experience and business models?
Pankaj Patel: Normally, when we think of a subscriber, we associate that with a fixed line phone number. But with mobility, it makes more sense to think of the subscriber as an end user. You can only do so much on a fixed line, even if you are a cable subscriber. But if you are on the move, and the communications company has location, roaming and other intelligence about you, the potential revenue opportunities explode in a very different way.

For example, today you might be fairly forgiving when it comes to calls dropping or having a less-than-ideal video experience on a smart phone, but I don't believe that will always be the case. The time is coming when you will be able to watch pretty decent clips of a live basketball or football or hockey game, and I'm sure new business models will emerge where franchise owners will work with service providers to allow you to access this experience for a subscription fee or something similar. We're talking about live, personalized, multimedia experiences for every subscriber. Consumers are going to demand these services to any screen, any time, anywhere. In addition, the lines between the wireline and mobile spaces will blur with exciting applications like mobile Cisco TelePresence. Personally, that's one I can hardly wait for – to be able to have that experience while riding in the back of a cab in Manhattan!

New services are how service providers are going to make money. Features translate into services, and services translate into new revenue streams. In addition, the speed of deploying these services is going to play a key role because the mobility world moves very fast – much faster than the fixed wireline world. All of this has huge implications for the way data will be delivered to subscribers or end users. Clearly, the IP network will need to deliver unprecedented scale, performance and intelligence. So it comes as absolutely no surprise that, when you look at service providers' investment profile, so much of that capital expenditure is moving into mobility. With the help of products like the ASR 5000, Cisco and its ecosystem of partners can help turn this into a reality.

Jan 27, 2010

BPDU Guard vs BPDU Filter

When you configure PortFast on an access or trunk port, you assure that switch it should not expect a switch on this path. With this assurance, the switch can pass right through forward delay and go directly to forwarding when it gains link.

By default, PortFast does not disable STP on the port, but by skipping the listening and learning stats you do increase the probability of creating a loop if a switchin connected. To protect against this situation, you can enable BPDU guard or BPDU filter globally for PortFast port.

BPDU guard will error-disable the port if a BPDU is recevied.

Switch(config)# spanning-tree portfast bpduguard

When the BPDU filter is enabled globally, it causes PortFast ports to stop sending BPDUs. If a BPDU is recevied, the PortFast feature is disabled for that port and normal STP operation resumes.

Switch(config)# spanning-tree portfast bpdufilter

Jan 26, 2010

Cisco Announces New Service Provider Operations Track


Cisco Announces New Service Provider Operations Track


Built on the growing demand for dedicated professionals who can manage, maintain and troubleshoot complex service provider IP NGN core network infrastructures, Cisco is introducing a new Service Provider (SP) Operations track. This new track is focused on developing associate, professional and expert-level capabilities to operate large, complex SP networks. These new, first of their kind certifications are designed specifically for Cisco Service Provider Customers, Partners and Cisco Networking Engineers.

Over the coming months Cisco will release new CCIE, CCNP, and CCNA SP Operations courses and exams. In addition, the written exam topics for the CCIE SP Operations certification are now available on the Cisco Learning Network. The CCIE SP Operations written exam is scheduled for release in the second quarter of 2010.



CCIE SP Operations Certification

The Cisco CCIE SP Operations certification assesses and validates core IP NGN service provider operations expertise.  Candidates who pass the CCIE SP Operations certification exams demonstrate skills required of a expert-level (Tier III or Tier IV support) operations engineer to troubleshoot and maintain complex service provider IP NGN core (PE-PE and PE-CE) network infrastructures in both IOS and IOS XR operating environments, plus validate broad theoretical knowledge of operations management processes, frameworks, and network management systems.

CCIE SP Operations Certification benefits:
  • Certification helps qualify personnel for customer’s Operations (NOC) Centers
  • Provides a credential (certification) that a person holds significant knowledge in SP Operations
  • Provides expert level certification to network operations (i.e. NOC) personnel to validate they are qualified to support various Build-Operate Transfer operation models

The CCIE SP Operations written exam is scheduled for release in the second quarter of 2010. The practical exam is scheduled for release in the third quarter of 2010.


CCNP SP Operations Certification

The Cisco Certified Network Professional  in Service Provider Operations (CCNP SP Operations) validates knowledge and skills required (of a Tier II or Tier III support engineer) to troubleshoot and maintain service provider IP NGN core (PE-PE and PE-CE) network infrastructures.  With a CCNP SP Operations certification, a network professional demonstrates the knowledge and skills required to isolate network performance problems, implement proactive fault measures using operations management processes, frameworks, and network management systems. The CCNP SP Operations curriculum includes maintaining carrier class routing protocol environments, MPLS VPN and TE deployments, and QoS mechanisms using Cisco IOS and IOS XR.

CCNP SP Operations Certification benefits:
  • Certification helps qualify personnel for customers Operations Centers
  • Certification classes provide a developmental path for personnel in Operations
  • Provides advanced level training and certification to network operations (i.e. NOC) personnel

The Cisco CCNP SP Operations certification will be made available in the third quarter of 2010.


CCNA SP Operations Certification

Cisco Certified Network Associate in Service Provider Operations (CCNA SP Operations) validates basic knowledge and skills (of a Tier I support engineer) in a prescriptive troubleshooting environment within carrier class IP NGN core network infrastructure.  CCNA SP Operations curriculum includes incident (event), fault, configuration, change, and performance management procedures, along with NMS tools and protocols.

CCNA SP Operations Certification benefits:
  • Provides students with a foundation of network operations skills for SP NGN environments
  • Provides training and certifications around Network Operations job role
  • Provides entry level training and certification to entry level network operations (i.e. NOC) personnel

The CCNA SP Operations certification is scheduled to be released in the second quarter of 2010.

Jan 25, 2010

FRTS shape to 95% of CIR

Frame Relay Dual-FIFO

On the low-end router non-distributed platforms (Cisco 7200 and lower), Frame Relay employs a dual-FIFO queuing technique that automatically is invoked at the interface level when FRF.12 is configured. FRF.12 depends on Frame Relay traffic shaping (FRTS) or class-based FRTS being enabled.

In a Frame Relay environment, the Tx-ring does not directly provide back pressure to the Layer 3 queuing algorithm. Instead, when the Tx-ring is full, it provides back pressure to the shaper (FRTS or CB-FRTS), which, in turn, signals the Layer 3 queuing system (LLQ) to engage. Because the FRTS mechanism does not take into account Frame Relay headers and cyclic redundancy checks (CRCs) in its calculations, it generally is recommended that you shape to 95 percent of CIR on Frame Relay circuits up to T1/E1 speeds. This, in turn, engages the LLQ algorithm slightly earlier and improves performance for real-time traffic.

Traffic from each PQ for each DLCI is funneled into the high-priority, dual-FIFO interface queue; all traffic from the CBWFQ queues from the DLCIs is assigned to the lower-priority, dual-FIFO interface queue. Thus, the dual-FIFO Layer 2 queues ensure that the "priority" class traffic from one DLCI is not delayed by CBWFQ traffic from another DLCI.

資料來源:Cisco Press End to End QoS Network Design Quality of Service in LANs WANs and VPNs

ECN-Echo (ECE)

在Cisco QoS 2.3課程中的ECN(Explicit Congestion Notification)的章節中第一次談到了ECN-Echo(ECE),透過ECE(注意,這個欄位不在ToS中,而是在TCP header中的flag之一)可以通知對方放慢傳送的速度。當另一方收到ECE時,會減少它的congestion windows來放慢傳輸速率。然後在第一個封包中設置TCP header flag(CWR, Congestion Window Reduced),用來通知原先發送ECE的那一方已經減少windows size並且放慢了傳輸速率.


TCP 中的 ECN 支援

當路由器將 IP 封包的 ECN 欄位設定為 11 時,接收端 (而不是傳送端) 就會接到路徑中擁塞的通知。ECN 使用 TCP 標頭向傳送端指出網路正遇到擁塞狀況,同時向接收端指出傳送端已經從接收端接到擁塞指標,並且降低傳輸速率。
TCP 中的 ECN 支援使用 TCP 標頭中的兩個未使用位元 (先前定義為保留)。為 ECN 支援定義的兩個新旗標如下所示:
ECE ECN-Echo (ECE) 旗標是用來指出,在 TCP 三方信號交換程序期間,TCP 對等體具備 ECN 功能,並指出 ECN 欄位在 IP 標頭中設定為 11 的連線上接到 TCP 區段。如需有關 TCP 三方信號交換程序的資訊,請參閱 RFC 793。
CWR Congestion Window Reduced (CWR) 旗標是由傳送主機設定,指出已接到設定 ECE 旗標的 TCP 區段。擁塞視窗是由 TCP 維護的內部變數,可管理傳送視窗的大小。
[圖 2] 顯示 TCP 標頭中 ECE 和 CWR 旗標相對於其它旗標的位置。如需有關 TCP 標頭中其它旗標的資訊,請參閱 RFC 793。
[圖 2]:TCP 標頭中的 ECE 和 CWR 旗標
圖 2:TCP 標頭中的 ECE 和 CWR 旗標觀看完整大小的影像
當兩個具備 ECN 功能的 TCP 對等體建立 TCP 連線時,它們交換 Synchronize (SYN)、SYN-Acknowledgement (SYN-ACK) 和 ACK 區段。SYN 區段已經針對具備 ECN 功能的 TCP 對等體同時設定 ECE 和 CWR 旗標;但是 SYN-ACK 區段則是設定 ECE 旗標,同時清除 CWR 旗標。
具備 ECN 功能的主機為具備 ECN 功能的 TCP 連線傳送 TCP 區段,其 IP 標頭中的 ECN 欄位設定為 10 或 01;具備 ECN 功能而且遇到擁塞的路由器會將 IP 標頭中的 ECN 欄位設定為 11。當接收端 TCP 對等體傳送 ACK (其中包含 ECN 欄位設定為 11 的已接收 TCP 區段) 時,會設定 TCP 標頭中的 ECE 旗標,並繼續在後續 ACK 中設定 ECE 旗標。
當傳送主機接到設定了 ECE 旗標的 ACK 時,所表現的行為就好像已經捨棄了封包,開始縮減其傳送視窗,並執行慢速啟動演算法及擁塞避免演算法。在下一個區段,傳送端會設定 CWR 旗標。在接到設定了 CWR 旗標的新區段時,接收端會停止在後續 ACK 中設定 ECE 旗標。

ECN 範例

[圖 3] 顯示具備 ECN 功能的 TCP 對等體之間的 TCP 連線範例,其具備 ECN 功能的路由器正遇到擁塞狀況。
[圖 3]:TCP 連線的 ECN 範例
圖 3:TCP 連線的 ECN 範例 觀看完整大小的影像
在此範例中,TCP 對等體 A 正傳送資料給 TCP 對等體 B。TCP 對等體 A 傳送區段 1 到 5,區段 2 由遇到擁塞而具備 ECN 功能的路由器轉送,路由器將 IP 標頭中的 ECN 欄位設定為 11;當 TCP 對等體 B 接到此區段時,會傳送已設定 ECE 旗標的 ACK。當 TCP 對等體 A 接到第一個已設定 ECE 旗標的 ACK 時,便開始降低其傳輸速率,並傳送下一個已設定 CWR 旗標的區段 (區段 6)。在接到設定了 CWR 旗標的區段 6 時, TCP 對等體 B 便開始傳送已清除 ECE 旗標的後續 ACK。
如需各種不同 TCP 資料流程之行為的詳細資訊,請參閱 RFC 3168。

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.

Jan 1, 2010

Private VLANs (PVLANs)


今天晚上接到一位老同事來電詢問Private VLAN相關的問題,所以我上網找了一篇比較清楚簡單的說明摘錄如下,其中最容易讓大家confused的就是Private VLAN中包含了三種port,我用比較簡單的中文列出它們之間的不同點:  

  • Promiscuous - 在這種Port上通常連結的是這個VLAN中的共用設備,如Gateway或是外部Server
  • Isolated - 在這種Port上通常只能連結至Promiscuous ports,如果在IDC中提供主機代管服務,為了節省IP若是不想切割子網路造成無謂的IP浪費,可以在不同客戶主機使用同一個VLAN(使用同網段IP)但是彼此之間互不相通時就很適合使用這種Port
  • Community - 在這種Port的設備可以直接與相同Community Port上的其他設備互通(比方說某客戶要求三台主機代管,這三台主機使用同網段IP又要互連,但是不跟同網段其他客戶主機互連),也可以連結至 Promiscuous ports上的Gateway或是外部Server

Private VLANs (PVLANs)

Until now, I thought PVLANs were a bit  difficult to understand and to implement, like when studying to CCNP that took me a while to digest, and I had some doubts about it, till today! Man... how simple it is, and there´s no much "magic" in that (like our friend Scott Morris usually says)!  Pretty straight-forward and no big deals! The Security VideoIPExpert is AWESOME. It´s short, informative, to the point, and solved MANY questions I´ve for a while in minutes! Man! What a nice way to do it!
So, let´s get into that:

There are tree type of Private VLANs Ports: 

  • Promiscuous (P) - talk to everyone (usually connected to the exit Router, DNS, DHCP Server, NTP Server);
  • Isolated (I) - only talk to Promiscuous ports;
  • Community (C) - talk to others in the same Community & Promiscuous ports.
To have PVLANs configure the Switch MUST be in Transparent VTP mode, otherwise, it´ll not work. 

Just keep in mind that when you configure your switch to VTP Transparent mode, you do not loose what you´ve learned so far, you´re just not gaining anything new about the changes from now on! 

Hosts in different PVLANs are all in the same IP Subnet, BUT, they´re not able to talk to others in different community or isolated VLANs! That´s the main goal of a PVLAN, to split the VLAN domain into multiple isolated broadcast subdomains. But if one Community VLAN needs to talk to other Community VLAN?! Well... that can be done through a Router or L3 Switch. Also, you can apply some access-lists and other security features to permit only the things you want to pass through!

The best way to explain this is using an example, so check our topology, we´ll concentrate on the PVLAN ports:
PVLAN


There are three Community VLANs (there can be more if you want) so you put every client inside it´s own Community VLAN, avoiding that one client talk to another. That means Customer A could have a WebServer, and some other application server inside it´s own Community VLAN, and those equipments will be able to talk to each other, but they´ll NOT be able to talk to equipments in other Community or Isolated VLANs.

But, wait a minute, we´ve created one Community VLAN for each customer, and only one Isolated VLAN?! If we have more customers needing Isolated ports?! Should we create more Isolated VLANs?! The answer is NO. Isolated Ports only talks to the Promiscuous Ports and not to each other. So each customer inside an Isolated Port will be confined to this port only plus the Promiscuous Port.

First, lets go ahead and create our VLANs:
SW1 and SW2:


vlan 10
private-vlan primary
exit
!
vlan 101
private-vlan isolated
exit
!
vlan 102
private-vlan community
exit
!
vlan 103
private-vlan community
exit
!
vlan 104
private-vlan community
exit
!
vlan 10
private-vlan association add 101-104
exit

So, VLAN10 is our  Promiscous VLAN, and it´s associated to ALL other VLANs (101, 102, 103 and 104).

Now, we´ll associate each port to it´s VLAN, check it out:
SW1:

interface fa0/3
switchport mode private-vlan host
switchport private-vlan host-association 10 104
!
interface fa0/4
switchport mode private-vlan host
switchport private-vlan host-association 10 104
!
interface fa0/7
switchport mode private-vlan host
switchport private-vlan host-association 10 102
!
interface fa0/8
switchport mode private-vlan host
switchport private-vlan host-association 10 102

SW2:

interface fa0/3
switchport mode private-vlan host
switchport private-vlan host-association 10 101
!
interface fa0/4
switchport mode private-vlan host
switchport private-vlan host-association 10 103
!
interface fa0/5
switchport mode private-vlan host
switchport private-vlan host-association 10 103
!
interface fa0/2
switchport mode private-vlan promiscuous
switchport private-vlan mapping  10 add 101-104

Every device MUST be associated with the promiscuous VLAN (in our case VLAN10)! Beyond that they´ll be associated with the non-promiscuous  (the isolated or community VLANs) in order to specify how those ports will behave! That´s why ALL ports are associated with VLAN10 + it´s own VLAN.

So, what can be connected in the Promiscuous VLAN?! Normally the devices that are common to everybody, and needs to talk to all VLANs, like Routers, DNS Servers, NTP Servers, DHCP Servers, and many others!

You can verify your configuration using the "show vlan" command. The info regarding PVLANs will be at the end of the output of this command.

A good advice from the IPExpert Video is that the current IOS on the LAB (12.2.25) doesn´t allow us to use switchport port-security commands and private-vlans  at the same port at the same time!  Once it hits a newer version (12.2.40) (that can happen anyday Cisco wants) we´ll be able to do that!

Ok! But... do you know that 3550 doesn´t support PVLANs?! Yep.., me neither! They´ve a feature named Switchport Protected for that, it´s really simple, and for example, if we have 15 devices in a vlan, but, only two of them are protected (with the interface command switchport protected), they can talk to everybody else, but not to each other!

So one protected device will not talk to other protected device! It works just like an isolated vlan. No unicast, multicasts, broadcasts between protected ports! 

Not that difficult, right?!