|
CrazyLittle posted:just a short follow up to this: I use a keyspan USB to serial adapter with a program called zTerm that I found online to connect to my devices. Seems to work okay.
|
#
¿
Nov 2, 2007 23:22
|
|
|
|
| # ¿ Apr 28, 2024 10:52 |
|
|
Search is broken so I hope this wasn't addressed on another page. I'm trying to help someone out with NBAR QoS. They want to prioritize a series of sites and drop traffic on others; while still rate limiting others. I'm checking out some cisco resources but they aren't too useful on the subject. Would this be roughly what I want to do: 1. Create a class-map to identify traffic 2. create a policy-map to tag the traffic somehow 3. user priority queueing on the given interface I want to do QoS on? Or am I limited to just defining bandwidth specifics. I'm probably asking this question in the most horrible fashion. Any sort of website that explains this for stupid people would be greatly appreciated. Google is returning a lot of rate limiting examples (not necessarily what I'm looking for) and drop examples and cisco refers me to a reference guide that presumes I actually know what I'm doing. edit: I think a better way to say it is I have two websites that are business related: foo.com which is important and bar.com which is slightly less important then poo poo like myspace.com which are absolutely not important. I want to make sure requests to foo.com are always serviced first and that rest of the internet goes to the back of the line. 1000101 fucked around with this message at 23:22 on Jul 7, 2008 |
|
#
¿
Jul 7, 2008 22:53
|
|
|
inignot posted:http://www.paloaltonetworks.com/products/features/decryption.html I'm guessing if it sees an SSL/ssh session that it doesn't have a key for then it'll just outright deny it.
|
|
#
¿
Apr 23, 2011 01:04
|
|
|
z0ratio fartboner posted:I can't stand the 5k series. I guess they work well enough. Ungh. What do you hate about the 5k series? I'm a fan since I can get 10gbe and native FC in one box. Also pretty fond of vPC. There are a couple things that are annoying (lack of decent ACL logging for example) but by and large it makes a fine edge switch. To answer the poster you were responding to: http://docwiki.cisco.com/wiki/Cisco_Nexus_7000_NX-OS/IOS_Comparison_Tech_Notes Should be enough to get you started.
|
|
#
¿
Jun 1, 2012 07:19
|
|
|
adorai posted:Scenario: Quite possible! Do something like this on your uplink profile: 'channel-group auto mode active' Then if your upstream 5ks are configured to use vPC and LACP: interface po10 switchport mode trunk vpc 10 Then on your 2 5ks: int eth0/10 switchport mode trunk vpc 10 channel-group 10 mode active Add in other goodies like descriptions, vlan allowed lists, etc. as needed. Note you'll still use hashing to put various network flows on specific 10 gig uplinks but it will be one logical link. edit: I should get some sleep. Doc above me has some other things you should consider mentioned as well such as system vlans, etc.
|
|
#
¿
Aug 15, 2012 23:51
|
|
|
Martytoof posted:Hey, speaking of the Nexus, can you game the system and install multiple 60 day trials after they expire? I want to pick up some experience but there's no way I can do it in 60 days since I'm all over the place right now. You can actually! Just keep redoing the install from scratch and yeah it'll keep regenerating demo licenses. Don't recall having to need to flatten vcenter or the esxi hosts. Pretty sure you don't have to.
|
|
#
¿
Aug 16, 2012 00:26
|
|
|
Nitr0 posted:The default port channel setting in esxi is passive. You've got your ports set to active. Either get rid of that in the switch or do this. If it was 'passive' it'd technically still work. The standard vSwitch just doesn't support LACP period and you'll have to statically configure any etherchannels.
|
|
#
¿
Feb 4, 2013 18:48
|
|
|
NX-OS should push that down to member ports. It definitely won't come up without a 'channel-group X mode on' though.
|
|
#
¿
Feb 4, 2013 20:40
|
|
|
Most cases I don't even bother with etherchannel and just go with an originating port ID policy in VMware. It's a simple configuration and I still get some measure of load distribution. It also fails over fairly easy as well.
|
|
#
¿
Feb 4, 2013 20:50
|
|
|
evil_bunnY posted:This allowed me to bring up the channel, but I still don't have any IP connectivity. port-channel load-balance ethernet source-destination-ip on both of your switches. That will probably fix it assuming you're using IP hash. Make sure you do it on both sides. Also make sure your portgroups are setup to tag appropriate vlans.
|
|
#
¿
Feb 5, 2013 18:59
|
|
|
evil_bunnY posted:Did that already 8( Verify you don't have a portgroup override set to Originating port ID or MAC hash or something. Optionally; since you're on 10GbE you may consider ditching etherchannel and going with originating port ID. Any specific reason you need IP hash? edit: if you're testing with a management portgroup I believe by default it overrides itself to port ID but you can manually flip it.
|
|
#
¿
Feb 6, 2013 00:13
|
|
|
Servers don't typically speak STP so it won't help here. If that server is an ESXi host then you don't need to setup etherchannel at all. You can just setup an active/standby uplink on the virtual switch and when one link falls over the other picks right up.
|
|
#
¿
Feb 22, 2013 00:54
|
|
|
adorai posted:I am in a situation where I might be picking up two 10Ge switches (for my DR site). Most likely, I'd be looking at the nexus line. In my primary datacenter, I have two 5548UP switches today. Would it be possible to run two 6001 switches in tandem and join them in the cross chassis etherchannels? That would allow me to effectively replace my 5548 switch in situ, to take to my DR site. Basically I hate downtime, but like having the newest poo poo, so I need to be sure these ideals can coexist for this upgrade. Sounds like you want to configure "double sided vPC" but I may be delirious from being awake too long. http://www.cisco.com/en/US/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf Basically the short answer is yes. Create another vPC domain with the Nexus 6ks and go nuts. Any particular reason you want to put in Nexus 6001?
|
|
#
¿
Feb 22, 2013 04:58
|
|
|
You can run Nexus 2ks in a variety of ways. You can plug them into Nexus 5ks or 7ks and you can either connect them to just one upstream switch or two for extra resiliency. They're great when you know your traffic goes "north/south" as opposed to "east/west." I think if I were running storage traffic on them I'd just plug the storage into the 5k/7k directly to avoid that traffic hairpinning. I'm currently running vPC/LACP across multiple 2ks without issue. I like using the FEX's because you can bolt on a shitload of switchports without having to deal with STP or anything funky like Fabricpath. It's like using 40+ slot Nexus 7ks.
|
|
#
¿
Mar 12, 2013 20:33
|
|
|
adorai posted:I decided to put this here instead of the virtualization megathread. Also if you're using IP storage or plan to put your management on the 1000v don't forget to set your system VLANs!
|
|
#
¿
Mar 14, 2013 04:07
|
|
|
Ninja Rope posted:Great, more ponies. I work with a VAR that sells UCS 100% of the time they get a demo unit in the door. It's got it's warts but what blade system doesn't? I also have 8 blades and 6 C series servers in my lab that I'm pretty happy with.
|
|
#
¿
Apr 4, 2013 05:24
|
|
|
routenull0 posted:This is exactly why we initially looked at UCS....then we saw the cost. A VAR should be able to get it under the cost of HP with discounts.
|
|
#
¿
Apr 4, 2013 17:53
|
|
|
Powercrazy posted:I think it's the same. I'm certainly not current, but I'm not too concerned. I *think* if I take the CCIE Written I'll be current again, but meh. Whenever I see resumes unless they are claiming CCIE and a number I won't actually check any of their certs. Whenever I took a CCNP exam I noticed on the Cisco portal that it moved up my CCNA expiration date to match when I passed the last CCNP exam. If you're already expired (sounds like you are) you probably won't re-up any of the certs that were expired.
|
|
#
¿
Apr 24, 2013 10:58
|
|
|
Martytoof posted:I've been kind of moving into a VMware direction with my career so I'm up in the air about whether I want to follow down the CCNP path now. I guess I have until January to decide, that's when my NA expires. I might do something like CCNA Security just to keep it active though. It'd be a shame to let it expire. Keep it active. The NA is quite possibly the most boring and mind numbing thing to study for.
|
|
#
¿
Apr 24, 2013 18:31
|
|
|
Sepist posted:ROUTE was for sure the most difficult, my biggest hurdle was remembering which values were preferred when it came to routing decisions - it is very frustrating that BGP weight/local pref/HSRP priorities/etc use high or lows and they're not unified at all. I had much the same problems with ROUTE. SWITCH wasn't too difficult (felt more like an exam on FHRPs than anything) and TSHOOT was actually kind of fun. I ended up with my best score on the TSHOOT exam and I barely passed the ROUTE exam.
|
|
#
¿
May 6, 2013 20:48
|
|
|
jwh posted:I'm looking for ASA post 8.2+ 'best practices', or really any 'best practices' in general. Replace with an SRX and call it a day!
|
|
#
¿
May 9, 2013 22:44
|
|
|
Gap In The Tooth posted:I agree with you there, I'm having a real headache getting a basic multi-area OSPF setup going with virtual links. I'd post configs and stuff but I'm sure you guys don't want to have to deal with such trifles... Did you inherit a lot of that or are you designing it with virtual links in mind? I tend to avoid the whole idea of virtual links anytime I'm not doing some kind of merger with another company. Even then it's more of a transition tool rather than something to run steady.
|
|
#
¿
May 16, 2013 05:54
|
|
|
Buffer posted:Are there any limitations imposed based on the size of the peer-link when you configure a Nexus for virtual port-channel? I keep seeing 2x10GE but it's unclear if this is per 20GE VPC or if some kind of magic happens. Not really. The control traffic that goes over the peer link will fit more than comfortably in a single 10 gig pipe. Beyond that you're adding for redundancy and bandwidth of your data traffic. If you think you'll have a lot of traffic going from one of your 5ks to the other feel free to use 4 links or more for your peer-link. Regarding your second question, you don't need to have multiple peer links for vPC even if you planned on having 40 port-channels. 1 should be sufficient. The only caveat is you need to make sure any VLAN on a vPC port-channel is carried over the peer-link. That said I think you're still going to be limited to 16 interfaces per port-channel with 8 active at any time. Don't think you can have 21 members in a given channel-group.
|
|
#
¿
Jun 23, 2013 23:34
|
|
|
Buffer posted:Can you clarify this? The only traffic traversing the 5ks will be from one VPC to another. Am I really OK with just 2 10GE links for redundancy and can expect those vpcs to roughly perform like they were real port channels? I guess what has me a little leery is that it seems a bit too good to be true. My instinct is that I should size the peer link for the amount of cross-traffic that could occur without VPC. In a perfect world you shouldn't have a whole lot of traffic going over your vPC peer link. If every device connected to my 5k is using vPC then as long as everything is healthy you shouldn't see much of anything going over that link. However if there's a failure (say one of your downstream vPC connected devices loses one leg of it's vPC) then you might see some data traffic going over the peer link. In my lab environment I have a pair of Nexus 5ks acting like my "core" and the only traffic I see going over the peer link is non-VPC stuff. i.e. it's plugged into 1 5k but not the other and it happens to be talking to a device on the other. quote:It'd be 15 separate virtual port channels each with 1-2 interfaces per switch for a total of 21 used interfaces - to start with anyway. Ah should be fine then!
|
|
#
¿
Jun 24, 2013 01:27
|
|
|
ruro posted:B-but you don't understand, we have a critical need to vmotion VMs between the data centers! Vmotion has made server/application guys so lazy when it comes to building redundancy As a mostly VMware guy the only time I've really advocated for a layer2 stretch was for a datacenter move project over 1300 miles for over 20,000 systems (both physical and virtual.) That said its probably one of the few reasons I'd consider doing a layer 2 stretch which I'd stop at the end of the project. Beyond that though yeah it's generally fraught with peril.
|
|
#
¿
Jul 6, 2013 05:44
|
|
.
|
ruro posted:Has anyone ever implemented FHRP gateway localization on a 6500? I have a feeling I am going to lose an argument against having active VMs in several DCs on the same spanned VLAN while still having to provide host mobility, and I really want to avoid traffic tromboning if at all possible. It's definitely doable with a 7k using OTV. Don't see why the same principles wouldn't apply but I've never tried it (I personally hate layer 2 extension since it's usually the wrong solution to a problem.) From: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-644634.html code:
|
|
#
¿
Jul 15, 2013 23:18
|
|
|
routenull0 posted:I was involved a bit in the bake off for DCB deployment for DoD between QFabric / Nexus / Brocade........was fun. Could you talk about what worked out and some of the "whys" ?
|
|
#
¿
Aug 3, 2013 21:17
|
|
|
Flash z0rdon posted:5ks are poo poo. They're decent access layer devices since you can get FC and ethernet in one box. Layer 3 on them is horrible though.
|
|
#
¿
Aug 17, 2013 19:12
|
|
|
abigserve posted:The basic reason is you don't want to purchase additional hardware. If you've got some nexuses already, the simplest design would be to use them to route as well instead of buying at least one 6500 (two if you need redundancy). I'm doing routed-edge designs a lot more frequently now coupled with VXLAN. Bit of the best of both worlds and can keep the VMware people happy. edit: clarity
|
|
#
¿
Aug 19, 2013 06:11
|
|
|
psydude posted:I'm currently on a network that is using public IP addresses for internal addressing. I have a customer that's using someone else's public IP addresses for internal addressing.
|
|
#
¿
Nov 3, 2013 19:43
|
|
|
I put ssh keys on my switches so I can run commands remotely and it sends the output back to me. Handy when you have to run 'show tech' on a 7k and it blasts you with 700MB of data.
|
|
#
¿
Nov 28, 2013 18:44
|
|
|
less than three posted:What's the cheapest Cisco FCoE switch line, is it the Nexus 5000? Looking at the Nexus 5548P. Either Nexus 5k or 6k (comedy option of 7k if your environment is large enough to warrant it and you get the proper line cards.) Also you can opt for the Nexus 5548UP if you also want native FC support on top of FCoE support. Handy for older hosts and most storage arrays that may not have an FCoE HBA. edit: When you buy, you want to buy at least a pair. Put one switch on VSAN X and the other on VSAN Y (numbers aren't important just don't overlap the VSAN ID with a data VLAN ID you're already using.)
|
|
#
¿
Jan 9, 2014 00:34
|
|
|
psydude posted:Switches use Application Specific Integrated Circuits to perform quick switching at layers 2 and 3, whereas routers are just software running on top of a computer (IOS, F5 load balancers, and most firewalls are just applications running on top of RHEL or CentOS. Some vendors use FreeBSD). ASICs are incredibly more efficient, but they're insanely difficult to emulate with software because they're entirely hardware. Most routers these days will forward in hardware without involving the CPU. The only thing you can't really do with respect to emulating switching functions yet is run IOS on GNS3 or something to provide a fully functional catalyst. Hypervisors themselves can absolutely provide layer 2 functionality entirely in software and it's generally plenty fast since it's only limited by the speed in which it can copy data from one area of memory to the other.
|
|
#
¿
Jan 18, 2014 07:24
|
|
|
dont change my name posted:Can someone give me a detailed honest assessment of the Nexus line? We have 5010's, 7010's, 5596's and 2148's and what have you and I am simply not impressed with the Nexus. Vpc is a pretty rad feature as is fex. One of my customers manages 480 access ports from one pair of 5ks. I will say the 5010 is kind of lovely (it's an into product) but the 5500 series is decent for layer 2. What sorts of issues are you having? Could you describe your design a bit? Also for the person looking for an ios to nxos primer: http://docwiki.cisco.com/wiki/Cisco_Nexus_7000_NX-OS/IOS_Comparison_Tech_Notes 1000101 fucked around with this message at 08:45 on Feb 5, 2014 |
|
#
¿
Feb 5, 2014 08:41
|
|
|
I'd probably use /24s or smaller for desktops/phones. I'm an advocate of using l3 links to my access switches though.
|
|
#
¿
Feb 6, 2014 23:09
|
|
|
jwh posted:Well, trunks are (in this case) a collection of vlans. SVIs are the layer-3 interface of a single corresponding vlan. So by definition, a SVI can't be a trunk. If VLANs are lakes then an SVI is a dock and when you want to go to another lake you dock your boat on the SVI and walk over to another dock so you can ride a boat in the other lake. Think of an SVI as a sort of network card. With IP routing enabled you're basically creating a computer with a network card in every VLAN you define an SVI in. Since that computer has an interface in every VLAN it can naturally reach them all! It just happens that this particular computer isn't a physical thing and the SVIs are basically "virtual NICs." Generally a switch can only have 1 SVI in a given VLAN. If you're using vrfs then just think of each vrf as a separate computer.
|
|
#
¿
Feb 22, 2014 00:27
|
|
|
sudo rm -rf posted:vPC is blowing my loving mind. It was so simple to enable and set up, but I have no idea how everything else works now. Configure all SVIs on your 5ks just like you always would and setup an FHRP between them. One great thing about vPC and VRRP/HSRP is that either side will respond as the active gateway depending on which 5k receives a packet so you don't have to worry about traffic going over the peer link. How are your fex's configured? Are they physically connected to both 5ks or just one? if they're connected to both 5ks then make sure the channel-group for the fex has a VPC ID assigned to it. i.e. int port-channel 101 vpc 101 on both 5ks (assuming you're using po101 for fex101.) If they're single homed then just configure the port-channel as needed. For the ESXi host, assuming you want to use LACP/VPC and not just LBT or originating port you'll want to do something like this: int eth101/1/10 channel-group 210 mode active int po210 <your interface stuff here> vpc 210 Repeat on 5k-2 int eth102/1/10 channel-group 210 mode active int po210 <interface stuff> vpc 210 If your FEX's are dual homed then just add the interfaces to a channel group on both 5ks. If you don't then a "show int brief" will show the state as "inactive."
|
|
#
¿
Mar 5, 2014 20:05
|
|
|
Powercrazy posted:I don't think the 5548 can act as an NTP server. If you have a router, or server somewhere, use that instead. It can as of current releases. 'feature ntp' 'ntp master 2' Sets it as a stratum 2 NTP source. This is on version 6.0(2)N2(2)
|
|
#
¿
Mar 6, 2014 20:15
|
|
|
sudo rm -rf posted:In another update from sudo's first networking job, gently caress ASAs. I'll probably be asking for help about that later this weekend, but right now my brain needs time to recover. Just a heads up, you'll be saying this on your second, third, fourth and so on network jobs ceaselessly throughout eternity.
|
|
#
¿
Mar 8, 2014 04:55
|
|
|
|
| # ¿ Apr 28, 2024 10:52 |
|
|
Dilbert As gently caress posted:Got an Cisco Unified Manager, tips? I assume you mean UCS manager tips? If you do I have loads! Ask any questions for specifics. This is meant to be a quick set of guidelines/tips and wouldn't mind going into further detail. My CCIE data center lab is scheduled for July so I'm very keen to answer any and all questions around MDS, UCS and Nexus. Some highlights: 1. Create a maintenance policy for user ack or change the default policy. This is literally the first thing you should do when dealing with UCS after you get the FI clustering configured. 2. Use updating templates for everything. vnic templates, vhba templates, service profile templates, etc. 3. I like to create a BIOS policy and host firmware package for the blade at whatever rev I'm installing. This is helpful for avoiding changes in code/BIOS versions from screwing up something down the road. It also means you can change all of your blade BIOS versions/settings in one shot. 4. If the OS you're installing on the bare metal supports NIC failover then don't enable fabric failover for vnics. If it doesn't have built in failover then go ahead and enable it. Failover will be transparent from the actual OS itself. (VMware is a good example where you don't want to enable fabric failover for vnic templates because it will handle it on it's own and will generally do a better job/faster.) 5. When creating MAC pools/WWN pools try to stick some useful info in there but don't go apeshit. For example you might do something like this: 00:25:B5:XX:YZ:## for a MAC pool. Where XX might be the UCS domain ID (useful for multiple fabric interconnect clusters at one site); Y might be the vnic ID (i.e. for vnic 1 this value would be 1) and Z would be either A or B depending on which fabric you want to pin the vnic to. Other examples might include things like the OS ID (replace one of the X's) so if the PXE server sees say a '1' there it'll feed the blade a windows install image. I'm thinking things like this are better suited for a GUID pool where we have more bits to play with. 6. Keep up to date on releases of UCSM. Things are added/fixed/change constantly as Cisco is very keen on listening to customer feedback. 7. Learn some of the CLI bits. For example if you ssh/console into a UCSM FI you can 'connect nxos' and get access to the underlying NXOS instance that's responsible for forwarding traffic. You can't make changes here but you can collect useful bits of data.F or example 'show pinning border' will show you what blade interfaces are pinned to what uplink interfaces and 'show npv flogi' will show you what blades have logged into the FI which can be helpful when troubleshooting upstream SAN issues. You can also connect to some adapters via the UCSM FI CLI (from the top of the config hierarchy) and pull additional data like determining if your iSCSI config is working, what target it's actually trying to connect to, if it actually connected, etc. 8. Try to leave the fabric interconnects in end host mode for both ethernet and fibre channel switching. This simplifies things greatly and keeps you from having to deal with STP on the FIs or burning domain IDs and/or running in interop mode for FC. 9. For your chassis discovery protocol pick a number of links that seems appropriate (this is only used during chassis init/acknowledgement) for your minimum IO and set it to port-channel. This will allow blades to use all of the available bandwidth as opposed to being pinned to a specific IOM port. 10. If you're running certain combinations of Java and UCSM you may find that clicking on the KVM link in the UCSM UI will result in some sort of "file not found" error. Point your web browser to the FI cluster IP and click on the "KVM Manager" link and use that. Also if you've got more than say 8 blades on a chassis it's generally a better idea to use the KVM manager anyway. It's actually much easier to get to a KVM session via the manager when you've got 100+ blades on a fabric interconnect (we're doing ~120-140 blades per fabric interconnect depending on the site/environment and we're quite happy with it.) 11. As a point to #10; name your service profiles something sensible that makes sense to your server team. This generally should be the hostname of the blade itself. 12. Create all service profiles from a service profile template! Even one offs! 13. Don't forget to configure call home on the box before you put it into production. In addition to contacting TAC it should also contact your NOC/customer's NOC or whoever might care if a chassis PSU went tits up. 14. I like to create a new org to house all the non-default settings I've gone off and configured. 15. Did you create a maintenance policy set to user ack? 16. When uplinking to Cisco MDS fibre channel switches you'll want to configure an active port-channel for your fibre channel uplinks. This also holds true if you're linking up to a Nexus 5k UP. 17. When uplinking to Brocade fibre channel switches you're probably going to want to configure SAN pin groups since it doesn't support port-channels like Cisco does (Brocade has their own proprietary ISL tech which is pretty awesome but insists on everything plugging into it is brocade.) 18. Try to use LACP for northbound ethernet connectivity. Ideally your upstream switches should support some form of MLAG (i.e. Arista, Cisco vPC, etc.) 19. Have you created that maintenance policy yet? If this wasn't anything about UCSM then I suppose I just wrote a bunch of stuff for nothing!
|
|
#
¿
Mar 10, 2014 07:40
|
|