a***n
发帖数: 262 | 1 This is one of projects I am currently working on. Since we are a network
onion, Cisco Core/Firewall, Brocade/Foundry Aggregation/Access, Avaya UC. It
has been a heck lot of readings. Still work in progress. | x*********n
发帖数: 28013 | 2 I never got any chance to play with 6500, sad... | s*****g
发帖数: 1055 | 3 Policing at 128K for a phone? would that be enough for ad hoc conferencing? also when puting voice in a VRF, how do you handle inter-VRF communication especially for hosts running softphone? don't you need to import all other VRF's routes into Voice VRF?
Care to explain to us what are your design goals and challenges you are facing?
It
【在 a***n 的大作中提到】
: This is one of projects I am currently working on. Since we are a network
: onion, Cisco Core/Firewall, Brocade/Foundry Aggregation/Access, Avaya UC. It
: has been a heck lot of readings. Still work in progress.
| a***n
发帖数: 262 | 4 Attached please find the network virtualization hierarchical diagram. The
design will use global routing table as trunk of the tree while individual
L3VPN as leaf of the tree. From leaf to leaf, you have to go thru trunk.
Between trunk and leaf, there will be a virtual firewall.
We will see how this architecture will go along.
Challenges:
Impacts of going thru 2 VFWs between leaves.
Voice applications have to go from VoIP L3VPN to global table for campus wide
services, will that work out well?
Thanks for bringing up the 128k policing question, what's the ad-hoc conferencing? You mean more
than one conferencing on user PC? Please share issues you run into when you
deploy UC/VoIP.
Let me give credit where credit is due, Cisco has design guide for network
virtualization, I am trying to integrate Cisco's SRND into and tailor for our environment.
? also when puting voice in a VRF, how do you handle inter-VRF communication
especially for hosts running softphone? don't you need to import all other
VRF's routes into Voice VRF?
facing?
【在 s*****g 的大作中提到】
: Policing at 128K for a phone? would that be enough for ad hoc conferencing? also when puting voice in a VRF, how do you handle inter-VRF communication especially for hosts running softphone? don't you need to import all other VRF's routes into Voice VRF?
: Care to explain to us what are your design goals and challenges you are facing?
:
: It
| t*******r
发帖数: 3271 | | a***n
发帖数: 262 | 6
Give some new architecture examples please? Or some good book/link/blog to
read? We have backbone refreshment project next year :-)
Does Juniper have UC/VoIP deployment best practices/recommendations? Could
you please give me the links for them if there is any? So far, I have
Cisco, Avaya, Brocade/Foundry UC/VoIP recommendations whitepapers.
【在 t*******r 的大作中提到】
: 1, 网络结构太老套;
: 2, 关键在于QoS;
| he
发帖数: 2025 | 7 webex: 甲乙丙丁都打那个免费电话，各人随便加入退出，其他人不受影响；
ad-hoc: 甲乙在通话，甲再给丙打电话然后加入丙，成三方会谈，同样还可以在
加入丁。甲作为桥，如果甲断线，会谈结束。乙丙丁可以退出不影响他人。
wide
conferencing? You mean more
【在 a***n 的大作中提到】
: Attached please find the network virtualization hierarchical diagram. The
: design will use global routing table as trunk of the tree while individual
: L3VPN as leaf of the tree. From leaf to leaf, you have to go thru trunk.
: Between trunk and leaf, there will be a virtual firewall.
: We will see how this architecture will go along.
: Challenges:
: Impacts of going thru 2 VFWs between leaves.
: Voice applications have to go from VoIP L3VPN to global table for campus wide
: services, will that work out well?
: Thanks for bringing up the 128k policing question, what's the ad-hoc conferencing? You mean more
| t*******r
发帖数: 3271 | 8 你现在狠defensive, 这样谈话不太合适.
【在 a***n 的大作中提到】
:
: Give some new architecture examples please? Or some good book/link/blog to
: read? We have backbone refreshment project next year :-)
: Does Juniper have UC/VoIP deployment best practices/recommendations? Could
: you please give me the links for them if there is any? So far, I have
: Cisco, Avaya, Brocade/Foundry UC/VoIP recommendations whitepapers.
| a***n
发帖数: 262 | 9 没有的事。又不是我自己的网络。
我只对技术感兴趣。 “朝闻道，夕死可矣” ：－）
【在 t*******r 的大作中提到】
: 你现在狠defensive, 这样谈话不太合适.
| a***n
发帖数: 262 | 10 多谢提醒。
webex is ok, since there is a conference bridge.
ad-hoc, I will read more on that.
webex: 甲乙丙丁都打那个免费电话，各人随便加入退出，其他人不受影响；
ad-hoc: 甲乙在通话，甲再给丙打电话然后加入丙，成三方会谈，同样还可以在
加入丁。甲作为桥，如果甲断线，会谈结束。乙丙丁可以退出不影响他人。
wide
conferencing? You mean more
【在 he 的大作中提到】
: webex: 甲乙丙丁都打那个免费电话，各人随便加入退出，其他人不受影响；
: ad-hoc: 甲乙在通话，甲再给丙打电话然后加入丙，成三方会谈，同样还可以在
: 加入丁。甲作为桥，如果甲断线，会谈结束。乙丙丁可以退出不影响他人。
:
: wide
: conferencing? You mean more
| | | t*******r
发帖数: 3271 | 11 我搞错了, 你这个图是企业网的架构, 我还以为是nationwide的呢....这样的话怎么设
计都是无所谓的啦, 设备稳定即可.
我想知道图中主要网络设备的板卡具体型号以及对队列中剩余带宽的分配情况, 这个狠
重要地.
【在 a***n 的大作中提到】
: 没有的事。又不是我自己的网络。
: 我只对技术感兴趣。 “朝闻道，夕死可矣” ：－）
| a***n
发帖数: 262 | 12 backbone are all 10G, to building is 1G, access is 10/100/1000.
I will have Avaya Team come to evaluation UC/VoIP readiness
next week. We will start with trust dscp end-to-end first, then
go to priority queue for UC/VoIP if needed. Other class of traffic
will have to wait for later consideration.
backbone links are WS-6704 WS6708 WS6716 10G. egress mostly 1p7q4t.
1Gs are almost 1p3q4t.
【在 t*******r 的大作中提到】
: 我搞错了, 你这个图是企业网的架构, 我还以为是nationwide的呢....这样的话怎么设
: 计都是无所谓的啦, 设备稳定即可.
: 我想知道图中主要网络设备的板卡具体型号以及对队列中剩余带宽的分配情况, 这个狠
: 重要地.
| t*******r
发帖数: 3271 | 13 http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps70
思科的不是太懂了, 不过斗胆说一下, tx buffer size实在太小了(8个万兆的板卡, 总
体tx buffer才256MB)
但是这里又发现一个WS-X6708的问题
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps70
这个URL说WS-X6708 FIBER模块的buffer size是200 MB per port
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps70
这个URL又说WS-X6708这块板子的Total Buffer Size才256MB
我的理解, 板卡接口的buffer大部分都是给qos/queuing用的吧, 但是上面这块8口万兆
接口板的这两个数据似乎是矛盾的吧~~~~谁能给解释一下?
还有, 以上链接里关于WS-X6716的数据有2种模式, performance模式和oversubscribe
模式是不一样的, 具体是哪个组件分配的, 以及怎么分配的呢?
不要告诉我DFC-3CXL做的啊, 那样的话其实说明WS-X6716其实根本没有完整的qos能力的
【在 a***n 的大作中提到】
: backbone are all 10G, to building is 1G, access is 10/100/1000.
: I will have Avaya Team come to evaluation UC/VoIP readiness
: next week. We will start with trust dscp end-to-end first, then
: go to priority queue for UC/VoIP if needed. Other class of traffic
: will have to wait for later consideration.
: backbone links are WS-6704 WS6708 WS6716 10G. egress mostly 1p7q4t.
: 1Gs are almost 1p3q4t.
| t*******r
发帖数: 3271 | 14 另, 建议如下测试项目:
1, PQ打满, 看是否能挤掉其他traffic;
2, 普通Q打满, 看是否能挤掉PQ;
3, PQ打满并抖动, 另2个普通Q抖动, 看第三个Q如何表现;
4, 测试中关闭接口, 并重新打开, 看设备是否能正确reprogram cos value; | s*****g
发帖数: 1055 | 15
This does not make much sense to me, so if a softphone needs to make a call
to a phone in next cube, the audio traffic has to traverse all the way to
trunk and then come back again? the same would be true for wired/wireless
softphones to access voice gateways when you, presumably, put voice gateways in voip VRF, correct? the same is true for the connection between your voice mail server and Exchange server?
I really don't see the benefit of L3VPN deployment (the so called
virtualization?) in a typical enterprise environment. Segregation of
networks can be achieved in other simpler ways, some times simple ACLs will
suffice.
【在 a***n 的大作中提到】
: Attached please find the network virtualization hierarchical diagram. The
: design will use global routing table as trunk of the tree while individual
: L3VPN as leaf of the tree. From leaf to leaf, you have to go thru trunk.
: Between trunk and leaf, there will be a virtual firewall.
: We will see how this architecture will go along.
: Challenges:
: Impacts of going thru 2 VFWs between leaves.
: Voice applications have to go from VoIP L3VPN to global table for campus wide
: services, will that work out well?
: Thanks for bringing up the 128k policing question, what's the ad-hoc conferencing? You mean more
| a***n
发帖数: 262 | 16
call
gateways in voip VRF, correct? the same is true for the connection between
your voice mail server and Exchange server?
All the above are true :-). Most of our workstations are in global routing
table. Only selected group of things like PCI, VoIP, Wireless are segregated
into L3VPN.
will
Yeah, network virtualization :-). We are using ACLs on almost all non L3VPN
VLANs on campus. But run into tcam issue on catalyst 6500. If you are using
this network virtualization, only firewall rules on the link to the trunk,
within L3VPN, it's assumed trusted. This Network Virtualization is pretty
popular in high education campuses.
You made a good point though, VoIP may not be the best candidate to put into
a L3VPN. I was debating hard on my head for a while. But I will try it
anyway, and let's see how it will go.
【在 s*****g 的大作中提到】
:
: This does not make much sense to me, so if a softphone needs to make a call
: to a phone in next cube, the audio traffic has to traverse all the way to
: trunk and then come back again? the same would be true for wired/wireless
: softphones to access voice gateways when you, presumably, put voice gateways in voip VRF, correct? the same is true for the connection between your voice mail server and Exchange server?
: I really don't see the benefit of L3VPN deployment (the so called
: virtualization?) in a typical enterprise environment. Segregation of
: networks can be achieved in other simpler ways, some times simple ACLs will
: suffice.
| z**r
发帖数: 17771 | 17 I hate ACLs
call
gateways in voip VRF, correct? the same is true for the connection between
your voice mail server and Exchange server?
will
【在 s*****g 的大作中提到】
:
: This does not make much sense to me, so if a softphone needs to make a call
: to a phone in next cube, the audio traffic has to traverse all the way to
: trunk and then come back again? the same would be true for wired/wireless
: softphones to access voice gateways when you, presumably, put voice gateways in voip VRF, correct? the same is true for the connection between your voice mail server and Exchange server?
: I really don't see the benefit of L3VPN deployment (the so called
: virtualization?) in a typical enterprise environment. Segregation of
: networks can be achieved in other simpler ways, some times simple ACLs will
: suffice.
| z**r
发帖数: 17771 | 18 multi-verdor QoS will be pain at your butt
It
【在 a***n 的大作中提到】
: This is one of projects I am currently working on. Since we are a network
: onion, Cisco Core/Firewall, Brocade/Foundry Aggregation/Access, Avaya UC. It
: has been a heck lot of readings. Still work in progress.
| z**r
发帖数: 17771 | 19 don't think he is doing user based policing, all VoIP traffic in his design
shares the PQ pipe, so I think it should be fine
? also when puting voice in a VRF, how do you handle inter-VRF communication
especially for hosts running softphone? don't you need to import all other
VRF's routes into Voice
facing?
【在 s*****g 的大作中提到】
: Policing at 128K for a phone? would that be enough for ad hoc conferencing? also when puting voice in a VRF, how do you handle inter-VRF communication especially for hosts running softphone? don't you need to import all other VRF's routes into Voice VRF?
: Care to explain to us what are your design goals and challenges you are facing?
:
: It
| z**r
发帖数: 17771 | 20 网络设计原则就是KISS，不是为了fancy而fancy
【在 t*******r 的大作中提到】
: 1, 网络结构太老套;
: 2, 关键在于QoS;
| | | z**r
发帖数: 17771 | 21 这些都是LAN CARD，又不是WAN CARD要那么多buffer干什么
【在 t*******r 的大作中提到】
: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps70
: 思科的不是太懂了, 不过斗胆说一下, tx buffer size实在太小了(8个万兆的板卡, 总
: 体tx buffer才256MB)
: 但是这里又发现一个WS-X6708的问题
: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps70
: 这个URL说WS-X6708 FIBER模块的buffer size是200 MB per port
: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps70
: 这个URL又说WS-X6708这块板子的Total Buffer Size才256MB
: 我的理解, 板卡接口的buffer大部分都是给qos/queuing用的吧, 但是上面这块8口万兆
: 接口板的这两个数据似乎是矛盾的吧~~~~谁能给解释一下?
| t*******r
发帖数: 3271 | 22 我就知道你肯定得冒出來为思科摇旗呐喊.
就技术讨论来说如果做qos板卡肯定需要大一些的buffer可以按需分配.
你现在真的走火入魔了, 太defensive/competitive了, 已经偏离了正常的技术思维的
范畴, 什么都说思科好, 自己回去好好反省反省吧. | z**r
发帖数: 17771 | 23 说得好像J家没有LAN CARD似的，这跟谁家的有什么关系，同样数量的接口WAN CARD比
LAN CARD贵至少2倍，不是没有理由的。
LAN CARD做QoS很讨厌，都得迁就硬件上那点可怜的资源，才有1P4Q4T等等这些限制，
总共也就几个QUEUE，哪能像WAN CARD动辄几十K以上的QUEUE。
走火入魔的是你，不管谁跟你有不同意见，你都大扣帽子
【在 t*******r 的大作中提到】
: 我就知道你肯定得冒出來为思科摇旗呐喊.
: 就技术讨论来说如果做qos板卡肯定需要大一些的buffer可以按需分配.
: 你现在真的走火入魔了, 太defensive/competitive了, 已经偏离了正常的技术思维的
: 范畴, 什么都说思科好, 自己回去好好反省反省吧.
| s*****g
发帖数: 1055 | 24 Aglee, usually you only need marking on LAN cards and let WAN card to do
queuing.
【在 z**r 的大作中提到】
: 这些都是LAN CARD，又不是WAN CARD要那么多buffer干什么
| s*****g
发帖数: 1055 | 25 But at 128K? that is only 2 G711 concurrent calls.
design
communication
other
【在 z**r 的大作中提到】
: don't think he is doing user based policing, all VoIP traffic in his design
: shares the PQ pipe, so I think it should be fine
:
: ? also when puting voice in a VRF, how do you handle inter-VRF communication
: especially for hosts running softphone? don't you need to import all other
: VRF's routes into Voice
: facing?
| t*******r
发帖数: 3271 | 26 要是确定了是交换机组网并且要开QOS, 肯定要上buffer大的卡, 这个没什么可争议.
你为什么要用LAN CARD呢?
JUNIPER路由器还真没有LAN CARD.
如果你非得要混淆概念说SWITCH上的就是LAN CARD, 那我也没啥好说的.
现在只要有人说C家不好你就跳出来, 走火入魔的是你才对.
【在 z**r 的大作中提到】
: 说得好像J家没有LAN CARD似的，这跟谁家的有什么关系，同样数量的接口WAN CARD比
: LAN CARD贵至少2倍，不是没有理由的。
: LAN CARD做QoS很讨厌，都得迁就硬件上那点可怜的资源，才有1P4Q4T等等这些限制，
: 总共也就几个QUEUE，哪能像WAN CARD动辄几十K以上的QUEUE。
: 走火入魔的是你，不管谁跟你有不同意见，你都大扣帽子
| z**r
发帖数: 17771 | 27 right, if you consider how many people are going to make calls in the same
time, guess that's fine. usually 30% of the total usage is fine to me
【在 s*****g 的大作中提到】
: But at 128K? that is only 2 G711 concurrent calls.
:
: design
: communication
: other
| z**r
发帖数: 17771 | 28 小托啊，QoS又不是只有queueing feature, classification, marking, policing,
shaping, WRED, queueing全部都是属于QoS，LAN CARD完全可以做marking, policing
这些，真正需要大buffer的只有queueing features
【在 t*******r 的大作中提到】
: 要是确定了是交换机组网并且要开QOS, 肯定要上buffer大的卡, 这个没什么可争议.
: 你为什么要用LAN CARD呢?
: JUNIPER路由器还真没有LAN CARD.
: 如果你非得要混淆概念说SWITCH上的就是LAN CARD, 那我也没啥好说的.
: 现在只要有人说C家不好你就跳出来, 走火入魔的是你才对.
| he
发帖数: 2025 | 29 G.711自己要64k,还有底层协议呢，一般是80k左右。
家门内的局域网有的是带宽，不至于卡到128。
【在 s*****g 的大作中提到】
: But at 128K? that is only 2 G711 concurrent calls.
:
: design
: communication
: other
| z**r
发帖数: 17771 | 30 校园网还有很多其他应用，而且通常voip都是放在pq里面，这个pq也不能设太高了，超
过30%意义也不大了
【在 he 的大作中提到】
: G.711自己要64k,还有底层协议呢，一般是80k左右。
: 家门内的局域网有的是带宽，不至于卡到128。
| | | a***n
发帖数: 262 | 31 Should I use mls qos vlan-based on the backbone catalyst 6500 interfaces?
Since I am doing strict priority queue for VoIP and I am marking on the
network edge, I don't think I need to use mls qos vlan-based. Am I right on
this?
I might have to use mls qos vlan-based on interfaces facing customers since I do have service policy applied on L3 SVIs.
【在 z**r 的大作中提到】
: 网络设计原则就是KISS，不是为了fancy而fancy
| t*******r
发帖数: 3271 | 32 你说的很有道理. 说白了其实语音的应用弄大buffer没啥用.
buffer size调得太大, IP电话就会有刮白铁皮的声音, 巨难听.
policing
【在 z**r 的大作中提到】
: 小托啊，QoS又不是只有queueing feature, classification, marking, policing,
: shaping, WRED, queueing全部都是属于QoS，LAN CARD完全可以做marking, policing
: 这些，真正需要大buffer的只有queueing features
| z**r
发帖数: 17771 | 33
on
vlan-based PFC QoS is only for ingress, don't think you need it for output
direction
since I do have service policy applied on L3 SVIs.
yes
http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/config
【在 a***n 的大作中提到】
: Should I use mls qos vlan-based on the backbone catalyst 6500 interfaces?
: Since I am doing strict priority queue for VoIP and I am marking on the
: network edge, I don't think I need to use mls qos vlan-based. Am I right on
: this?
: I might have to use mls qos vlan-based on interfaces facing customers since I do have service policy applied on L3 SVIs.
| s*****g
发帖数: 1055 | 34 While Cisco's modular QoS framework is better than most other vendors, I
hate the implementation on 6500/7600 (specifically on LAN cards), too many
restrictions, not consistent across different modules, just to name a few.
【在 z**r 的大作中提到】
:
: on
: vlan-based PFC QoS is only for ingress, don't think you need it for output
: direction
: since I do have service policy applied on L3 SVIs.
: yes
: http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/config
| t*******r
发帖数: 3271 | 35 While Cisco's modular QoS framework is better than most other vendors
<== 上面这话太扯, QoS最好的SR目前还是ALU7750-SR
其他大家都差不多.
Juniper的M/T上的IQE,IQ2,IQ2E, MX上的EQ-DPC, TRIO芯片上的eq-mpc, 都是有细微的
差别的
【在 s*****g 的大作中提到】
: While Cisco's modular QoS framework is better than most other vendors, I
: hate the implementation on 6500/7600 (specifically on LAN cards), too many
: restrictions, not consistent across different modules, just to name a few.
|
|
