Oct 11, 2008

Cisco will announce upcoming changes for the CCIE Program

Watch a live presentation done Learning@Cisco Product Marketing Managers David Bump, Mary Ng and Sanjay Mehta. David Bump manages the Cisco 360 Program and the Service Provider curriculum. Sanjay Mehta manages the Wireless Certifications and Curriculum. Mary Ng manages the Unified Communications Curriculum and is the Project Lead for CCIE Security.

Date: October 23, 2008
Time: 8:00 am PST, 11:00 am EST, 15:00 GMT
Duration: 1.5 hour


Agenda:
The program will focus on the following objectives. After the presentation portion of the show, we’ll be taking live calls from YOU – the viewer— during our Q&A session. You may also submit questions electronically.

Objectives:
• CCIE Program Overview
• CCIE 360 Program
• CCIE Mobile Testing Labs
• CCDE Updates
• Security Lab Updates
• Brand new curriculum!!!

Register Now

Oct 10, 2008

中華電信擬調降光纖上網費率至990元


文/蘇文彬 (記者) 2008-10-09 

因應有線電視業者也以佈建光纖網路或其他ISP同業的競爭,中華電信擬首次調降光纖上網公告費率,未來若通過可望刺激整體寬頻上網市場。 

中華電信表示,目前正規劃調降光纖上網月租費至990元,期望以此降低用戶上網成本,以吸引用戶昇級採用光纖上網。 

目前依中華電信獲得NCC通過的光纖上網公告費率,光世代10M/2M速率費用包括上網費650元與電路月租費650元在內,用戶每月需繳1300元。雖然過去中華電信也提供990元的促銷價吸引用戶昇級,但面對日趨激烈的市場競爭,中華電信因此擬調降公告費率。 

這是自中華電信去年通過NCC審核推出光世代費率以來,首次自行調降光世代費率,希望將10M/2M公告費率從現有每月1300元降至每月990元,讓過去短期促銷才有的優惠費率成為正式的定價。 

規劃中的990元新費率因為同時調降電路費與Hinet上網費,因此若未來獲得NCC通過,其影響性將遍及整體寬頻上網市場。除了電路費的調降可讓其他使用中華電信線路的ISP業者同步降低費率外,Hinet上網費率的降低也可望經過市場競爭刺激其他ISP業者跟進降價因應。 

除了將調降公告費率至促銷價位外,中華電信也規劃拉低光世代速率門檻,針對MOD用戶推出3M的光纖上網速率,其每月費用將介於現有ADSL 2M與8M之間,用以吸引佔ADSL用戶多數的2M速率市場。 

中華電信已將新費率送請NCC核准,中華電信Hinet行銷處長馬宏燦表示,按原先的預期原本今年6、7月應該就能獲得通過開始實施,但由於審核要件不足,NCC已要求中華電信再補件,目前等待排入委員會議程,應該很快便能獲得NCC通過。 

由於應NCC要求明年4月中華電信必須再調降ADSL費率,為維持ADSL與光世代上網費價差在一定範圍以吸引用戶昇級,因此明年4月前中華電信勢必希望能夠獲得NCC審核通過。 

除了調降費率吸引ADSL用戶外,由於部份地區還未完成光纖網路佈建,因此尚有用戶無法使用中華電信光纖上網服務,因此中華電信目前正佈建全台光纖網路,今年底將提昇網路涵蓋率至全台都會區近5成的家庭,配合政府目標到民國100年則將提昇至8成涵蓋率。 

目前中華電信光世代用戶數已有80萬戶以上,年底目標鎖定在100萬用戶目標。拜近來持續推動光纖上網服務之賜,Hinet既有約430萬用戶中,目前8M以上高速率用戶數至9月已有150萬戶,佔Hinet總用戶數的三分之一。

Oct 9, 2008

GNS3 Beta.0.6 Win32 UNOFFICIAL Release By GNS3-Labs

最近GNS3-Lab release了GNS3 0.6 Beta版,目前在GNS3官網上尚無法下載,有興趣的人可以參考一下:

Release: GNS3 Beta.0.6 Win32 UNOFFICIAL Release By GNS3-Labs - A Gift :-)

Written By LBSources From Http://Www.Gns3-Labs.Com On October 8th, 2008 | 0 Comments

Hello ..

I will release to you guys the latest BETA-0.6 from the GNS3 Team. This is NOT officially released by GNS3, but there are no limitations to release this either.

There aren’t too many changes on the front-end with the exception of the option to show interfaces in the network topology, which is really helpful.

I’m working on a changelog and as soon as I get it i will provide it here.

Enjoy otherwise!

GNS3-Labs.Com - GNS3 BETA-0.6 Win32 Version

LBSources

Oct 8, 2008

J-Central | Free O'Reilly book(JUNOS™ Enterprise Routing)

最近J-Central網站提供一個好康,只要到以下網站填寫註冊資料就可以得到一本免費的O'Reilly出版的JUNOS™ Enterprise Routing,請參考:

https://www.j-central.net/request/

Request your copy.

To request your copy of JUNOS™ Enterprise Routing, simply complete the form below and we'll send you your copy in the post. We'll also keep you up to date with new developments on the J-Central site, your resource for JUNOS™. And if you have any ideas on what you'd like to see on J-Central, don't forget you can add your suggestions in the box.

Oct 7, 2008

How to ensure specific subnets within supernet are not leaked to specific neighbor without 'aggregate-address' command ?

假設現在我們的BGP Table中有許多192.168.X.0/24的小網段,不過我們只想要送出192.168.0.0/16這個Supernet給特定的neighbor 3.3.3.3,但是不能使用aggregate-address指令,我們可以設定如下,利用neighbor後面加上route-map參數進行小網段的過濾:

Router(config)#interface loopback 0
Router(config-if)# ip address 192.168.0.254 255.255.255.0
!
Router(config)#interface loopback 1
Router(config-if)# ip address 192.168.1.254 255.255.255.0
!
Router(config)#interface loopback 2
Router(config-if)# ip address 192.168.2.254 255.255.255.0
!
Router(config)#interface loopback 3
Router(config-if)# ip address 192.168.3.254 255.255.255.0
!
Router(config)#router bgp 100
Router(config-router)#network 192.168.0.0 mask 255.255.255.0
Router(config-router)#network 192.168.1.0 mask 255.255.255.0
Router(config-router)#network 192.168.2.0 mask 255.255.255.0
Router(config-router)#network 192.168.3.0 mask 255.255.255.0
Router(config-router)#network 192.168.0.0 mask 255.255.0.0
Router(config-router)#neighbor 3.3.3.3 route-map AGGREGATE out
!
Router(config)#ip route 192.168.0.0 255.255.0.0 null0
!
Router(config)#ip prefix-list AGGREGATE_PREFIX seq 5 permit 192.168.0.0/16
!
Router(config)#route-map AGGREGATE permit 10
Router(config-route-map)# match ip address prefix-list AGGREGATE_PREFIX

How to config Outbound Route Filter(ORF) between two BGP speakers ?

如果我們今天在Service Provider中同時要代管許多不同客戶的CE Router BGP configuration時,有時會覺得麻煩的事就是要在每一個CE Router設置相同outbound filter的話要重複許多次同樣的工作。這時就可以使用BGP的一種feature - Outbound Route Filter(ORF),這個功能不但可以減少routine的作業進行集中控管,更可以節省不必要的BGP update所導致的頻寬浪費。

假設現在有兩個Router,分別為PE(AS100), CE(AS18000),我們希望設置一個ACL,讓CE Router送出BGP update時,先過濾掉不必要的traffic(如不小心從IGP redistribute到BGP的private network or default),但是這個動作可以直接在PE Router上進行設置而不需要到每一台的CE Router上去分別設置:

PE
PE(config)#ip prefix-list ORF_NORFC1918 seq 5 deny 10.0.0.0/8 le 32
PE(config)#ip prefix-list ORF_NORFC1918 seq 10 deny 172.16.0.0/12 le 32
PE(config)#ip prefix-list ORF_NORFC1918 seq 15 deny 192.168.0.0/16 le 32
PE(config)#ip prefix-list ORF_NORFC1918 seq 20 deny 0.0.0.0/0
PE(config)#ip prefix-list ORF_NORFC1918 seq 25 permit 0.0.0.0/0 le 32
!
PE(config)#router bgp 100
PE(config-router)#neighbor 18.18.18.18 remote-as 18000
PE(config-router)#neighbor 18.18.18.18 capability orf prefix-list send
PE(config-router)#neighbor 18.18.18.18 prefix-list ORF_NORFC1918 in


CE
CE(config)#router bgp 18000
CE(config-router)#neighbor 18.18.18.100 remote-as 100
CE(config-router)#neighbor 18.18.18.100 capability orf prefix-list receive

Oct 6, 2008

Bidirectional Forwarding Detection (BFD)

Bidirectional Forwarding Detection (BFD) support for BGP was introduced in Cisco IOS Releases 12.0(31)S, 12.4(4)T, 12.0(32)S, and 12.2(33)SXH, and later releases. BFD is a detection protocol designed to provide fast forwarding path failure detection times for all media types, encapsulations, topologies, and routing protocols. In addition to fast forwarding path failure detection, BFD provides a consistent failure detection method for network administrators. Because the network administrator can use BFD to detect forwarding path failures at a uniform rate, rather than the variable rates for different routing protocol hello mechanisms, network profiling and planning will be easier, and reconvergence time will be consistent and predictable. The main benefit of implementing BFD for BGP is a marked decrease in reconvergence time.
One caveat exists for BFD; BFD and BGP graceful restart capability cannot both be configured on a router running BGP. If an interface goes down, BFD detects the failure and indicates that the interface cannot be used for traffic forwarding and the BGP session goes down, but graceful restart still allows traffic forwarding on platforms that support NSF even though the BGP session is down, allowing traffic forwarding using the interface that is down. Configuring both BFD and BGP graceful restart for NSF on a router running BGP may result in suboptimal routing.


For more details about BFD, see the Bidirectional Forwarding Detection chapter of the Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4(4)T.

Decreasing BGP Convergence Time Using BFD
BFD support for BGP was introduced in Cisco IOS Releases 12.0(31)S, 12.4(4)T, 12.0(32)S, and 12.2(33)SXH, and later releases. You start a BFD process by configuring BFD on the interface. When the BFD process is started, no entries are created in the adjacency database, in other words, no BFD control packets are sent or received. The adjacency creation takes places once you have configured BFD support for the applicable routing protocols. The first two tasks must be configured to implement BFD support for BGP to reduce the BGP convergence time. The third task is an optional task to help monitor or troubleshoot BFD.

interface FastEthernet 0/1
ip address 172.16.10.1 255.255.255.0
bfd interval 50 min_rx 50 multiplier 3
!
router bgp 100
bgp log-neighbor-changes
neighbor 172.16.10.2 remote-as 45000
neighbor 172.16.10.2 fall-over bfd

How to use Unicast Reverse Path Forwarding command with ACL ?

以下範例示範如何使用Unicast RPF搭配ACL及Log紀錄。

在這個範例中,利用extended ACL 197來允許或拒絕特定網路位址範圍的流量。在interface Ethernet0上設定Unicast RPF來檢查到達該介面的封包。

比方說,來源位址192.168.201.10的封包到達Ethernet0會被drop是因為在ACL 197的deny條件(access-list 197 deny ip 192.168.201.0 0.0.0.63 any log-input)。在這個案例中,ACL的資訊會被紀錄下來,被drop的封包數量會針對每個interface及整體為單位加以統計。

來源位址192.168.201.100的封包到達interface Ethernet0/1/1會被轉送因為在ACL 197中的permit條件(access-list 197 permit ip 192.168.201.64 0.0.0.63 any log-input)。ACL資訊像是被drop或是被抑制的封包被紀錄下來,或是轉送至log server。

int eth0/1/1
ip address 192.168.200.225 255.255.255.0
ip verify unicast reverse-path 197
!
int eth0/1/2
ip address 192.168.201.1 255.255.255.0
!
access-list 197 deny ip 192.168.201.0 0.0.0.63 any log-input
access-list 197 permit ip 192.168.201.64 0.0.0.63 any log-input
access-list 197 deny ip 192.168.201.128 0.0.0.63 any log-input
access-list 197 permit ip 192.168.201.192 0.0.0.63 any log-input
access-list 197 deny ip 10.0.0.0 0.255.255.255 any log-input
access-list 197 deny ip 172.16.0.0 0.15.255.255 any log-input
access-list 197 deny ip 192.168.0.0 0.0.255.255 any log-input

How to transport the multicast traffic without any PIM or IGMP join messages received ?

相對於大家都很熟悉的指令 - 'ip igmp join-group',這邊我要跟各位介紹一個不常使用到的指令 - 'ip igmp static-group'

ip igmp static-group

To configure static group membership entries on an interface, use the ip igmp static-group command in interface configuration mode. To delete static group membership entries, use the no form of this command.

ip igmp static-group {* | group-address [source {source-address | ssm-map}] | class-map class-map-name}

no ip igmp static-group {* | group-address [source {source-address | ssm-map}] | class-map class-map-name}

Usage Guidelines

Use the ip igmp static-group command to configure static group membership entries on an interface. When you configure the ip igmp static-group command, packets to the group are fast-switched out the interface, provided that packets were received on the correct reverse path forwarding (RPF) interface. Once configured, static group membership entries are added to the IGMP cache and mroute table.

Configuring the ip igmp static-group command is unlike configuring the ip igmp join-group command, which allows the router to join the multicast group. This configuration of the ip igmp static-group command would cause the upstream routers to maintain the multicast routing table information for that group, which would ensure that all the paths to that multicast group are active.

If you configure the ip igmp join-group command for the same group address as the ip igmp static-group command, the ip igmp join-group command takes precedence, and the group behaves like a locally joined group.

Use the ip igmp static-group command with the ssm-map keyword to configure static traffic forwarding with SSM mapping on the last hop router. Static traffic forwarding can be used in conjunction with SSM mapping to statically forward SSM traffic for certain groups. When static traffic forwarding with SSM mapping is configured, the last hop router uses Domain Name System (DNS)-based SSM mapping to determine the sources associated with a group. The resulting (S, G) channels are then statically forwarded.

Use the ip igmp static-group class-map command with the class-map keyword and class-map-name argument to attach an IGMP static group class map to an interface. Once attached, all groups entries that are defined in the class map become static members on the interface and are added to the IGMP cache and to the mroute table.

Examples

The following example shows how to configure group address 239.100.100.101 on Ethernet interface 0:

interface ethernet 0
ip igmp static-group 239.100.100.101