Tuesday, January 31, 2012
BGP update-source
BGP is unlike any protocol you learned during your CCNA studies, and even the similarities are a little bit different!
BGP forms neighbor relationships, much like EIGRP and OSPF do. The interesting thing with BGP is that potential neighbors, or "peers", do not need to be directly connected and can use their loopback interfaces to form the peer relationships.
It may well be to your advantage to use loopbacks to form peer relationships rather than the actual interface facing the potential neighbor. This can be done because BGP uses static neighbor statements rather than any kind of dynamic neighbor discovery process.
Consider a router that has two paths to a BGP speaker. The interfaces are numbered like this:
Router1: Serial0, 172.1.1.1 /24, Serial2, 179.1.1.1 /24, loopback0, 1.1.1.1 /32.
Router2: Serial0, 172.1.1.2/24, Serial2 179.1.1.2/24, loopback0, 2.2.2.2 /32.
We could configure Router1 like this:
router bgp 200
neighbor 172.1.1.2 remote-as 200
In this case, BGP would automatically use 172.1.1.1 as the source for the TCP connection that has to be set up with the neighbor before updates can be exchanged; this address is known as the best local address. However, if the remote peer´s serial0 interface is shut down or goes down for another reason, the peer relationship would be lost even though Router2 is still available.
Instead of using one of the physical interfaces, we can use the loopbacks on each router to establish the TCP-based peer connection. The configurations would look like this:
Router1:
router bgp 200
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 update-source loopback0
Router2:
router bgp 200
neighbor 1.1.1.1 remote-as 200
neighbor 1.1.1.1 update-source loopback0
In this case, losing one of the physical connections does not necessarily mean the BGP peering is lost; as long as the routers have a valid path to each other´s loopback addresses, the BGP peer relationship will stay in place. And better yet, we avoid the dreaded "single point of failure"!
BGP Next-hop-self
There are three most important keywords which we should have in mind
while setting up BGP neighbor relationship. Even sometimes when we have
successful BGP relationship, we are not able to see routes in the
routing table. Following are the three important keywords.
1)ebgp-multihop :- In EBGP, neighbor relationships are only formed if we have directly connected networks. We would require to use ebgp-multihop keyword with neighbor statement so that neighbors which are not directly connected can form relationship with each other. We need to specify a number with ebgp-multihop keyword, number can be between 1-255. This number represents how many hop counts is the router away.
2)update-source. We need to specify the interface which will be used to update neighbor table incase routers are not directly connected. Without update-source we will not be able to form BGP neighbor relationships. update-source keyword will update the interface which will be used to form neighbor relationship. see configuration example below for better understanding.
3) next-hop-self:- When ebgp relation replicates , next hop always changes.IBGP routers only connected with other ibgp routers in same AS will not be able to talk with routers outside the AS, if they are not directly connected with each other. We would require a next-hop-self keyword in the ibgp router which is directly connected with ebgp neighbor so that other router in same AS (IBGP) can talk with ebgp routers. Refer to configuration examples below:-
Lets assume that we have three routers and we have to setup a ebgp relationship in between them. Router A ( AS :- 34 Serial0 192.168.1.1 , loopback0 1.1.1.1) , RouterB ( AS 34, loopback0 2.2.2.2 , Serial0 192.168.1.2 , Serial1 172.16.1.1), RouterC ( AS 400 , loopback0 3.3.3.3, Serial0 172.16.1.2)
Lets start configuring Router A
router BGP 34 –> As soon as we type 34 BGP process will start in the background
neighbor 192.168.1.2 remote-as 34 –> Bgp will know that this is IBGP looking at AS
Router B
router BGP 34
neighbor 192.168.1.1 remote-as 34
neighbor 172.16.1.2 remote-as 400 –> neighbor relationship with ebgp peer.
neighbor 3.3.3.3 remote-as 400
neighbor 3.3.3.3 ebgp-multihop 255 –> 255 is number of hops that neighbor is away. we can use any number from 1-255, it can be more specific by using 1 or 2 but my personal fav is 255 as it avoids confusion.
neighbor 3.3.3.3 update-source loopback 0 –> Here is the idea, when its sourcing the packets its sourcing it from serial interface, we need to inform the otherside that source interface is not serial interface, it is looback interface so that it cann match ip ip’s with the right interface and form neighbor relationship.
we would require to do similar configuration on router c
router bgp 400
neighbor 172.16.1.1 remote-as 34
neighbor 2.2.2.2 remote-as 34
neighbor 2.2.2.2 ebgp-multihop 255
neighbor 2.2.2.2 update-source loopback 0
Now after forming the neighbro relationships we’ll use network commands to add neighbors in routing table. Network command in BGP is bit different then Network command in other routing protocols. we ‘ll need to define mask keywork with network command in order to advertise clasless network where as if it is using a default mask we can ignore the same.
Example
Router C
router bgp 400
neighbor 172.16.1.0 mask 255.255.255.0
note:- i cannot use network 172.16.0.0 command without mask keyword as it will treat this as class B network. For any customised subnetting scheme we ‘ll need to specify subnet mask with mask keyword in network command.
Even after configuring above, Router A will not be able to talk with Router C. If we will use show ip bgp command on Router A. we’ll see that it has a valid route for Router C but it will not be able to ping router c. This is because next hop will be 3.3.3.3 which is not directly connected with Router A. . First thing which will come in our mind is that rule of synchronisation has taken in to effect but even after disabling synchronisation between router a and router B, Router C will not be reachable. we would need a special command on Router B so that all IBGP peers of AS 34 can talk with AS 400
To troubleshoot this we can use “debug ip bgp updates” but before using this debug we should use ” clear ip bgp *” command. We’ll see that it will show us that there is no valid path for networks in Router C. Next hop should be Router B but in the updates it will show next hp as router c. to avoid the we will use next-hop self keyword in Router B.
Router B
router bgp 34
neighbor 192.168.1.1 next-hop-self
When Router B is sending an update to Router A it is sending the update without changging its next hop so router A will receive next hop as Router C which is not directly connected. To avoid this we will use next-hop-self command in Router B so that router A should receve valid route.
1)ebgp-multihop :- In EBGP, neighbor relationships are only formed if we have directly connected networks. We would require to use ebgp-multihop keyword with neighbor statement so that neighbors which are not directly connected can form relationship with each other. We need to specify a number with ebgp-multihop keyword, number can be between 1-255. This number represents how many hop counts is the router away.
2)update-source. We need to specify the interface which will be used to update neighbor table incase routers are not directly connected. Without update-source we will not be able to form BGP neighbor relationships. update-source keyword will update the interface which will be used to form neighbor relationship. see configuration example below for better understanding.
3) next-hop-self:- When ebgp relation replicates , next hop always changes.IBGP routers only connected with other ibgp routers in same AS will not be able to talk with routers outside the AS, if they are not directly connected with each other. We would require a next-hop-self keyword in the ibgp router which is directly connected with ebgp neighbor so that other router in same AS (IBGP) can talk with ebgp routers. Refer to configuration examples below:-
Lets assume that we have three routers and we have to setup a ebgp relationship in between them. Router A ( AS :- 34 Serial0 192.168.1.1 , loopback0 1.1.1.1) , RouterB ( AS 34, loopback0 2.2.2.2 , Serial0 192.168.1.2 , Serial1 172.16.1.1), RouterC ( AS 400 , loopback0 3.3.3.3, Serial0 172.16.1.2)
Lets start configuring Router A
router BGP 34 –> As soon as we type 34 BGP process will start in the background
neighbor 192.168.1.2 remote-as 34 –> Bgp will know that this is IBGP looking at AS
Router B
router BGP 34
neighbor 192.168.1.1 remote-as 34
neighbor 172.16.1.2 remote-as 400 –> neighbor relationship with ebgp peer.
neighbor 3.3.3.3 remote-as 400
neighbor 3.3.3.3 ebgp-multihop 255 –> 255 is number of hops that neighbor is away. we can use any number from 1-255, it can be more specific by using 1 or 2 but my personal fav is 255 as it avoids confusion.
neighbor 3.3.3.3 update-source loopback 0 –> Here is the idea, when its sourcing the packets its sourcing it from serial interface, we need to inform the otherside that source interface is not serial interface, it is looback interface so that it cann match ip ip’s with the right interface and form neighbor relationship.
we would require to do similar configuration on router c
router bgp 400
neighbor 172.16.1.1 remote-as 34
neighbor 2.2.2.2 remote-as 34
neighbor 2.2.2.2 ebgp-multihop 255
neighbor 2.2.2.2 update-source loopback 0
Now after forming the neighbro relationships we’ll use network commands to add neighbors in routing table. Network command in BGP is bit different then Network command in other routing protocols. we ‘ll need to define mask keywork with network command in order to advertise clasless network where as if it is using a default mask we can ignore the same.
Example
Router C
router bgp 400
neighbor 172.16.1.0 mask 255.255.255.0
note:- i cannot use network 172.16.0.0 command without mask keyword as it will treat this as class B network. For any customised subnetting scheme we ‘ll need to specify subnet mask with mask keyword in network command.
Even after configuring above, Router A will not be able to talk with Router C. If we will use show ip bgp command on Router A. we’ll see that it has a valid route for Router C but it will not be able to ping router c. This is because next hop will be 3.3.3.3 which is not directly connected with Router A. . First thing which will come in our mind is that rule of synchronisation has taken in to effect but even after disabling synchronisation between router a and router B, Router C will not be reachable. we would need a special command on Router B so that all IBGP peers of AS 34 can talk with AS 400
To troubleshoot this we can use “debug ip bgp updates” but before using this debug we should use ” clear ip bgp *” command. We’ll see that it will show us that there is no valid path for networks in Router C. Next hop should be Router B but in the updates it will show next hp as router c. to avoid the we will use next-hop self keyword in Router B.
Router B
router bgp 34
neighbor 192.168.1.1 next-hop-self
When Router B is sending an update to Router A it is sending the update without changging its next hop so router A will receive next hop as Router C which is not directly connected. To avoid this we will use next-hop-self command in Router B so that router A should receve valid route.
Wednesday, January 25, 2012
再也不要把好东西留到特别的日子才用， 你活着的每一天都是特别的日子！
文章有些长 但不妨一读
请珍惜眼下的每一天
请爱惜和家人每一刻快乐的时光
最近我的一位朋友刚刚离婚，常常跑到我家来聊天诉苦。
这位弟兄算是大家羡慕的成功人士吧，他在华尔街任分析师，年薪三十万美金，开宝
马。
我和他是大学同学，又都住在新泽西，现在已是无话不说。
说来惭愧，我的年薪只有七万，还要带两个小孩和不工作的老婆，买房子是根本不用
想了，也总被一些同学认为没出息。
我一向羡慕这个朋友，那么有追求，事业那么成功，看我这土老冒，安逸享乐，这辈
子算浪费了。
本来我和老婆准备帮助这位朋友和他老婆和好的，但是我知道他们离婚的原因后，
觉得无话可说了，开始对生活有了新的认识。
他和老婆是大学同学，青梅竹马，让人羡慕。
来美国后，两人都开始为学习生活努力，并且毕业后都找到好工作，更流煞人。
工作两年后，弟兄被哥伦比亚大学录取去读MBA，毕业后又到华尔街工作，
而我这时刚在一个学校找到职位，老婆也生了个儿子，羡慕死人家了。
可是不要只是看到这弟兄光鲜的外表，他的婚姻却正在经历痛苦。
刚开始两人一起工作时，他老婆问要不要小孩，他说还有好多事没有做完，没有精
力。
在念MBA时，每天早出晚归忙学习，连老婆也忽略了，老婆几次希望能亲密一下，他
都已经睡着了。
在华尔街工作后，老婆认为终于可以喘口气了，却不想他更是每天早出晚归，因为工
作压力比念MBA还大。
又过了两年，我又有第二个女儿了，他的薪水加奖金也几乎是我薪水的3倍了，老婆
却要和他离婚了。
女人生小孩也有压力，她的年龄已经太大，不生就晚了；而他却天天忙工作，回到家
不是太晚就是太累，他们亲密的机会很少。
最近，他发现自己已经阳痿了，试了几次都不行。
老婆一气之下和他离婚了－－不是因为阳萎，而是觉得他不爱她。
听完他的诉苦，我无话可说。
一直被大家羡慕的夫妻生活竟是这样过的，宝马装的竟全是痛苦。
钱，钱，钱，现在的人为什么就好像是钻到了钱坑，忽略了其他任何的一切。
钱是身外之物，生不带来，死不带走，赚那么多却没有机会花岂不是很悲哀。
我相信现在每年赚三十万的他，宁可花所有的钱来每年来买我的生活，我的老婆和小
孩，可是为什么非要到太晚才觉悟呢？
他现在正在找一个压力小薪水低的工作，可是谈何容易。
除了其他华尔街公司要他做类似的职位外，几乎没有其他公司愿意出那么高价来聘用
他。
他薪水的一半对于一般的公司都太高了。他开玩笑说是走上了不归路。
生活的真正意义是你在死前回过头来问自己是不是活的很快乐，是不是对得起家人，
而不是一辈子赚了多少钱。
我们的小孩也根本不在乎他们是不是有高级玩具，而是有没有爸爸陪他们玩不花钱的
游戏。
有人认为如果不趁年轻时赚钱将来怎么办。
人不能活在将来，因为你怎么知道你有将来？
你甚至怎么知道你有明天？未来？还有将来的将来？
什么时候是你的今天？钱是永远也赚不完的。
但是你一定确定你有现在，你可以把现在活好。
而且有没有出息并不是完全用钱来衡量的。
对于我来说，我的出息是可以每天早早回到家陪家人吃饭和陪小孩玩。
这也是有出息。
刚刚收到一份EMAIL故事和大家分享：
多年前我跟悉尼的一位同学谈话。
那时他太太刚去世不久，他告诉我说，他在整理他太太的东西的时候，发现了一条丝
质的围巾
那是他们去纽约旅游时，在一家名牌店买的
那是一条雅致、漂亮的名牌围巾，高昂的价格标签还挂在上面
他太太一直舍不得用，她想等一个特殊的日子才用。
讲到这，他停住了，我也没接话
好一会后他说："再也不要把好东西留到特别的日子才用，你活着的每一天都是特别
的日子!"
以后，每当我想起这几句话时，我常会把手边的杂事放下，找一本小说，打开音响，
躺在沙上，抓住一些自己的时间。
我会从落地窗欣赏淡水河的景色，不去管玻璃上的灰尘，我会拉着太太到外面去吃
饭，不管家里的菜饭该怎么处理。
生活应当是我们珍惜的一种经验，而不是要捱过去的日子。
我曾经将这段谈话与一位女士分享，后来见面时，她告诉我她现在已不像从前那样，
把美丽的磁具放在酒柜了。
以前她也以为要留待特别的日子才拿出来用，后来发现那一天从未到来。
"将来"，"总有一天" 已经不存在她的字典了。
如果有什么值得高兴的事，有什么得意的事，她现在就要好好体会，对没有拥有的事
物，看淡些，不去想它。
我们常想跟老朋友聚一聚，但总是说"找机会"。
我们常想拥抱一下已经长大的小孩，但总是等适当的时机。
我们常想写封信给另外一半，表达一下浓郁的情意，或想让他知道你很在乎他/她，
但总是告诉自己不急。
其实每天早上我们睁开眼睛时，都要告诉自己这是特别的一天。
每一天，每一分钟都是那么可贵。
有人说：你该尽情的跳舞，好象没有人在看你一样。
你该尽情的用爱心对待所有人，好象从来不会受伤害一样。
我也要尽情的跳舞，尽情的爱。
看完这篇短文后，可以马上起身去擦桌子，或洗碗；可以把报纸放一边，闭起眼睛沉
思一会；
也可以把这篇短文COPY下来， 传真给很多朋友。
当然，我最希望你选择最后这一项，或许，你会改变很多人的一生！谁知道呢？
Tuesday, January 24, 2012
1千怎样变成1百万呢？
们暂时不去研究，他是如何去累积那些车贷和卡债，我们就假设，他从五年前，刚刚踏入社会工作就下定决心要成为百万富翁，领到薪水后，就拿出1千令吉作为起点，踏上百万之路。
1千怎样变成1百万呢？
1千变成1百万只需要十个番，也就是十次的增长一倍，这就是开番的神奇。
算法很简单，用手指算一算就可以了。
第1番：1千变成2千
第2番：2千变成4千
第3番：4千变成8千
第4番：8千变成16千
第5番：16千变成32千
第6番：32千变成64千
第7番：64千变成128千
第8番：128千变成256千
第9番：256千变成512千
第10番：512千变成1024千（已经超过百万了！）
让金钱开番
所以，只要有能力让金钱开番，百万就是简单的事情了。
这位年轻人听完我的解说后就问：那么，怎样让金钱开番呢？
我说：方法很简单，首先你要领悟开番的奥妙，然后积极的做好准备就可以了。从第1番到第6番，是很简单的步骤，只要有恒心，五年内就可以达至了。
这个简单的步骤就是储蓄，只要你每个月定期储蓄1千令吉，五年后的今天，你肯定有了储蓄钱64千，那么你距离百万只剩下4个番而已。
年轻人就说：但是，这并不是金钱开番呀，它是我自己的储蓄钱。
勿怨没本钱
我说：无所谓，总之它已经是你的钱。可惜，当年你没有这个概念，所以你今天就要从头开始，如果你能够每个月定期储蓄1千令吉，经过了漫长的五年，你已经自动开了6个番，而且也具备了致富的条件。
接下来，就是靠你的投资眼光了，你只要掌握住4次的开番机会你就可以完成百万的心愿。
年轻人再问：那么，开番机会在哪里？
我说：就举个例子，去年的金融风暴股票跌到好惨，你只要敢敢的进场，今天你最少也开了一，两番。
就算你错过了那次的机会，但是，你已经小有资本，以你的年龄，再等个十年也不为过，总之，你还是会遇到下一次的机会，如果你继续维持定期的储蓄习惯，下一 次机会出现时，你的资本更雄厚了，你所需要的开番次数就越少，也许，你一生中只需要碰上一，两次的机会，你就是百万富翁了。
不要拘泥于一种投资，眼界扩一点，不管是股票，地产或生意，只要是能够给资本开番的机会，你都要认真的考虑，这才是真正的资本家。
不要埋怨你没有本钱，那是因为你没有储蓄，没有想要致富的欲望，只要你有强烈的致富欲望，你就会培养定期储蓄的习惯，那么，你就会存到一笔钱。
你有储蓄就是有准备，记住：机会总是留给有准备的人。
1千怎样变成1百万呢？
1千变成1百万只需要十个番，也就是十次的增长一倍，这就是开番的神奇。
算法很简单，用手指算一算就可以了。
第1番：1千变成2千
第2番：2千变成4千
第3番：4千变成8千
第4番：8千变成16千
第5番：16千变成32千
第6番：32千变成64千
第7番：64千变成128千
第8番：128千变成256千
第9番：256千变成512千
第10番：512千变成1024千（已经超过百万了！）
让金钱开番
所以，只要有能力让金钱开番，百万就是简单的事情了。
这位年轻人听完我的解说后就问：那么，怎样让金钱开番呢？
我说：方法很简单，首先你要领悟开番的奥妙，然后积极的做好准备就可以了。从第1番到第6番，是很简单的步骤，只要有恒心，五年内就可以达至了。
这个简单的步骤就是储蓄，只要你每个月定期储蓄1千令吉，五年后的今天，你肯定有了储蓄钱64千，那么你距离百万只剩下4个番而已。
年轻人就说：但是，这并不是金钱开番呀，它是我自己的储蓄钱。
勿怨没本钱
我说：无所谓，总之它已经是你的钱。可惜，当年你没有这个概念，所以你今天就要从头开始，如果你能够每个月定期储蓄1千令吉，经过了漫长的五年，你已经自动开了6个番，而且也具备了致富的条件。
接下来，就是靠你的投资眼光了，你只要掌握住4次的开番机会你就可以完成百万的心愿。
年轻人再问：那么，开番机会在哪里？
我说：就举个例子，去年的金融风暴股票跌到好惨，你只要敢敢的进场，今天你最少也开了一，两番。
就算你错过了那次的机会，但是，你已经小有资本，以你的年龄，再等个十年也不为过，总之，你还是会遇到下一次的机会，如果你继续维持定期的储蓄习惯，下一 次机会出现时，你的资本更雄厚了，你所需要的开番次数就越少，也许，你一生中只需要碰上一，两次的机会，你就是百万富翁了。
不要拘泥于一种投资，眼界扩一点，不管是股票，地产或生意，只要是能够给资本开番的机会，你都要认真的考虑，这才是真正的资本家。
不要埋怨你没有本钱，那是因为你没有储蓄，没有想要致富的欲望，只要你有强烈的致富欲望，你就会培养定期储蓄的习惯，那么，你就会存到一笔钱。
你有储蓄就是有准备，记住：机会总是留给有准备的人。
Tuesday, January 17, 2012
Configuring Source Specific Multicast
Table Of Contents
Configuring Source Specific Multicast
This chapter describes how to configure Source Specific Multicast (SSM).
For a complete description of the SSM commands in this chapter, refer
to the "IP Multicast Routing Commands" chapter of the Cisco IOS IP Command Reference, Volume 3 of 3: Multicast.
To locate documentation of other commands that appear in this chapter,
use the command reference master index, or search online.
The Source Specific Multicast feature is an extension of IP multicast
where datagram traffic is forwarded to receivers from only those
multicast sources to which the receivers have explicitly joined. For
multicast groups configured for SSM, only source-specific multicast
distribution trees (no shared trees) are created.
To identify the hardware platform or software image information
associated with a feature, use the Feature Navigator on Cisco.com to
search for information about the feature or refer to the software
release notes for a specific release. For more information, see the
"Identifying Supported Platforms" section in the "Using Cisco IOS
Software" chapter.
SSM Components Overview
SSM is a datagram delivery model that best supports one-to-many
applications, also known as broadcast applications. SSM is a core
networking technology for the Cisco implementation of IP multicast
solutions targeted for audio and video broadcast application
environments. This chapter discusses the following Cisco IOS components
that support the implementation of SSM:
•
Protocol Independent Multicast source specific mode (PIM-SSM)
Protocol Independent Multicast source specific mode (PIM-SSM)
•Internet Group Management Protocol Version 3 (IGMPv3)
Internet Group Management Protocol Version 3 (IGMPv3)
•Internet Group Management Protocol Version 3 lite (IGMP v3lite)
Internet Group Management Protocol Version 3 lite (IGMP v3lite)
•URL Rendezvous Directory (URD)
URL Rendezvous Directory (URD)
PIM-SSM is the routing protocol that supports the implementation of SSM
and is derived from PIM sparse mode (PIM-SM). IGMP is the Internet
Engineering Task Force (IETF) standards track protocol used for hosts to
signal multicast group membership to routers. Version 3 of this
protocol supports source filtering, which is required for SSM. To run
SSM with IGMPv3, SSM must be supported in the Cisco IOS router, the host
where the application is running, and the application itself. IGMP
v3lite and URD are two Cisco-developed transition solutions that enable
the immediate development and deployment of SSM services, without the
need to wait for the availability of full IGMPv3 support in host
operating systems and SSM receiver applications. IGMP v3lite is a
solution for application developers that allows immediate development of
SSM receiver applications switching to IGMPv3 as soon as it becomes
available. URD is a solution for content providers and content
aggregators that enables them to deploy receiver applications that are
not yet SSM enabled (through support for IGMPv3). IGMPv3, IGMP v3lite,
and URD interoperate with each other, so that both IGMP v3lite and URD
can easily be used as transitional solutions toward full IGMPv3 support
in hosts.
How SSM Differs from Internet Standard Multicast
The current IP multicast infrastructure in the Internet and many
enterprise intranets is based on the PIM-SM protocol and Multicast
Source Discovery Protocol (MSDP). These protocols have proved to be
reliable, extensive, and efficient. However, they are bound to the
complexity and functionality limitations of the Internet Standard
Multicast (ISM) service model. For example, with ISM, the network must
maintain knowledge about which hosts in the network are actively sending
multicast traffic. With SSM, this information is provided by receivers
through the source addresses relayed to the last hop routers by IGMPv3,
IGMP v3lite, or URD. SSM is an incremental response to the issues
associated with ISM and is intended to coexist in the network with the
protocols developed for ISM. In general, SSM provides a more
advantageous IP multicast service for applications that utilize SSM.
ISM service is described in RFC 1112. This service consists of the
delivery of IP datagrams from any source to a group of receivers called
the multicast host group. The datagram traffic for the multicast host
group consists of datagrams with an arbitrary IP unicast source address S
and the multicast group address G as the IP destination address.
Systems will receive this traffic by becoming members of the host group.
Membership to a host group simply requires signalling the host group
through IGMP Version 1, 2, or 3.
In SSM, delivery of datagrams is based on (S, G) channels. Traffic for
one (S, G) channel consists of datagrams with an IP unicast source
address S and the multicast group address G as the IP destination
address. Systems will receive this traffic by becoming members of the
(S, G) channel. In both SSM and ISM, no signalling is required to become
a source. However, in SSM, receivers must subscribe or unsubscribe to
(S, G) channels to receive or not receive traffic from specific sources.
In other words, receivers can receive traffic only from (S, G) channels
to which they are subscribed, whereas in ISM, receivers need not know
the IP addresses of sources from which they receive their traffic. The
proposed standard approach for channel subscription signalling utilizes
IGMP INCLUDE mode membership reports, which are supported only in IGMP
Version 3.
SSM IP Address Range
SSM can coexist with the ISM service by applying the SSM delivery model
to a configured subset of the IP multicast group address range. The
Internet Assigned Numbers Authority (IANA) has reserved the address
range 232.0.0.0 through 232.255.255.255 for SSM applications and
protocols. Cisco IOS software allows SSM configuration for an arbitrary
subset of the IP multicast address range 224.0.0.0 through
239.255.255.255. When an SSM range is defined, existing IP multicast
receiver applications will not receive any traffic when they try to use
addresses in the SSM range (unless the application is modified to use
explicit (S, G) channel subscription or is SSM enabled through URD).
SSM Operations
An established network, in which IP multicast service is based on
PIM-SM, can support SSM services. SSM can also be deployed alone in a
network without the full range of protocols that are required for
interdomain PIM-SM (for example, MSDP, Auto-RP, or bootstrap router
[BSR]) if only SSM service is needed.
If SSM is deployed in a network already configured for PIM-SM (Cisco IOS
Release 12.0 or later releases is recommended), then only the last hop
routers must be upgraded to a Cisco IOS software image that supports
SSM. Routers that are not directly connected to receivers do not have to
upgrade to a Cisco IOS software image that supports SSM. In general,
these nonlast hop routers must only run PIM-SM in the SSM range, and may
need additional access control configuration to suppress MSDP
signalling, registering, or PIM-SM shared tree operations from occurring
within the SSM range.
The SSM mode of operation is enabled by configuring the SSM range through the ip pim ssm global configuration command. This configuration has the following effects:
•For
groups within the SSM range, (S, G) channel subscriptions are accepted
through IGMPv3 INCLUDE mode membership reports, IGMP v3lite, or URD
(each of these methods must be configured on a per-interface basis).
IGMP v3lite and URD (S, G) channel subscriptions are ignored for groups
outside the SSM range.
For
groups within the SSM range, (S, G) channel subscriptions are accepted
through IGMPv3 INCLUDE mode membership reports, IGMP v3lite, or URD
(each of these methods must be configured on a per-interface basis).
IGMP v3lite and URD (S, G) channel subscriptions are ignored for groups
outside the SSM range.
Both IGMP v3lite and URD are based on utilizing existing application
IGMP group membership and extending it with their respective (S, G)
channel subscription mechanism, which is ignored by Cisco IOS software
outside the SSM range of addresses. Within the SSM range, IGMP Version 1
(IGMPv1) or Version 2 (IGMPv2) group membership reports or IGMPv3
EXCLUDE mode membership reports are acted upon only in conjunction with
an (S, G) specific membership report from URD or IGMP v3lite.
•PIM
operations within the SSM range of addresses change to PIM-SSM, a mode
derived from PIM-SM. In this mode, only PIM (S, G) join and prune
messages are generated by the router, and no (S, G) rendezvous point
tree (RPT) or (*, G) RPT messages are generated. Incoming messages
related to RPT operations are ignored or rejected and incoming PIM
register messages are immediately answered with register-stop messages.
PIM-SSM is backward compatible with PIM-SM, unless a router is a last
hop router. Therefore, routers that are not last hop routers can run
PIM-SM for SSM groups (for example, if they do not yet support SSM).
PIM
operations within the SSM range of addresses change to PIM-SSM, a mode
derived from PIM-SM. In this mode, only PIM (S, G) join and prune
messages are generated by the router, and no (S, G) rendezvous point
tree (RPT) or (*, G) RPT messages are generated. Incoming messages
related to RPT operations are ignored or rejected and incoming PIM
register messages are immediately answered with register-stop messages.
PIM-SSM is backward compatible with PIM-SM, unless a router is a last
hop router. Therefore, routers that are not last hop routers can run
PIM-SM for SSM groups (for example, if they do not yet support SSM).
•No MSDP Source-Active (SA) messages within the SSM range will be accepted, generated, or forwarded.
No MSDP Source-Active (SA) messages within the SSM range will be accepted, generated, or forwarded.
IGMPv3 Host Signalling
IGMPv3 is the third version of the IETF standards track protocol in
which hosts signal membership to last hop routers of multicast groups.
IGMPv3 introduces the ability for hosts to signal group membership with
filtering capabilities with respect to sources. A host can either signal
that it wants to receive traffic from all sources sending to a group
except for some specific sources (called EXCLUDE mode), or that it wants
to receive traffic only from some specific sources sending to the group
(called INCLUDE mode).
IGMPv3 can operate with both ISM and SSM. In ISM, both EXCLUDE and
INCLUDE mode reports are applicable. In SSM, only INCLUDE mode reports
are accepted by the last hop router. EXCLUDE mode reports are ignored.
For more information on IGMPv3, see the "Configuring IP Multicast Routing" chapter in this document.
IGMP v3lite Host Signalling
IGMP v3lite is a Cisco-developed transitional solution for application
developers to immediately start programming SSM applications. It allows
you to write and run SSM applications on hosts that do not yet support
IGMPv3 in their operating system kernel.
Applications must be compiled with the Host Side IGMP Library (HSIL) for
IGMP v3lite. This software provides applications with a subset of the
IGMPv3 applications programming interface (API) that is required to
write SSM applications. HSIL was developed for Cisco by Talarian and is
available from the following web page:
http://www.talarianmulticast.com/cgi-bin/igmpdownld
One part of the HSIL is a client library linked to the SSM application.
It provides the SSM subset of the IGMPv3 API to the SSM application. If
possible, the library checks whether the operating system kernel
supports IGMPv3. If it does, then the API calls simply are passed
through to the kernel. If the kernel does not support IGMPv3, then the
library uses the IGMP v3lite mechanism.
When using the IGMP v3lite mechanism, the library tells the operating
system kernel to join to the whole multicast group, because joining to
the whole group is the only method for the application to receive
traffic for that multicast group (if the operating system kernel only
supports IGMPv1 or IGMPv2). In addition, the library signals the (S, G)
channel subscriptions to an IGMP v3lite server process, which is also
part of the HSIL. A server process is needed because multiple SSM
applications may be on the same host. This server process will then send
IGMP v3lite-specific (S, G) channel subscriptions to the last hop Cisco
IOS router, which needs to be enabled for IGMP v3lite. This Cisco IOS
router will then "see" both the IGMPv1 or IGMPv2 group membership report
from the operating system kernel and the (S, G) channel subscription
from the HSIL daemon. If the router sees both of these messages, it will
interpret them as an SSM (S, G) channel subscription and join to the
channel through PIM-SSM. We recommend referring to the documentation
accompanying the HSIL software for further information on how to utilize
IGMP v3lite with your application.
IGMP v3lite is supported by Cisco only through the API provided by the
HSIL, not as a function of the router independent of the HSIL. By
default, IGMP v3lite is disabled. When IGMP v3lite is configured through
the ip igmp v3lite interface configuration command on an interface, it will be active only for IP multicast addresses in the SSM range.
URD Host Signalling
URD is a Cisco-developed transitional solution that allows existing IP
multicast receiver applications to be used with SSM without the need to
modify the application and change or add any software on the receiver
host running the application. URD is a content provider solution in
which the receiver applications can be started or controlled through a
web browser.
URD operates by passing a special URL from the web browser to the last
hop router. This URL is called a URD intercept URL. A URD intercept URL
is encoded with the (S, G) channel subscription and has a format that
allows the last hop router to easily intercept it.
As soon as the last hop router intercepts both an (S, G) channel
subscription encoded in a URD intercept URL and sees an IGMP group
membership report for the same multicast group from the receiver
application, the last hop router will use PIM-SSM to join toward the (S,
G) channel as long as the application maintains the membership for the
multicast group G. The URD intercept URL is thus only needed initially
to provide the last hop router with the address of the sources to join
to.
A URD intercept URL has the following syntax:
http://webserver:465/path?group=group&source=source1&...source=sourceN&
The webserver string is the name or IP
address to which the URL is targeted. This target need not be the IP
address of an existing web server, except for situations where the web
server wants to recognize that the last hop router failed to support the
URD mechanism. The number 465 indicates the URD port. Port 465 is
reserved for Cisco by the IANA for the URD mechanism so that no other
applications can use this port.
When the browser of a host encounters a URD intercept URL, it will try
to open a TCP connection to the web server on port 465. If the last hop
router is enabled for URD on the interface where the router receives the
TCP packets from the host, it will intercept all packets for TCP
connections destined to port 465 independent of the actual destination
address of the TCP connection (independent of the address of the web
server). Once intercepted, the last hop router will "speak" a very
simple subset of HTTP on this TCP connection, emulating a web server.
The only HTTP request that the last hop router will understand and reply
to is the following GET request:
GET argument HTTP/1.0
argument = /path?group=group&source=source1&...source=sourceN&
When it receives a GET command, the router tries to parse the argument
according to this syntax to derive one or more (S, G) channel
memberships. The path string of the argument is anything up to, but not including, the first question mark, and is ignored. The group and source1 through sourceN
strings are the IP addresses or fully qualified domain names of the
channels for which this argument is a subscription request. If the
argument matches the syntax shown, the router interprets the argument to
be subscriptions for the channels (source1, group) through (sourceN, group).
The router will accept the channel subscriptions if the following conditions are met:
•The IP address of the multicast group is within the SSM range.
The IP address of the multicast group is within the SSM range.
•The IP address of the host that originated the TCP connection is directly connected to the router.
The IP address of the host that originated the TCP connection is directly connected to the router.
If the channel subscription is accepted, the router will respond to the TCP connection with the following HTML page format:
HTTP/1.1 200 OK
Server:cisco IOS
Content-Type:text/html
<html>
<body>
Retrieved URL string successfully
</body>
</html>
If an error condition occurs, the <body> part of the returned HTML
page will carry an appropriate error message. The HTML page is a
by-product of the URD mechanism. This returned text may, depending on
how the web pages carrying a URD intercept URL are designed, be
displayed to the user or be sized so that the actual returned HTML page
is invisible.
The primary effect of the URD mechanism is that the router will remember
received channel subscriptions and will match them against IGMP group
membership reports received by the host. The router will "remember" a
URD (S, G) channel subscription for up to 3 minutes without a matching
IGMP group membership report. As soon as the router sees that it has
received both an IGMP group membership report for a multicast group G
and a URD (S, G) channel subscription for the same group G, it will join
the (S, G) channel through PIM-SSM. The router will then continue to
join to the (S, G) channel based only on the presence of a continuing
IGMP membership from the host. Thus, one initial URD channel
subscription is all that is needed to be added through a web page to
enable SSM with URD.
If the last hop router from the receiver host is not enabled for URD,
then it will not intercept the HTTP connection toward the web server on
port 465. This situation will result in a TCP connection to port 465 on
the web server. If no further provisions on the web server are taken,
then the user may see a notice (for example, "Connection refused") in
the area of the web page reserved for displaying the URD intercept URL
(if the web page was designed to show this output). It is also possible
to let the web server "listen" to requests on port 465 and install a
Common Gateway Interface (CGI) script that would allow the web server to
know if a channel subscription failed (for example, to subsequently
return more complex error descriptions to the user).
Because the router returns a Content-Type of text and HTML, the best way
to include the URD intercept URL into a web page is to use a frame. By
defining the size of the frame, you can also hide the URD intercept URL
on the displayed page.
By default, URD is disabled on all interfaces. When URD is configured through the ip urd interface configuration command on an interface, it will be active only for IP multicast addresses in the SSM range.
Benefits
IP Multicast Address Management Not Required
In the ISM service, applications must acquire a unique IP multicast
group address because traffic distribution is based only on the IP
multicast group address used. If two applications with different sources
and receivers use the same IP multicast group address, then receivers
of both applications will receive traffic from the senders of both
applications. Even though the receivers, if programmed appropriately,
can filter out the unwanted traffic, this situation would cause
generally unacceptable levels of unwanted traffic.
Allocating a unique IP multicast group address for an application is
still a problem. Most short-lived applications use mechanisms like
Session Description Protocol (SDP) and Session Announcement Protocol
(SAP) to get a random address, a solution that does not work well with a
rising number of applications in the Internet. The best current
solution for long-lived applications is described in RFC 2770, but this
solution suffers from the restriction that each autonomous system is
limited to only 255 usable IP multicast addresses.
In SSM, traffic from each source is forwarded between routers in the
network independent of traffic from other sources. Thus different
sources can reuse multicast group addresses in the SSM range.
Denial of Service Attacks from Unwanted Sources Inhibited
In SSM, multicast traffic from each individual source will be
transported across the network only if it was requested (through IGMPv3,
IGMP v3lite, or URD memberships) from a receiver. In contrast, ISM
forwards traffic from any active source sending to a multicast group to
all receivers requesting that multicast group. In Internet broadcast
applications, this ISM behavior is highly undesirable because it allows
unwanted sources to easily disturb the actual Internet broadcast source
by simply sending traffic to the same multicast group. This situation
depletes bandwidth at the receiver side with unwanted traffic and thus
disrupts the undisturbed reception of the Internet broadcast. In SSM,
this type of denial of service (DoS) attack cannot be made by simply
sending traffic to a multicast group.
Easy to Install and Manage
SSM is easy to install and provision in a network because it does not
require the network to maintain which active sources are sending to
multicast groups. This requirement exists in ISM (with IGMPv1, IGMPv2,
or IGMPv3).
The current standard solutions for ISM service are PIM-SM and MSDP.
Rendezvous point (RP) management in PIM-SM (including the necessity for
Auto-RP or BSR) and MSDP is required only for the network to learn about
active sources. This management is not necessary in SSM, which makes
SSM easier than ISM to install and manage, and therefore easier than ISM
to operationally scale in deployment. Another factor that contributes
to the ease of installation of SSM is the fact that it can leverage
preexisting PIM-SM networks and requires only the upgrade of last hop
routers to support IGMPv3, IGMP v3lite, or URD.
Ideal for Internet Broadcast Applications
The three benefits previously described make SSM ideal for Internet broadcast-style applications for the following reasons:
•The
ability to provide Internet broadcast services through SSM without the
need for unique IP multicast addresses allows content providers to
easily offer their service (IP multicast address allocation has been a
serious problem for content providers in the past).
The
ability to provide Internet broadcast services through SSM without the
need for unique IP multicast addresses allows content providers to
easily offer their service (IP multicast address allocation has been a
serious problem for content providers in the past).
•The
prevention against DoS attacks is an important factor for Internet
broadcast services because, with their exposure to a large number of
receivers, they are the most common targets for such attacks.
The
prevention against DoS attacks is an important factor for Internet
broadcast services because, with their exposure to a large number of
receivers, they are the most common targets for such attacks.
•The
ease of installation and operation of SSM makes it ideal for network
operators, especially in those cases where content needs to be forwarded
between multiple independent PIM domains (because there is no need to
manage MSDP for SSM between PIM domains).
The
ease of installation and operation of SSM makes it ideal for network
operators, especially in those cases where content needs to be forwarded
between multiple independent PIM domains (because there is no need to
manage MSDP for SSM between PIM domains).
Restrictions
Legacy Applications Within the SSM Range Restrictions
Existing applications in a network predating SSM will not work within
the SSM range unless they are modified to support (S, G) channel
subscriptions or are enabled through URD. Therefore, enabling SSM in a
network may cause problems for existing applications if they use
addresses within the designated SSM range.
IGMP v3lite and URD Require a Cisco IOS Last Hop Router
SSM and IGMPv3 are solutions that are being standardized in the IETF.
However, IGMP v3lite and URD are Cisco-developed solutions. For IGMP
v3lite and URD to operate properly for a host, the last hop router
toward that host must be a Cisco IOS router with IGMP v3lite or URD
enabled.
Note This
limitation does not apply to an application using the HSIL if the host
has kernel support for IGMPv3, because then the HSIL will use the kernel
IGMPv3 instead of IGMP v3lite.
This
limitation does not apply to an application using the HSIL if the host
has kernel support for IGMPv3, because then the HSIL will use the kernel
IGMPv3 instead of IGMP v3lite.
Address Management Restrictions
Address management is still necessary to some degree when SSM is used
with Layer 2 switching mechanisms. Cisco Group Management Protocol
(CGMP), IGMP snooping, or Router-Port Group Management Protocol (RGMP)
currently support only group-specific filtering, not (S, G)
channel-specific filtering. If different receivers in a switched network
request different (S, G) channels sharing the same group, then they
will not benefit from these existing mechanisms. Instead, both receivers
will receive all (S, G) channel traffic (and filter out the unwanted
traffic on input). Because of the ability of SSM to reuse the group
addresses in the SSM range for many independent applications, this
situation can lead to less than expected traffic filtering in a switched
network. For this reason it is important to follow the recommendations
set forth in the IETF drafts for SSM to use random IP addresses out of
the SSM range for an application to minimize the chance for reuse of a
single address within the SSM range between different applications. For
example, an application service providing a set of television channels
should, even with SSM, use a different group for each television (S, G)
channel. This setup will guarantee that multiple receivers to different
channels within the same application service will never experience
traffic aliasing in networks that include Layer 2 switches.
IGMP Snooping and CGMP Limitations
IGMPv3 uses new membership report messages that may not be recognized
correctly by older IGMP Snooping switches, in which case hosts will not
properly receive traffic. This situation is not an issue if URD or IGMP
v3lite is used with hosts where the operating system is not upgraded for
IGMPv3, because IGMP v3lite and URD rely only on IGMPv1 or IGMPv2
membership reports. For more information about switching issues related
to IGMP (especially with CGMP), refer to the "Configuring IGMP Version
3" section of the "Configuring IP Multicast Routing" chapter in this
document.
URD Intercept URL Limitations
A URD intercept URL string must be fewer than 256 bytes in length, starting from the /path
argument. In the HTTP/TCP connection, this string must also be
contained within a single TCP/IP packet. For example, for a 256-byte
string, a link maximum transmission unit (MTU) of 128 bytes between the
host and intercepting router would cause incorrect operation of URD.
State Maintenance Limitations
In PIM-SSM, the last hop router will continue to periodically send (S,
G) join messages if appropriate (S, G) subscriptions are on the
interfaces. Therefore, as long as receivers send (S, G) subscriptions,
the shortest path tree (SPT) state from the receivers to the source will
be maintained, even if the source is not sending traffic for longer
periods of time (or even never).
This case is opposite to PIM-SM, where (S, G) state is maintained only
if the source is sending traffic and receivers are joining the group. If
a source stops sending traffic for more than 3 minutes in PIM-SM, the
(S, G) state will be deleted and only reestablished after packets from
the source arrive again through the RPT. Because no mechanism in PIM-SSM
notifies a receiver that a source is active, the network must maintain
the (S, G) state in PIM-SSM as long as receivers are requesting receipt
of that channel.
HSIL Limitations
As explained in the "IGMP v3lite Host Signalling"
section, the HSIL tries to determine if the host operating system
supports IGMPv3. This check is made so that a single application can be
used both on hosts where the operating system has been upgraded to
IGMPv3 and on hosts where the operating system only supports IGMPv1 or
IGMPv2. Checking for the availability of IGMPv3 in the host operating
system can only be made by the HSIL if IGMPv3 kernel support exists for
at least one version of this operating system at the time when the HSIL
was provided. If such an IGMPv3 kernel implementation has become
available only recently, then users may need to also upgrade the HSIL on
their hosts so that applications compiled with the HSIL will then
dynamically bind to the newest version of the HSIL, which should support
the check for IGMPv3 in the operating system kernel. Upgrading the HSIL
can be done independently of upgrading the application itself.
SSM Configuration Task List
To configure SSM, perform the tasks described in the following sections.
The tasks in the first section are required; the tasks in the remaining
section are optional.
•Configuring SSM (Required)
Configuring SSM (Required)
•Monitoring SSM (Optional)
Monitoring SSM (Optional)
Configuring SSM
To configure SSM, use the following commands beginning in global configuration mode:
Monitoring SSM
To monitor SSM, use the following commands in privileged EXEC mode, as needed:
SSM Configuration Examples
This section provides the following SSM configuration examples:
SSM with IGMPv3 Example
The following example shows how to configure a router (running IGMPv3) for SSM:
ip multicast-routing
!
interface Ethernet3/1
ip address 172.21.200.203 255.255.255.0
description backbone interface
ip pim sparse-dense-mode
!
interface Ethernet3/2
ip address 131.108.1.2 255.255.255.0
ip pim sparse-dense-mode
description ethernet connected to hosts
ip igmp version 3
!
ip pim ssm default
SSM with IGMP v3lite and URD Example
The following example shows how to configure IGMP v3lite and URD on
interfaces connected to hosts for SSM. Configuring IGMP v3lite and URD
is not required or recommended on backbone interfaces.
interface ethernet 3/1
ip address 172.21.200.203 255.255.255.0
ip pim sparse-dense-mode
description ethernet connected to hosts
!
interface ethernet 1
description ethernet connected to hosts
ip address 131.108.1.2 255.255.255.0
ip pim sparse-dense-mode
ip urd
ip igmp v3lite
SSM Filtering Example
The following example shows how to configure filtering on a legacy RP
router running Cisco IOS releases earlier than Release 12.1(3)T for SSM
routing. This filtering will suppress all unwanted PIM-SM and MSDP
traffic in the SSM range. Without this filtering, SSM will still
operate, but there may be additional RPT traffic if legacy first hop and
last hop routers exist in the network.
ip access-list extended no-ssm-range
deny ip any 232.0.0.0 0.255.255.255 ! SSM range
permit ip any any
! Deny registering in SSM range
ip pim accept-register list no-ssm-range
ip access-list extended msdp-nono-list
deny ip any 232.0.0.0 0.255.255.255 ! SSM Range
! .
! .
! .
! See ftp://ftpeng.cisco.com/ipmulticast/config-notes/msdp-sa-filter.txt
for other SA
! messages that typically need to be filtered.
permit ip any any
! Filter generated SA messages in SSM range. This configuration is only needed
if there
! are directly connected sources to this router. The "ip pim accept-register"
command
! filters remote sources.
ip msdp redistribute list msdp-nono-list
! Filter received SA messages in SSM range. "Filtered on receipt" means messages
are
! neither processed or forwarded. Needs to be configured for each MSDP peer.
ip msdp sa-filter in msdp-peer1 list msdp-nono-list
! .
! .
! .
ip msdp sa-filter in msdp-peerN list msdp-nono-list
Subscribe to:
Posts (Atom)
