|
karttoon posted:Ok so I have my CCNA, making good progress on my CCNP but do not work at all with Cisco gear. I don't even do networking for that matter. So what I want to know is, while I'm on the hunt for a networking job (hopefully at where I currently work) what would you guys recommend as the best way to 'practice' to keep the skills and knowledge relatively fresh in my head? You've probably got a slightly better chance at moving up to a neteng position at your current job than leaving your position and trying to get one of those with just a CCNP and no hands-on experience with production equipment. groupstudy.com has a lot of CCIE's that are studying for their lab exam - if you want ideas/scenarios to blow your mind, that's probably a decent place to start.
|
# ¿ May 29, 2007 19:01 |
|
|
# ¿ Apr 26, 2024 04:37 |
|
Sorry for the double post but I am sad I missed the beginnings of this thread.
|
# ¿ May 29, 2007 19:02 |
|
I've got a question. Here's a short disclaimer: I recently completed my CCNP, and I should really be punched in the face for not understanding this by now. Now that that's out the way, here's the question: So this has ALWAYS confused me, and I can't seem to find a clear answer on my own. I have a 3750 here, which I've added 5 loopbacks to: int lo0 ip address 10.1.1.1 255.255.255.0 int lo1 ip address 10.1.2.1 255.255.255.0 int lo2 ip address 10.1.3.1 255.255.255.0 int lo3 ip address 10.1.4.1 255.255.255.0 int lo4 ip address 10.1.5.1 255.255.255.0 Each with a /24 mask. Here's the output of "show ip route" code:
code:
code:
Thanks atticus fucked around with this message at 15:53 on May 30, 2007 |
# ¿ May 30, 2007 15:49 |
|
jwh, as always, is welcome to have my cisco babies.
|
# ¿ May 30, 2007 16:13 |
|
M@ posted:I recently purchased 3 WS-X6704-10GE blades. While trying to install the WS-F6700-DFC3B daughter boards I noticed the heatsinks on the boards were too tall to allow the board to sit right on the standoffs. Has anyone ever had/heard of an issue like this? I know for a fact that daughter board works with that blade! Why not just save yourself the hassle and order the 6704 with the daughterboard pre-installed?
|
# ¿ Jul 4, 2007 10:42 |
|
Mierdaan posted:I'm having a bit of trouble getting intra-vlan routing working. Cisco devices in question are a PIX 515 functioning as a router-on-a-stick, and two Catalyst 2950s. You need to define the allowed VLANs on the trunk. edit: wait, what? So the problem is that "you can't get any traffic from one vlan to the other" - I thought the only VLAN you were concerned about was VLAN101...? Care to clarify a bit more? For defining allowed vlans: code:
atticus fucked around with this message at 17:20 on Jul 5, 2007 |
# ¿ Jul 5, 2007 17:10 |
|
Herv posted:I am under the impression that all vlans are allowed across a trunked switchport unless explicitly pruned or enumerated. At least this is my experience on all COS/IOS switches. Yeah actually you're right... From reading his post that says "getting traffic from one VLAN to the other" I'm not sure what he means. In any case I don't think 2950's can do MLS, and I don't think a PIX can either. Someone correct me if I'm wrong please because my experience with PIX/ASA is very very very limited. edit: doh 2950's can! atticus fucked around with this message at 17:29 on Jul 5, 2007 |
# ¿ Jul 5, 2007 17:26 |
|
Mierdaan posted:Sorry; what I mean is that I can't ping any device on vlan1 from vlan101, nor vice-versa. Communication between all vlan1 hosts is fine, and communication between all vlan101 hosts is fine, it's just communication between the two vlans that isn't working. is the native VLAN the same on both sides of the trunk? atticus fucked around with this message at 17:36 on Jul 5, 2007 |
# ¿ Jul 5, 2007 17:27 |
|
atticus posted:is the native VLAN the same on both sides of the trunk? Haha I called it try this on both sides: code:
|
# ¿ Jul 5, 2007 17:42 |
|
Mierdaan posted:Hey buddy, last time I read that post it said "bogus post"! Yeah sorry about that, I edited it a few minutes ago
|
# ¿ Jul 5, 2007 17:46 |
|
Looking at this further I don't think that's going to work. What I can see is that all you're doing is allowing multiple VLANs across a trunk, but they still won't be able to talk to each other without layer 3 functionality. As I mentioned before, I suck at PIX/ASA stuff, so if possible try to take the PIX out of the picture and enable ip routing globally on both of the 2950s. Or try to set up a couple static routes on the PIX maybe?
|
# ¿ Jul 5, 2007 18:02 |
|
In typical router-on-a-stick setups used for inter-vlan routing, subinterfaces have to be configured on the router's physical ethernet interfaces, with .1q trunking and IP addresses enabled on the subifs. From digging around online on PIX configs for inter-vlan routing I noticed somewhat of a similar setup, however I'm not sure if the PIX supports .1q trunking: code:
atticus fucked around with this message at 18:27 on Jul 5, 2007 |
# ¿ Jul 5, 2007 18:15 |
|
dwarftosser posted:The PIX is not a router. It will only forward traffic through it or deny traffic. It is impossible to redirect traffic out of a pix on the same port it comes in on. PIX support RIP and static routes but that's about it. While it doesn't have as much layer 3 functionality as your typical router, it can in fact route.
|
# ¿ Jul 5, 2007 19:41 |
|
jwh posted:How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space? Yeah that also caught my eye... technically they should both be /24's shouldn't they?
|
# ¿ Jul 5, 2007 20:20 |
|
Arkady posted:I'm experiencing the strangest problem... Then what is it? Are you running routed, gated, quagga on some server if it's not a router? Are they configured properly? Arkady posted:The problem is that Router B is not sending RIP updates towards Router A. It is configured with RIP v2, classless, zubnet zero and with no split horizon. Why why why oh why Arkady posted:I have checked the "show ip protocols" and the 192.168.0.0 network is recognised by RIP. It is also there in the "show ip route" as a locally connected network. Not the class. RIPv2 is classless. First of all you need to fix the subnet masks on the 192.168.x.x network. Secondly split horizon is still turned on from looking at your config. Thirdly you need to use major network addresses in your network statements. If you fix both ends of the link to /30's and add the network with code:
edit for clarity: It doesn't even have to be /30's on both sides. You could do /8's or /24's on both sides, but they have to match. Even if you tried to use static routes, your traffic is just getting black holed. If you do a show ip route on router A, you won't see 192.168.0.0/16 as a directly connected network, because your /30 you have on the other side is encompassed in that. atticus fucked around with this message at 19:27 on Jul 12, 2007 |
# ¿ Jul 12, 2007 19:15 |
|
jwh posted:192.168/16 is classful /24 space, so your third octet needs to play ball with what's configured on the interface. RIPv2 is classless, but it's configuration isn't. The reason your 10/8 and 172.16/16 attempts worked, is because they were accidentally the correct classful mask. Ah thanks jwh - this is exactly what i was trying so hard to figure out how to say. Again, you're awesome.
|
# ¿ Jul 12, 2007 21:54 |
|
jwh posted:So in other words, it looks to me like IOS uses the RIP network statement along classful boundaries. Even though your interface is technically 'covered' by the larger supernet of 192.168.0.0/16, IOS is considering 192.168.0.0 classfully, which would match the 192.168.0 portion of the network, because 192.168 is part of class C or /24 classful address space. Yep you're exactly right - I wasn't even sure how RIP was allowing him to add a "network 192.168.0.0" as that breaks the class boundary rules for the network statements required of RIP, but I tried it on a 3750, and sure enough it worked, so I got a little confused myself. RIP does suck.
|
# ¿ Jul 14, 2007 15:24 |
|
I've done some testing in my own lab. Two 3750's so keep in mind that ports are going to be gigabit ethernet, that should be the only difference here. I've also turned off RIP's auto-summarization so it didn't advertise the major 10.0.0.0 automatically to prevent that route from being possibly aged out of the routing table when we change stuff around. I've also disabled split horizon on the interfaces, even though that won't help anything, but just for similarity's sake. Here's what I've been able to verify so far (stuff that we already knew): RIP will not send updates with a non-classful network statement. On Routers A and B it needs to be changed from "network 192.168.0.0" to "network 192.168.4.0" On Router A, this immediately begins to trigger RIP updates out of the interface that's connected to router B: code:
code:
code:
code:
code:
code:
code:
code:
code:
code:
code:
code:
code:
code:
code:
code:
Router B is still not sending updates on the interface: code:
code:
I guess in conclusion, you're pretty much hosed unless you change the addressing.
|
# ¿ Jul 16, 2007 17:40 |
|
Nice work Jeff. It makes sense now that I look at it... RouterB now has an exact route in its FIB to send data to that network. I think I was putting my static route in the wrong place.
|
# ¿ Jul 16, 2007 19:55 |
|
GodofLint posted:One of the big messy parts of this is that we are using fully public IPs and there is no way in hell I will be able to change that in to a fully NATed environment at this point. IPs are in the 111.x.x.x/255.248.0.0 range, with each building typically getting 1 to 3 111.x.x.0 DHCP assigned IP blocks to work with depending on the size, along with a static range for weird crap that needs it. Those would obviously change to IPs assigned to the main building once the DHCP traffic is routed through the VPN. Jesus christ what a big lovely mess
|
# ¿ Jul 17, 2007 19:31 |
|
Jeff73 posted:one of the chapters asserted three times (including in the quiz) that a newly-added switch in VTP client mode can't overwrite vlans in the domain regardless of its config revision number. annnnnd how is that incorrect? I'm almost positive that he's correct, as only switches in VTP server mode can modify VLAN information. Wikipedia confirms... From wikipedia: quote:
|
# ¿ Jul 22, 2007 20:43 |
|
landoverbaptist posted:Great news my boss said I can have that 2620 for free if I promise to try for a CCNA this year! hooray That must be nice. I get to work 60 hours next week pushing racks around. God I hate my job.
|
# ¿ Jul 25, 2007 17:53 |
|
jwh posted:Is MPLS on the CCNP now? If so, what do they ask you to know? Yes, the new CCNP exam (ISCW - replaced the BCRAN) now covers frame-mode MPLS. Exam blueprint here. As far as I know though, MPLS is still much more heavy in the CCIP certification track; there's still an entire exam dedicated to it.
|
# ¿ Dec 25, 2007 06:13 |
|
karttoon posted:Is there any particular reason "sh int status" just comes up blank? Using IOS (tm) C2600 Software (C2600-JK9S-M), Version 12.3(21), RELEASE SOFTWARE (fc2) on a 2610XM router. "sh int status" only works on switch platforms, use "sh ip int bri" instead. atticus fucked around with this message at 04:03 on Dec 30, 2007 |
# ¿ Dec 30, 2007 03:56 |
|
karttoon posted:I use sh int status on our routers at work all day. Also, sh ip int bri doesn't include duplex/speed/port type which is what I want. 'sh int <int> status' returns a blank line too. I've just tried it on at least 3 of our production routers (2800s) and I get the same results. I tried it on two 6509's and two 3750 stacks and it works fine. What's the platform that you're having success on at work?
|
# ¿ Dec 30, 2007 06:44 |
|
para posted:This may be a question for its own thread, but what kind of admin tools do you guys prefer? What do you mean when you say "send pre-written commands to the router"? If you're looking for something interactive, I know that people have had good luck with Expect scripts, however you should just be able to paste a bunch of commands from notepad into your console or ssh session, and IOS should interpret them sequentially...
|
# ¿ Jan 8, 2008 17:51 |
|
Hey everyone! Thought I'd give this a bump with a question and probably a little shameless plug. So I've got an extra large EC2 instance (that's 15GB of RAM, and 4 dual-core 2GHz CPUs) and I'm planning on using it for Dynamips/Dynagen foo. Here's an additional side-note - I found the cheapest CCIE lab rack rental place I could find. You pay $13 for 4 hours worth of rack time. Keep that number in mind. Now, if you want to use an extra large EC2 instance, you pay 80 cents an hour. So, that's $4 for 4 hours (partial hours are pro-rated). Now dynamips can't do switching, but that's still a hell of a deal compared to fighting for lab time that fits into your schedule. I'm a Network Engineer for Amazon, so I get the "internal pricing plan" for EC2 - but if anyone's interested in learning about how to use EC2 for your dynamips foo, please shoot me a PM and we'll chat. Now, on to my question. I'm building an AMI for EC2 that has everything I need to use dynamips and dynagen, only I'm attempting to lock down the build so it's a little more secure. By default, when you invoke dynamips under Linux, you say "dynamips -H 7200 &" What I've found is that what this does is basically open that TCP port to the entire world. So, I think "ok we'll just tell dynamips to bind the port to the loopback address so the outside world can't connect to that port and only people that are actually on the box will be able to." No problem right? So I try: code:
code:
code:
So what's the workaround if you want to run multiple instances of Dynamips securely? Create multiple aliases to your loopback interface on your linux box and just tell Dynamips to run on all of them on port 7200, rather than running all the instances on the same loopback on different port numbers. See below (Sorry Windows folks, this won't work for you): Step One: Make an alias (or multiple aliases) of your Loopback interface on your linux box and give it another IP address. code:
Invoke dynamips on all of the loopbacks code:
code:
There's still another problem though, and I'm looking for a little help here. When I invoke dynagen on a lab, the routers all start up, and the console ports start up as expected on port 2000, incrementing. However, we run into the same problem as before, where port 2000 isn't just open to localhost and localhost only, but rather open to the entire world. This obviously isn't something I want. Any linux experts know of a way to "work around" this like I did with the localhost IP foo? If not, then my only two options are going to have to be to build some iptables stuff (not something I want to do) or bother the author of Dynamips to build some functionality into the application to allow for more security for stuff like this (also not something I'd want to do). Any ideas guys? EDIT: After trolling through the manpage for dynamips, I realized that it allows you to specify the console port on the command line, so the function I'm looking for is actually within Dynagen's realm, since it's essentially just a frontend for Dynamips written in Python. I suck at programming so I'm not even going to try to see if I can figure out what's going on under the hood, but I've posted a similar question in the hacki.at forums, and maybe I'll get somewhere by poking at the author of Dynagen. atticus fucked around with this message at 20:32 on Apr 23, 2008 |
# ¿ Apr 23, 2008 19:13 |
|
Can you clarify what this means?InferiorWang posted:
Is this a general statement, or a statement that applies to your architecture? You can get away with this without using BGP at all...
|
# ¿ May 21, 2008 21:56 |
|
FatCow posted:
shutting down DFC's isn't something you really want to do. what's CEF looking like on the box? Also what does show mls cef summary show mls cef maximum-routes say atticus fucked around with this message at 19:26 on Jun 24, 2008 |
# ¿ Jun 24, 2008 19:13 |
|
ior posted:Running without DFC´s works just fine, 90% of my customers are running CFC mode with no ill effects, just keep in mind that you loose out on local switching and is therefore limited by the 40Gbps/slot backplane. Sure, running without DFC's works, but it depends on the function. If you're pushing a fuckton of multicast like we do, the amount of replication required can eat a CFC alive. CFC's "work" but if you have DFCs, why disable them? That's like spending the money on a decent monitor but only running it at 800x600.
|
# ¿ Jun 25, 2008 00:43 |
|
Smegmatron posted:Close: VWIC2-1MFT-G703 - 1-Port RJ-48 Multiflex Trunk - T1/E1 & G.703 Is the MPLS circuit from an upstream provider or is it something you've set up to a branch office or the like? If you want to do an IPSec tunnel that ought to be fine and you should be able to do some per-destination load balancing as long as the MPLS connection and the IPSec tunnel are going to the same place, and as long as you control that place, and not an upstream provider. If it is an upstream provider, then I wouldn't waste my time trying to load balance. Also I'm looking at buying some switches. Does anyone have any that they want to unload? Thinking about at least 3; 4 optimally.
|
# ¿ Jul 7, 2008 05:54 |
|
Am I missing something? I was under the impression that the 7600 and the C6K were practically the same box... Anyway, I haven't heard any replies to my switch request. Does anyone have any that they can move, or should I start trolling ebay?
|
# ¿ Jul 10, 2008 18:28 |
|
jwh posted:What sort of switches, and did you ask M@ what he's got around? He's sort of the unofficial go-to used market guy around here I guess. I could shoot him a PM but thought I saw him post in this thread pretty regularly, so I figured he might jump on it earlier. Doesn't matter what kind, something low-end and cheap, 2950s or slightly better. Just need them for a CCIP/CCIE lab - I'll use Dynamips for everything else. Thanks for the clarification on the platforms. We're pretty C6K heavy but started putting 7609's on our edge in places. Maybe I just stuck on old knowledge but was under the impression (until now anyway ) that they were architecturally identical. Oh well. Times change I guess.
|
# ¿ Jul 10, 2008 19:01 |
|
ionn posted:Oh, sorry, those two statements (spanning-tree bpdufilter enable, spanning-tree link-type point-to-point) where what was on the switch after the issue was "resolved" (as in "working, though I'm not really sure why"). Those are the only two lines changed from before when it was not working. Bridging loops don't just cause broadcast bursts for a few seconds. They'll peg the CPU's of the affected devices and render them unusable as long as the devices are connected. The ARP tables in CAM will get flooded with repeating entries (on different ports) and become unstable. I've seen a bridging loop bring down an entire corporate office. IIRC, if you configure PortFast on an interface, BPDUGuard is configured on it automatically as well, but if for whatever reason you want to disable BPDUguard, that's where you'll run into problems. As jwh said, bpdufilter keeps the switch from sending or receiving BPDUs on that particular port, so that's probably the bit that made it start working, but I'm not sure why "link-type point-to-point" was configured as this is only pertinent to RPVST+, and they only have PVST+ configured. The spanning tree link type of point-to-point is also set automatically because it's based on the duplex of the port, so the logic of setting that manually is completely beyond me. EDIT: jwh posted:Well, when you connected a router or PC to the 2960, was it also in vlan 1? I say this because out of the box, Cisco will set 'no spanning-tree vlan 1'. Are you sure about that? From my experience, PVST is enabled on all switches by default - I'm not aware of Cisco having spanning tree turned off on a switch out of the box... EDIT2: So, from what I'm getting, those were the settings that you configured on your end to make it work? Then yeah, they may be running BPDUguard on their end. If you set bpdufilter on the interface, then yeah, it should've come up... atticus fucked around with this message at 01:04 on Jul 18, 2008 |
# ¿ Jul 18, 2008 00:39 |
|
Girdle Wax posted:But with portfast while the port is initially in the forwarding state, if it receives any BPDUS it will immediately switch to blocking/learning- thus breaking the forwarding loop very quickly. While portfast and bpduguard go hand in hand bpduguard is not automatically turned on on every portfast port unless you turn on the "spanning-tree portfast bpduguard default" config knob. Granted, but there's still a chance that the bridging loop could cause an issue in the network to the point where the port transitioning back to a blocking/listening state wouldn't be able to fix things, yeah?
|
# ¿ Jul 18, 2008 01:08 |
|
Girdle Wax posted:Only if there were dormant loop undetected in the network that causes it to continue storming, generally once the loop that caused the issue is broken the traffic can only make 1 more pass around the network. Sure, ARP entries can time out, but you'll also be in a lovely state of affairs if that switch you connect up to a PortFast-enabled port is now the shiny new root bridge in the spanning tree topology... Also assuming here that the layer 2 topology is flat and there's no other VLANs.
|
# ¿ Jul 18, 2008 01:40 |
|
I think the default priority for most stackable switches out of the box is 1. The higher the switch priority, the more likely it is to become the master. Check your existing switch prioritycode:
code:
On your new switch, make sure the priority is lower than 15 (same command as above) and yes, make sure they're running the same version of code. After that, you should just be able to hook them up (loop-style - stack port 1 on switch 1 to stack port 2 on switch 2, stack port 1 on switch 2 to stack port 2 on switch 1) and power on the second switch.
|
# ¿ Jul 28, 2008 18:38 |
|
Paul Boz_ posted:I've got a CCNP for the "real world" stuff. Don't take this the wrong way, but I thought a CCNP was for the "real world" stuff too. It's not. Don't get me wrong, I think certifications serve their purpose, but I don't really agree with your expectations after obtaining them.
|
# ¿ Aug 3, 2008 02:19 |
|
Tab8715 posted:How much is everyone making? From what I've read entry/newbie CCNA'rs are making ~50k/y. Yes, it's too good to be true. If you don't have a college degree and just have a CCNA and zero experience, don't expect to make more than 40k a year (and that's being generous).
|
# ¿ Aug 15, 2008 07:02 |
|
|
# ¿ Apr 26, 2024 04:37 |
|
Powercrazy posted:But apparently its easier to simulate routers then it is to simulate switches. All Dynamips does is emulate a CPU that's capable of understanding the IOS image. The "core" in most routers is just a CPU and some DRAM. Only recently have companies (thinking of Cisco here, not sure if Juniper does this or not, but IIRC they don't really deal with routers, but more just modular switching platforms that can do routing) been starting to stick stuff like port ASICs in routers to get better performance out of them. If you look at the various port adapters that Dynamips does support, the selection is somewhat limited, again because it has to do with loading code that supports/emulates the chipsets used on those port adapters. I loaded up a couple 7200's each with the single GigE port adapter and connected them up and attempted to ping across the links. The throughput was god-awful. Even with low-end stuff like serial or regular 10Mb Ethernet, the throughput isn't that great but it's good enough to get routing protocols to converge and use debugs and the like. With a switch you have (again) things like port ASICs, TCAM, various buses (in modular hardware), fabric-enabled modules, non-fabric enabled, etc. This would be pretty hard to emulate. quote:Then CCNP in like 3 months. Woohoo getting paid to cert is awesome. Good luck with that... atticus fucked around with this message at 06:51 on Aug 16, 2008 |
# ¿ Aug 16, 2008 05:56 |