|
Tony Montana posted:You guys actually crimp cables? I tried gluing them in but that didn't work.
|
#
?
Apr 4, 2011 22:50
|
|
|
|
| # ? May 14, 2024 14:31 |
|
|
Bardlebee posted:What program is this and what happened between those weeks for the sudden change? MRTG, graphing throughput on 5-min averages from the CO perspective. It's a new customer hooked up to four DSL circuits, bonded. Tony Montana posted:You guys actually crimp cables? I don't if I can avoid it, but carrying a crimp tool and some ends beats carrying a million different lengths of patch cords when I'm not at my office. Cable runs are always jack-to-jack though. gently caress crimping a run. That's scrub-tier work.
|
|
#
?
Apr 4, 2011 23:08
|
|
|
Jack to jack? As in wall jacks? You will run cabling for wall jacks? Don't you have cabling contractors?
|
|
#
?
Apr 4, 2011 23:15
|
|
|
Tony Montana posted:Jack to jack? As in wall jacks? You will run cabling for wall jacks? Depends. If I'm in a colo and I'm setting up a connection for another colo customer, I can hire a wiring contractor and wait a week, or I can pull ~35' of cat5 in the cable ladders in about 30 minutes. You decide. Let me put it this way: I've used my cable crimper a total of 6 times in the past year. I've used my punchdown tool countless times, but that's because I'm not going to wait for a LV contractor to come wire a T1 when all the wiring is already there and all it needs is a cross connect from the MPOE to the jack. So it really depends on what your job entails and how often you really need to do that work. CrazyLittle fucked around with this message at 23:28 on Apr 4, 2011 |
|
#
?
Apr 4, 2011 23:22
|
|
|
Tony Montana posted:You guys actually crimp cables? Rarely. Go ahead and source me a Lantronix SLC to Adtran-MX2800 console cable. TIA.
|
|
#
?
Apr 5, 2011 00:44
|
|
|
Tony Montana posted:Jack to jack? As in wall jacks? You will run cabling for wall jacks? Cable contractors take time. I (or a coworker) can run a cross connect in our colo facility in the time we'd spend managing a cable contractor to do the same. Richard Noggin posted:OT, but networking related - what's everyone's preferred brand of RJxx crimp tool? I need to pick up another one. I'm doing RJ45 and RJ11 mostly. You can't go wrong with the Paladin suggestion, or you may also want to look the Molex's crimper (although the design has changed somewhat from the one we use). The Molex crimper is built like a tank and you could probably cause someone serious injury if you used it as a weapon. If you have a relationship with them hit up your local Graybar/Anixter/Kirby/Grainger and see what they have in stock, then see if they'll bring them out to the counter for you to try. Powercrazy posted:Yea. Its going to be a standards war all over again, but now there are a lot more players in the market. Cisco is siding with the IEEE, and juniper is lone-wolfing it trying to be first to market. ragzilla fucked around with this message at 02:33 on Apr 5, 2011 |
|
#
?
Apr 5, 2011 02:27
|
|
|
jwh posted:I want TRILL. Literally the future of networking in just about every space. Bone up on IS-IS...
|
|
#
?
Apr 5, 2011 05:46
|
|
|
This may or may not be a silly question but what are people's general opinions about VRF being the next big thing in WAN solutions? Our exiting network architect told me in passing that I should be looking into two things deeply for the forseeable future, VRF and IPv6. IPv6 I at least get to work with as he's dumping half of a IPv6 project in our hands as he leaves but we have no customers with a VRF network so I don't get any play time with it.
|
|
#
?
Apr 5, 2011 12:37
|
|
|
Don't know poo poo about VRF, but IPv6 still is for government departments and regulatory bodies that have to comply with poo poo non-technical people came up with. It's all integrated into pretty much every modern NIC and we're all ready to go, except if you've done a CCNA recently and remember the IPv6 section you'd remember how different it'll all be. I've heard of things like carrier-grade NAT to extend the IPv4 space, but NAT is also apparently breaking a lot of innovation. Apparently the issue is really management, rather than the size of the addressing space. Yeah sure, we've got so many more devices now than ever before with their own WAN connections such as phones. But I read something about Comcast assigning 6 IP addresses to each customer, for options such as Internet TV and VoIP or something and very few people actually use those services. In the past organizations would apply for a routable space and instead of getting a /16 they'd get a /8, no-one perceived this crazy network was going to get this huge. If you go to IANA's IPv4 space registry (here is the link: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml, if you don't know what IANA is maybe go and Google that first) and have a look at really the beginnings of the Internet, just because of legacy rights and 'that's the way it's always been' major IT corporations (many that don't really exist anymore like DEC) have class As. Now as DEC has been eventually bought by HP (who have their own class A by the way) that means HP has something like 32 million Internet addresses to themselves. They are just one corporation, do with them what they like and seem to have no responsibility to the rest of us and the network to share their surplus. You can see in that list things like 'APNIC' and thats a Internet registry (under IANA I think) that we've set up because once we realised where this was going we needed to set up organizations to manage this for the good of all (APNIC is actually the Asia-Pacific one, responsible for the IP I'm writing this via right now  ). But as you can see from that list, the first fifth of the addressing space has a lot of guys in there that wouldn't be helping. So management, using the addresses we've got better, is actually the problem. But you can go to HP and say 'ok we're taking back these addresses because it's going to break the net, you're going to get these instead'. HP would understandably go ballistic, challenge it in every court possible (I wonder what kind of legal might HP could wield) because the sheer size of the project of changing HP's entire Internet presence would be staggering. So not only changing the addressing format to give us lots more addresses, but this time when we start we'll divide them up more in line with the world-wide network we know the Internet is and will continue to grow and be (I remember there is country specific ranges for instance, built into IPv6). Now, I've just had a nice waffle there for a while off the top of my head and I've read some posts in here about people playing with CRS routers, so I'm a little fish in this pond. Please, SA Cisco thread, add your two cents on this.
|
|
#
?
Apr 5, 2011 13:16
|
|
|
Sepist posted:This may or may not be a silly question but what are people's general opinions about VRF being the next big thing in WAN solutions? I wouldn't call it the next big thing, it's been around a while now. VRF-lite is useful as hell, especially if you have different layers to your network that you want to have more control over and simplify your routing and ACLs. I am moving us towards a setup where we have 4 VRF's: Production, Guest/Vendor, Video, Voice. We've had a big push in the past year for some separation of traffic outside of just firewall rules, we're in the process of setting up completely separate environments for things like Video (where we connect to an exchange), Vendors (completely separate AD along with VPN and DMZ server environments) and Voice (looking into SIP providers for external calling). If you have GNS3 you can build and play with VRF and do all sorts of fun things with it. I've been working on building out my test production environment in lab, nothing like a data center refresh to give you a glut of hardware to play with.
|
|
#
?
Apr 5, 2011 15:01
|
|
|
VRFs already are a big thing, really. You should lab them up, if you haven't, just because they're a great tool to have in your back pocket, and they can significantly influence a design if you're comfortable using them. There's still a lot of fighting about IP6 if you read the lists. I think a general way forward is slowly emerging, but there's still religious debates about "the right thing to do" popping up every month or so. I have no problem with being slow to adopt IP6- it's going to be a long, long time before every element and every provider that I deal with either has native IP6 support or offers native IP6 transit. As for cabling, I create every cable by smelting copper ore in a crucible and then extruding the molten copper into thin rails. I slowly hammer each rail out to the desired length and thickness (which does take some time) before carefully wrapping each one in the finest silk cloth, which is created by my small silk moth colony I've established in the back of the datacenter. Then I wrap each silk-clad hand-hewn copper wire carefully, preserving the appropriate twist ratio, before wrapping the entire assembly in alpaca wool that's been treated with ambergris (for tensile strength). Finally, I wire-wrap everything with with wax-thread.
|
|
#
?
Apr 5, 2011 15:57
|
|
|
VRF is an integral part of MPLS and VPN4. Its not that it is the "next big thing" its just the next "mainstream," non-provider thing. We have several VRF segments throughout our network, and as we move to the provider space VRF is more important than ever. Really once you understand the basics, Route-Targets, Route Descriptors, VRF is really easy and straightforward. As for cables I use only the highest quality Anti-oxygen Gold Connectors provided by Monster® Brand Cables. Sure they cost 30 Dollars per foot, but the signal clarity and warmth of the bits really gives me peace of mind.
|
|
#
?
Apr 5, 2011 16:14
|
|
|
CrazyLittle posted:MRTG, graphing throughput on 5-min averages from the CO perspective. It's a new customer hooked up to four DSL circuits, bonded. Did you add a circuit each week or something?
|
|
#
?
Apr 5, 2011 16:28
|
|
|
Bob Morales posted:Did you add a circuit each week or something? No - IIRC they weren't fully moved into the building yet when the router went live. Now that they know it works they're using it as much as they can.
|
|
#
?
Apr 5, 2011 16:43
|
|
|
FYI once you have an MPLS network in place, it's trivial to add the VPNv6 address family to the config & offer customers IPv6 service. Finding one that wants it may be more difficult.
|
|
#
?
Apr 5, 2011 16:45
|
|
|
I've always found it slightly hilarious that for digital applications people still seem to care about cable quality. Like buying HDMI cables that are extremely expensive. I'm probably just showing my electrical engineering ignorance, but I always assumed for digital applications, your cable either worked for that application, or it didn't (essentially).
|
|
#
?
Apr 5, 2011 17:06
|
|
|
Well it depends on the bit encoding and how tolerant it is of loss or noise, but honestly none of that matters when you are talking about consumer grade hardware, and the quality of expensive cables is completely perceived and driven by marketing. In other words the cable quality makes zero difference. But I'm sure you have seen instances on Serial Interfaces where you can ping across but can't pass traffic do to errors once you get above a particular bandwidth, and that is certainly a cable path issue, (probably the connector, but the cable run is important as well).
|
|
#
?
Apr 5, 2011 17:16
|
|
|
jwh posted:I've always found it slightly hilarious that for digital applications people still seem to care about cable quality. Like buying HDMI cables that are extremely expensive. Basically a higher quality (note: NOT necessarily more expensive, I mean truly objectively higher quality) cable will typically be more resistant to interference and thus allow longer runs or runs through interference-rich areas, but once you hit the point of "working" there's no improvement. The only application where the average consumer ever might need to think about cable quality is a long DVI/HDMI run for a 1080p+ home theater, conference room, etc. Beyond 10-15 feet those signals can get pretty picky. Otherwise, if it meets spec it's good.
|
|
#
?
Apr 5, 2011 18:05
|
|
|
There's a lot of technical reading relating to cables to be found here: http://www.bluejeanscable.com/store/hdmi-cables/hdmi-cable.htm I could have sworn they had a link to tests done with their cables but I think it may have been another site that posted them.
|
|
#
?
Apr 5, 2011 18:21
|
|
|
Tony Montana posted:You guys actually crimp cables? For quick jobs, yes. If it has to go through a wall, I call the cabling contractor.
|
|
#
?
Apr 5, 2011 19:20
|
|
|
Richard Noggin posted:For quick jobs, yes. If it has to go through a wall, I call the cabling contractor. Yup. If it has to go up in the plenum, or through walls, or up/down floors I won't do it.
|
|
#
?
Apr 5, 2011 19:33
|
|
|
My bits only travel along gold connectors and the finest handmade cables, such as jwh's. Anything else would be selling my data short 
|
|
#
?
Apr 5, 2011 19:37
|
|
|
Voip problem here. PoE Polycom phones require static IPs (for some reason) and often lose the ability to make/receive calls. Phones are registered in the ARP table and pingable from the Gateway and the Switch. We have a Cisco router on a stick out in a remote location handling three 3750s. Everything inside is NATed to a public IP that's assigned to the router. The router is behind a cable modem. There are three VLANS. One for physical access to serve PCs. One for the wireless LAN controllers. One for VOIP phones. Each VLAN has it's own IP range and each range has a DHCP pool and .1 0 .50 is reserved through each pool. Gateway has sub interfaces to carry the individual vlan tags across the point to point to our internet equipment. And that's all I got. No problems with wireless or PCs and their connectivity. Phones will stay working for an indeterminable amount of time until problem. Bouncing the interface does nothing. Phones have to basically be reset and IP put back in. On the DHCP pool for the phones we have option 66 enabled, another option I can't think of off the top of my head, and a "default-router" that supposedly points the phones to an FTP/config server. An earlier problem that was fixed with static IPs on the phones was, we believe, created by the phones booting and trying to contact the FTP/config server before it gets an IP address from the DHCP pool. It would attempt to contact server, time out, not pull any config information, and then sit there dead. So I guess I have two VOIP problems, as a solution to either would basically make my day and, honestly, would put an end to a several months long problem.
|
|
#
?
Apr 6, 2011 03:50
|
|
|
Zuhzuhzombie!! posted:Voip problem here. PoE Polycom phones require static IPs (for some reason) and often lose the ability to make/receive calls. Phones are registered in the ARP table and pingable from the Gateway and the Switch. Are the phones talking SIP? What are they registering to? Is it inside or outside the network? Are the dynamic translations/state entries in your firewall timing out? My usual workaround for SIP endpoints behind a single dynamic NAT is to assign each SIP endpoint a unique SIP port to talk on (I usually use 5060, 5061, 5062, etc), then statically PAT those in the firewall. That way whatever the phone is registering to should always be able to contact the phone back at that IP/port combo (since it's a configured PAT in the firewall, not a dynamic translation). Zuhzuhzombie!! posted:On the DHCP pool for the phones we have option 66 enabled, another option I can't think of off the top of my head, and a "default-router" that supposedly points the phones to an FTP/config server.
|
|
#
?
Apr 6, 2011 03:56
|
|
|
Give this a shot:code:Zuhzuhzombie!! posted:An earlier problem that was fixed with static IPs on the phones was, we believe, created by the phones booting and trying to contact the FTP/config server before it gets an IP address from the DHCP pool. It would attempt to contact server, time out, not pull any config information, and then sit there dead. Actually I can confidently say that this doesn't happen. The polycom IP sip phones won't even get past the "waiting for network to initialize" screen if they don't get a DHCP IP allocation, or if they don't already have a static IP assigned. They'll start rebooting themselves when they time out waiting for an IP. How are you assigning the VLAN to the polycom phones? Are you using "voice vlan"? CrazyLittle fucked around with this message at 04:18 on Apr 6, 2011 |
|
#
?
Apr 6, 2011 04:12
|
|
|
ragzilla posted:iirc polycoms look at opt 66 and 150. If you have an opt 66 make sure it is an ASCII option on your DHCP server. The Polycom's will not honor option 66 if it's configured as an IP. By default the current models all look at option 160 first, then 66. Older phones and early BootROM revisions of the newer speakerphones use 66 and possibly 150. I can only confirm 150's use by Cisco phones.
|
|
#
?
Apr 6, 2011 06:53
|
|
|
Speaking of IPv6, is anyone else taking part in the IPv6 flag day? How's the preparation going?
|
|
#
?
Apr 6, 2011 11:40
|
|
|
Is anyone familiar with the Cisco 11xxx series content switches? We're having an issue with a pair that, when traffic is introduced to the primary, latency spikes up to 8k roundtrip where normally it would be 800ms. This apparantly started out of the blue, no changes were made to the CSS and a reboot didn't fix it. I'm not familiar with troubleshooting content switches so I'm mainly just wondering where I should start past what I've done, which is reboot and remove "preempt" from the backup CSS Vlan so it doesn't fight over who is primary. I can't do live traces right now because the traffic has been pulled off of them in lieu of the problems..
|
|
#
?
Apr 6, 2011 12:51
|
|
|
CrazyLittle posted:How are you assigning the VLAN to the polycom phones? Are you using "voice vlan"? Yup. Running auto qos voip trust on the interface as well. I'll give these ideas a shot fellas. Really really appreciate it.
|
|
#
?
Apr 6, 2011 12:54
|
|
|
Powercrazy posted:Yea. Its going to be a standards war all over again, but now there are a lot more players in the market. Cisco is siding with the IEEE, and juniper is lone-wolfing it trying to be first to market. Uh, what? Cisco went with FabricPath on the Nexus range and still hasn't committed to actually supporting SPB/TRILL beyond "Hey guys, we've got this thing that works like TRILL but requires contiguous segments, implements proprietary things like vPC and is full of goodies! Also maybe in the future we'll just offer the IEEE version (but only the MUST bits of the RFC)". Juniper's QFabric is much the same. Ultimately I'm sure it will become like EIGRP - another protocol to choose only if you're a single vendor shop.
|
|
#
?
Apr 6, 2011 13:14
|
|
|
code: These phones are registereding to a Broadsoft server but I can't recall if it's on the public network or if it's on the private, but I do know that at least with the DHCP pool the Option 66 IP was an IP on our public range and everything else was private.
|
|
#
?
Apr 6, 2011 14:53
|
|
|
CrackTsunami posted:Uh, what? Cisco went with FabricPath on the Nexus range and still hasn't committed to actually supporting SPB/TRILL beyond "Hey guys, we've got this thing that works like TRILL but requires contiguous segments, implements proprietary things like vPC and is full of goodies! Also maybe in the future we'll just offer the IEEE version (but only the MUST bits of the RFC)". Also EIGRP is awesome and if you are an all cisco shop there is no reason not to run it.
|
|
#
?
Apr 6, 2011 16:52
|
|
|
Off-topic, has anyone looked at ForeScout CounterACT?
|
|
#
?
Apr 6, 2011 21:14
|
|
|
So, I got thrust into setting up a VOIP-in-a-box using a 2801 and 2960 PoE with about 20 7960 IP phones running on a Comcast 50/10 Business line using an SMCD3G hooked up to the 2801 via FastEthernet. Each phone has a PC hooked into its PC port. The Call Manager is being run by our VOIP provider and this router was configured as a backup for our existing VOIP system at our main office, so really all I had to do was set up DHCP for the data and voice vlans with option 150, NAT, DNS, outgoing static default route, and configure the external-facing Fa interface with the static WAN IP. Everything seems to be running okay with about 10 users, but my main concern is QoS since I haven't really delved too deeply into it. I kept the QoS policy that came pre-configured by our VOIP provider who shipped the 2801 and 2960 to us, but that was configured for the dual T1 multilink in the device since this router also serves as a backup for our existing infrastructure router in the event of an emergency. I basically just added the service-policy output voice command already in the multilink interface config to the outgoing Fa interface. This should work just as well considering our bandwidth, correct? I may be overthinking things, but I just want to make sure I'm not missing some crucial consideration. chipclip fucked around with this message at 03:03 on Apr 7, 2011 |
|
#
?
Apr 7, 2011 02:49
|
|
|
What's your policy-map look like? Is it a nested map that shapes to a percentage of interface bandwidth, or is it explicitly configured to specific bandwidths?
|
|
#
?
Apr 7, 2011 16:11
|
|
|
I had a theory question for those familiar with VPN's. I had a situation where I had to change a VPN IP address on a remote router. My previous configuration didn't work and it looked like this:code:code:Am I right in this assumption?
|
|
#
?
Apr 7, 2011 16:32
|
|
|
Sounds right to me. You may want to look into using gre tunnels with ipsec protection, just because it's a little bit easier to manage. I've never liked crypto maps.
|
|
#
?
Apr 7, 2011 17:40
|
|
|
jwh posted:Sounds right to me. I'll look into that, I don't know what this fangled GRE tunnel thing is, but I have heard of it. I will find it somewhere via google. Thanks!
|
|
#
?
Apr 7, 2011 17:45
|
|
|
Was 10.10.10.10 still up when you made the change? You can't match one ACL to two crypto maps; you'd have to change it, remove match address from the first crypto map then clear your SA's and make sure 11.11.11.11 comes up.
|
|
#
?
Apr 7, 2011 20:13
|
|
|
|
| # ? May 14, 2024 14:31 |
|
|
Here's the policy map: policy-map voice class voice priority percent 70 class signaling bandwidth percent 5 class class-default fair-queue I interpret that as guaranteeing 70% of the outgoing traffic for voice and 5 for signaling, not totaling more than 75% and leaving the remainder for data. Going to begin studying up on QoS shortly, but I'm wondering whether or not the smooth performance is more due to the amount of dedicated bandwidth we have available or if QoS really is helping guarantee certain traffic classes going out the WAN interface. Welp, long story short, we had all 20 users up and running simultaneously today without a single hiccup or dropped call so so far so good.
|
|
#
?
Apr 8, 2011 03:53
|
|