|
You can manage an ASA via both ASDM and CLI interchangeably if you so wish. Most people do one or the other for the most part, though. ASDM generally will drop strange group names into your config that you'd probably not use if you were configuring it via CLI.
|
#
?
Mar 8, 2014 18:30
|
|
|
|
| # ? May 28, 2024 06:52 |
|
|
doomisland posted:We have PAN's at work in our office. One problem is that they don't do IPv6 well at all. Thanks Obama. I have some datacenter SRXs but haven't had any hardware issues so I can't say how difficult they are to troubleshoot. They run nice though.
|
|
#
?
Mar 8, 2014 20:09
|
|
|
My coworkers use asdm and I only use cli, not sure where you heard that you can only use one or the other.
|
|
#
?
Mar 8, 2014 20:28
|
|
|
Bluecobra posted:Unless they changed something in a newer version, you can certainly do both CLI and ASDM. Either way, ASAs are poo poo and for my next job I will try to avoid a company that uses them. Checkpoint is the only vendor I have 0 experience with, aside from playing golf with the local account manager once. They seem OK from reading product sheets... I think the other thing about my ASA experience is I've never tried them as IPS's, that could be another source of pain and the reason people hate them so much (I mean, I've never configured it because I've just assumed it was terrible - there you go).
|
|
#
?
Mar 8, 2014 23:34
|
|
|
GOOCHY posted:You can manage an ASA via both ASDM and CLI interchangeably if you so wish. Most people do one or the other for the most part, though. ASDM generally will drop strange group names into your config that you'd probably not use if you were configuring it via CLI. One handy thing about ASDM is that you can tell it what you want to do and it will spit out the commands, which you can then go through and paste into CLI.
|
|
#
?
Mar 9, 2014 01:17
|
|
|
I think what Powercrazy is saying is that if you use ASDM or more specifically *any* of the wizards in ASDM you will want to kill yourself if you ever go into the CLI to check on the config. I swear that utility will double the size of your config if you try to do it the "easy" way.Inspector_666 posted:One handy thing about ASDM is that you can tell it what you want to do and it will spit out the commands, which you can then go through and paste into CLI. I wish this is all it did. Why yes I would like 20 minutely different isakamp policies *snip* Why yes I would like all of my objects & groups named by an autistic 8 year old with a love for hyphens *snip* God that thing pours out drivel. Fatal fucked around with this message at 05:50 on Mar 9, 2014 |
|
#
?
Mar 9, 2014 05:46
|
|
|
1000101 posted:Just a heads up, you'll be saying this on your second, third, fourth and so on network jobs ceaselessly throughout eternity. Got an Cisco Unified Manager, tips?
|
|
#
?
Mar 9, 2014 09:44
|
|
|
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
|
|
|
1000101 posted:I assume you mean UCS manager tips? Yeah my bad, thanks for the info!
|
|
#
?
Mar 10, 2014 07:46
|
|
|
Sepist posted:My coworkers use asdm and I only use cli, not sure where you heard that you can only use one or the other. Because after an ASDM conversion, the CLI becomes unusable garbage, well more so. Fatal posted:I think what Powercrazy is saying is that if you use ASDM or more specifically *any* of the wizards in ASDM you will want to kill yourself if you ever go into the CLI to check on the config. I swear that utility will double the size of your config if you try to do it the "easy" way. Bingo.
|
|
#
?
Mar 10, 2014 08:09
|
|
|
I have a habit of copy pasting the Config into notepad when I do anything with acl's
|
|
#
?
Mar 10, 2014 14:18
|
|
|
I spent all last week raging hard against ASAs and even ranting to my boss about how they won't work right and are giving me a hell of a problem. I couldn't for the life of me get a port on the ASA5505 to go up/up. It was always up/down. No matter what! Straight, crossover, access, trunk, VLAN changes, nothing helped. Then Friday evening I realized I was SSH'd into one ASA, but plugging things into a different ASA 
|
|
#
?
Mar 10, 2014 15:19
|
|
|
QPZIL posted:I spent all last week raging hard against ASAs and even ranting to my boss about how they won't work right and are giving me a hell of a problem. Even misplaced ASA hate is still deserved.
|
|
#
?
Mar 10, 2014 15:25
|
|
|
The CLI is still usable after a careless someone uses ASDM, just messier. The whole "don't mix CLI and ASDM" thing is really "don't mix CLI and PDM (Pix Device Manager)" - there were some known problems with interop. I've never had a problem with an ASA being managed via ASDM and CLI *except* once when we had two people trying to make changes to the same firewall at the same time (one using ASDM, the other, CLI). Locked the thing right up.
|
|
#
?
Mar 10, 2014 18:54
|
|
|
Powercrazy posted:Because after an ASDM conversion, the CLI becomes unusable garbage, well more so. You mean it's not standard practice to name all of your rules with the prefix DM_INLINE?
|
|
#
?
Mar 10, 2014 18:54
|
|
|
BelDin posted:You mean it's not standard practice to name all of your rules with the prefix DM_INLINE? Speaking of which...curious to see what everyone uses for object names. We've standardized on a format along the lines of code:
|
|
#
?
Mar 10, 2014 19:48
|
|
|
I always use all caps in any variable name, and generally prefix it with what its function is. 'class-map CM-FOO' for example. Easier to decipher stuff, at least for me.
|
|
#
?
Mar 10, 2014 23:08
|
|
|
falz posted:I always use all caps in any variable name Hello, old friend.
|
|
#
?
Mar 11, 2014 00:01
|
|
|
falz posted:I always use all caps in any variable name, and generally prefix it with what its function is. 'class-map CM-FOO' for example. Easier to decipher stuff, at least for me. Similar. I prefer descriptive obj grp names as opposed to subnets/ports. It makes it easier to read the access-list entries.
|
|
#
?
Mar 11, 2014 00:19
|
|
|
falz posted:I always use all caps in any variable name, and generally prefix it with what its function is. 'class-map CM-FOO' for example. Easier to decipher stuff, at least for me. I really need to get into this habit. I find myself using lowercase for everything and it's so much easier to see user configured poo poo when I do it in all caps.
|
|
#
?
Mar 11, 2014 00:59
|
|
|
Tremblay posted:Similar. I prefer descriptive obj grp names as opposed to subnets/ports. It makes it easier to read the access-list entries. I agree with you on the object-group names, as there really isn't a good way to represent non-contiguous address space or multiple ports in an object name. However, for regular network object names, I prefer the subnet/mask format as it's generally known when troubleshooting. Then again...my company manages over a hundred ASAs, so standardization is super important. There's nothing more frustrating than trying to comb through NAT/ACLs and then have to match it up against a 'sh run object in-line'.
|
|
#
?
Mar 11, 2014 16:51
|
|
|
Richard Noggin posted:I agree with you on the object-group names, as there really isn't a good way to represent non-contiguous address space or multiple ports in an object name. However, for regular network object names, I prefer the subnet/mask format as it's generally known when troubleshooting. Then again...my company manages over a hundred ASAs, so standardization is super important. There's nothing more frustrating than trying to comb through NAT/ACLs and then have to match it up against a 'sh run object in-line'. Sure, depends on purpose. I'll use descriptive naming when pooling applications, things like that.
|
|
#
?
Mar 11, 2014 18:19
|
|
|
abigserve posted:In other firewall news a coworker in another state came into the team meeting to let us know one of the Palo Alto's shat itself again and they are sending a replacement. They haven't proved the most reliable of boxes but the usability has probably still offset the time spend debugging and fixing the problems. Is it a 4000 series?
|
|
#
?
Mar 12, 2014 20:40
|
|
|
Anyone know of some "pro reads" for MAN/WAN design? Or is it basically do it yourself and leverage vendor knowledge?
|
|
#
?
Mar 13, 2014 19:09
|
|
|
doomisland posted:Anyone know of some "pro reads" for MAN/WAN design? Or is it basically do it yourself and leverage vendor knowledge? https://learningnetwork.cisco.com/docs/DOC-2457 Look at the very bottom of this: http://www.cisco.com/c/en/us/solutions/enterprise/validated-design-program/networking_solutions_products_genericcontent0900aecd80601e22.html Understand when to use this: http://blog.ine.com/2008/12/23/dmvpn-phase-3/ and also realize that MAN design is MUCH different than WAN, because otherwise you can't set realistic expectations.
|
|
#
?
Mar 14, 2014 00:19
|
|
|
Powercrazy posted:and also realize that MAN design is MUCH different than WAN, because otherwise you can't set realistic expectations. I don't manage networks quite the size of some of you, but I still have a 60 branch network with offices across my state.
|
|
#
?
Mar 14, 2014 00:29
|
|
|
adorai posted:The main difference, from my perspective, is that your cannot leverage qos on the provider network. Otherwise, it's just a layer two wan. If you have a known CIR you can leverage QoS by policing what you send into the providers network. Obviously they could still fail to deliver CIR and cause problems, but that should be an exceptional circumstance and not the norm. Your provider may also offer QoS within their network for a fee.
|
|
#
?
Mar 14, 2014 00:50
|
|
|
ragzilla posted:If you have a known CIR you can leverage QoS by policing what you send into the providers network. Obviously they could still fail to deliver CIR and cause problems, but that should be an exceptional circumstance and not the norm. Your provider may also offer QoS within their network for a fee.
|
|
#
?
Mar 14, 2014 02:26
|
|
|
adorai posted:I am curious what exactly is so different about MAN design vs WAN design. The main difference, from my perspective, is that your cannot leverage qos on the provider network. Otherwise, it's just a layer two wan. The main difference is that a MAN is typically a low latency, high-bandwidth connection between datacenters, or main offices, etc. It used to be a protected SONET ring, but these day's it'll be a metro-ethernet something or other. While a WAN is considered low-bandwidth or "slow," those same expectations don't hold for MAN. In short, pinging from LA to NYC over your IPSec+GRE WAN is one thing, pinging from your NY Datacenter to your NJ Datacenter over a flat layer 2 network is completely different.
|
|
#
?
Mar 14, 2014 15:02
|
|
|
A simple question: What was I looking at yesterday? My knowledge of highend Cisco hardware ends at the handful of ASA's and 3750G's I manage. Anyways, I visited a friends colo DC and hiding in the back corner was a new build out. Inside two 48u racks were the largest Cisco routers I have ever seen, taking up the entire 48u rack. My friend blabbered something out about 9000 series chassis while we stood in awe. The best part, there was a single card in each of these monsters with a single green fiber running to the mdf in the basement... 100Gb's claimed my friend. Guess who owned it? Haha.
|
|
#
?
Mar 14, 2014 19:14
|
|
|
ASR 9922? That's the only full cab ASR9K unless its two ASR9912s on top of each other? I think just recently you could convert two 9912's into a single 9922 but I'm mostly a Juniper guy so someone may have to correct me. Also it's a shame they only have a single 100g, wheres the redundancy?
|
|
#
?
Mar 14, 2014 19:29
|
|
|
We call it the megatron, it's an ASR9922. If you saw a linecard with 1 or 2 ports chances are it was a 100gb linecard. We have a lot of them deployed in our DC's, here's some pics. You can see the 2x100Gb linecards in the lower part of each chassis
Sepist fucked around with this message at 19:37 on Mar 14, 2014 |
|
#
?
Mar 14, 2014 19:31
|
|
|
Sepist posted:We call it the megatron, it's an ASR9922. If you saw a linecard with 1 or 2 ports chances are it was a 100gb linecard. We have a lot of them deployed in our DC's, here's some pics. You can see the 2x100Gb linecards in the lower part of each chassis What do you use to label, assuming you guys are labeling that there fiber?
|
|
#
?
Mar 14, 2014 19:44
|
|
|
It looks like the same P-Touch we use to label all the other SM fiber, I don't work with the group who ran it so I'm not sure.
|
|
#
?
Mar 14, 2014 19:54
|
|
|
Sepist posted:We call it the megatron, it's an ASR9922. If you saw a linecard with 1 or 2 ports chances are it was a 100gb linecard. We have a lot of them deployed in our DC's, here's some pics. You can see the 2x100Gb linecards in the lower part of each chassis I have nothing to add besides holy poo poo, dat router 
|
|
#
?
Mar 14, 2014 20:46
|
|
|
Sepist posted:We call it the megatron, it's an ASR9922. If you saw a linecard with 1 or 2 ports chances are it was a 100gb linecard. We have a lot of them deployed in our DC's, here's some pics. You can see the 2x100Gb linecards in the lower part of each chassis That's it! They were bloody huge. A popular social media company owned these. I'm sure the two were linked, we just did not notice it.
|
|
#
?
Mar 14, 2014 20:49
|
|
|
What's amazing to me is that's not even the most expensive thing Cisco sells, the ASR 5500 and line cards are more costly (and I work with one of these  ) - Ours, with all the linecards is about 5 million dollars and it's not even full. I'm pretty sure it's the most expensive thing you can buy from them.
Sepist fucked around with this message at 21:23 on Mar 14, 2014 |
|
#
?
Mar 14, 2014 21:21
|
|
|
Sepist posted:What's amazing to me is that's not even the most expensive thing Cisco sells, the ASR 5500 and line cards are more costly (and I work with one of these ASR5500 is fairly specialized. If talking general packet forwarding- checked the pricing on CRS-3? List price on the 16 slot LCC in a multi shelf system is 1.5M, plus another 2M for every 8 pack of fabric cards (each fabric shelf accepts a maximum of 24 cards). Docjowles posted:I have nothing to add besides holy poo poo, dat router And if you want to go really big you can do 2 of them connected together in an nV Edge cluster where both chassis act as one monster chassis. Or even bigger you can go look at CRS-3 multi chassis systems, where you can have up to 8 16 slot line card chassis in a system in the docs (some presentations refer to configurations up to 72 LC chassis). I'm sure we'll see something similar for ASR9k in the future when metro-e providers are pushing the limits on 2 chassis 9922 systems. ragzilla fucked around with this message at 00:45 on Mar 15, 2014 |
|
#
?
Mar 15, 2014 00:35
|
|
|
Anyone here take the Nexus exams? Thinking about just going that path on nexus switching since new jerb is going with 7k's and 5k's. Just don't want to study for an exam that is a sales pitch like the (old)UCS one was...
|
|
#
?
Mar 15, 2014 02:52
|
|
|
|
| # ? May 28, 2024 06:52 |
|
|
I was offered access in to our local fiber exchange today and I'm pissed because I doubt my boss is going to go for it. We're starting to push/pull a large amount of data to/from Google/EC2 (TB's) and Comcast quoted $2300/m for a 100/100 EDI line over existing dark fiber. The local exchange is ~8 blocks from our office and has a peer link to Google and Amazon (along with Netflix, local schools/hospitals/datacenters. I was able to borrow a port thanks to a friend who's company manages it and it got the data there nearly two weeks quicker then we could have. Here's how the cost broke down: 1/3rd cabinet $400/m in the DC 100MB Internet Carrier 1 $200/m + $15 copper fee 1GB burst (100MB normal) Internet Carrier 2 $600/m + $15 copper fee 1GB Fiber link to local fiber exchange- $100/m Dark fiber to office $unknown- checking on Juniper MX5 $15k (NOS friends company ordered spare for a project that did not happen.) Apparently I would have to act ASAP due to IPV4 addresses running out. To even get a block, I have to have two ISP's and be running BGP. The upside here is I would end up with portable addresses and I could ditch our existing cable internet for both offices. It all comes down to how much Comcast is going to want to rape me for 8 blocks of fiber. (I wish it was that simple- I don't believe they have a direct line back to this DC, I'll find out more next week.) Worst case, I toss a small server in the 1/3rd cabinet with a USB3 card and do it from there. I ran a speed test on the 1GB's link they let me borrow- solid 920/980Mbps on my laptop. I can dream, right? 
|
|
#
?
Mar 15, 2014 03:17
|
|