|
jwh posted:If IP telephony is a requirement, you may want a network that provides better guaranteed forwarding for the real-time data, so that would (to me) rule out p2p vpn over commodity broadband. Yup. And if you can't get info about QoS then you should probably get another cheap broadband connection (DSL) and use that strictly for your voice bandwidth. Not having a voip-prioritized line will result in dropped calls, choppy calls, or other odd behavior.
|
#
?
May 2, 2012 17:28
|
|
|
|
| # ? Apr 29, 2024 02:34 |
|
|
Also something to consider, an MPLS solution is scalable, a LEC L2 ethernet service won't be able to be extended to any additional branch offices. Of course if this branch office is a one-off with no other plans for additional offices, then get a dedicated point to point for the best of both worlds: Dedicated Bandwidth, and most likely cheaper.
|
|
#
?
May 2, 2012 18:19
|
|
|
Yeah, I plan on pressing Comcast on an SLA but they're guaranteeing 3 different response times based on however much money we want to pay them. Is there a good resource for getting up to speed on MPLS, and how it works from a customer standpoint? I know nothing about it at all.
|
|
#
?
May 2, 2012 19:58
|
|
|
Comcast? SLA? I'm sorry Mario but the SLA is in another castle!
|
|
#
?
May 2, 2012 20:13
|
|
|
CrazyLittle posted:Comcast? SLA? I'm sorry Mario but the SLA is in another castle! But, but, they promised me 
|
|
#
?
May 2, 2012 20:18
|
|
|
From a customer perspective, your MPLS circuit is just going to look like any typical kind of access technology- frame, atm (unlikely), ppp, ethernet, etc. In a layer-3 configuration, you'll exchange routes with your private MPLS VPN by talking BGP or another (unlikely) protocol with the provider. Or, in a layer-2 configuration, you'll see what looks like a large shared broadcast domain. In the vast majority of cases, the magic isn't happening on the customer side, so you won't have to worry much about LSPs, or LDP, or mysterious address families, or anything like that. Best advice I can give you is to ask your provider for their customer MPLS configuration documentation.
|
|
#
?
May 2, 2012 21:32
|
|
|
Powercrazy posted:The main concern for MTU size is fragmentation, since each fragment would have to be encrypted individually. Oversized packets can essentially double your PPS, causing higher cpu utilization. To lower chance of fragmentation you can also use "ip tcp mss-adjust 1360" command. This impacts TCP traffic, so each tcp packet size doesn't exceed 1400 mtu.
|
|
#
?
May 2, 2012 21:44
|
|
|
Powercrazy posted:Also something to consider, an MPLS solution is scalable, a LEC L2 ethernet service won't be able to be extended to any additional branch offices. Of course if this branch office is a one-off with no other plans for additional offices, then get a dedicated point to point for the best of both worlds: Dedicated Bandwidth, and most likely cheaper. If your provider can't do E-LAN you need to find a new provider. AT&T OpteMAN and TW NLAN products both have point-to-multipoint capability though we primarily use them as E-TREE they work as E-LAN. I would however recommend you get an unlimited tag service with them (dot1q tunnel) and establish site pair VLAN IDs and route across the metro due to the MAC address limitations which makes the whole thing start to look a lot like ATM or frame.
|
|
#
?
May 2, 2012 21:55
|
|
|
Yeah, that's how I was imagining it working from the really brief talk we had today - ethernet handoff to our core L3 switch and the branch office gets its own vlan/vlans. I'll make sure to ask about point-to-multipoint in case we need to do this again in the future. Thanks for the input guys - goons rule. I am not a network guy, so while I could make something work, not pissing off the next guy or hacking together something unsustainable is important to me.
|
|
#
?
May 3, 2012 06:54
|
|
|
Zuhzuhzombie!! posted:CEF is turned on. I have the following in most of my configs to monitor processor usage: pre:process cpu threshold type total rising 80 interval 5 falling 20 interval 5 process cpu statistics limit entry-percentage 40 size 300 If there's a pattern of high cpu usage you should start to see alerts in your logs about it. They should be accompanied by a process number, so you can see what's causing the issue. Also try running sh ip cef switching statistics. If you have a cef issue, you should see a whole mess of punts.
|
|
#
?
May 3, 2012 07:48
|
|
|
Thank you sir. SSH pushed it to 88% earlier. Regened key at 512 instead of 4096. Dunno if this will help. No debugging on either switch. Zuhzuhzombie!! fucked around with this message at 19:29 on May 3, 2012 |
|
#
?
May 3, 2012 14:44
|
|
|
EDIT Sorry, trip post. Zuhzuhzombie!! fucked around with this message at 19:29 on May 3, 2012 |
|
#
?
May 3, 2012 19:16
|
|
|
EDIT. Sorry, trip post.
|
|
#
?
May 3, 2012 19:27
|
|
|
Zuhzuhzombie!! posted:Thank you sir. There is a reason people don't use 512-bit SSH keys, you know. 1024 is at least somewhat realistic, 2048 is better. 4096 is overkill, but how often do you have people logging in?
|
|
#
?
May 3, 2012 21:52
|
|
|
Ninja Rope posted:There is a reason people don't use 512-bit SSH keys, you know. 1024 is at least somewhat realistic, 2048 is better. 4096 is overkill, but how often do you have people logging in? And what is the platform?
|
|
#
?
May 3, 2012 22:09
|
|
|
Zuhzuhzombie!! posted:Regened key at 512 instead of 4096. Dunno if this will help. No debugging on either switch.
|
|
#
?
May 3, 2012 22:32
|
|
|
Ninja Rope posted:There is a reason people don't use 512-bit SSH keys, you know. 1024 is at least somewhat realistic, 2048 is better. 4096 is overkill, but how often do you have people logging in? If you're paranoid define a rollover policy based on key strength.
|
|
#
?
May 3, 2012 23:41
|
|
|
Ninja Rope posted:There is a reason people don't use 512-bit SSH keys, you know. 1024 is at least somewhat realistic, 2048 is better. 4096 is overkill, but how often do you have people logging in? Doesn't that stop you from being able to use SSH v2 as well?
|
|
#
?
May 4, 2012 02:00
|
|
|
Martytoof posted:I don't know exactly how much heat that bad boy puts out but that seems like an iffy idea Funny you should mention this... I picked up a 2950 with the gigabit uplink ports for NZD$60, ~USD$50, due to 'fan making excessive noise, otherwise fine'. Yes it made noise, oh boy. The price was right however, so I figured I could pick up a cheap silent 40mm replacement fan for 20 bucks and use it. Right now I'm in the process of upgrading it to take a silent 80mm fan secured to the top, I will post pics when I'm done. Testing has revealed that it will work, but respond with an amber system LED due to the fan control pin not receiving any juice.
|
|
#
?
May 7, 2012 23:46
|
|
|
Mierdaan posted:Yeah, that's how I was imagining it working from the really brief talk we had today - ethernet handoff to our core L3 switch and the branch office gets its own vlan/vlans. I'll make sure to ask about point-to-multipoint in case we need to do this again in the future. Just as a side note to this: last time I talked to the Comcast Metro-E guys, it was a fiberline service with a real SLA, and the l2 handoffs were running VPLS in the Comcast network - so you could do multipoint layer2 assuming all sites were in the fiber footprint. They also worked really hard to distance themselves from any of the cable modem services and offer competitive Metro-E services with actual SLAs.
|
|
#
?
May 8, 2012 00:15
|
|
|
Gap In The Tooth posted:Funny you should mention this...
|
|
#
?
May 8, 2012 21:54
|
|
|
aksuur posted:I've been running a 2950 at my house with the fan removed since it was malfunctioning. Same amber LED, but it seems to have been going strong for the last 9 months. Definitely wouldn't do such a thing in production, though. What sort of load do you have it under? I am planning for ~10 devices and possible streaming of one gigabit/sec between my media center and file server when playing HD movies.
|
|
#
?
May 10, 2012 00:49
|
|
|
it was a tossup whether I should post this here or in the asterisk thread. I have a CUCM environment. In this environment I have branch offices that I would like gain access to the PSTN via SIP. Does it make sense to license CUBE on each branch router, and terminate the local SIP trunks at the router, or should I terminate them all at our main datacenter? If I terminate at the branches, will the RTP stream traverse our wan to the CUCM, then back to the branch to hit the phone, or will the RTP stream only go from the branch router to the phone?
|
|
#
?
May 10, 2012 03:24
|
|
|
aksuur posted:I've been running a 2950 at my house with the fan removed since it was malfunctioning. Same amber LED, but it seems to have been going strong for the last 9 months. Definitely wouldn't do such a thing in production, though. Same here, just that toothpick solved fan noise problem. Switch is under heavy power load - multiple PoE devices attached. Haven't encountered any problem so far (unless toothpick falls out).
|
|
#
?
May 10, 2012 06:46
|
|
|
adorai posted:it was a tossup whether I should post this here or in the asterisk thread. Are you going to have PSTN access at the branch sites other than the SIP trunks? Are you planning on using SRST? What are your plans for calling 911 at the branch sites? What we usually do for customers if they have a main office and several branch locations in a general metro area is to have one or two POTS lines at each branch location and a PRI at the main location. Incoming calls to the main lines at the branches come in over the POTS lines, and outgoing calls go out over the PRI at the main location. This way you save money by bundling and sharing the bulk of the lines over the PRI at the main office, but each branch also has at least one POTS line to make/receive calls over in SRST mode in the event of a WAN or datacenter failure. Also, all 911 calls are routed out over the local gateway through the POTS line at each site so the e911 information is correct. If you terminate at the branches, the RTP stream will only traverse from the router to the phone.
|
|
#
?
May 10, 2012 12:38
|
|
|
c3750e-universalk9-mz.122-55.SE3 c3750e-ipbasek9-mz.150-1.SE2 Is Universal the new iOS line? I basically just need EIGRP, Auto QOS, and Layer 3, which Universal does and for some reason I have the impression that it is the more up to date iOS.
|
|
#
?
May 10, 2012 20:29
|
|
|
Zuhzuhzombie!! posted:c3750e-universalk9-mz.122-55.SE3 Yes, universal is the new IOS line (iOS is for Apple devices). However, instead of having different features in different versions, they're activated in the universal version using licenses.
|
|
#
?
May 10, 2012 23:28
|
|
|
n0tqu1tesane posted:Yes, universal is the new IOS line (iOS is for Apple devices). However, instead of having different features in different versions, they're activated in the universal version using licenses.
|
|
#
?
May 11, 2012 01:21
|
|
|
n0tqu1tesane posted:Are you going to have PSTN access at the branch sites other than the SIP trunks? Are you planning on using SRST? What are your plans for calling 911 at the branch sites? Alternatively, if we have to have a central trunking location, I would be ok with a setup that allows us to have a second CUBE router at another location, and the trunks to come up on that router if the primary one goes down. I could probably finish the cisco press voice book i have for the answer, but I am hoping the goons will save me the trouble.
|
|
#
?
May 11, 2012 01:34
|
|
|
ruro posted:Really? I thought that only started in the 15.x lines. I'm running 12.2(53)SE2 on my access switches, and didn't have to add any licenses but then again they're running ipbase, not universal. There are a few devices (3750-X being the one I know about) that have introduced universal images in the 12 release family.
|
|
#
?
May 11, 2012 02:04
|
|
|
adorai posted:We are going to continue to terminate a single pots line (shared with the alarm) for 911 access. I did some experimentation today, and it looks like the CUBE router relays all traffic, including RTP, through our call manager. I am using sip to sip, not h323 internally. Are you sure all the traffic is hairpinning through the callmanager? I know in traditional voice gateway scenarios with POTS or PRI lines, it doesn't, and I don't see why it would with the CUBE. In fact, this Cisco whitepaper sells the CUBE on the fact that remote sites don't need to hairpin the voice traffic through the central CM. http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/cis_45835_cube_assets_wp1e.pdf (Page 7-8) Granted, I don't have much experience with the CUBE. One of my coworkers is working on his CCIE Voice, and has played around with the CUBE quite a bit, so I'll run it by him tomorrow.
|
|
#
?
May 11, 2012 02:20
|
|
|
Kenfoldsfive posted:There are a few devices (3750-X being the one I know about) that have introduced universal images in the 12 release family. So how does this work, exactly? I haven't heard anything about this from our reseller. What kind of services are they releasing via licenses?
|
|
#
?
May 11, 2012 15:53
|
|
|
Zuhzuhzombie!! posted:So how does this work, exactly? I haven't heard anything about this from our reseller. Google dude, come on. http://www.cisco.com/en/US/docs/ios/csa/configuration/guide/csa_overview.html The feature breakout is different for each platform so you'll have to look that up. It is on cisco.com. Easiest way to search is to google site:cisco.com <keywords>
|
|
#
?
May 11, 2012 18:04
|
|
|
AtmaHorizon posted:Same here, just that toothpick solved fan noise problem. Switch is under heavy power load - multiple PoE devices attached. Haven't encountered any problem so far (unless toothpick falls out). I've had a couple of devices where the fan has failed, it has overheated, and shut off. In wiring closets mostly. It gets pretty darn hot. "sh env all" of course come back with FAN is OK . OK is not my criteria, I guess.
|
|
#
?
May 11, 2012 18:17
|
|
|
Welp, after six years at my place, I put in my notice. Going to be interesting working for a startup again.
|
|
#
?
May 12, 2012 05:46
|
|
|
By the way, who has built a mpls-te environment?
|
|
#
?
May 12, 2012 05:47
|
|
|
Partycat posted:I've had a couple of devices where the fan has failed, it has overheated, and shut off. In wiring closets mostly. It gets pretty darn hot. "sh env all" of course come back with FAN is OK . OK is not my criteria, I guess. In wiring closets we usually don't care about noise. This exact swith I was talking about is laying on my colleagues desk, so impact of shutting down is reduced to one person. Regarding "sh env". It should not display OK for a failed FAN. I suppose behaviour varies between chassis. Below is output from one router (3825). Fan 1 OK Fan 2 OK Fan 3 Low RPM Every 20 seconds there is a new syslog entry: "%ENVMON-4-FAN_LOW_RPM: Fan 3 service recommended" messages. If you don't like these messages, they can be filtered out. Not that it resolves the problem, but log doesn't get used up by them. Use with caution! code:
|
|
#
?
May 12, 2012 10:00
|
|
|
jwh posted:By the way, who has built a mpls-te environment? Ooo, oo. Me, ME! Although it was only 4 PE routers, it was for financial data and around 200 customers though.
|
|
#
?
May 12, 2012 18:13
|
|
|
Quick load balancing question. Have 6509-1 and 6509-2. There is a vlan with an IP shared between the two of them and 6509-1 hosts the SVI. These two interfaces are bonded into a Linux server with the far end of the /30. Everything is up and working, and I don't particularly NEED load balancing as I don't think it will ever need it, but just curious if there would be any load balancing at all or if the second interface would only be used in case the first is flooded, if at all.
|
|
#
?
May 15, 2012 22:33
|
|
|
|
| # ? Apr 29, 2024 02:34 |
|
|
I assume you are using HSRP, so the active gateway is .1 on 6509-1. Also I hope you mean that you have a single linux host sharing a /29 running a similar first hop redundancy protocol between it's two NICs (CRRP?). Anyway the short answer is no, load balancing doesn't work like any non-network person thinks it does. If one of the links "gets too full" then traffic will just be dropped. 6509's don't support cross-chassis etherchannel so you can't even use an intelligent link-sharing protocol like LACP. The best you can do is set up NIC teaming on the linux host and tell it to do per packet round robin load-balancing but depending on what that host is doing you would probably be better off leaving it alone.
|
|
#
?
May 15, 2012 22:42
|
|