|
Yeah, never try and navigate the Cisco web maze if you value your sanity.
|
#
?
Sep 18, 2012 23:09
|
|
|
|
| # ? Apr 23, 2024 22:48 |
|
|
jwh posted:Yeah, never try and navigate the Cisco web maze if you value your sanity. To be fair they have made improvements in the past few years (downloading the right IOS is easier now), it's still pretty lovely though.
|
|
#
?
Sep 18, 2012 23:18
|
|
|
Erwin posted:2960-S, version 12.2, which is weird because we just bought them, so I would have figured 15.2? Nah, 2960 switches are still on the old catalyst OS 12.2 branch. It's the routers that are up to 15.2 jwh posted:Yeah, never try and navigate the Cisco web maze if you value your sanity. The worst is how it randomly logs me out while navigating the various pay-gates within their site.
|
|
#
?
Sep 19, 2012 00:33
|
|
|
Sepist posted:My coworker uses ASDM and I use CLI, I can confirm the eye bleeding. I love Cisco docs
|
|
#
?
Sep 19, 2012 01:30
|
|
|
CrazyLittle posted:Nah, 2960 switches are still on the old catalyst OS 12.2 branch. It's the routers that are up to 15.2 The 3750-X and 3560-X switches are on 15 as well.
|
|
#
?
Sep 19, 2012 01:39
|
|
|
We've got a buttload of 2960's out on sites and around the place, they're pretty solid for our purposes. What are you using them for?
|
|
#
?
Sep 19, 2012 04:35
|
|
|
n0tqu1tesane posted:The 3750-X and 3560-X switches are on 15 as well. Hmmm. We've ordered at almost 40 3560X/3750X in the last six months and they've all shipped with 12.2(55).
|
|
#
?
Sep 19, 2012 13:41
|
|
|
But you can upgrade them if you want.
|
|
#
?
Sep 19, 2012 13:58
|
|
|
VR Cowboy posted:Hmmm. We've ordered at almost 40 3560X/3750X in the last six months and they've all shipped with 12.2(55). Depends where they're coming from, if you order new from Cisco you can pick the software version when you place the order. If you're ordering from distribution (99% of the time you're buying fixed config devices, Cisco wants you buying from distribution, unless you're a distributor) you get whatever was current when the distributor ordered a truckload of switches. Looks like you can get 3560/3750 -E and -X shipped new with 15.0 software in the current price list.
|
|
#
?
Sep 19, 2012 14:31
|
|
|
I'm cross-posting this from the enterprise storage thread since I figure most of you don't read that: I'm having a routing(?) issue on my netapp system and our network team is being fantastically uncooperative (though the original issue is most probably my doing). Can any of you actually smart people spot any obvious mistakes? I don't understand why this wouldn't work. Right now I can't ping even my default GW. I can't seem to route to our normal networks, only on my management interface/subnet/VLAN. This is the cisco VPC/ports: code:
|
|
#
?
Sep 19, 2012 15:15
|
|
|
switchport trunk native vlan 731 Is there a setting in your netapp setting that recognises untagged traffic as being in vlan 731 like the above command? If you don't then you got a native vlan mismatch and your netapp is receiving untagged traffic that it doesn't know belongs to vlan 731.
|
|
#
?
Sep 19, 2012 17:19
|
|
|
It should have also told you that in the syslog if you are getting a native vlan mismatch.
|
|
#
?
Sep 19, 2012 17:23
|
|
|
BurgerQuest posted:We've got a buttload of 2960's out on sites and around the place, they're pretty solid for our purposes. What are you using them for? Was this a question for me? General switching for a small office - stack of 4 plus 1 PoE for phones and such. Maybe iSCSI, but I'll probably reuse the Procurves for that.
|
|
#
?
Sep 19, 2012 18:48
|
|
|
Ok, our internet is totally messed up and it has been for literally years. Typically when it rains a lot it will go to 10% packet loss, and/or the latency will go up. By the time charter sends out one of their redneck reps 2 days later it stops, so they run their little tests, replace the cable modem and leave. This month they have replaced the cable modem 3 times and ran a new home run from the pole, and are now telling us we have an internal network issue. I am hesitant to believe them since last I checked it doesn't rain on our goddamn server racks. However, on the off chance they are right I need to look into this and apparently prove them wrong before they will show up to replace our cable modem again. Right now our latency varies between 20ms up to 800ms and for the last hour it has been hovering around 400ms. We have a cisco asa, some sort of cisco router, and then that router is plugged into their lovely modem. The ASA is set to fall back to DSL on failure of the cable modem (which it hardly ever does since its just packet loss, not a full on loss of connection). Here is an incoming trace code:code:Could this still be an issue with our internal network given the info above? We do not have anything to do with the routers in the 10.0.0.1 subnet. As far as internal problems, the issues happen at all hours when people are not here since I get text messages when some public IPs become unavailable. I also did show interfaces on the cisco router and it is showing a 5 minute average throughput of something like 1.2mbs and we have a 20mbs connection. I can download stuff quite quickly. I ran show conn on the ASA and didn't see anything suspicious or questionable outside ports open. I can ping our router and the cable router at about 1ms. I have no idea what else to do to troubleshoot this or what I need to tell Charter cuz' apparently they cannot figure this out on their own.
|
|
#
?
Sep 19, 2012 19:43
|
|
|
Run continuous pings to 8.8.8.8 and to your first hop in the ISPs network. In your case it looks like 10.154.126.1. But use the 0/0 route that your ASA uses to leave your network. What you'll find is that you can ping your first hop with <5ms latency, but 8.8.8.8 will go to hell. This demonstrates that the problem is taking place outside of your network. (It is most certainly an issue at the cable providers node). Now the challenge is to convince your provider that the issue is on their side, not yours, do you have an official SLA in your Business contract? If not, make sure you work one in there when you re-up. Get your account manager involved and start seriously shopping around for other options, the issue won't be resolved unless you force the providers hand.
|
|
#
?
Sep 19, 2012 20:31
|
|
|
Begby posted:Ok, our internet is totally messed up and it has been for literally years. Typically when it rains a lot it will go to 10% packet loss, and/or the latency will go up. By the time charter sends out one of their redneck reps 2 days later it stops, so they run their little tests, replace the cable modem and leave. Do you have any access to the cable modem's web pages which display SNR and output power? If so, start graphing them using Cacti or similar.
|
|
#
?
Sep 19, 2012 20:58
|
|
|
Crossposting something that pisses me off... Cisco. Backstory: We bought 2x 5548Ps and 20x 2248s in order to converge our data and storage networks in our new datacenter. After carefuly reading the configuration limitations document and designing around the limitations for our migration, we pulled the trigger and bought the material. The document that I used as prep work for the actual deployment was Data Center Access Design with Cisco Nexus 5000 Series Switches and 2000 Series Fabric Extenders and Virtual PortChannels. I panned on being able to hook the Nexus up to our distribution switches and standalone iSCSI network for the migration process and to provide L3 services (because of the limitations with using the L3 routing modules) Current: The document states that you can configure per-interface MTU size. Why is this important you might ask? Our data network (dist./access switches) run a standard MTU size of 1500. Our iSCSI network, on the other hand, use jumbo frames with a MTU of 9000. After trying the steps outlined in the document, I have only been able to set the MTU globally on the Nexus to jumbo or non-jumbo. After contacting TAC, they have confirmed that the MTU qos policy can only be applied at the system level, not per interface. So, any ideas other than not converging our networks and buying a standalone 4900/3750x series pair for our iSCSI network? If I take that approach, management will pretty much eat me alive. If I don't enable jumbo frames for storage traffic, the SAN admins will probably eat me alive. All the while, Cisco TAC shrugs and implies that it is my fault for believing their own documentation. I'm currently waiting on suggestions of how to make it work. In the meantime, I'm going home to break out the Glenlivet. BelDin fucked around with this message at 02:37 on Sep 20, 2012 |
|
#
?
Sep 19, 2012 23:59
|
|
|
Whats wrong with enabling jumbo frames globally? The nexus isn't doing any layer 3 so it shouldn't respond to any maximum MTU ICMP requests, and your routers are going to stay using the normal 1500mtu.
|
|
#
?
Sep 20, 2012 00:30
|
|
|
Powercrazy posted:Run continuous pings to 8.8.8.8 and to your first hop in the ISPs network. In your case it looks like 10.154.126.1. But use the 0/0 route that your ASA uses to leave your network. Thank you for this, we do not have one as far as I know, but I will get the contract pulled and check it out, then demand that we get one. I'll put together some info and send it off to them to make my case. ragzilla posted:Do you have any access to the cable modem's web pages which display SNR and output power? If so, start graphing them using Cacti or similar. Also thank you. I do not have access to the cable modem as far as I know, it is owned by them and I have no idea how to get into it. Edit: Goddamit. Got an email from them, finally, saying they got into our router to troubleshoot it and they are getting 30ms pings and no drops and that from their end its not an issue since they can't reproduce it. Well no poo poo, ITS NOT loving RAINING ANYMORE AND LIKE I KEEP loving SAYING IT ONLY HAPPENS WHEN IT RAINS. gently caress. Its like talking to my 4 year old. Begby fucked around with this message at 00:42 on Sep 20, 2012 |
|
#
?
Sep 20, 2012 00:37
|
|
|
A lot of cable modems listen on 192.168.100.1, if you can try it on the network the inside interface is on. It's often not configurable, but will give you the SNR metrics and whatnot. edit: rain would also imply a problem at the physical layer. Maybe a splitter with a rusty or loose connection outside needs replacing or tightening? bort fucked around with this message at 01:26 on Sep 20, 2012 |
|
#
?
Sep 20, 2012 01:11
|
|
|
Powercrazy posted:Whats wrong with enabling jumbo frames globally? The nexus isn't doing any layer 3 so it shouldn't respond to any maximum MTU ICMP requests, and your routers are going to stay using the normal 1500mtu. The traffic with jumbo MTU going to a switch without it would be the problem as far as I can tell. My understanding is that fragmentation doesn't happen at L2, the frame is just dropped as too large. The distribution switches are 1500, so if I enable jumbo on them, all 1g and 10g links would have that MTU. Then I would have to change on the L2 switches downstream, etc. BelDin fucked around with this message at 02:39 on Sep 20, 2012 |
|
#
?
Sep 20, 2012 01:17
|
|
|
I find MTR better than traceroute with figuring out network issues. Mostly because it'll give you packet drop % on each hop so you at least know where there may be congestion.
|
|
#
?
Sep 20, 2012 02:17
|
|
|
Has anyone worked with the Cisco SRE modules and WAAS? Looking at a small integrated device (2911ish) that also runs a few apps off a Windows Server 2008R2 instance, and will be on the end of a satellite link (hence WAAS). Opinions? Worth it? Utter crap?
|
|
#
?
Sep 20, 2012 03:00
|
|
|
I've been having a hard time getting this 860 up. The config looks OK to me. What am I missing here? This is a very basic setup. DHCP works fine. I can ping the inside global from a connected host, but nothing beyond that. I can also access it from the outside, and ping the outside from the console. This tells me it's probably a NAT issue but damned if I can find any problem with it. code:
|
|
#
?
Sep 20, 2012 04:00
|
|
|
I see the overload now. bort fucked around with this message at 04:20 on Sep 20, 2012 |
|
#
?
Sep 20, 2012 04:07
|
|
|
The vlan network doesn't show up in the routing table. But I don't think that should matter since I can access the router with the inside global address from the LAN side. I tried adding it anyway but it still doesn't show up.code:
|
|
#
?
Sep 20, 2012 04:44
|
|
|
I think what you want is: ip nat inside source list 1 interface FastEthernet4 overload e: I'd also remove: ip route 192.168.1.0 255.255.255.0 Vlan1 That's a connected route on the router and shouldn't need to be static. bort fucked around with this message at 05:36 on Sep 20, 2012 |
|
#
?
Sep 20, 2012 05:09
|
|
|
BelDin posted:The traffic with jumbo MTU going to a switch without it would be the problem as far as I can tell. My understanding is that fragmentation doesn't happen at L2, the frame is just dropped as too large. Remember, if you do not set your MTU on the NIC for the server it will not send out packets above 1500 anyway. If you did set it higher then 1500 on the server, then the packets would drop at the first switch that did not have jumbo frames enabled - be it the nexus or the next switch in line. The few NICs that "auto-discover" MTU all do path-mtu-discovery to at least the first L3 hop - so it will max out at 1500 if your router is still only 1500 MTU.
|
|
#
?
Sep 20, 2012 05:32
|
|
|
Ok, I'm officially stupid. I've been focused on deploying this for so long that it didn't occur to me to just control the frame size at the host level. Will CDP throw errors that I have to supress? Also, I thought that mtu mismatches were detected and ok on layer 3 links, not layer 2. BelDin fucked around with this message at 06:30 on Sep 20, 2012 |
|
#
?
Sep 20, 2012 06:09
|
|
|
ofwolfandan posted:The vlan network doesn't show up in the routing table. But I don't think that should matter since I can access the router with the inside global address from the LAN side. I tried adding it anyway but it still doesn't show up. It's a problem with NATing as you correctly determined. There are two ways to do NAT. One is to explicitly assign interfaces as either outside/inside (ip nat inside/ip nat outside) The other way is to simply assign interfaces as nat enabled ( ip nat enable). Change your interface NAT statements to ip nat enable, and your config should work fine. Alternatively do what bort told you to do, both should work, but I think the new way of doing it requires less configuration.
|
|
#
?
Sep 20, 2012 06:49
|
|
|
bort posted:I think what you want is: Ok that was it. Thank you. I'm retarded.
|
|
#
?
Sep 20, 2012 13:52
|
|
|
Give a thought to Powercrazy's recommendation. I didn't know that was available, and anything that makes NAT simpler is okay in my book.
|
|
#
?
Sep 20, 2012 14:09
|
|
|
BelDin posted:Ok, I'm officially stupid. I've been focused on deploying this for so long that it didn't occur to me to just control the frame size at the host level. Will CDP throw errors that I have to supress? Also, I thought that mtu mismatches were detected and ok on layer 3 links, not layer 2. MTU mismatchs will always cause a frame drop - every "layer 3" link is *also* a layer2 link, never forget that. At a "layer 3" router boundary, the router can fragment the packet if the outbound interface that it is sending the packet on has a lower configured MTU then the packet size it is trying to send (see: ATM). Technically, this is true for a host as well - we just never consider this as it is part of the normal behavior for an endpoint. Also, unless the host sends out (properly formatted) CDP messages, you will no get any CDP log messages. All mismatch log messages from CDP are a result of receiving a CDP packet on the interface reporting the error that the router about the configuration of the other side of the link. I do not know about the nexus platform, but on IOS platforms if you enabled "jumbo" frames it actually did not raise the outbound MTU for packets generated / routed by that device, it only allowed the router/switch to accept and switch packets above the configured MTU up to the jumbo maximum for that platform. This methodology was very confusing to people, however.
|
|
#
?
Sep 20, 2012 18:33
|
|
|
mezoth posted:I do not know about the nexus platform, but on IOS platforms if you enabled "jumbo" frames it actually did not raise the outbound MTU for packets generated / routed by that device, it only allowed the router/switch to accept and switch packets above the configured MTU up to the jumbo maximum for that platform. This methodology was very confusing to people, however. This hasn't matched my experience, I've always had to drop ip mtu on interfaces after raising system MTU on platforms where MTU is system wide to restore OSPF adjacencies after the interface IP MTU matched the system MTU.
|
|
#
?
Sep 20, 2012 19:42
|
|
|
Okay, another dumb question, but I want to confirm my understanding coming from the Procurve world: I have a VLAN 10 for VOIP with Polycom phones. The phones are configured explicitly for that vlan, so they tag their traffic. On the Procurves, ports have a primary vlan, but can also be a member of other tagged vlans. Trunks are something entirely different (aggregated links). With Cisco, it sounds like if I want to plug a computer into a port and have it be on vlan 1, then disconnect it and connect a phone tagged on 10, it needs to be a trunk, even though trunks are defined as connecting two switches in the Cisco world. Is that right? Is that the best way to handle it? We're not daisy-chaining the computer through the phone, so it doesn't need to recognize both at the same time, but I don't want to reconfigure anything if I swap a computer out for a phone, and I want the phones on their own VLAN. Not that that's the end of the world, but I'm lazy.
|
|
#
?
Sep 20, 2012 21:36
|
|
|
Well, yes, but in practice, not necessary: the switchport voice vlan command, when applied to an access port, will also allow the switch to accept that tagged traffic.
|
|
#
?
Sep 20, 2012 21:43
|
|
|
Erwin posted:Okay, another dumb question, but I want to confirm my understanding coming from the Procurve world: Set 'switchport voice vlan 10' on the port and set the Polycoms to auto negotiate their voice VLAN through CDP. I think it should still work even if they don't negotiate voice VLAN using CDP, the 'switchport voice vlan 10' command should let the tagged VLAN 10 traffic come into the port.
|
|
#
?
Sep 20, 2012 21:43
|
|
|
Ok, neat, everything I read about voice VLAN was for Cisco phones, but it was all Cisco documentation. The Cisco documentation for Polycom phones said to use trunks, but also assumed daisy chaining.
|
|
#
?
Sep 20, 2012 21:46
|
|
|
May also want to run auto qos voip trust at the interface level. It will auto config mls qos on the switch if it's compatible.
|
|
#
?
Sep 20, 2012 22:10
|
|
|
|
| # ? Apr 23, 2024 22:48 |
|
|
mezoth posted:MTU mismatchs will always cause a frame drop - every "layer 3" link is *also* a layer2 link, never forget that. At a "layer 3" router boundary, the router can fragment the packet if the outbound interface that it is sending the packet on has a lower configured MTU then the packet size it is trying to send (see: ATM). Technically, this is true for a host as well - we just never consider this as it is part of the normal behavior for an endpoint. So in theory, if I have one switch with a default mtu setting and another with jumbo frames set, as long as the hosts on each switch are at or lower than the lowest mtu in use by the switches, they should talk fine. Kinda like a low water mark governed by the hosts communicating with each other.
|
|
#
?
Sep 20, 2012 22:31
|
|