Re: [c-nsp] 回复: RE: Monitoring 6K performance (pps)
Simply subtract the previous value from the current value and divide by the time interval. That will give your time average over a time interval. Mack From: Aaron Riemer [mailto:arie...@amnet.net.au] Sent: Monday, May 14, 2012 9:09 PM To: 'jstuxuhu0816'; Mack McBride; 'Kyle Duren' Cc: 'cisco-nsp' Subject: RE: RE: [c-nsp] 回复: RE: Monitoring 6K performance (pps) Yep that's what I'm after thanks!. Need to find the OID's now :D With the output of the 'show mls statistics' command would that be total packets since up time? What would be nice would be a 5 minute rate or something. I would like to see peaks etc rather than an uptime average if that makes sense. At the moment it looks like I can't justify going to SUP2T :D Thanks for all the valued input guys. Cheers, Aaron. From: jstuxuhu0816 [mailto:jstuxuhu0...@gmail.com]mailto:[mailto:jstuxuhu0...@gmail.com] Sent: Tuesday, 15 May 2012 9:41 AM To: Mack McBride; Aaron Riemer; 'Kyle Duren' Cc: cisco-nsp; 许, 虎 Subject: 回复: RE: [c-nsp] 回复: RE: Monitoring 6K performance (pps) Yes, you are right, through the 'show mls statistics' we can check the L3 forwarding speed. That's what Aaron want. Also can combine the command of show plat hardware capacity to check much more information. Best Regards, Hu Xu 发件人： Mack McBridemailto:mack.mcbr...@viawest.com 发送时间： 2012-05-15 00:45 收件人： jstuxuhu0816mailto:jstuxuhu0...@gmail.com; Aaron Riemermailto:arie...@amnet.net.au; 'Kyle Duren'mailto:pixitha.k...@gmail.com 抄送： cisco-nspmailto:cisco-nsp@puck.nether.net 主题： RE: [c-nsp] 回复: RE: Monitoring 6K performance (pps) You would need to capture this for each DFC/PFC. The equivalent command line is 'show mls statistics' In the command output there is a total L3 packets processed but that does not include layer 2 packets processed. I would have to research OIDs for the equivalent of that command. Mack -Original Message- From: cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of jstuxuhu0816 Sent: Monday, May 14, 2012 7:02 AM To: Aaron Riemer; 'Kyle Duren' Cc: cisco-nsp Subject: [c-nsp] 回复: RE: Monitoring 6K performance (pps) Because i saw your original email said looking to obtain raw packets per second (pps) that are actually processed by the switch. Through this command, you can got this result? Best Regards, Hu Xu 发件人： Aaron Riemer 发送时间： 2012-05-14 20:43 收件人： '许, 虎'; 'Kyle Duren' 抄送： 'cisco-nsp' 主题： RE: Re: [c-nsp] Monitoring 6K performance (pps) What do you mean you don't see any useful result? I am monitoring the data you see in your show command via SNMP and graphing this in Cacti. Cheers, Aaron. From: jstuxuhu0816 [mailto:jstuxuhu0...@gmail.com] Sent: Monday, 14 May 2012 7:18 PM To: Aaron Riemer; 'Kyle Duren' Cc: cisco-nsp Subject: Re: Re: [c-nsp] Monitoring 6K performance (pps) Hi Aaron, Just now i monitored the utilization of fabric through command show fabric utilization detail , i don't see any useful result for your case, see as bellow: Router#show fabric utilization detail Fabric utilization: IngressEgress Module Chanl Speed rate peak rate peak 1 020G1%0% 1%0% 1 120G1%0% 0%0% 4 0 8G0%0% 0%0% 5 020G1%0% 2%0% 6 020G0%0% 0%0% 7 0 8G0%0% 0%0% 8 020G0%0% 1%0% I don't understand how you can see the result, let me know if you have any progress about this issue. Thanks and Regards, Hu Xu From: Aaron Riemer Date: 2012-05-13 15:29 To: 'Kyle Duren' CC: cisco-nsp Subject: Re: [c-nsp] Monitoring 6K performance (pps) Hi Kyle, I have had a think about this a little more. It is probably more worthwhile monitoring the utilisation of the fabric on all blades rather than counting up packets per second per interface. I understand that I would lose visibility of any local switching going on (i.e. traffic not traversing the switch fabric). Please see my other post. Any comments welcome :) Cheers, Aaron. From: Kyle Duren [mailto:pixitha.k...@gmail.com] Sent: Sunday, 13 May 2012 3:12 PM To: Aaron Riemer Cc: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Monitoring 6K performance (pps) You can use snmp to collect packets/sec also, cacti can make nice graphs for both mb/sec and packets/sec -Kyle On Sat, May 12, 2012 at 11:19 PM, Aaron Riemer arie...@amnet.net.aumailto:arie...@amnet.net.au wrote: Hey guys, We are looking at upgrading our CAT6K SUP's and I am trying to figure out how I can monitor the current throughput. We currently monitor the interface utilisation (bits / sec) with SNMP. That is all well and good but I am looking to
[c-nsp] p2mp te tunnels on me3600x
Hi, Are there any plans on implementing p2mp te-tunnels or mldp on me3600x please? Thanks adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco TAC website upgraded
Sigh. So, does anyone else see a new, shiny (a.k.a. broken) TAC web UI today? Leaving aside the fact that I get an hilarious refresh loop when I try to view a case (based on the URL argument, I guess Google Chrome is an unsupported browser) it is full of brokenness - file uploads not working for a colleague, no list of previous TAC cases until you open a new one, horrible UI... I just don't understand how Cisco can be so utterly clueless in the website department. grumble. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco TAC website upgraded
Hi, On Tue, May 15, 2012 at 01:05:18PM +0100, Phil Mayers wrote: I just don't understand how Cisco can be so utterly clueless in the website department. This is not a matter of cluelessness. You have to work hard to achieve this. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp3vaeH6byrl.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OSPFv3 in a VRF on a 7600
Actually, the 7600 is in the ERBU, which also has the 9K, 10K, and 12K. So, no BU cooperation needed ;-) -A -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: 10. april 2012 16:54 To: Aaron Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPFv3 in a VRF on a 7600 Hi, On Tue, Apr 10, 2012 at 09:27:41AM -0500, Aaron wrote: Does anyone know if this and other things are slow to be or possibly will not be supported as an agenda within cisco to cause folks to upgrade to ASR9K-type platforms from older 7600 ? Nah, that would assume cooperation between BUs, and the 7600 BU doesn't cooperate with anyone. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OTV on-a-stick
You might be able to make that work in the lab, at least with 'switch trunk allow' so that you don't bridge between the internal interfaces, and if you make sure that you didn't have overlapping VLAN numbers to extend. But I wouldn't consider it best practice. The OTV VDC needs a site VLAN, which would exist on one of the L2 interfaces, but not both, thus making OTV functionality for one 'client' VDC dependent on the life of the other. Not really where I'd want to go. If you used a separate physical interface for the site VLAN, it would make slightly more sense, but you'd still want to be careful with which interfaces were allowed on the insite, and not to overlap them in the overlay... and it's not likely to be solution tested and supported from Cisco, I would think, which means that you should do a lot more testing yourself. -A -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Soares Sent: 14. maj 2012 12:15 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OTV on-a-stick Guys, any comments to this OTV on-a-stick question ? Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Soares Sent: quinta-feira, 10 de Maio de 2012 19:09 To: cisco-nsp@puck.nether.net Subject: [c-nsp] OTV on-a-stick Hello group, Anyone knows if having more than one Routing VDC is a supported deployment ? Basically I want OTV on-a-stick like we have bellow but I want another VDC to make use of the OTV VDC: http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepa per/DCI_1.html#wp1215970 So I would need to create a second Internal Interface connected to the new Routing VDC and use the existing Join Interface connected to the already in place Routing VDC. Does it work ? In terms of configuration, it should be something like this: interface Overlay0 otv join-interface ethernet1/1 interface Ethernet1/1 description Layer-3-to-Routing-VDC-1 (join interface) interface Ethernet1/2 description Layer2-to-Routing-VDC-1 (internal interface) switchport interface Ethernet1/3 description Layer2-to-Routing-VDC-2 (internal interface) switchport Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] RHI with Nexus7K
AFAIK, RHI is currently supported only in the 6500. If the 6500 has a Layer 3 interface into the VLAN, you can do RHI. -A -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of henrry huaman Sent: 11. maj 2012 21:02 To: cisco-nsp@puck.nether.net Subject: [c-nsp] RHI with Nexus7K Hi all! I´m looking for a functionality like a RHI between ACE and Nexus7K. Currently We have 2 DCs sending the same VIP and the topology is: ServersACE(6500 L2)-N7K (OSPF) The ACE is working in mode L3 is there a feature similar to RHI? Thanks! Henry ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Small DC switch design
Your size sounds fairly close to our situation... Do you have a spare fiber pair going to each location? Right now in each of the 7 buildings has a 3560G as an aggregation switch connected back to the DC. The DC also has a few 3560G's and 3750G's for the sans and servers. [...] What I would like to know (costs being the biggest factor) is what would be a better switch design for the current and future traffic in this network. Some options I was thinking about are as follows: Without more details I'm guessing here. Like many smaller shops I've been around the thing has grown from a long time ago and there may be a primarily flat L2 design in place, maybe there are some vlans. Maybe there is some (or a lot of) daisy chaining of switches; maybe the spanning-tree configuration hasn't gotten a lot of thought. OTOH, hopefully you're in a better spot than this? In the Cisco world I think you're right on the money with Cat45xx; the 49xx series are related... Skim over this document and see if the general idea makes sense. You have L3 capable switches everywhere so it's a no brainer in a way: https://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigr ation_09186a00805fccbf.pdf We used this as a model, a pair of 4900M switches as the core and a few 4507-E w/SUP-6E as our access switches running OSPF; it is collapsed-core w/10G links fanning out (no separate distribution layer). As a whole we are very happy with the system. The nice thing about routing everything is it fails in more pleasant ways than the typical spanning-tree disaster. The 45xx line has seen a major upgrade. You probably want a +E chassis instead of -E. Also, the SUP-7E is out and it has netflow amongst other upgrades. There is an SUP-7L-E as well for a cheaper option. Check with your rep about bundles as it's definitely money saving. For the core, look at the 4900M or the newer 4500-X; these two switches are basically a semi-fixed version of the cat45xx (fixed sup, replaceable line cards). Note with sup-7 based switches you are going to IOS-XE instead of classic IOS. Another budget-wise choice for the core and aggregation may be the ME3600X/ME3800X. It's marketed at the ISP space but search through the archives of this list for discussion of it. Even if you aren't going down the road of L3 in the access layer I can't recommend enough making sure a hierarchical design is in place. It is much easier to troubleshoot and changes are much easier to implement. ~JasonG ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OTV on-a-stick
Thanks for the feedback, in fact we won't deploy this in any production network without having Cisco saying it works and it's supported :) The idea is to extend the concept. We have this: VDC1===Layer 2 (VLANs 100,101,...)===OTV===Layer 3===VDC1---Layer 3 to remote DC And we want to add this: VDC2===Layer 2 (VLANs 200,201,...)===OTV In the case we have overlapping Vlans, the option would be the creation of a second OTV VDC: VDC1===Layer 2 (VLANs 100,101,...)===OTV 1===Layer 3===VDC1---Layer 3 to remote DC VDC2===Layer 2 (VLANs 100,101,...)===OTV 2=== ??? Above I don't know if we can configure the Join interface to the same VDC1 or if we need to do it to VDC2. Then since VDC1 is the VDC that connects to the other DC, we would need a L3 connection between VDC2 and VDC1. I've come across these 4 scenarios: http://ccie18473.net/otv-on-a-stick-3.jpg Scenario 1 is what I want. Scenario 3 is for situations with overlapping Vlans. Scenarios 2 and 4, I thought initially that the Internal and Join interfaces should connect to the same VDC, maybe this is not necessary at all. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: Asbjorn Hojmark - Lists [mailto:li...@hojmark.org] Sent: terça-feira, 15 de Maio de 2012 15:59 To: 'Antonio Soares' Cc: cisco-nsp@puck.nether.net Subject: RE: [c-nsp] OTV on-a-stick You might be able to make that work in the lab, at least with 'switch trunk allow' so that you don't bridge between the internal interfaces, and if you make sure that you didn't have overlapping VLAN numbers to extend. But I wouldn't consider it best practice. The OTV VDC needs a site VLAN, which would exist on one of the L2 interfaces, but not both, thus making OTV functionality for one 'client' VDC dependent on the life of the other. Not really where I'd want to go. If you used a separate physical interface for the site VLAN, it would make slightly more sense, but you'd still want to be careful with which interfaces were allowed on the insite, and not to overlap them in the overlay... and it's not likely to be solution tested and supported from Cisco, I would think, which means that you should do a lot more testing yourself. -A -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Soares Sent: 14. maj 2012 12:15 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OTV on-a-stick Guys, any comments to this OTV on-a-stick question ? Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Soares Sent: quinta-feira, 10 de Maio de 2012 19:09 To: cisco-nsp@puck.nether.net Subject: [c-nsp] OTV on-a-stick Hello group, Anyone knows if having more than one Routing VDC is a supported deployment ? Basically I want OTV on-a-stick like we have bellow but I want another VDC to make use of the OTV VDC: http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepa per/DCI_1.html#wp1215970 So I would need to create a second Internal Interface connected to the new Routing VDC and use the existing Join Interface connected to the already in place Routing VDC. Does it work ? In terms of configuration, it should be something like this: interface Overlay0 otv join-interface ethernet1/1 interface Ethernet1/1 description Layer-3-to-Routing-VDC-1 (join interface) interface Ethernet1/2 description Layer2-to-Routing-VDC-1 (internal interface) switchport interface Ethernet1/3 description Layer2-to-Routing-VDC-2 (internal interface) switchport Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] p2mp te tunnels on me3600x
MLDP is on the roadmap for 2HCY13. P2MP TE is supported in hardware but software support is in radar. If you have a requirement, please ask your account team to reach out to me. Thanks, Waris -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of adam vitkovsky Sent: Tuesday, May 15, 2012 5:00 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] p2mp te tunnels on me3600x Hi, Are there any plans on implementing p2mp te-tunnels or mldp on me3600x please? Thanks adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OTV on-a-stick
If using a single OTV VDC to connect two 'client' (DCI) VDCs over the core, I would connect the OTV VDC to the core, not back to one of the 'client' VDCs, again because it creates a dependency between the 'client' VDCs. (If VDC 1 is down, and VDC 1 does L3 and/or site VLAN for OTV, then VDC 2 DCI will be down as well). (The OTV VDC can only have a single join interface). -A -Original Message- From: Antonio Soares [mailto:amsoa...@netcabo.pt] Sent: 15. maj 2012 18:32 To: 'Asbjorn Hojmark - Lists' Cc: cisco-nsp@puck.nether.net Subject: RE: [c-nsp] OTV on-a-stick Thanks for the feedback, in fact we won't deploy this in any production network without having Cisco saying it works and it's supported :) The idea is to extend the concept. We have this: VDC1===Layer 2 (VLANs 100,101,...)===OTV===Layer 3===VDC1---Layer 3 to remote DC And we want to add this: VDC2===Layer 2 (VLANs 200,201,...)===OTV In the case we have overlapping Vlans, the option would be the creation of a second OTV VDC: VDC1===Layer 2 (VLANs 100,101,...)===OTV 1===Layer 3===VDC1---Layer 3 to remote DC VDC2===Layer 2 (VLANs 100,101,...)===OTV 2=== ??? Above I don't know if we can configure the Join interface to the same VDC1 or if we need to do it to VDC2. Then since VDC1 is the VDC that connects to the other DC, we would need a L3 connection between VDC2 and VDC1. I've come across these 4 scenarios: http://ccie18473.net/otv-on-a-stick-3.jpg Scenario 1 is what I want. Scenario 3 is for situations with overlapping Vlans. Scenarios 2 and 4, I thought initially that the Internal and Join interfaces should connect to the same VDC, maybe this is not necessary at all. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: Asbjorn Hojmark - Lists [mailto:li...@hojmark.org] Sent: terça-feira, 15 de Maio de 2012 15:59 To: 'Antonio Soares' Cc: cisco-nsp@puck.nether.net Subject: RE: [c-nsp] OTV on-a-stick You might be able to make that work in the lab, at least with 'switch trunk allow' so that you don't bridge between the internal interfaces, and if you make sure that you didn't have overlapping VLAN numbers to extend. But I wouldn't consider it best practice. The OTV VDC needs a site VLAN, which would exist on one of the L2 interfaces, but not both, thus making OTV functionality for one 'client' VDC dependent on the life of the other. Not really where I'd want to go. If you used a separate physical interface for the site VLAN, it would make slightly more sense, but you'd still want to be careful with which interfaces were allowed on the insite, and not to overlap them in the overlay... and it's not likely to be solution tested and supported from Cisco, I would think, which means that you should do a lot more testing yourself. -A -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Soares Sent: 14. maj 2012 12:15 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OTV on-a-stick Guys, any comments to this OTV on-a-stick question ? Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Soares Sent: quinta-feira, 10 de Maio de 2012 19:09 To: cisco-nsp@puck.nether.net Subject: [c-nsp] OTV on-a-stick Hello group, Anyone knows if having more than one Routing VDC is a supported deployment ? Basically I want OTV on-a-stick like we have bellow but I want another VDC to make use of the OTV VDC: http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepa per/DCI_1.html#wp1215970 So I would need to create a second Internal Interface connected to the new Routing VDC and use the existing Join Interface connected to the already in place Routing VDC. Does it work ? In terms of configuration, it should be something like this: interface Overlay0 otv join-interface ethernet1/1 interface Ethernet1/1 description Layer-3-to-Routing-VDC-1 (join interface) interface Ethernet1/2 description Layer2-to-Routing-VDC-1 (internal interface) switchport interface Ethernet1/3 description Layer2-to-Routing-VDC-2 (internal interface) switchport Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net
Re: [c-nsp] QOS difference behavior for GSR and 7609
On 5/14/12 7:54 PM, Xu Hu wrote: Ok, do you heard about the MDRR in the GSR? What's the main purpose of this QOS approach? Yes, we've heard of it. Its purpose is to manage QoS through a 64x64 (or 16x or 128x, platform-dependent) crossbar fabric. pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Call rejeciton from Cisco
Hello. I am using an AS5400 to generate a PRI that is then going to a CiscoIAD. So on the AS5400 side I have. The IAD only has 8 analog voice ports, so I am using the last 8 channels of the PRI for voice ports, and the first 16 channels as a T1 for internet service. controller T1 1/0:24 framing esf channel-group 0 timeslots 1-16 speed 64 loopback network ignore pri-group timeslots 17-24 interface Serial1/0:24:0 ip address 216.24.28.249 255.255.255.252 encapsulation ppp no cdp enable ! interface Serial1/0:24:23 no ip address isdn switch-type primary-ni isdn protocol-emulate network no isdn outgoing ie redirecting-number no isdn incoming alerting add-PI no cdp enable On the IAD I have controller T1 1/0 framing esf linecode b8zs channel-group 0 timeslots 1-16 speed 64 pri-group timeslots 17-24 nfas_d primary nfas_int 1 nfas_group 1 interface Serial1/0:0 ip address 216.24.28.250 255.255.255.252 encapsulation ppp ! interface Serial1/0:23 no ip address isdn switch-type primary-ni isdn incoming-voice voice no cdp enable dial-peer voice 1 pots description route calls to ISDN destination-pattern .T port 1/0:23 The PRI and TEI's seem to be up. The AS5400 has intermachine trunks connecting it to the telco system and routes incoming and outgoing phone calls all day long, but when I try to make an outgoing call from the Cisco IAD I see the IAD 2400 appear to do the call setup and send the call out 1/0:23, but eventually I get a reject with a cause code of 0x0, which isn't very helpful. I'm not even sure if the error message is coming from the far end (the AS5400) or the near end (the IAD2400). Error output below with the reject highlighted in red. It would seem that the called is being rejected for Invalid information element contents. I'm having a hard time determining which elements it considers invalid, though. We've never generated our own PRI out to a client box before, so any information anyone has would be greatly appreciated. Also, if anyone has a config example of both ends of such an arrangement I would love to see it. 022127: 1w0d: ISDN Se1/0:24:23 Q931: RX - SETUP pd = 8 callref = 0x002C Bearer Capability i = 0x9090A2 Standard = CCITT Transer Capability = 3.1kHz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xE1818397 Preferred, Interface 1, Channel 23 Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x2183, '5025673005' Plan:ISDN, Type:National Called Party Number i = 0x80, '75023871095' Plan:Unknown, Type:Unknown 022128: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x64FBB518), ticks (3), event (0x1250) 022129: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x20A, event = 0x241, call id = 0x0, int id = 0x0 022130: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x2F62 cr 0x802C state 0 event 0x5 ces 1 022131: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802C SETUP:U0_Setup(nlcb) 022132: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802C old NULL_STATE, new CALL_PRESENT 022133: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x400, event = 0x340, call id = 0x2F62, int id = 0x0 022134: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x2F62 cr 0x802C state 6 event 0x82 ces 1 022135: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802C CC_SETUP_REJ_REQ:U6_SetupRejReq(nlcb) 022136: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802C old CALL_PRESENT, new NULL_STATE 022137: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x65F432AC), ticks (1000), event (0x1240) 022138: 1w0d: ISDN Se1/0:24:23 Q931: TX - RELEASE_COMP pd = 8 callref = 0x802C Cause i = 0x82E418 - Invalid information element contents 022139: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x64FBB518), ticks (3), event (0x1250) AMSS1# ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Call rejeciton from Cisco
On a related note, I am aware that part of the problem might be that the called party number might be listed as plan unknown and type unknown. I've been trying to figure out a way on the IAD 2400 to set this to national and isdn for all outgoing calls, but the only way I can find to do that is with translation rules, and those all seem to assume that the first thing you want to do is search and replace part of the dialed number. I really don't care what the dialed number is. Is there some way to match just on the plan and type, or some way to set those values other than a translation rule? - Original Message - From: Joseph Mays To: cisco-...@puck.nether.net ; cisco-nsp@puck.nether.net Sent: Tuesday, May 15, 2012 1:42 PM Subject: Call rejeciton from Cisco Hello. I am using an AS5400 to generate a PRI that is then going to a CiscoIAD. So on the AS5400 side I have. The IAD only has 8 analog voice ports, so I am using the last 8 channels of the PRI for voice ports, and the first 16 channels as a T1 for internet service. controller T1 1/0:24 framing esf channel-group 0 timeslots 1-16 speed 64 loopback network ignore pri-group timeslots 17-24 interface Serial1/0:24:0 ip address 216.24.28.249 255.255.255.252 encapsulation ppp no cdp enable ! interface Serial1/0:24:23 no ip address isdn switch-type primary-ni isdn protocol-emulate network no isdn outgoing ie redirecting-number no isdn incoming alerting add-PI no cdp enable On the IAD I have controller T1 1/0 framing esf linecode b8zs channel-group 0 timeslots 1-16 speed 64 pri-group timeslots 17-24 nfas_d primary nfas_int 1 nfas_group 1 interface Serial1/0:0 ip address 216.24.28.250 255.255.255.252 encapsulation ppp ! interface Serial1/0:23 no ip address isdn switch-type primary-ni isdn incoming-voice voice no cdp enable dial-peer voice 1 pots description route calls to ISDN destination-pattern .T port 1/0:23 The PRI and TEI's seem to be up. The AS5400 has intermachine trunks connecting it to the telco system and routes incoming and outgoing phone calls all day long, but when I try to make an outgoing call from the Cisco IAD I see the IAD 2400 appear to do the call setup and send the call out 1/0:23, but eventually I get a reject with a cause code of 0x0, which isn't very helpful. I'm not even sure if the error message is coming from the far end (the AS5400) or the near end (the IAD2400). Error output below with the reject highlighted in red. It would seem that the called is being rejected for Invalid information element contents. I'm having a hard time determining which elements it considers invalid, though. We've never generated our own PRI out to a client box before, so any information anyone has would be greatly appreciated. Also, if anyone has a config example of both ends of such an arrangement I would love to see it. 022127: 1w0d: ISDN Se1/0:24:23 Q931: RX - SETUP pd = 8 callref = 0x002C Bearer Capability i = 0x9090A2 Standard = CCITT Transer Capability = 3.1kHz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xE1818397 Preferred, Interface 1, Channel 23 Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x2183, '5025673005' Plan:ISDN, Type:National Called Party Number i = 0x80, '75023871095' Plan:Unknown, Type:Unknown 022128: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x64FBB518), ticks (3), event (0x1250) 022129: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x20A, event = 0x241, call id = 0x0, int id = 0x0 022130: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x2F62 cr 0x802C state 0 event 0x5 ces 1 022131: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802C SETUP:U0_Setup(nlcb) 022132: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802C old NULL_STATE, new CALL_PRESENT 022133: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x400, event = 0x340, call id = 0x2F62, int id = 0x0 022134: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x2F62 cr 0x802C state 6 event 0x82 ces 1 022135: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802C CC_SETUP_REJ_REQ:U6_SetupRejReq(nlcb) 022136: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802C old CALL_PRESENT, new NULL_STATE 022137: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x65F432AC), ticks (1000), event (0x1240) 022138: 1w0d: ISDN Se1/0:24:23 Q931: TX - RELEASE_COMP pd = 8 callref = 0x802C Cause i = 0x82E418 - Invalid information element contents 022139: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x64FBB518), ticks (3), event (0x1250) AMSS1# ___ cisco-nsp mailing list
Re: [c-nsp] Call rejeciton from Cisco
On Tue, May 15, 2012 at 14:08:17, Joseph Mays wrote: Subject: Re: [c-nsp] Call rejeciton from Cisco On a related note, I am aware that part of the problem might be that the called party number might be listed as plan unknown and type unknown. I've been trying to figure out a way on the IAD 2400 to set this to national and isdn for all outgoing calls, but the only way I can find to do that is with translation rules, and those all seem to assume that the first thing you want to do is search and replace part of the dialed number. I really don't care what the dialed number is. Is there some way to match just on the plan and type, or some way to set those values other than a translation rule? You can try this: voice translation-rule 100 rule 1 /^\(.*\)/ /\1/ type any national plan any isdn ! voice translation-profile outbound-set translate called 100 Then put that on your POTS dial-peer outbound. -ryan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Call rejeciton from Cisco
Disregard. I figured out how to get it to set the plan and type, but it's still having the same problem. 027789: 1w0d: ISDN Se1/0:24:23 Q931: RX - SETUP pd = 8 callref = 0x002D Bearer Capability i = 0x9090A2 Standard = CCITT Transer Capability = 3.1kHz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xE1818397 Preferred, Interface 1, Channel 23 Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x2183, '5025673005' Plan:ISDN, Type:National Called Party Number i = 0xA1, '5023871095' Plan:ISDN, Type:National 027790: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x64FBB518), ticks (3), event (0x1250) 027791: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x20A, event = 0x241, call id = 0x0, int id = 0x0 027792: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x300E cr 0x802D state 0 event 0x5 ces 1 027793: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802D SETUP:U0_Setup(nlcb) 027794: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802D old NULL_STATE, new CALL_PRESENT 027795: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x400, event = 0x340, call id = 0x300E, int id = 0x0 027796: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x300E cr 0x802D state 6 event 0x82 ces 1 027797: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802D CC_SETUP_REJ_REQ:U6_SetupRejReq(nlcb) 027798: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802D old CALL_PRESENT, new NULL_STATE 027799: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x65F432AC), ticks (1000), event (0x1240) 027800: 1w0d: ISDN Se1/0:24:23 Q931: TX - RELEASE_COMP pd = 8 callref = 0x802D Cause i = 0x82E418 - Invalid information element contents - Original Message - From: Joseph Mays To: cisco-...@puck.nether.net ; cisco-nsp@puck.nether.net Sent: Tuesday, May 15, 2012 2:08 PM Subject: Re: Call rejeciton from Cisco On a related note, I am aware that part of the problem might be that the called party number might be listed as plan unknown and type unknown. I've been trying to figure out a way on the IAD 2400 to set this to national and isdn for all outgoing calls, but the only way I can find to do that is with translation rules, and those all seem to assume that the first thing you want to do is search and replace part of the dialed number. I really don't care what the dialed number is. Is there some way to match just on the plan and type, or some way to set those values other than a translation rule? - Original Message - From: Joseph Mays To: cisco-...@puck.nether.net ; cisco-nsp@puck.nether.net Sent: Tuesday, May 15, 2012 1:42 PM Subject: Call rejeciton from Cisco Hello. I am using an AS5400 to generate a PRI that is then going to a CiscoIAD. So on the AS5400 side I have. The IAD only has 8 analog voice ports, so I am using the last 8 channels of the PRI for voice ports, and the first 16 channels as a T1 for internet service. controller T1 1/0:24 framing esf channel-group 0 timeslots 1-16 speed 64 loopback network ignore pri-group timeslots 17-24 interface Serial1/0:24:0 ip address 216.24.28.249 255.255.255.252 encapsulation ppp no cdp enable ! interface Serial1/0:24:23 no ip address isdn switch-type primary-ni isdn protocol-emulate network no isdn outgoing ie redirecting-number no isdn incoming alerting add-PI no cdp enable On the IAD I have controller T1 1/0 framing esf linecode b8zs channel-group 0 timeslots 1-16 speed 64 pri-group timeslots 17-24 nfas_d primary nfas_int 1 nfas_group 1 interface Serial1/0:0 ip address 216.24.28.250 255.255.255.252 encapsulation ppp ! interface Serial1/0:23 no ip address isdn switch-type primary-ni isdn incoming-voice voice no cdp enable dial-peer voice 1 pots description route calls to ISDN destination-pattern .T port 1/0:23 The PRI and TEI's seem to be up. The AS5400 has intermachine trunks connecting it to the telco system and routes incoming and outgoing phone calls all day long, but when I try to make an outgoing call from the Cisco IAD I see the IAD 2400 appear to do the call setup and send the call out 1/0:23, but eventually I get a reject with a cause code of 0x0, which isn't very helpful. I'm not even sure if the error message is coming from the far end (the AS5400) or the near end (the IAD2400). Error output below with the reject highlighted in red. It would seem that the called is being rejected for Invalid information element contents. I'm having a hard time determining which elements it considers invalid, though. We've never generated our own PRI out to a client box before, so any
Re: [c-nsp] Call rejeciton from Cisco
http://www.cisco.com/en/US/docs/ios/12_2/dial/command/reference/drfisl2.html#wp1116673 Usually Cause i = 0x82E418 - Invalid information element contents means that it's not happy about it requesting an exclusive channel vs preferred iirc.. Could also be a mismatched ISDN switch type? NI2 I would assume on both? On Tue, May 15, 2012 at 1:16 PM, Joseph Mays m...@win.net wrote: Disregard. I figured out how to get it to set the plan and type, but it's still having the same problem. 027789: 1w0d: ISDN Se1/0:24:23 Q931: RX - SETUP pd = 8 callref = 0x002D Bearer Capability i = 0x9090A2 Standard = CCITT Transer Capability = 3.1kHz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xE1818397 Preferred, Interface 1, Channel 23 Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x2183, '5025673005' Plan:ISDN, Type:National Called Party Number i = 0xA1, '5023871095' Plan:ISDN, Type:National 027790: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x64FBB518), ticks (3), event (0x1250) 027791: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x20A, event = 0x241, call id = 0x0, int id = 0x0 027792: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x300E cr 0x802D state 0 event 0x5 ces 1 027793: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802D SETUP:U0_Setup(nlcb) 027794: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802D old NULL_STATE, new CALL_PRESENT 027795: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x400, event = 0x340, call id = 0x300E, int id = 0x0 027796: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x300E cr 0x802D state 6 event 0x82 ces 1 027797: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802D CC_SETUP_REJ_REQ:U6_SetupRejReq(nlcb) 027798: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802D old CALL_PRESENT, new NULL_STATE 027799: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x65F432AC), ticks (1000), event (0x1240) 027800: 1w0d: ISDN Se1/0:24:23 Q931: TX - RELEASE_COMP pd = 8 callref = 0x802D Cause i = 0x82E418 - Invalid information element contents - Original Message - From: Joseph Mays To: cisco-...@puck.nether.net ; cisco-nsp@puck.nether.net Sent: Tuesday, May 15, 2012 2:08 PM Subject: Re: Call rejeciton from Cisco On a related note, I am aware that part of the problem might be that the called party number might be listed as plan unknown and type unknown. I've been trying to figure out a way on the IAD 2400 to set this to national and isdn for all outgoing calls, but the only way I can find to do that is with translation rules, and those all seem to assume that the first thing you want to do is search and replace part of the dialed number. I really don't care what the dialed number is. Is there some way to match just on the plan and type, or some way to set those values other than a translation rule? - Original Message - From: Joseph Mays To: cisco-...@puck.nether.net ; cisco-nsp@puck.nether.net Sent: Tuesday, May 15, 2012 1:42 PM Subject: Call rejeciton from Cisco Hello. I am using an AS5400 to generate a PRI that is then going to a CiscoIAD. So on the AS5400 side I have. The IAD only has 8 analog voice ports, so I am using the last 8 channels of the PRI for voice ports, and the first 16 channels as a T1 for internet service. controller T1 1/0:24 framing esf channel-group 0 timeslots 1-16 speed 64 loopback network ignore pri-group timeslots 17-24 interface Serial1/0:24:0 ip address 216.24.28.249 255.255.255.252 encapsulation ppp no cdp enable ! interface Serial1/0:24:23 no ip address isdn switch-type primary-ni isdn protocol-emulate network no isdn outgoing ie redirecting-number no isdn incoming alerting add-PI no cdp enable On the IAD I have controller T1 1/0 framing esf linecode b8zs channel-group 0 timeslots 1-16 speed 64 pri-group timeslots 17-24 nfas_d primary nfas_int 1 nfas_group 1 interface Serial1/0:0 ip address 216.24.28.250 255.255.255.252 encapsulation ppp ! interface Serial1/0:23 no ip address isdn switch-type primary-ni isdn incoming-voice voice no cdp enable dial-peer voice 1 pots description route calls to ISDN destination-pattern .T port 1/0:23 The PRI and TEI's seem to be up. The AS5400 has intermachine trunks connecting it to the telco system and routes incoming and outgoing phone calls all day long, but when I try to make an outgoing call from the Cisco IAD I see the IAD 2400 appear to do the call setup and send the call out 1/0:23, but eventually I get a reject with a cause code of 0x0, which isn't very helpful. I'm
Re: [c-nsp] RHI with Nexus7K
Hi Henry, You could take a look at Dynamic Workload Scaling at the ACE, which works together with the Nexus 7000 series. Unfortunately I can't tell you, if you can accomplish what you want, when you are using ACE modules, but it might be a worth having a look. URL: http://www.cisco.com/en/US/prod/collateral/contnetw/ps5719/ps7027/ps8361/white_paper_c11-688039.html Lars Christensen CCIE #20292 Den 11/05/2012 kl. 21.02 skrev henrry huaman: Hi all! I´m looking for a functionality like a RHI between ACE and Nexus7K. Currently We have 2 DCs sending the same VIP and the topology is: ServersACE(6500 L2)-N7K (OSPF) The ACE is working in mode L3 is there a feature similar to RHI? Thanks! Henry ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Call rejeciton from Cisco
On the IAD2400 I have -- interface Serial1/0:23 no ip address isdn switch-type primary-ni isdn incoming-voice voice isdn map address .T plan isdn type national isdn negotiate-bchan no cdp enable and on the AS5400 I have -- interface Serial1/0:24:23 no ip address isdn switch-type primary-ni isdn protocol-emulate network isdn negotiate-bchan no isdn outgoing ie redirecting-number no isdn incoming alerting add-PI trunk-group WinnetOfficePri no cdp enable - Original Message - From: Tim Jackson jackson@gmail.com To: Joseph Mays m...@win.net Cc: cisco-...@puck.nether.net; cisco-nsp@puck.nether.net Sent: Tuesday, May 15, 2012 3:44 PM Subject: Re: [c-nsp] Call rejeciton from Cisco http://www.cisco.com/en/US/docs/ios/12_2/dial/command/reference/drfisl2.html#wp1116673 Usually Cause i = 0x82E418 - Invalid information element contents means that it's not happy about it requesting an exclusive channel vs preferred iirc.. Could also be a mismatched ISDN switch type? NI2 I would assume on both? On Tue, May 15, 2012 at 1:16 PM, Joseph Mays m...@win.net wrote: Disregard. I figured out how to get it to set the plan and type, but it's still having the same problem. 027789: 1w0d: ISDN Se1/0:24:23 Q931: RX - SETUP pd = 8 callref = 0x002D Bearer Capability i = 0x9090A2 Standard = CCITT Transer Capability = 3.1kHz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xE1818397 Preferred, Interface 1, Channel 23 Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x2183, '5025673005' Plan:ISDN, Type:National Called Party Number i = 0xA1, '5023871095' Plan:ISDN, Type:National 027790: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x64FBB518), ticks (3), event (0x1250) 027791: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x20A, event = 0x241, call id = 0x0, int id = 0x0 027792: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x300E cr 0x802D state 0 event 0x5 ces 1 027793: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802D SETUP:U0_Setup(nlcb) 027794: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802D old NULL_STATE, new CALL_PRESENT 027795: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: source = 0x400, event = 0x340, call id = 0x300E, int id = 0x0 027796: 1w0d: ISDN Se1/0:24:23 Q931d: L3_Go: call_id 0x300E cr 0x802D state 6 event 0x82 ces 1 027797: 1w0d: ISDN Se1/0:24:23 Q931d: L3_ProcessEvent: callref = 0x802D CC_SETUP_REJ_REQ:U6_SetupRejReq(nlcb) 027798: 1w0d: ISDN Se1/0:24:23 Q931d: L3_state_change: callref 0x802D old CALL_PRESENT, new NULL_STATE 027799: 1w0d: ISDN Se1/0:24:23 LIFd: LIF_StartTimer: timer (0x65F432AC), ticks (1000), event (0x1240) 027800: 1w0d: ISDN Se1/0:24:23 Q931: TX - RELEASE_COMP pd = 8 callref = 0x802D Cause i = 0x82E418 - Invalid information element contents - Original Message - From: Joseph Mays To: cisco-...@puck.nether.net ; cisco-nsp@puck.nether.net Sent: Tuesday, May 15, 2012 2:08 PM Subject: Re: Call rejeciton from Cisco On a related note, I am aware that part of the problem might be that the called party number might be listed as plan unknown and type unknown. I've been trying to figure out a way on the IAD 2400 to set this to national and isdn for all outgoing calls, but the only way I can find to do that is with translation rules, and those all seem to assume that the first thing you want to do is search and replace part of the dialed number. I really don't care what the dialed number is. Is there some way to match just on the plan and type, or some way to set those values other than a translation rule? - Original Message - From: Joseph Mays To: cisco-...@puck.nether.net ; cisco-nsp@puck.nether.net Sent: Tuesday, May 15, 2012 1:42 PM Subject: Call rejeciton from Cisco Hello. I am using an AS5400 to generate a PRI that is then going to a CiscoIAD. So on the AS5400 side I have. The IAD only has 8 analog voice ports, so I am using the last 8 channels of the PRI for voice ports, and the first 16 channels as a T1 for internet service. controller T1 1/0:24 framing esf channel-group 0 timeslots 1-16 speed 64 loopback network ignore pri-group timeslots 17-24 interface Serial1/0:24:0 ip address 216.24.28.249 255.255.255.252 encapsulation ppp no cdp enable ! interface Serial1/0:24:23 no ip address isdn switch-type primary-ni isdn protocol-emulate network no isdn outgoing ie redirecting-number no isdn incoming alerting add-PI no cdp enable On the IAD I have controller T1 1/0 framing esf linecode b8zs channel-group 0 timeslots 1-16 speed 64 pri-group timeslots 17-24 nfas_d primary nfas_int 1 nfas_group 1 interface Serial1/0:0 ip address 216.24.28.250 255.255.255.252 encapsulation ppp ! interface Serial1/0:23 no ip address isdn switch-type primary-ni isdn incoming-voice voice no cdp enable dial-peer voice 1 pots description route calls to ISDN
Re: [c-nsp] p2mp te tunnels on me3600x
On Tuesday, May 15, 2012 07:12:52 PM Waris Sagheer (waris) wrote: MLDP is on the roadmap for 2HCY13. P2MP TE is supported in hardware but software support is in radar. Waris, supporting the data plane signaling is great, but it would be great if (at least for) NG-MVPN's, the full BGP C- Multicast support, which add the MCAST-NLRI capability to BGP, effectively turning BGP into PIM, were also supported, for the control plane side of things. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Small DC switch design
On Tuesday, May 15, 2012 05:58:34 PM Jason Gurtz wrote: For the core, look at the 4900M or the newer 4500-X; these two switches are basically a semi-fixed version of the cat45xx (fixed sup, replaceable line cards). We quite like the 4500-X jobs for core switching these days, especially when much of your traffic is hitting the routers and not going across the core switches to begin with. The ability to easily switch between Gig-E and 10-Gig-E on the same port is massively attractive. Same reason we like Juniper's EX4500 switches. We're finding fewer and fewer reasons to justify classic core switches (6500's, EX8200's, e.t.c.) in some deployments where you need them for hierarchy and versatility, but less so for brutal strength. Another budget-wise choice for the core and aggregation may be the ME3600X/ME3800X. It's marketed at the ISP space but search through the archives of this list for discussion of it. I've used the ME3600X's as core switches (pure Layer 2) as well as Access switches (IP/MPLS). They work. Still lots of software development required for the IP/MPLS side of things, but they work. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QOS difference behavior for GSR and 7609
Do you have any related experience about this? Or do you have ever configured about this? Thanks and Regards, Hu Xu From: Pete Templin Date: 2012-05-16 01:29 To: Xu Hu CC: cisco-nsp Subject: Re: [c-nsp] QOS difference behavior for GSR and 7609 On 5/14/12 7:54 PM, Xu Hu wrote: Ok, do you heard about the MDRR in the GSR? What's the main purpose of this QOS approach? Yes, we've heard of it. Its purpose is to manage QoS through a 64x64 (or 16x or 128x, platform-dependent) crossbar fabric. pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Call rejeciton from Cisco
On 5/15/12 11:16 AM, Joseph Mays wrote: Disregard. I figured out how to get it to set the plan and type, but it's still having the same problem. 027800: 1w0d: ISDN Se1/0:24:23 Q931: TX - RELEASE_COMP pd = 8 callref = 0x802D Cause i = 0x82E418 - Invalid information element contents Invalid information element contents is often a switch type mismatch. Could also be CNAM being delivered in the wrong format. What does debug isdn q931 show? Kind of noisy but debug isdn q931 detail may turn up something if regular q931 doesn't. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Small DC switch design
Jason, Thank you for the response. I have a few more questions and maybe some clarification if you could. On Tue, May 15, 2012 at 10:58 AM, Jason Gurtz jasongu...@npumail.com wrote: Your size sounds fairly close to our situation... Do you have a spare fiber pair going to each location? Right now in each of the 7 buildings has a 3560G as an aggregation switch connected back to the DC. The DC also has a few 3560G's and 3750G's for the sans and servers. [...] What I would like to know (costs being the biggest factor) is what would be a better switch design for the current and future traffic in this network. Some options I was thinking about are as follows: Without more details I'm guessing here. Like many smaller shops I've been around the thing has grown from a long time ago and there may be a primarily flat L2 design in place, maybe there are some vlans. Maybe there is some (or a lot of) daisy chaining of switches; maybe the spanning-tree configuration hasn't gotten a lot of thought. OTOH, hopefully you're in a better spot than this? Yes things have been around a while and have seen alot of growth. Still have many closets with original cat5 cable. I have however been eliminating the small closets with one or two switches and consolidating them in most buildings, removing the daisy chains. I have also added many vlans, as all of our access switches are 2960's. Distribution switches are 3560's running eigrp. I have also added etherchannel links between distribution closets, and I have added redundant uplinks to form a ring in most of the larger buildings. I did a spanning tree project two years ago including RSTP and verifying vlan priorites, so this part has been working well, and it makes for a much easier time when doing upgrades and maintenance. Most buildings have 2-4 access vlans, voice vlans, wireless vlans, etc. As far as the fiber connections, each building that is connected to the DC has at least two pairs back to the DC, and then another pair is spliced so that it connects to the next closest building forming a ring. Each building has at least two paths back to the DC, and a 3560G or two as an aggregation switch which connects to the DC and to the next closest building in case of sfp or switch failure. I'm sure there is more I can do, but I am in an ok spot as of right now. In the Cisco world I think you're right on the money with Cat45xx; the 49xx series are related... Skim over this document and see if the general idea makes sense. You have L3 capable switches everywhere so it's a no brainer in a way: https://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigr ation_09186a00805fccbf.pdf We used this as a model, a pair of 4900M switches as the core and a few 4507-E w/SUP-6E as our access switches running OSPF; it is collapsed-core w/10G links fanning out (no separate distribution layer). As a whole we are very happy with the system. The nice thing about routing everything is it fails in more pleasant ways than the typical spanning-tree disaster. So just to clarify my design idea. I was thinking to use an ME3600X, with an ip services licensing for routing, as my core/aggrigation switch for all of the fiber coming into the DC. The ME3600X would also have the internet routers and firewalls connected to them, then have a 10G uplink to the 4500-E which would host the servers and sans. In the future I would look at adding another 4500-E and possibly another ME3600X, but for now I would just be one of each. Crude drawing: routers, firewalls-- | building a --1gig fiber - ME3600X (Layer 3) --10g fiber -4500-Eservers and sans. | building b -1gig fiber --- | building c ---2gig fiber -- Most high bandwidth traffic is to and from the servers and sans, and would stay within the 4500-E, second to that would be the traffic from all of the users from all the buildings to and from the servers, and then all of the internet traffic. Some of the things I would like to do with the me3600x is PBR, possibly some shaping or policing, eigrp routing, and some access lists. Netflow would be nice, but it doesn't seem like it supports it. Do you know what the buffer size is on an me3600x? What about on a 4500-E with a sup6l-e? Do you know if an me3600x has support for eigrp without an extra license? The 45xx line has seen a major upgrade. You probably want a +E chassis instead of -E. Also, the SUP-7E is out and it has netflow amongst other upgrades. There is an SUP-7L-E as well for a cheaper option. Check with your rep about bundles as it's definitely money saving. For the core, look at the 4900M or the newer 4500-X; these two switches are
Re: [c-nsp] QOS difference behavior for GSR and 7609
Hu Xu, you should really rephrase the question, as it's unclear what you're trying to do (at least to me at this stage). Yes, WRR and MDRR as queuing/scheduling mechanisms on the PFC (65xx/76xx) and on the GSR are different, but what is really the biggest practical difference is the way queuing is configured: While the GSR uses the MQC syntax with class-maps/policy-maps and bandwidth to assign bandwidth/ratios to the different queues (and with priority to denote a queue PQ), the PFC QoS requires you to use wrr-queue/priority-queue syntax, which is, at least to me, more cumbersome. By nature, QoS is very platform/hardware dependent. MQC is an attempt to abstract the HW complexity, but even there you'll see noticeable differences between platforms/linecards/xxx.. Oh, and I just found your initial post: You imply there that GSR doesn't use PQ/WRED, which is not the case.. Both platforms support PQ, and both support WRED for congestion avoidance. but they're configured very differently. If you want to transform the MQC configu to 6500, you should read up on PFC QoS or 6500 QoS. or let me see if I can find some time later this week.. oli -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of jstuxuhu0816 Sent: 16 May 2012 03:27 To: Pete Templin Cc: cisco-nsp Subject: Re: [c-nsp] QOS difference behavior for GSR and 7609 Do you have any related experience about this? Or do you have ever configured about this? Thanks and Regards, Hu Xu From: Pete Templin Date: 2012-05-16 01:29 To: Xu Hu CC: cisco-nsp Subject: Re: [c-nsp] QOS difference behavior for GSR and 7609 On 5/14/12 7:54 PM, Xu Hu wrote: Ok, do you heard about the MDRR in the GSR? What's the main purpose of this QOS approach? Yes, we've heard of it. Its purpose is to manage QoS through a 64x64 (or 16x or 128x, platform-dependent) crossbar fabric. pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
