|
Powercrazy posted:Right I agree, but for home use 10/100 is fine. Not if you have a home server. Crushing a 100mbit connection is trivial for a single user to do moving large files around, gigabit not so much. A 10/100 switch will be fine to learn on, but no way in hell I'd actually put it in my home network in a place where I have to use it. Gigabit's still expensive enough at the business switch level that I can see why people don't do it there, but for home use where $35 D-Links are perfectly acceptable it's gigabit all the way.
|
#
¿
Apr 20, 2012 16:54
|
|
|
|
| # ¿ May 14, 2024 09:18 |
|
|
adorai posted:I've seen all sorts of cisco gear do this due to a speed/duplex mismatch or failure to auto negotiate (which is ultimately the same thing). Link comes up for a few minutes, then goes down. Is there actually a good reason why Cisco (and other "enterprise" network gear, but most often Cisco) still can't seem to manage to autonegotiate properly? I have literally never once had an autonegotiation failure on consumer/SoHo hardware, but if there's something Cisco in play there's a 50/50 shot that at least one interface will end up hardcoded. Same with the non-Cisco but still "enterprise" switches Time Warner and others use for their fiber deployments. I really don't get this, why the crap $10 hardware can do it perfectly every time, but hardware costing hundreds or thousands can't.
|
|
#
¿
Jun 4, 2012 18:45
|
|
|
The ATA186 provides two FXS ports, which are used to feed ordinary analog phones. To attach it to an existing line for use to place/receive calls, you need a device with FXO ports. There are a number of cheap ATAs with FXO ports, the Sipura/Linksys/CiscoSB SPA-3102 being a popular one. You can register a SIP phone to one of these to use its FXO port. Unfortunately however, the 7937G appears to be Cisco SCCP only and does not seem to support SIP, eliminating pretty much every analog gateway on the market. Hooray Cisco and their proprietary poo poo. It's nothing but a rebadged Polycom Soundstation IP 7000, so you might be able to get a SIP firmware for it or flash the Polycom firmware, but you're on your own there. If you can't get that, the phone is absolutely dependent on a PBX of some sort (Cisco Call Manager officially, Asterisk and others have varying levels of support for SCCP devices).
|
|
#
¿
Jun 11, 2012 18:48
|
|
|
Powercrazy posted:Is there any reason to use SCCP? Exactly how old are the legacy cisco devices that don't support SIP? I hate to say it (my paycheck is entirely based on SIP and I have literally hundreds of these in the field), but the 7940/7960 and 7911/7912 are both much better as SCCP devices. They support SIP because Cisco felt they had to, and it clearly is half-assed. No BLF, no shared call appearances, nothing more than basic call functionality, hold, transfer, and three-way. These phones were built to be dumb terminals to a CUCM system and were basically bodged in to operation on a SIP system. I love everything they expose for diagnostics over their telnet and serial interfaces. I hate everything else about them. "Protocol Application Invalid" is the bane of my existence and pretty much any time someone has these and comes to me asking for a feature that depends on the phone I have to tell them no. Unfortunately they're also everywhere. They were sold in plentiful quantities and are very popular on the resale market, so it's not uncommon to find them with users who want to run them as SIP devices. ragzilla posted:Our Adtran TA stuff we use for POTS to VoIP gateways run MGCP. gently caress MGCP. The only advantage it has over a SIP device in this use case is that our softswitch sees the individual lines on the MGCP device and can address them directly (instead of having to maintain number-port mappings on the gateway). Yikes, TA6xx? Those things are beasts, I was happy when the last customer I had running one left. They work great until they don't, then they're a sonofabitch to troubleshoot entirely due to MGCP. The 9xx series has had some interesting bugs (I'm partially responsible for a few firmware releases) but it's a lot nicer to work with overall IMO.
|
|
#
¿
Jan 9, 2013 05:06
|
|
|
I am trying to set up guest wireless as well as a voice VLAN at a customer site where some old 2950s are in use, and it seems I was wrong for assuming that 802.1q VLAN support was pretty much universal among managed switches. Apparently this one does not know standards and only does VTP/ISL. It also doesn't seem aware of the fact that VLAN IDs can exceed 1005, probably for the same reason. I'm now sitting on site with a pile of equipment configured to do 802.1q for three total VLANs, one of which is ID 2600 (voice for obvious reasons) and apparently have a switch which isn't happy with either of these facts. I'm still a total Cisco newbie who finds his way around IOS with tab completion and Google, so can someone tell me if I'm hosed here? IOS on the one I'm in front of is "IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(14)EA1a, RELEASE SOFTWARE (fc1)" wolrah fucked around with this message at 19:55 on Jan 10, 2013 |
|
#
¿
Jan 10, 2013 19:44
|
|
|
Fatal posted:Seems like you're getting termnology screwed up, VTP is "VLAN Trunking Protocol" which is a way to distribute VLAN configs across a network. This allows you to configure at a core swtich the VLANs you want and have all of your access layer switch keep in sync and generate the vlans in their config automatically. Yeah, every VLAN doc relating specifically to this switch I saw mentioned ISL and VTP together, so I assumed one went with the other. The only Cisco fake standard I touch is prestandard PoE for some drat 7940s, so I can't say I know those well. quote:Not sure where you're getting the ISL from, 2950 *only* do dot1q. See below response to Powercrazy. quote:Use low numbered VLANs, 1-100, no need to have some crazy high number. I know we don't need the high number, but it is nice to have a "standard" I can assume all my VoIP customers can have their voice VLAN on as we begin to deploy more of those. No one else is likely to be using it and the spec allows it, so I'd rather just fix the switch to support it like it's supposed to. Powercrazy posted:That is an old as hell switch however it should support dot1q and extended range vlans. Make sure vtp mode is transparent and then add the vlan the normal way. Shouldn't be any problem and I don't think the syntax has changed. Nope, dot1q wouldn't take. ISL was the only option it showed when I did "switchport encap ?" Here's something that might blow your mind, another one of the same model switch with the same software release that I brought back to my office to test with: code:
|
|
#
¿
Jan 12, 2013 05:45
|
|
|
Haven't seen anything posted about this yet: http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20130318-type4 The short version is that Cisco hosed up massively when implementing their new "type 4" password hashing in IOS 15 and rather than running PBKDF2 with 1000 runs of SHA256 and an 80 bit salt, they instead just SHA256 it once without a salt. This obviously has a massive impact on the ability to brute force a hashed password and reopens rainbow tables as an option. Anyone who has posted a config file to the internet containing type 4 hashes should consider those passwords compromised. It gets better, too. Any device that supports type 4 hashes will not generate type 5 hashes, so to change these passwords you'll need to generate the type 5 hash elsewhere and then you have to do that every time the password is changed until you can downgrade to an older version or Cisco releases a fix.
|
|
#
¿
Mar 19, 2013 17:49
|
|
|
Powercrazy posted:Eh. Just use type 7, it's fine. If the local config password is important, say a BGP-peering password or a TACACS authentication password, omit it from the Config. According to Cisco this issue only applies to login users and enable passwords. quote:All the preceding issues apply only to devices running Cisco IOS or Cisco IOS XE releases with support for Type 4 passwords, and only to the "enable secret <password>" and "username <username> secret <password>" commands. Unfortunately while I don't have an IOS 15 device to verify with, the examples they show for how to determine whether your device even supports type 4 seem to imply that at least some of the affected devices will only support 0 and 5 otherwise, so with support for 4 disabling the ability to create 5s those users would seem to be in a tough spot.
|
|
#
¿
Mar 19, 2013 17:58
|
|
|
Fatal posted:Do people actually do this? On purpose? More than one customer of mine has had this sort of a configuration as a "security" solution where devices like printers are statically configured to a separate subnet from the main DHCP network and then the print server or other administrative systems which may need to communicate with them have multiple addresses configured on the same interface. In some cases they even had proper VLAN-aware switching in place, they just didn't know how to use it. I've done it as mentioned for transitions and every now and then for a quick test network in my office, but obviously running something like that as a long-term production solution is generally a sign of insanity somewhere in the decision-making chain.
|
|
#
¿
Apr 26, 2013 22:27
|
|
|
Martytoof posted:I gather it's IOS running on a Unix kernel or something like that. I think you're thinking of IOS XR, which is a QNX-based system used on the big routers like the HFR, 12000, and such.
|
|
#
¿
May 28, 2013 02:16
|
|
|
TFTP has no "list directory" functionality so unless the switches are checking for every previous numbered file (which should show up pretty obviously in your TFTP logs) the archive number is likely stored somewhere in the switch.
|
|
#
¿
Jul 30, 2013 20:45
|
|
|
Flash z0rdon posted:I just need the 3ms. Here's one option I've come across when looking in to link quality emulation in the past: http://www.gl.com/wan-link-emulation-iplinksim-packetexpert.html They claim full gigabit capability, but who knows. I don't need high bandwidth for my purposes so I always end up going back to dummynet boxes. Or comedy option it would "only" take about 250-300 miles of fiber to add that sort of latency if I'm remembering correctly.
|
|
#
¿
Aug 15, 2013 15:30
|
|
|
SamDabbers posted:Why would it be better to cap it at 64 or 48 bits instead of 128? The whole point was to make it such a large address space that we'd never have to deal with the address exhaustion problem again, at least on this planet. Also, it allows for some cool features like mapping a 48-bit MAC address into the 64-bit host portion for auto-addressing within a subnet. You couldn't do that as easily with a 64 or 48 bit address. There are two main reasons for wanting a shorter address space. The first is entirely human. Most of us who deal with a lot of IPs end up remembering a bunch of them. An IPv4 address is pretty easy in that way, it's only slightly more complicated than a phone number and nicely grouped. This also helps in communicating them via speech, be it in person, over the phone, etc. IPv6 pretty much makes DNS a requirement for meatbag-friendly operation. I mean just think about 10.0.0.15 vs. fd00:0000:0000::15. IPv6 addresses don't really get simpler than that and can be a lot more complex. Technically since those two sets are all zeros they can also be compacted in to the ::, but officially the fd00::/8 range is supposed to have all those zeroes as 40 bits of random, so you'd legitimately need to remember at least the amount I listed in most cases. That said, it's not like being forced to do DNS right is truly a bad thing, but to those who have been happily doing without for years it can be a challenge to deal with. The second is routers. Big routers use specialized chips for everything to do things as fast as they do. Those chips only have so much memory, as in some cases the kind of memory best suited for the job is expensive. More address space = more routes to deal with = greater memory requirements = greater cost. Multiply that by the scale of large providers and its not hard to see why so many have waited until the absolute last minute to do anything. edit: This should not be taken as me arguing against IPv6 or it being 128 bits, I really don't care what the answer is as long the end result gets NAT the gently caress out of my life. Since IPv6 is currently the only viable option for that, even with its arguable "flaws" I have to support it. edit2: Now that I'm not at a customer site that blocks Wiki, here's a link for anyone interested in the expensive memory in big routers/switches: http://en.wikipedia.org/wiki/Content-addressable_memory Basically it's memory that the CPU can ask "is this value here?" rather than having to search the entire thing looking for it. Herv posted:Yep, even if we have 6 octets in an 'IP v7 address' the first 5 would stay rather static, with a padded out mask. That's thinking about it in a rather narrow way. Obviously private addresses will stay rather boring in general, but I only used those for the direct comparison with as simple of an address as they get. The internal-only addresses I used really don't have much of a point for most users in IPv6, link-local is already there for local communication and its so easy to get more IPv6 space than you'd ever need so any actual managed IPv6 networks should usually be using the real stuff unless it will absolutely never ever need internet connectivity. For a more real-world comparison, how about google.com, which returns 74.125.225.67 (among others) for IPv4 but 2607:f8b0:4009:803::1000 for IPv6. Neither are "padded out", but the IPv6 one is a lot less human-friendly. Regarding the number of addresses, keep in mind that a large chunk of IPv4 space is "wasted" due to the logistics of routing traffic in logical ways without blowing up routing tables (see TCAM problem above). IPv6 will be the same way, so having more addresses than we could ever need multiple times over allows the space to be divided in logical ways while still practically guaranteeing that we won't find ourselves 15 years down the road with some new space crunch requiring us to start the whole process over again. Since memory chips and memory buses tend to have power-of-two sizes/widths, 64 and 128 are the two logical steps up from 32 bits. Why not 64 bit then? My best guess is something to do with wanting to be able to use the 48 bit MAC address as a supposedly unique number for automatic addressing schemes, but that's just a thought off the top of my head and not based in any actual knowledge. wolrah fucked around with this message at 21:49 on Aug 19, 2013 |
|
#
¿
Aug 19, 2013 16:30
|
|
|
ruro posted:Either you have a great memory for numbers or I have a terrible one. I can generally remember down to region and perhaps site if it's an important one It probably helps that a large number of my customers are on one of three ISPs, so in general simply remembering which of those they're on tells me the first two octets. Beyond that I guess its just using it regularly. I have to think about my own phone number, but I can log in to a router in a Lockheed building in Akron off the top of my head. quote:The internal draft IPv6 addressing standard they have where I work at the moment is easier for me to remember than the IPv4 standard as there are sufficient 'fields' to use for pertinent information, e.g.: <routing prefix>:site/cust id:building:level:level-net:host or <routing prefix>:dc num:cust id:cust-net:device-type:host. That's not a bad idea, if you have appropriate standardization as it sounds like you do. This is certainly what's nice about IPv6 giving us a lot of space to do arbitrary things with numbers. psydude posted:Shouldn't be, since by design IPv6 addressing and allocation is constructed entirely around the idea of using summary addresses for everything. If nothing else, it should reduce the size of routing tables. I had heard routing table size and CAM space discussed so regularly by those complaining about going to IPv6 that I just took it as fact, since it seemed to make sense. My best routers run FreeBSD on Celerons, so I've never had to deal directly with anything CAM-equipped.
|
|
#
¿
Aug 19, 2013 23:29
|
|
.
|
SamDabbers posted:Do you really need a GigE interface for a DSL connection? That 1841 you have should rock anything through ADSL2+ speeds, and FastE would not be a bottleneck. The answer is you definitely do not need GigE for anything DSL in the real world. VDSL2 technically supports 250mbit/sec down at very short distances, but at even half-kilometer range is only rated for 100mbit/sec. I can't find anyone commercially offering service claiming more than that on a single pair. There's only so much you can ask of voice-grade copper. A warning about home use of an 1841 though, a lot of home devices expect UPnP to be available for getting through NAT. Xbox Live is one of those things. Without properly functioning UPnP you have about a 50/50 shot of online play working at all, and if you have roommates/family also trying to use their own at the same time its an absolute guarantee that someone will be disappointed. I used an 1841 for about a year and immediately swapped it out for OpenWRT (later pfSense) when I got back in to gaming.
|
|
#
¿
Aug 21, 2013 22:18
|
|
|
CrazyLittle posted:You can have a decent switch paired with a decent router for less money, or you can try to combine the two in one and end up with compromises. Annoyingly this isn't entirely true. For average home users it is of course, but for the slightly geekier user the (which I assume is most posting in this thread) switch-in-router tends to be better on any platform where open alternative firmwares are available. Those switch-on-a-chips tend to have a variety of basic management features which aren't exposed in the official software. They of course exist the same in the standalone home switches, but without any interface (see http://spritesmods.com/?art=rtl8366sb for someone actually doing something about that). It's a minor point, but to those who care its very nice. There is no cheaper managed switch than a hacked home router, especially if you happen to need one in a hurry making retail availability a factor. That said I do a best of both worlds with a standalone pfSense attached to hacked routers operating solely as switches.
|
|
#
¿
Aug 21, 2013 22:56
|
|
|
Have Time Warner switch the modem to actually be a modem, not a lovely router, and then put your router behind it. NAT is bad enough, double NAT should always be avoided.
|
|
#
¿
Apr 18, 2014 22:30
|
|
|
If the second Ethernet is available I'd create the guest subnet there and attach any APs in a bridged mode to that. If its in use or if I'm misunderstanding that model (assuming the switch ports are internally seen as eth3 or such) then you could do the same with VLANs. Basically the Adtran sees two different LANs and can firewall them as you want. Since you say you have multiple IPs I think it's even possible to have them NAT through different ones so youll know if any complaints are about trusted or guest users.
|
|
#
¿
Jul 2, 2014 19:25
|
|
|
This is a really dumb one, but I have a device that isn't getting along with my USB-Serial adapter and since my old laptop broke the only other thing I have with a serial port is my 2970 switch. Is there any way I can use its Console port as a serial terminal while connected over telnet? edit: I guess side question since networking types do tend to use them a lot, any recommendations on a better adapter than my Prolific-based Dynex? wolrah fucked around with this message at 13:37 on Aug 1, 2014 |
|
#
¿
Aug 1, 2014 13:33
|
|
|
Cool concept, but no way to use it without their software is a no-go. I understand there isn't really a standard serial-over-LAN protocol that carries RTS/CTS and the like for applications that really need a full virtual serial port, but many of the potential uses would be satisfied by a simple SSH (or Telnet if you want to be lazy and insecure) session. Them being proud over "full 5v" RS-232 is a bit concerning as well, given that the spec is 3 to somewhere between 15 and 25 volts and most sources I've read about why cheap adapters don't work with some devices is the adapter only delivering 5v from USB rather than the 12v that a native PC serial port usually provides. I have a battery-powered wireless bridge running OpenWRT that has a USB port though, so I will steal the basic idea and use that with a USB adapter. As far as that goes it does look like the FTDI chips are the current favorite. No such luck on using the switch's console port right now in a pinch though, it seems? I found I have some 1841s around as well, those have an AUX port, is that useful for this?
|
|
#
¿
Aug 1, 2014 17:28
|
|
|
falz posted:I received one of these as a gift but have never used it because I didn't bother to see how it works with a standard PC running Linux (vs a touchscreen phone with a special app). Looks like one can use `socat` to make it work which may be acceptable. Interesting, looks like I was wrong and there is sort of a standard for serial over LAN in the form of an experimental RFC (2217). Now this thing is a lot more appealing, since it costs pretty much the same as my bridge and a USB-serial adapter. I'll still stick with the homebrew option since I have half the parts already, but I will certainly be telling coworkers about this rather than trying to talk them through OpenWRT.
|
|
#
¿
Aug 2, 2014 00:53
|
|
|
unknown posted:Sounds like a duplex mismatch. Many providers turn off auto detection on 100mb ports and lock it to full duplex where Cisco seems to be the only vendor that constantly has issues and goes randomly to half duplex which causes slowdowns due to retransmits. This matches my experience as well, for whatever reason Cisco has never bothered to get autonegotiate working right even thought everyone else has had it working reliably for over a decade. I have never once had a duplex mismatch that wasn't caused by a Cisco device being stupid.
|
|
#
¿
Feb 10, 2015 14:57
|
|
|
Ashley Madison posted:General networking question: I need to a do a sniff/port mirror for a capture that could take a really long time (like more than a day) while we try to capture a very specific bad VoIP call. Can anyone recommend the best way to go about doing that? If you have a *nix-ish system that you can get the traffic to somehow (span/mirror on the switch, or if it's passing through a router/firewall appliance that runs *nix underneath) the "dumpcap" program from the tcpdump suite is my favorite way to do it. You can set it to capture files in a rolling buffer or split files by time/packets/bytes to make it easier to go back through the data. If it's remote there's a way to tunnel tcpdump over SSH using FIFOs so you can store the capture locally even from a device on the other side of the planet. I do this all the time when troubleshooting my hosted customers and can go in to more detail if needed.
|
|
#
¿
May 15, 2015 18:55
|
|
|
Eh, a full day of capturing one phone worth of voice traffic is about 1.4GB if that phone was in use literally 100% of the time without silence suppression. In the real world where most phones don't get used more than an hour or two in a day my largest single customer with nearly 500 extensions does around 10GB/day. It's not too bad if you're not capturing to a potato. I would not recommend just firing up Wireshark and hoping for the best though, in my experience it gets slow and crashy when dealing with more than a gigabyte or two. You don't want to have the problem happen and it turns out Wireshark ate poo poo hours earlier. dumpcap is bundled and will be right there next to wireshark.exe on a Windows system, so if you don't have a *nix box I'd still recommend using dumpcap to actually do the capture and just use Wireshark to view the results. This should get you started: code:Replace 4.2.2.2 with the IP address of the VoIP server or device to monitor, or just put any tcpdump-style filter string in the quotes and it'll sit there quietly capturing away until you kill it with Control-C. If you want shorter captures change the duration, it's set to one hour in my example, and of course you can change the output filename to something more descriptive.
|
|
#
¿
May 15, 2015 21:46
|
|
|
Panthrax posted:Ooh, this sounds sexy. I wouldn't mind getting my hands on this info. If you don't want to put it here, you can email my username @ gmail. Thanks! It's all good, it's pretty simple between two *nix boxes. There's probably a way to do this on Windows but I haven't bothered to figure it out since I can just X forward Wireshark from my server when I want to do a remote GUI capture on my Windows box. On your capture machine you need to open two terminals. The first step is to create the FIFO we'll use. code:Then we use SSH command line forwarding to launch tcpdump directly on the remote machine: code:The "-i" parameter specifies the interface to capture from, in this case eth0. "-s 0" tells it to not truncate any packets. The downsides of doing this are that the remote upload bandwidth must be sufficient for what you're capturing, and it only flushes the buffer after a certain number of bytes (IIRC 65536) so if what you're monitoring is small and rare you might need to run this for a while before the remote host actually sends you anything. If you know the packets you're looking for will never exceed a certain size or don't care about anything but the headers you can cut this back. "-w -" tells it to output raw pcap format to stdout which is what our remote end will be looking for. Normally tcpdump output is somewhat human readable, but you're not looking for a human to read it. "port 5060" is just an example capture filter. If you're capturing low-traffic stuff but still want it to be close to real-time you can work around the issue with "-s 0" above by adding some other kind of traffic to the capture filter (I usually use "or icmp" and then start pinging the host to generate that traffic) and just filter the garbage out locally. "> /tmp/pcap" redirects stdout from the SSH session to the FIFO At this point the SSH session should be stalled before it would even ask for a password because there's nothing listening on the FIFO. If you see it going ahead you probably did something wrong and it's writing to a file instead. This isn't necessarily bad of course if you want a file instead, but in this case we're trying to get it to a local application in real-time. Now switch over to your other terminal and launch your capture application of choice. I'm going to use Wireshark as the example, but it works with most other applications that deal with libpcap. code:"-i /tmp/pcap" tells it to capture from the FIFO as if it was an interface. At this point your terminal with the SSH session will now be prompting for a password if applicable or will do the key authentication and when that's complete you should see tcpdump say it's capturing on the requested interface. Wireshark will then start capturing from the incoming stream. You may need to vary it up depending on the specific configuration of the remote device. OpenWRT for example does not seem to set PATH properly when trying to execute a command directly from the SSH command line so in that case you need to use the absolute path to the tcpdump executable. BSD devices like pfSense don't use a standard interface naming scheme so you'll have to figure out the correct one on your own. Anything with a roughly *nix-ish environment works on either end, the only real requirement is that the remote side has tcpdump or something equivalent that can send PCAP format data to stdout. I've been doing this for years with Linux and BSD powered router/firewall devices as the remote end and Mac or Linux machines as the local end.
|
|
#
¿
May 19, 2015 17:37
|
|
|
Slickdrac posted:In theory, no. But VPN is always a bastard that takes a bit of smacking around when you pair devices you've not done before. Exactly this. I've never been unable to get the two ends talking eventually, but more often than not it doesn't work the first time even if the settings appear to match at each end. Inevitably the logs are useless on both ends so figuring out which device doesn't like what can be a major challenge. Doubly so if the far end is not under your control and/or can not have settings changed for whatever reason.
|
|
#
¿
Jun 15, 2015 04:44
|
|
|
funk_mata posted:This is the cool thing to do nowadays. I think it's okay as long as VoIP is dedicated to one of the circuits and data to the other, the branches are okay with a "best effort" approach to VoIP quality troubleshooting, and you are okay with the nightmare of working with multiple ISPs for the various outages you experience. If you can't tell, the last point was the pain point when I was part of managing a similar environment. Been doing hosted VoIP via SMB-class internet connections for 10 years now and you pretty much hit the pain points right on the nose. Most of my customers don't even have two connections and it usually works out, but I think they're nuts for doing that if they consider their phones important.
|
|
#
¿
Jul 11, 2015 03:39
|
|
|
adorai posted:protip: VGA is DB-15 not DB-9. DB-9 is serial, and would be the correct port to use. Pedantic tip: The modern standard VGA connector is actually DE-15 and serial is DE-9. DB is a wider connector, with the plain DB-25 variant being the one most of us will be familiar with from parallel ports, old Macs with external SCSI, and occasionally serial ports. Thanks Ants posted:Unless it's a really old CGA monitor EGA as well, and apparently some early VGA devices used DE-9.
|
|
#
¿
Aug 5, 2015 14:38
|
|
|
OmniCorp posted:I saved the duplex chapter to educate anyone questioning why auto/half/full/no-negotiate matters. Just to be clear, you're saying it matters in that it's good to know the symptoms of a failure to autonegotiate so you can identify and fix the problem, right? Because if you're saying that manually setting those things when you're not forced to by something like a broken and unfixable/irreplaceable device at the far end is a good idea, I'd like to hear your thought process. I'm glad it's been a few years since I've run in to an ISP that insisted on hardcoding the interfaces on their managed circuit hardware to 100/full or 1000/full.
|
|
#
¿
Sep 23, 2015 20:28
|
|
|
adorai posted:I understand the sentiment when at the demarc, when you hardcore you avoid a possible autonegotiate problem. Or you create one when the next tech down the line who never received the original documentation about the hardcode (if it exists) goes to plug in a piece of replacement hardware after whatever was hooked up there takes a lightning strike. I don't think you're avoiding any problems by hardcoding when the equipment at the far side is unpredictable, just changing them. You avoid problems with lovely gear that doesn't autonegotiate properly, but you create problems for the rest of us who reasonably expect autonegotiate to work on anything 100mbit or above. Obviously when the far side can't be fixed you do what you have to, likewise for forcing a link up temporarily in unusual circumstances. Partycat, your gig link going down versus failing to 100/f is possibly the first time I've heard a situation described where auto would work just fine but fixed config actually offers a benefit. In theory 100mbit and above autonegotiation can actually specify that it'll only accept certain rates, allowing one to force a rate without disabling autonegotiation, but I certainly wouldn't be surprised to find out that can't be customized on a lot of ethernet devices.
|
|
#
¿
Sep 24, 2015 02:39
|
|
|
adorai posted:Do you not backup configs for reference? I don't understand how you could not see the hardcode in a previous config. The company I work for does outsourced IT type stuff for small/medium businesses. A lot of our business on that side has started with existing customers of our VoIP service who come to us for help after something failed that was set up by some other vendor years ago or the kid of the old boss or whatever. Between that sort of thing and installing our supported routers for VoIP in place of problematic existing ones for which the password is long gone I'll admit that I end up dealing with a disproportionate amount of these undocumented situations.
|
|
#
¿
Sep 24, 2015 03:56
|
|
|
falz posted:If "quiet" is a requirement, perhaps you should use different switch model. Cat3560C / Cat2960C / Juniper EX2200C are all fanless, and would not need to be in a sealed rack. I actually had that switch sitting around unused for a year before I plugged it in and discovered it was a lot quieter than I thought it would be. psydude posted:Man and here I thought I was a hardcore nerd with my Uquiti ERL running at the edge of my home network. Zero VGS posted:Vodaphone just installed a fiber connection at our remote UK site and plugged it into our multi-WAN router, then left for the day. Put in the IP and subnet, then try HostMin and HostMax. I've never seen an ISP use anything other than the extremes of the network range as the gateway.
|
|
#
¿
Oct 14, 2015 04:20
|
|
|
The only reason I'd go with a plain syslog setup instead of ELK would be if the machine I had to run it was really low-end. My old syslog-ng server was running on an ancient Pentium 4 with 256MB of RAM and handled all my needs without a stutter running a homebrew PHP web interface to browse it, where the same exact load on an ELK setup needed about 6GB of RAM to get the job done. RAM is cheap though and the functionality difference was massive, so there's absolutely no question in my mind that it's worth it.
|
|
#
¿
Nov 27, 2015 17:16
|
|
|
CrazyLittle posted:Yes dual stack, no tangible benefits yet. Pretty much the same here, dual stack through Tunnelbroker at my home and office, customers that have native support from their ISPs get it as well but I won't run a tunnel for a customer unless they actually had a need for v6. The only real practical benefit at this point is I can access machines on my home network directly from work and vice versa with one simple firewall rule rather than a pile of port forwards, but I like being future-proof.
|
|
#
¿
Jan 7, 2016 16:40
|
|
|
CrazyLittle posted:Absolutely. VoIP would work a fuckton better if it were on ipv6 but a lot of the hardware and software that's out there today doesn't support it. Getting rid of NAT would fix a lot of protocol handling issues.
|
|
#
¿
Jan 9, 2016 07:36
|
|
|
CrazyLittle posted:
I have a T48 testing with a customer and a T46 on my desk right now, considering the price they're drat good and I'm sure unless there's a showstopper of some sort I'll be moving a lot more of them soon.
|
|
#
¿
Jan 10, 2016 18:06
|
|
|
CrazyLittle posted:Customers give them a funny look because all they see on TV is Cisco... which ironically sound like garbage. Maybe it's because I've been working with the things for years so they stand out, but I see pretty much as many Polycoms on TV as Ciscos. I remember House and 24 had Ciscos everywhere, but Weeds and I think Californication had Polycoms. I just started watching Blunt Talk and they had Polycoms in the conference room (two linked IP7000s on a table that was barely large enough to need extension mics, much less linked bases, but still), not sure if they're anywhere else. I've seen Grandstreams once before as well, but never Yealink so far. I haven't used any of the wideband Ciscos, are they really that bad? We used 7940/60s everwhere when I started, but the terrible support for non-CUCM SIP in the 79x1s made us stop caring about Cisco and we've never looked back since.
|
|
#
¿
Jan 10, 2016 23:06
|
|
|
CrazyLittle posted:It's this. These are the phones that will not die, and will be shuffled from office to office in a never ending cycle of refurbishment until there's nothing but rats and roaches on this gay earth. edit: Also just remembered that most of the missing ones are from one site where the PoE switch decided the phones might want to try a lot more voltage. wolrah fucked around with this message at 03:59 on Jan 11, 2016 |
|
#
¿
Jan 11, 2016 03:56
|
|
|
CrazyLittle posted:I still have poly501's in service. Kill me. Oh god, with that terrible special cord with the power socket in the middle. gently caress those things to hell and beyond. I went off on one of my sales guys once for selling a new site with those things years after the HD models were out, slimy fucker would do anything to make a sale. To make it worse this was a site where the customer supposedly already had a good network. I arrive to install and find ethernet cables dangling from the ceiling plugged in to computers. wolrah fucked around with this message at 15:29 on Jan 11, 2016 |
|
#
¿
Jan 11, 2016 15:27
|
|
|
|
| # ¿ May 14, 2024 09:18 |
|
|
Looking for a sanity check. A customer just bought a building that has Cisco VG224 24 port FXS boxes in place already currently attached to a CUCM system. I'm playing with one to see if we can support them on their Asterisk system when we switch over the phones rather than having them buy a set of Adtran TA924s that would be functionally identical. These are just acting as 24 port dumb ATAs to feed resident lines in a nursing home, no advanced call control features required. Inbound calls to extension, outbound calls straight to DID numbers or 911 with no dialing 9 or any of that silliness. This config seems to work properly with the two lines I have registered right now and I have no reason not to believe that if I add more dial-peer entries for the rest of the ports they'll work just as well. Have I missed anything that'll bite me in the rear end later? code:
|
|
#
¿
Apr 6, 2016 21:57
|
|