The Cisco Short Questions Thread v12.4.9(WTF)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cisco Short Questions Thread v12.4.9(WTF)

«‹›3 »

BelDin: Jan 29, 2001

jwh posted:

Take me with you! I'm very friendly and I don't need much food.

Well, there are a few ways to run multiple clients behind a single access port, but it's messy- if I remember correctly, any one of the attached devices can put the port into an authenticated state, at which time the other devices will be allowed onto the network as well- although it's hard to see how that's an acceptable solution in most cases. A combination of devices with supplicants and without supplicants sharing the same access port is another tricky issue, and we have that scenario in spades, thanks to little printers without supplicants.

Well, it's a tough sell when you think about how expensive it is to retrofit an environment with enough "smart" access ports to do 802.1x correctly when you've been getting by for years with an ever-multiplying colony of NetGear switches. The capital cost is very high for more wiring closet switches, for instance. And that's without considering inside wiring and whatever else is necessary. The real scare is in the OpEx, which I can't even begin to model correctly.

Is there any reason that you couldn't use these for NAC at the desktop?

http://www.cisco.com/en/US/products/ps9974/index.html

It looks like they support 802.1q trunking and 802.1x authentication as well as SNMP traps.

# ¿ Apr 1, 2010 01:33

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 19:29

BelDin: Jan 29, 2001

R1CH posted:

Anyone have any ideas on how to make the DHCP server on my 871W respond faster? I tried reducing ip dhcp ping packets and timeout to really low values. Whenever I plug in a network cable, Windows sits at Acquiring IP address for so long it actually times out and assigns an automatic private IP, then the DHCP IP is assigned about 5 second later. I'm guessing the DHCP server is waiting for an authoritative DHCP server to respond first, is there any way I can tell it that it's the authoritative server?

You have portfast turned on the ports? If you don't it will take about 30 seconds for your link to come up.

Edit: Curses!!

# ¿ Jul 22, 2010 01:01

BelDin: Jan 29, 2001

R1CH posted:

I'm assuming portfast was off by default, I turned it on which should hopefully fix it given the description of how it operates. Figures I was looking in completely the wrong place, I had no idea this was even happening . Thanks.

One of us three should be right.

# ¿ Jul 22, 2010 02:45

BelDin: Jan 29, 2001

CrazyLittle posted:

Set your side to 100 full, and try, etc etc etc. Also, try calling your ISP and get them to work with you while you try to fix the duplex mismatch.

Can you get any information with a show cdp neighbors detail?

# ¿ Sep 8, 2010 04:08

BelDin: Jan 29, 2001

Martytoof posted:

A vague question: Is there any cheap way to pick up any ASA experience? Does PIX IOS carry over at all? 5505s are scarce on eBay, and 5510s are running more than a grand.

One of those things I'd really like to look into, but the cost to get some actual hands on time looks to be way out there.

Packetlife has a community lab with a couple of 5505s hooked to it. Other than that, GNS3 can emulate an ASA at about 70% functionality at the moment.

http://www.brainbump.net/2010/03/gns3-how-to-emulate-asa-in-windows-7/

# ¿ Sep 9, 2010 02:19

BelDin: Jan 29, 2001

I've been trying to wrap my head around HSRP, and had a question that is probably simpler than I can describe it.

I have two layer 3 switches set as distribution switches with etherchannel links going back to a core layer 3 switch. All switches are running EIGRP, and they have separate IP addresses running back to the core for redundancy. They also have links between each other for HSRP and redundant links to the access switches under them.

If I am running HSRP and one of the two are the active, that will prevent the standby switch from sending EIGRP advertisements back to the core, correct? I'm trying to determine if traffic will come back in the standby switch due to equal EIGRP route costs, as they would both have them in the routing tables.

# ¿ Sep 15, 2010 21:02

BelDin: Jan 29, 2001

Powercrazy posted:

Is this what your HSRP setup looks like?

In any case EIGRP won't be affected by HSRP/VRRP as they serve a different purpose.

That is my (Cisco's) design to a T.

My concern is that with equal cost routing, and EIGRP enabled on both switches with active IPs on the same network (including the floating gateway IP), that some of the return traffic from the core will go through the standby switch rather than the active switch.

I guess the better question is, with any dynamic routing protocol (I use EIGRP) should I tweak the metric to force prevention of asymmetric routing or should I not worry about it? I know I'll be getting extra packets on the network if I ignore it, but how bad will it be after the CAM tables get populated on both switches?

I've never really had to worry about large scale performance, but we're doing a network expansion from about 500 PCs to possibly 2000 over the next year. This concern primarily from a performance/HA standpoint, but I'm sure I'm missing something else that will impact usability.

Off to read Casimirius' link now.

# ¿ Sep 15, 2010 22:43

BelDin: Jan 29, 2001

Tremblay posted:

You guys might want to look at going to routed edge/access layer.

Casimirus: I'm planning on using 3560-x pairs for the distribution switches, so GLBP is out unless we upgrade later. With the 6509E running as the core (we will pair as needed later) we are going with redundant power supplies, SUP32s, and line cards. Our problem now is getting the rack space to put the thing, and getting another 220 outlet installed this week. I've done most of this already, and some of it in GNS3, but real world input always makes me more comfortable.

My biggest concern is downtime due to IOS upgrades, maintenance, etc. Cabling for core to distribution will all be new, the links from the distribution to the access switches will be existing cat5e runs and campus fiber. The big concern there will be single points of failure due to a single line going from a remote switch over fiber to an intermediate switch that breaks it into two links before hitting the distribution switches. Otherwise, the asymmetric routes will possibly crap out the traffic to the distribution switch not hooked up to the access switch. Dual fiber links to all access switches is another long term project on the horizon.

Did I mention I'm a manager so I don't know anything about computers? :P

Tremblay: I am planning on pushing that over the next few years with 3750s in the server room, but it's been baby steps for this company. I'm the InfoSec Manager and lead security tech lead where we work, and was able to get upgrades over the last year for the 20+ 5+ year old access switches they had (EOL, no IOS upgrades = security issue) to 2960s.

When I got there everything was running a mess of cabling and all default VLANs hardwired to mesh separate networks through switches. It's been an accomplishment so far just to get proper VLANs (no VTP yet... if ever), trunks (manually pruned), and RSTP+ working over the campus with our existing network guy. I have a feeling now that our budget has been planned for our Cyber Security program over the next 5 year contract I will be migrating back to IT and take over the lead for the network administration.

Ever seen a closet full of cables patched through two separate banks of 66 and 110 punch down blocks using only two pair each? That was a night of heavy drinking!

Now, do I get some leeway for asking this stuff since I've went the CCSP track, still need to take my ICND2, and got my ASA 5520s running active/standby (for VPN) with AIP-SSMs working yesterday afternoon? (I know, amateur

)

Edit: Atroshus speling!

BelDin fucked around with this message at 04:02 on Sep 16, 2010

# ¿ Sep 16, 2010 03:13

BelDin: Jan 29, 2001

jwh posted:

You won't be getting extra packets, just packets delivered asymmetrically to the distribution layer. It is what it is, so to speak. If it doesn't bother you / isn't problematic, it'll be fine. If anything, it's a better use of your existing paths, albeit one that is slightly more complex.

My concern with that was the unicast flooding issues that people were having requiring tweaks to ARP timeouts / MAC aging timing and getting them closer to each other.

# ¿ Sep 16, 2010 03:18

BelDin: Jan 29, 2001

CrackTsunami posted:

I'm struggling to visualize your topology for some reason but from what I can understand, no. Traffic will load balance across both of them on the return trip. HSRP doesn't affect routing protocols and this is a dangerous thing to watch. STP complicates this a bit more because you may get circumstances where all traffic is going to one of your distribution switches and then immediately switched to another distribution switch or even not at all and just getting dropped.

A lot of people do testing based on failover times but don't think about what happens when the master comes back up. HSRP is light, it loads very quickly but routing protocols don't. So HSRP fails back but the routing protocol is still loading, traffic gets black holed. It's not a major concern where it's end users but in the DC it can be an absolute killer waiting for 45 seconds for EIGRP/OSPF to get it's poo poo together. HSRP has some timers that can be used to stop the old master from preempting itself until x amount of time has passed which prevents this.

Here's a rough draft of what I'm looking at for design. The NAC equipment will be in-band virtual gateway, so it will be used as the gateway address for certain VLANs only to pass the traffic to the distribution switches.

http://www.conkel.net/download/Network-Overview.png

All of our servers will be locally contained in a distribution block and talking on the local subnet, so we should be fine from that respect. That, and redundant links from our VMHosts to the distribution switches that are always on.

# ¿ Sep 16, 2010 16:49

BelDin: Jan 29, 2001

Powercrazy posted:

Looks good, but I would definitely recommend that you have redundant cores rather than just one chassis.

Also if/when you do expand to double cores make sure you run additional connection from each distribution switch.

I also assume that each vlan lives on the distribution layer and so EIGRP will know where each network lives and it has a default route pointing to the HSRP address of your edge gateways.

Again, budget constraints forced me to choose between two 4500 series or one 6500 series with budget to buy a second next fiscal year. Sucks to be the manager, then you're held accountable for your budget.

Our current network passes all of our subnets through a PIX firewall for local traffic at the moment, so this is a radical change for our site. It will go to a redundant core design, and then I will have to worry about making sure that a core failure doesn't pull a dist. level switch into the core role, but that's further down the line. I have a plan put together that treats a layer 3 switch as a gateway between the old and new networks allowing them to all talk to each other during migration.

Yep, at the distribution level all switches have all VLANs local to that block. All non-local routes will default out our ASAs at the edge. I wanted to keep edge expansion options open for the future redundant internet access and BGP (our site has a block of legacy ARIN numbers we can use).

# ¿ Sep 16, 2010 20:23

BelDin: Jan 29, 2001

Bardlebee posted:

because this experience will be a catalyst in my career.

In that case, you need a switch or two as well! :rimshot:

On a more serious note, what kind of connection do the other sites have? You can get ASA5505s with the base license for a few hundred dollars, and those would even let you dial back to your central location.

You get a CLI on just about every piece of network gear from Cisco, but you also get the ASDM. I'm a cli guy myself, but the gui makes access rule editing so much easier on firewalls it's not funny.

# ¿ Oct 14, 2010 03:23

BelDin: Jan 29, 2001

CrazyLittle posted:

The ASA line is the successor to the PIX line of firewall/security boxes. They all have CLI.

There's two things that you have to remember:
1) They don't run IOS, no matter how similar it looks.
2) PIX/ASA is not a router. They don't "route" traffic.

Sure they are! Don't you see the area where you can configure EIGRP and OSPF? All we need to do is insert 30 NAT exemption rules and make all the interfaces have the same security level!

Swear to god, that's what was running on the network at my current work location when I got here. Still working on finishing the migration to, you know, Layer 3 switches and routers now.

# ¿ Oct 14, 2010 16:30

BelDin: Jan 29, 2001

I'm currently running into a roadblock, and just want to double check before I have to move everything over an evening.

I have a PIX (running 8.0ish) with three legacy internal networks attached, a DMZ, and an external network connection. All of the legacy internal networks can talk to each other and the DMZ through NAT exemption rules, and it is using PAT for the external connection.

I have a new network established that I am migrating to, and:
- Set a port on the new network's L3 switch with a host IP address on one of the legacy internal networks.
- Added the route for the new networks on a legacy network interface of the PIX.
- Made sure that there were static routes on the new network L3 switch to the legacy interface on the old network, redistributed throughout the new network with EIGRP.
- Made sure there were NAT exemption rules for the new network address block on the interfaces of the legacy PIX.
- Allowed intra- and inter-interface communications on the legacy PIX.

I am trying to allow the migration of one network at a time from the old system to the new network while maintaining connectivity with new networks as well.

The problem that I am running in to is that traffic from the two internal networks that require traffic to flow THROUGH interfaces on the PIX work perfectly.

The PIX interface network that is used to cross link the new and old network does not allow traffic to any of the new networks. Traffic is getting from the new networks to hosts on the legacy network, and they are going out to the local default gateway, only to die there instead of getting routed back to the new network.

Disclaimer: At this point, before you explain to me that PIX are not routers, please understand that I realize this and fully agree with you.

I thought that a static identity NAT on the legacy network interface may make it work, but all it did was hose the chicken stick shaking voodoo magic that the predecessor put in the PIX. I know that hairpinning for non VPN was allowed post 7.2 or so, and thought that I did everything that was required. Oh, and no ACL hits on the traffic to use as a guide.

I'm at a loss other than to take the spare interface on the PIX and convert it to a /30 private network range for the network link so that all traffic must travel through the PIX interface. What ticks me off the most is that packet tracer says that it should work, and pings DO work while normal TCP traffic does not.

Wow... that was kind of ranty.

# ¿ Oct 21, 2010 23:08

BelDin: Jan 29, 2001

Tremblay posted:

I'm confused. The internal interface on the PIX is connected to a router or an L3 switch that has connections to legacy and the new network? I'm reading this like it does, but then that doesn't make sense if you are trying to uturn. Can you post the relevant sections of the PIX config?

Not until Monday when I'm at work.

Here's a simplified, sanitized diagram to give an idea:

The PIX has one of three interfaces connected to a VLAN that has a L3 switch with a valid IP on that network, and I'm trying to route all the traffic for the other old networks directly connected to the PIX through the .253 IP in question back to the new network.

Right now, according to the diagram above, everything works from the DMZ and Local Area Network back to the New Local Area Network, but traffic from the New Local Area Network destined for the Management Network gets back to the Firewall as the default gateway, and never gets sent back to the L3 switch.

The Management Network has the route to the New Local Area Network on the firewall.

# ¿ Oct 24, 2010 01:07

BelDin: Jan 29, 2001

Tremblay posted:

Not to be a dink, but if management network hangs off that L3 switch why route up to the FW only to route back down? I'm sure there is a good reason, but I like to ask the dumb questions.

Not a dumb question, and if you add a static route on the management network hosts to the new network it works just fine. I'm just being lazy and trying to avoid adding persistent static routes to a couple hundred computers and servers only to remove them once the network is migrated.

Powercrazy posted:

I assume its some kind of Firewall on a Stick topology, otherwise how else would you enforce the firewall rules between segments?

The person here before me decided that using a PIX as a router was easier than using access lists on a router to do our internal network access control. This involved NAT exemptions for every local network, and access lists allowing all traffic between all local networks except the DMZ.

# ¿ Oct 25, 2010 15:27

BelDin: Jan 29, 2001

Tremblay posted:

Physically on a stick but logically separated makes sense (vlan subints). Otherwise this isn't really a great idea...

My predecessor not only didn't use VLANS )all switches were using VLAN 1), but put each network on an interface all it's own. That's why I'm migrating it to a more traditional 3 layer design.

As a side note, I now know what the problem above is, I just need to figure out the best way to fix it. Turns out, even with the NAT exemption, the traffic from the management network to the new LAN was getting to the outside NAT pool. I'm thinking of adding a policy NAT to only pick up the traffic in question and Uturn it, I'm nervous due to the 500+ people this would cut off to our servers while it is ocurring.

I think I'm just going to bite the bullet, take a weekend outage hit, and move all the networks to the new L3 switch. I'll just have to recreate the SNATs for the DMZ and internal hosts. I should be able to advance prep everything else.

We should start a thread with all the horrendous poo poo that we've all inherited over the years!

# ¿ Oct 26, 2010 04:24

BelDin: Jan 29, 2001

Martytoof posted:

I'd rather use EIGRP than RIP, for example

Back in my day, we only had UUCP and bangpaths for e-mail! :corsair:

Dynamic routing protocols? We just use static routes for everything! :corsair:

I have actually heard both these in the last two years. EIGRP being rolled out is voodoo magic as far as they are concerned.

# ¿ Oct 28, 2010 01:44

BelDin: Jan 29, 2001

Bardlebee posted:

Does the CCNA even cover OSPF? That is my main fear. I have the ICND1, but if the ICND2 doesn't cover something that you need to know for employment. Then.... its kinda silly.

Yep, it covers the basics like single area OSPF. The big thing to know is that it is a link state protocol and not distance-vector like EIGRP, the base metric is cost and not bandwidth/delay, and the steps it uses to build the tables (LSAs and LSDBs using Djikstra).

You may get into some basic troubleshooting, but nothing multi-area IIRC.

# ¿ Oct 28, 2010 01:54

BelDin: Jan 29, 2001

Cavepimp posted:

Uh oh...maybe I'm rustier than I thought.

Not necessarily, but they do come in handy for rapid convergence and the use of redundant infrastructure protocols such as HSRP and GLBP. Again, shake that voodoo stick and explain that using L3 switches with routed interfaces (no switchport)does not introduce loops in your network at L2.

The last time a switch went down on our network edge due to a DSL line problem, the IT manager kept harping about spanning tree and how it was causing issues in the network. He then went on blaming the recently implemented VLANs (rather than everything running on VLAN 1 with separate switches and lines) and trunks between switches (Running PVST+) causing network instability.

They were physically moving lines between switches in network closets. These lines use two pair of a CAT5 cable going to 110 blocks that are cross linked to the infrastructure lines at the work cubes.

Remember kids, you only need four wires for Ethernet! :corsair:

# ¿ Oct 28, 2010 02:07

BelDin: Jan 29, 2001

ragzilla posted:

If static routing is good enough for the PSTN, it's good enough for my network

Fair enough, but then again, you don't typically get a helpdesk guy promoted to sole network administrator/engineer in a PSTN. (at least not without serious skills)

It's bad enough that our 600 client LAN is expected to scale 4x over a large campus in three months.

# ¿ Oct 28, 2010 02:11

BelDin: Jan 29, 2001

FatCow posted:

NPAC would like to talk to you.

LERG for IP would be awesome.

*Makes route update*
*Waits 3 months for the effective date*
*network becomes unreachable as only 1/2 the other networks load the update*

I can imagine it now...

*helpdesk call*

:supaburn:

:Why can't I get to icanhazcheezburger? I NEED to get there for business purposes!

:corsair:

: Because the NSFNet got taken down by a backhoe and BGP, rear end, and ASNs haven't been invented yet?

# ¿ Oct 28, 2010 02:24

BelDin: Jan 29, 2001

inignot posted:

Sometimes I wonder how people like that scammed their way into a paycheck.

Work as a government contractor, such as myself. You'll be amazed at the level of incompetence across the board.

# ¿ Oct 28, 2010 16:01

BelDin: Jan 29, 2001

Tremblay posted:

Annnnd how! Also "IA professionals".

I cringe every time I have to refer to myself as "Cyber Security" for that very reason. I've gone from helpdesk, applications administrator, systems administrator, and network administrator over my career. Don't lump me in with the IA grad that can write policies, watch logs, and not much else.

The best INFOSEC guys I have worked with over time have been the ones that had technical jobs before treating security as a specialization, not a degree program.

# ¿ Oct 28, 2010 16:39

BelDin: Jan 29, 2001

inignot posted:

I've done mostly federal work for the past seven years, and yes, it's full of fools. Actually I think any large organization tends to be dominated by fools. Anyway, it still boggles my mind that the kind of goofball that would think you can make a network run faster by changing the bandwidth statement on an interface once sat in an interview and was judged the most competent man for the job.

And I concur that IA people are laughable. One of the more recent eye rollingly bizarre IA edicts is that using vlan 1 for anything is bad. Because one is an easily guessed number. Of course, the switches they are moaning about are in data centers with no end users attached. So I suppose they are concerned attackers will remotely send crafted dot1q headers over the internet (in IA world layer 2 headers somehow persist across layer 3) ...and then something bad happens. Cripes, based on default behavior on Cisco switches, vlan 1 is never tagged anyway.

I'm considering pursuing the ISSEP just to spite them. Or I may just start asking for CERT or Mitre advisory numbers on these alleged issues to see if I can force them to admit it's all unsubstantiated. How did risk analysis become risk fabrication?

I like to think of myself as an up and coming security engineer with a management day job.

I don't like using VLAN 1 for anything because we keep it the default, not because it is the default. The primary reason that we are taught not to use VLAN 1 is misconfiguration. Some goober plugging a computer in a DTP enabled port can make for a bad day. We actually enforce access ports and set nonegotiate by default so that double tagging and VLAN hopping aren't easily possible.

Risk analysis became risk fabrication when there was money to be made in selling fear. It's been a long time now.

More on topic:

I had one of my guys get concerned once I pushed going to VLANs and trunking.

:downs:

: Be sure to turn on port security for all the switch ports to make everything more secure!

:raise:

: Even trunk lines?

:downs:

: Especially trunk lines, they are the most vulnerable because you can get on all the VLANs with them!

:eng99:

: ...

# ¿ Oct 29, 2010 03:45

BelDin: Jan 29, 2001

Martytoof posted:

I'm not calling you out, but this is almost too ridiculous to believe

This guy is not IT, he's a physical security / policy writer type who was a floor supervisor for about 20 years before moving into security (in the 90s) . He then took some MCSE classes (but hasn't passed an MCP exam) to get into the exciting field of Cyber Security. To his credit, he doesn't know much about networking and doesn't need to for his job duties.

Give him an information security topic (non computer), and he'll beat you to death with paper. That's his forte, and I keep him corraled in that area for reasons like this. Very useful against auditors.

You're right that this is the condensed version of the conversation... he didn't know what trunk lines were, so I had to explain them to him. This was the result of that talk. He asked it in more of a questioning tone. Call it artistic license, if you will.

I can't grumble too much, he's one of the two reasons why I got hired.

Enough derailing.... new Cisco short question choices:

1) Has anyone here taken the SNAF exam? How bad was it?

2) For those who use port security, what is a good aging time? We're currenly using sticky macs on most workstation ports, and all equipment moves are updated manually. My understanding is that the static entries from the stickies will not get cleared during aging and only the ports without stickies will age.

# ¿ Oct 29, 2010 06:04

BelDin: Jan 29, 2001

abigserve posted:

At my old job I believe we had the aging time said to 300 seconds (5 mins).

As for sticky mac addresses, they don't age as far as I'm aware - buuut if you don't write the config, the entries will vanish on reboot.

Out of curiosity, why do you want to enable this feature?

We have a problem where certain IT cubes that have port security on are not aging out MAC addresses properly due to desktop switches.

The recent event is that an IT worker with a workstation switch in their cube is hooked to a switch with port security (no sticky) and imaged a bunch of machines. When we went to deploy the computer (on the same infrastructure switch) it err-disabled because the MAC was still hanging on the IT worker's port. I figured we would turn it on across the board if it didn't affect sticky macs.

We use the stickies on our workstations so that people can't move computers or hook new ones up on the network. It triggers an err-diable, and we have to bring the interface back up after we bludgeon the user. We have a NAC appliance sitting in the corner to remove the need for stickies, but are so busy putting out fires that we haven't got it put in yet.

# ¿ Oct 29, 2010 15:33

BelDin: Jan 29, 2001

Tremblay posted:

I don't think aging timers work with sticky since sticky adds the mac to the config.

That's the behavior I want so that I can push it out on all public interfaces stickied or otherwise. Then we don't have to tell the fill in admins another configuration item to look for when moving people from cube to cube.

Explaining to systems administrators why we want to have small frame violation rates, broadcast and multicast storm control, etc. on workstation ports was enough of a headache to last me a lifetime.

# ¿ Oct 29, 2010 20:18

BelDin: Jan 29, 2001

nex posted:

Earlier this week I put up a RSPAN session in a switchport(trunk with 3 VLANs) for a colleague, but he tells me he sees a lot of "Duplicate ACK" packets in Wireshark.

Did some testing and the duplicate packets are gone if you put just put a SPAN directly on the switch.

So I can see why this would happen if you rspanned a VLAN where the traffic enters and exits, but in this case I just spanned the port and filtered out the relevant VLANs in the monitor session.

Has anyone seen something similar? Would this behavior be solved by just spanning RX or TX?

Don't have access to the lab on the weekend so I can't test myself right now.

Did you have the RSPAN traffic go a fourth VLAN between the switches? Weird things can happen if you don't dedicate separate VLANS to the RSPAN traffic...

# ¿ Dec 5, 2010 04:47

BelDin: Jan 29, 2001

I'm trying to wrap my head around an issue I'm having in my lab for eventual use in production. I'm trying to configure a 3 tier system using EIGRP between the core and distribution layer, HSRP on SVIs in the distribution switches, and access switches trunked with multiple identical VLANs on all of them.

The problem I am running into is spanning tree in the access layer. I would be afraid to turn it STP off in a production environment, but for the life of me I can't figure out how the asymmetric routing actually works with the HSRP. The link between 2 or more access switches and the distribution layer switches would only have one link active at any time, and this is not factored into the EIGRP routing.

I've seen the Cisco SWITCH book design and it talks about putting unique VLANs on each access switch, but I wouldn't be able to do that in production.

How do you get around the traffic to the core coming back to the distribution switch with the blocked port? Do I need to just turn on RPVST+ for all the access switches and turn the connection between the distribution switches to L2? Do I need also to weight the EIGRP delay value on the switch according to HSRP based on who has the active gateway?

Here's a diagram hinting at what I'm describing: (Each color is a VLAN, black trunks)

# ¿ Dec 10, 2010 00:07

BelDin: Jan 29, 2001

tortilla_chip posted:

If I am interpreting your diagram correctly, a frame destined for a mac address off an access switch will always have a path.

It will either flow directly from the distribution switch to the access. (Link between distribution switches has a blocked port).

Or it will flow through the port channel to the other distribution switch and then on to the access. (Link between first distribution switch and access switch has a blocked port).

Remember only one port in the triangle is actually blocking.

Kinda... I made the portchannel between the distribution switches a non routed L3 link in a misguided attempt at diverting HSRP traffic from traversing the core. I was also worried about the randomness of links leaving spanning tree to it's own devices and it's effect on convergence if I decided to reboot one of the distribution switches.

I can make it L2 and use RPVST+, but should I make one distribution switch root for all the vlan instances, or should I spread the wealth?

# ¿ Dec 10, 2010 00:53

BelDin: Jan 29, 2001

Powercrazy posted:

Just have the vlans live in the Distribution switches and have the spanning tree root switch be the HSRP primary. All ports that connect to the backup switch will be blocking. There isn't really a reason to split the VLAN load between distribution switches unless you have a need to load balance traffic flowing to the core.

You are dealing with the standard Cisco 3 Layer campus model, shouldn't be any problems honestly. Oh also note that the Access layer switches will not be running HSRP/EIGRP, only STP, so there shouldn't be any asymmetric routing issues.

My concern was using vanilla PVST+ and the time required to unblock if the primary switch were to be taken down. I've already converted the link between the distribution switches to a L2 etherchannel and manually set the spanning tree root to the distribution switch that is the HSRP primary.

My concern was the return path of traffic that went through the core from the first distribution switch that would come back by way of the second distribution switch. With the networks active on both switches with EIGRP, they would have equal metrics and asymmetry could happen there.

# ¿ Dec 11, 2010 15:37

BelDin: Jan 29, 2001

Powercrazy posted:

You can turn off EIGRP load balancing and then set the delay of the link that connects to the core higher by using the delay command on the interface level.

So if both distribution switches are connected to the core via gig1/1 and gig1/2.
code:
conf t
int gig1/2
delay 50000
Now when EIGRP looks at the paths it can take it will see the path to switch one is much better and will never take the other path.

Good to know that I had the right idea with the right metric.

# ¿ Dec 13, 2010 20:13

BelDin: Jan 29, 2001

Corvettefisher posted:

Does anyone know a cheap cisco switch anything really I'll take a 2950/2960 that supports IGMP snooping? preferably ~200 dollars? 16 ports and gigabit? Or where I can find a list of cheap switches that do support it? The netgear at work we have for WDS does not support it and the hard drive has a max R/W of 58/MB throughput and max IOPS of less than 100 I think.

If you can find a 2960, it should work. Most all switches support IGMP snooping anymore, but the feature you will need for a standalone switch is an IGMP querier unless you have an upstream router or other L3 device that can query for you. (Going by memory, so refresh me if I'm wrong.)

A 2950 probably won't work, and 2955s are made for industrial apps and are usually 10/100 from my experience.

Cisco Multicast Feature Matrix

# ¿ Jan 15, 2011 00:10

BelDin: Jan 29, 2001

jwh posted:

To clarify, I know I sound bitter, but at the end of the day, nobody is ever going to criticize your OSPF area design, or your EIGRP timers, or your BGP communities, or your spanning-tree optimizations. That's never going to happen. Nobody is going to ask you about anything you think is cool, or interesting.

No, they're going to ask you why Exchange keeps popping up a little balloon that says it's having a bad day, or why they think eight hops cross-country is too many in their expert mind, or why they think the IPS is misconfigured because they can't download hugsandkisses.pcr from some site in the Czech Republic.

Or they'll ask you about the practicality of blocking all of Azerbaijan on the firewall because you received one piece of spam from them.

Maybe I need a vacation.

Nah, you just get tired of the systems guys blame the network by default, even when their DHCP server is out of leases or plain not working.

My last one was that the Exchange server stopped getting mail, and it was blamed on the firewall and network (no pings). No changes had been made to the firewall for two weeks, and it was verified by our backup software. After getting them to get of their asses and look at the Exchange edge server, it had rebooted itself for updates and the NIC had been disabled on reboot.

It's the job I love, but it like an abusive spouse... I don't know how to leave it.

# ¿ Jan 25, 2011 03:33

BelDin: Jan 29, 2001

Bardlebee posted:

My Cisco press book just told me that OSPF uses least-cost to send information to routers. Then it gave me an example of two possible routes R4 could take to get to R3.

R4-R1-R3 cost = 111
R4-R2-R3 cost = 75

Ok, so I think it will go through R2, since that direction is the least cost to get there. Apparently Cisco press says it will go through R1 then R3 because it is the best route.

What?

You have the first printing? I have a copy of it as well. I'm assuming that you're talking about pg. 357.

Errata are wonderful things.

3rd Printing (Listed as �3rd Printing, November 2007�)
(Applies to previous printings as well)

Page 357 � paragraph below figure 9-4 � the 2 references to �R1� should instead be �R2�, because the lowest-cost route is through R2, not R1.

# ¿ Jan 29, 2011 01:56

BelDin: Jan 29, 2001

nzspambot posted:

MAC in the ARP cache will be the MAC last L3 boundary

Yes, and that MAC will be associated with the gateway IP address.

I've never seen a system that can keep IP information in it's cache for remote addresses, since all of those will use the same MAC and IP as the local gateway for the remote network (or DG).

Is this in the same CCNA book you quoted earlier, Bardlebee?

# ¿ Jan 31, 2011 22:21

BelDin: Jan 29, 2001

Bardlebee posted:

Hey guys is it possible to figure out what the DLCI is for a sub-interface using the show frame-relay lmi command? I don't see where I can figure this out...

I know show frame-relay map and show frame-relay pvc will get you what you want, but I think the only information you will get from that command other than debugging information is if the router interface is a DTE or a net-net interface.

# ¿ Feb 1, 2011 18:06

BelDin: Jan 29, 2001

Sepist posted:

That did it thanks, showed reason as Loopback so at least now I know that little switch brought down the port. Is there something I can change on that interfaces config to not bring it down due to loopback? I thought switchport access would do it but I guess not.

You can set the "errdisable recovery cause loopback", but it is switch wide. Be sure not to set your recovery timers too low if you do it.

The last time we had loopback errors, it was on a 3750g that ended up failing ASIC tests within 6 months on the two ports that had the failures.

# ¿ Feb 3, 2011 20:13

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 19:29

BelDin: Jan 29, 2001

I know this is sort of an odd question, but I figured I'd give it a shot before experimenting.

I am running a simple three layer design network, gateways on a distribution layer with hsrp, and all the other goodies like EIGRP.

I have a legacy network that has a PIX for a router, and has a non-standard gateway interface address (192.168.0.2 to a remote network 192.168.1.0/24).

The simple part: In order to move the old VLAN/subnet under the new network design, I'm going to create the configurations on the distribution switches to serve out the old gateway address (192.168.1.1) for the existing clients.

The head scratcher: Some hosts in other subnets (like 192.168.0.0) use a static persistent route on the hosts to get to the 192.168.1.0 subnet (route 192.168.1.0 gw 192.168.0.2). Can I create a secondary IP address in the same subnet to serve as the legacy gateway address?

Here's what I'm thinking:

interface VLAN 10
description interface to LAN 1
ip address 192.168.0.3 255.255.255.0
standby 1 ip 192.168.0.1
standby 1 ip 192.168.0.2 secondary

If I understand correctly, this will allow HSRP to serve up two gateway addresses on the same subnet, and all traffic will return on the primary address to the local subnet.

# ¿ Mar 18, 2011 21:34

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cisco Short Questions Thread v12.4.9(WTF)

«‹›3 »