|
People who love free junk: If you sign up for a Meraki webinar, Cisco will supposedly send you a free unit. My boss got his and it's licensed through 2017 so a free $300 doodad with 3 years of cloud management for an hour or two of your time. https://meraki.cisco.com/webinars Signed up cause I can't pass up free gadgets, figured I'd pass it on.
|
#
?
Feb 11, 2014 19:35
|
|
|
|
| # ? May 28, 2024 06:33 |
|
|
Is it just a sales thing or do they tell you any technical stuff, too?
|
|
#
?
Feb 11, 2014 19:50
|
|
|
Man, trying to get a virtual WLC set up on an ESX host is like pulling god drat teeth.
|
|
#
?
Feb 11, 2014 20:10
|
|
|
Martytoof posted:People who love free junk: Here's the fine print
|
|
#
?
Feb 11, 2014 20:15
|
|
|
It's a sales thing, and those fuckers didn't even send me one after I sat through their stupid pitch.
|
|
#
?
Feb 11, 2014 20:50
|
|
|
Totally sales, and they'll vet you after the fact with a phonecall. If it's relevant to your workplace, just tell them you're in a position to recommend their products etc etc.
|
|
#
?
Feb 11, 2014 20:52
|
|
|
Martytoof posted:Totally sales, and they'll vet you after the fact with a phonecall. If it's relevant to your workplace, just tell them you're in a position to recommend their products etc etc. Only one AP per company. Found out an old employee here already snagged one.
|
|
#
?
Feb 11, 2014 21:28
|
|
|
Does URPF work on subinterfaces? Here's the config I'm using, pre:interface GigabitEthernet1/1 no ip address ! interface GigabitEthernet1/1.101 encapsulation dot1Q 101 ip address 10.0.1.1 255.255.255.0 ip verify unicast source reachable-via rx ! interface GigabitEthernet1/1.102 encapsulation dot1Q 102 ip address 10.0.2.1 255.255.255.0 ip verify unicast source reachable-via rx ! interface GigabitEthernet1/1.103 encapsulation dot1Q 103 ip address 10.0.3.1 255.255.255.0 ip verify unicast source reachable-via rx pre:#show ip verify source interface GigabitEthernet 1/1.101
^
% Invalid input detected at '^' marker.
#show ip verify source interface GigabitEthernet 1/1.102
^
% Invalid input detected at '^' marker.
#show ip verify source interface GigabitEthernet 1/1.103
^
% Invalid input detected at '^' marker.
#
#show ip verify source interface GigabitEthernet 1/1
IP source guard is not configured on the interface Gi1/1
|
|
#
?
Feb 12, 2014 00:48
|
|
|
So I know this isn't Cisco, but there doesn't seem to be a general enterprise networking thread, so I figured this would be the best place. Short version: Does anyone know how the port selection process is configured for port translation on an F5 BIG/ip, and whether it is possible to modify the process, i.e. to tell the device to assign ports for port translation sequentially instead of randomly? Long version: We have a load-balanced pair of FTP servers that we've moved from one F5 load balancer to another (similar, if not identical) F5 recently. We have a client who connects to the system via the F5 VIP for FTP and performs dozens or hundreds of active mode FTP data transfers in a single command session; each transfer opens a brand new data connection. Port translation is enabled on the F5 for active mode FTP data connections. The option to preserve the original port unless it is already in use by another connection on the F5 is enabled, but the port pass-through only seems to happen half the time or less; the rest of the time, the F5 does port translation with a new port that it chooses when it passes the connection to the FTP server. On the old F5, the ports the F5 assigned for port translation appeared to be selected sequentially, i.e. it would use port 20000 for the first translated active mode FTP data connection, 20001 for the next one, 20002 for the next, and so on. On the new F5, however, it appears to be selecting the ports completely at random, so that the first data connection might use port 20000, the next might use port 61382, the next one 3285, the next 15291, etc.; no logic or order to the selection of ports at all. The problem this is causing is that sometimes during one of these huge hundreds-of-files command sessions from this client, the F5 will attempt to reuse a port that it used for a previous data connection a few seconds ago. When this happens, the old connection is still in a TIME_WAIT state, so the server cannot open a new connection to the same IP and port, and the active mode data connection attempt fails. This causes the entire job on the client to fail and makes a lot of work for the people managing that system. Unfortunately the FTP server is a proprietary module in a third party application suite, and the client is a mainframe system, so options to work around this behavior from either end (e.g. configuring the client to reuse existing data connections instead of opening new ones for every file it transfers) are limited or nonexistent. We also aren't sure what effect disabling port translation on those connections would have, as the networking setup around this platform is fairly complex, and as the FTP server is a critical system (that quite literally costs us thousands of dollars a minute if it's down), "turn port translation off and see what happens" isn't really a great option. Ideally, we would like to fix the problem by changing the port assignment behavior of the F5 so that it assigns ports sequentially instead of randomly, like the old F5 did. However, our network admin isn't sure how to do that (or even if it can be done), and couldn't get an immediate answer from F5 support. I've tried searching, but can't find anything useful myself either. (Probably doesn't help that the sum total of my experience with F5s, or any other network hardware for that matter, is staring blankly at the pretty blinky lights in the network cabinets while waiting for old broken Dell servers to reboot...  ) Anyone here ever messed with F5s and have any idea how to modify the method it uses to assign port translation ports?
|
|
#
?
Feb 12, 2014 01:22
|
|
|
Powercrazy posted:Ran into a wierd thing on a Cisco 6500. I usually see this when there is some kind of mismatch on the other end or with the QoS on the switch side. Usually there'll be at least one port listed in the non-A channel though.
|
|
#
?
Feb 12, 2014 02:55
|
|
|
Filthy Lucre posted:Does URPF work on subinterfaces? Guessing you're looking at something 4500/6500 here, because "verify source" is used by source guard, which is seeded by source guard via DHCP inspection. I'd still expect subinterface support though for BBA applications, but probably not on 6500 platform. Check "show cef interface <intf>", there should be a line saying "IP unicast RPF check is enabled" if it's on. Not sure how to check counters on that in IOS, since subif counters are hidden in 6500/4500 platforms iirc. Not sure if it'll report via SNMP as an input drop. -edit- Looks like it reports on 'show ip int <intf>': code:$ snmpget -mCISCO-IP-URPF-MIB -v2c -cREDACTED car1.ind1 CISCO-IP-URPF-MIB::cipUrpfIfDrops.817.ipv4 CISCO-IP-URPF-MIB::cipUrpfIfDrops.817.ipv4 = Counter32: 313 packets Doesn't look like it shows in IF-MIB, l2vlan ifType doesn't report any errors/discards in either direction. Only in/out octets/packets. -/edit- ragzilla fucked around with this message at 04:25 on Feb 12, 2014 |
|
#
?
Feb 12, 2014 03:53
|
|
|
Powercrazy posted:Ran into a wierd thing on a Cisco 6500. could be anything from a bonding config error on the other end to mismatch QOS capabilities of the channel member interfaces. We saw a lot of this moving from SXI2a to SXJ6. There is a command you can put on the interface to tell IOS to ignore and bond anyway, but we fixed this by moving any etherchannel child interfaces to qos matched line cards. Once we did this, the xxxA interfaces went away.
|
|
#
?
Feb 12, 2014 05:19
|
|
|
I assume 5/4, 5/5 and 6/4, 6/5 are sup 10 gig interfaces?
|
|
#
?
Feb 12, 2014 05:23
|
|
|
CrazyLittle posted:It's a sales thing, and those fuckers didn't even send me one after I sat through their stupid pitch. Did you call the number of the rep in your email? I literally just got off the phone with him and he verified my address and that was it. It's on it's way. He didn't even try to sell me on anything or ask any questions about what I do.
|
|
#
?
Feb 12, 2014 21:22
|
|
|
The rep assigned to me called me after registering, and that was the last I heard from them. So yeah I didn't bother calling them back. I just went with Ubiquiti instead.
|
|
#
?
Feb 12, 2014 22:00
|
|
|
XRv went GA yesterday with XR 5.1.1, so bug your SE for access if you want to get acquainted with XR. Download center is hosed up as usual, but your SE should be able to get you a link to the file exchange.
|
|
#
?
Feb 12, 2014 22:44
|
|
|
ragzilla posted:XRv went GA yesterday with XR 5.1.1 Yesss, fina-- ragzilla posted:so bug your SE for access 
|
|
#
?
Feb 13, 2014 04:04
|
|
|
Cisco download page works fine for me! Use this link: http://software.cisco.com/portal/pub/download/portal/select.html?&i=!m&mdfid=285013070 Edit, missed the "v" yeah, not seeing a download. Fatal fucked around with this message at 17:30 on Feb 13, 2014 |
|
#
?
Feb 13, 2014 17:26
|
|
|
ragzilla posted:Looks like it reports on 'show ip int <intf>': Yup, that did it. Thanks. I'm not entirely where allow-default comes into play with URPF. 'ip verify unicast source reachable-via rx' is strict mode, so only the network on the interface is allowed ingress into the interface. 'ip verify unicast source reachable-via any' is loose mode, so any IP matching a route in the routing table is allowed ingress. But what does the allow-default do?
|
|
#
?
Feb 13, 2014 18:45
|
|
|
Functionally it allows packets sourced from any IP to enter an interface that has the default route pointed at it... which is a weird use case. E: Might be some corner cases for platforms that only support one uRPF mode globally (6500/7600), otherwise still kind of useless.
|
|
#
?
Feb 13, 2014 19:02
|
|
|
tortilla_chip posted:Functionally it allows packets sourced from any IP to enter an interface that has the default route pointed at it... which is a weird use case. You'd use it on your interface facing your default route to prevent them from spoofing your IPs, uRPF will drop traffic sourced from a more specific if the more specific egresses a different interface. But it won't consider defaults valid by default hence the knob. tortilla_chip posted:Functionally it allows packets sourced from any IP to enter an interface that has the default route pointed at it... which is a weird use case. It's to uRPF your upstream so they can't send you packets with your source IPs.
|
|
#
?
Feb 13, 2014 19:08
|
|
|
Anyone care to help me with what should be a simple problem? Working with a Cisco 2811. Trying to set a static route going to an interface. Whenever I enter the static route and it takes it fine, but doesn't show up when I do a "show ip route". It does show up with "show run". The interface shows as up. Any ideas on what I am missing? I don't normally deal with routers much, so I am working a lot from google.
|
|
#
?
Feb 14, 2014 17:30
|
|
|
Moey posted:Anyone care to help me with what should be a simple problem? Is the next hop you are pointing the route to in your routing table (as directly connected)?
|
|
#
?
Feb 14, 2014 17:59
|
|
|
Jelmylicious posted:Is the next hop you are pointing the route to in your routing table (as directly connected)? The route in question is not showing up at all in the routing table (show ip route). It does show up when I do a "show run" though.
|
|
#
?
Feb 14, 2014 18:07
|
|
|
Are you using ip route 0.0.0.0 0.0.0.0 FastEthernet4 or ip route 0.0.0.0 0.0.0.0 x.x.x.1 ?
|
|
#
?
Feb 14, 2014 19:04
|
|
|
Powercrazy posted:Are you using ip route 192.168.1.0 255.255.255.0 fa0/1.10 The network that is connected to fa0 I have no control over. To my knowledge it is all just dumb switches patched together and is closed outside of this connection in there. Doing a traceroute to the 192.168.1.0 network from that router just loops on the 0.0.0.0 route I have set. Edit: To expand a little more. fa0/1 is setup like so: ! int fa0/1 no ip address duplex auto speed auto ! int fa0/1.10 encapsulation dot1q 10 native ! Double Edit: Here is a quick drawing of what I am talking about. Want to be a clear as possible. R1 is the Router in question I am working with. R2 is the Router at the other end of the T1 link that connects this mess back to our real network POOP is this network that is all dumb switches that I have no control over 
Moey fucked around with this message at 19:32 on Feb 14, 2014 |
|
#
?
Feb 14, 2014 19:09
|
|
|
So your router doesn't have an IP on the 192.168.1.0 network? Because if not, there is no way devices on that network will be able to get back to the router. And I'm pretty sure the packets aren't even being sent since the router doesn't have a source address for the IP Packet. Also there are some historical caveat's about using a broadcast instead of a NBMA/PtP interface as a next hop. I just avoid the situation by always using an IP Address as the next hop.
|
|
#
?
Feb 14, 2014 19:39
|
|
|
Powercrazy posted:So your router doesn't have an IP on the 192.168.1.0 network? Because if not, there is no way devices on that network will be able to get back to the router. And I'm pretty sure the packets aren't even being sent since the router doesn't have a source address for the IP Packet. Correct, no IP on the 192.168.1.0/24 network. Good call on source address IP, I didn't even think of that. Backstory: This was setup long before I was here. R1 recently poo poo the bed and somehow got wiped back to factory defaults. We don't have any documentation on the config. No documentation on the 192.168.1.0/24 network. It runs some very important stuff, but is literally strung together with lovely unmanaged switches. I guess I'll have to do some network scans and find out what is actually out there, then assign an IP like it should be. Thanks for your help. Edit: I am now beginning to learn that the workstations on that network they want to get to are just dual homed onto another lovely network. And for some reason that private network is using public address for all of it's devices. I know it doesn't make a difference since this thing doesn't go out to the internet at all, but still. Moey fucked around with this message at 21:40 on Feb 14, 2014 |
|
#
?
Feb 14, 2014 19:45
|
|
|
Powercrazy posted:Also there are some historical caveat's about using a broadcast instead of a NBMA/PtP interface as a next hop. I just avoid the situation by always using an IP Address as the next hop. This. If you next-hop to an interface every. single. packet. must get ARP'd for destination address. Moey posted:Backstory: This was setup long before I was here. R1 recently poo poo the bed and somehow got wiped back to factory defaults. We don't have any documentation on the config. No documentation on the 192.168.1.0/24 network. It runs some very important stuff, but is literally strung together with lovely unmanaged switches. As a long shot, check the flash to see if there is anything residual from the old config. "dir flash:"
|
|
#
?
Feb 15, 2014 15:30
|
|
|
H.R. Paperstacks posted:If you next-hop to an interface every. single. packet. must get ARP'd for destination address. It doesn't arp for every packet, the arp cache is still populated as normal, but every destination will be ARPd for. Typically this is only a concern for default routes, but obviously less than optimal if you know the correct gateway (and won't work at all if proxy-arp is disabled in that gateway).
|
|
#
?
Feb 15, 2014 17:38
|
|
|
Is there a negative to using an interface with a /30 as the default route?
|
|
#
?
Feb 15, 2014 18:00
|
|
|
adorai posted:Is there a negative to using an interface with a /30 as the default route? Not really, unless you're trying to setup HSRP/VRRP across that link. (Depending on the media you might not have that option anyways.) You could even go with a /31 if your hardware supports it like most Cisco gear does. /31 - bare minimum number of IPs needed for a point-to-point link. May not be supported on some hardware. /30 - Wastes two IPs for the network and broadcast. /29 - gives you the ability to HSRP/VRRP CrazyLittle fucked around with this message at 20:19 on Feb 15, 2014 |
|
#
?
Feb 15, 2014 20:17
|
|
|
Powercrazy posted:
Same, OP.
|
|
#
?
Feb 15, 2014 23:48
|
|
|
adorai posted:Is there a negative to using an interface with a /30 as the default route? No.
|
|
#
?
Feb 15, 2014 23:48
|
|
|
Marvel posted:I think I'm getting a Netgear GS728TP-100NAS switch, plus a bigass Well, it turns out that UPS has an 80mm fan that runs at SUPER HIGH SPEED all the time and it's deafening. I spent so much shipping the thing that it's not really worth sending it back and getting a new one so I'm going to try to open up the case and swap in a quieter fan. It won't push as much air but I'm not running the thing anywhere near capacity so I think it should work fine.
|
|
#
?
Feb 17, 2014 05:44
|
|
|
I'm looking to rig up some console cables to go from my terminal server to some Cisco devices. I found this diagram for mapping out the cables:  Going from that, which one of these two would be correct?   I'm guessing the second, but I'm not fully awake and want to double check before I crank out like 15 of these.
|
|
#
?
Feb 17, 2014 15:44
|
|
|
QPZIL posted:I'm looking to rig up some console cables to go from my terminal server to some Cisco devices. Don't use Cat 5e/6 cable. Use the flat gray 8-wire cable instead. You don't need to do any special wiring, you just need to strip the ends off and make sure that both ends are opposite: 
|
|
#
?
Feb 17, 2014 16:38
|
|
|
I could do that... but I already have so much spare Cat5e cable and a crap ton of connectors.
|
|
#
?
Feb 17, 2014 16:58
|
|
|
QPZIL posted:I could do that... but I already have so much spare Cat5e cable and a crap ton of connectors. I can bust out 30 rollover cables in the time is takes even a really skilled cable crimper (this is a bad skill by the way) to crank out 6. There is also the added benefit of being able to easily and positively identify console cables if you have to be in the Datacenter for some reason.
|
|
#
?
Feb 18, 2014 19:23
|
|
|
|
| # ? May 28, 2024 06:33 |
|
|
The key to making cables is to just zone out and let muscle memory take over. As I learned when I redid a whole datacenter by hand because my boss was too cheap to spring for pre-cut cables.
|
|
#
?
Feb 18, 2014 20:48
|
|