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)

«‹›2 »

atticus: Nov 7, 2002; this is how u post~

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?

Ideally I'd like to buy a poo poo ton of equipment (right now I have a 2924xl, 2610xm, 1231ga that I have my home network setup with) and just setup random different networks. Would also like to find some kind of Cisco forum where people ask for help and I could try to help/research/figure out real problems. Anyone know of such a forum or have any other suggestions?

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

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 06:52

atticus: Nov 7, 2002; this is how u post~

Sorry for the double post but I am sad I missed the beginnings of this thread.

# ¿ May 29, 2007 19:02

atticus: Nov 7, 2002; this is how u post~

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:

SW1#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     [b]10.0.0.0/24 is subnetted, 5 subnets[/b]
C       10.1.3.0 is directly connected, Loopback2
C       10.1.2.0 is directly connected, Loopback1
C       10.1.1.0 is directly connected, Loopback0
C       10.1.5.0 is directly connected, Loopback4
C       10.1.4.0 is directly connected, Loopback3

What I NEVER understood was this line:

code:

10.0.0.0/24 is subnetted, 5 subnets

It just never made sense to me. To me, 10.0.0.0/24 always meant 10.0.0.0 - 10.0.0.255! So from that point of view, how can you get 10.1.1.0 out of a 10.0.0.0/24 subnet?!? Furthermore, if I change the mask on each of the loopbacks to a /32 - I get this for "show ip route" :

code:

SW1#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     [b]10.0.0.0/32 is subnetted, 5 subnets[/b]
C       10.1.2.1 is directly connected, Loopback1
C       10.1.3.1 is directly connected, Loopback2
C       10.1.1.1 is directly connected, Loopback0
C       10.1.4.1 is directly connected, Loopback3
C       10.1.5.1 is directly connected, Loopback4

Now you can clearly see how even further I get confused, using my logic: how can you possibly "subnet" a /32?!? Can you guys shed some light as to WHY Cisco does this? I sure would appreciate it.

Thanks

atticus fucked around with this message at 15:53 on May 30, 2007

# ¿ May 30, 2007 15:49

atticus: Nov 7, 2002; this is how u post~

jwh, as always, is welcome to have my cisco babies.

# ¿ May 30, 2007 16:13

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

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.

Gliffy diagram:

PIX config
Right switch config

I didn't publish the other switch's config as it's pretty similar to the above.

The two IP Office switches and the VM Server are the only devices on vlan101. I can communicate between vlan101 hosts just fine, but I can't get any traffic from one vlan to the other. Both can get out to the internet just fine, as long as I'm using external DNS servers for my vlan101 hosts since they can't use mine

So, what am I doing wrong here? Is it a security issue?

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:

interface GigabitEthernet0/1
 switchport mode trunk
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 101

Do that on both sides.

atticus fucked around with this message at 17:20 on Jul 5, 2007

# ¿ Jul 5, 2007 17:10

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

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.

Does that still point to trunking issues? I'd assume I'd have much bigger issues if there was something wrong with the trunk between the two catalysts.

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: Nov 7, 2002; this is how u post~

atticus posted:

is the native VLAN the same on both sides of the trunk?

Haha I called it

try this on both sides:

code:

interface GigabitEthernet0/1
 switchport trunk native vlan 1

# ¿ Jul 5, 2007 17:42

atticus: Nov 7, 2002; this is how u post~

Mierdaan posted:

Hey buddy, last time I read that post it said "bogus post"!

Let me give that a try...

Yeah sorry about that, I edited it a few minutes ago :v:

# ¿ Jul 5, 2007 17:46

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

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:

interface Ethernet1
nameif inside
security-level 100
ip address 192.168.62.233 255.255.255.0
!
interface Ethernet1.1
vlan 2
nameif v2
security-level 90
ip address 192.168.60.25 255.255.255.0
interface Ethernet1.2
vlan 3
nameif v3
security-level 80
ip address 192.168.61.25 255.255.255.0

I dunno how much that will help. :/

atticus fucked around with this message at 18:27 on Jul 5, 2007

# ¿ Jul 5, 2007 18:15

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

jwh posted:

How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space?

Wouldn't clients on the inside network just arp for 10.10.7.x hosts? Is the pix doing proxy-arp?

Yeah that also caught my eye... technically they should both be /24's shouldn't they?

# ¿ Jul 5, 2007 20:20

atticus: Nov 7, 2002; this is how u post~

Arkady posted:

I'm experiencing the strangest problem...

...Router A is not really a router and we don't really care about it at the moment....

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.
What is even more strange is that if I change the IP of the interfaces between Router A and B to 172.30.x.x it works just fine, sending updates to both interfaces.
All of the above is leading me to believe it has something to do with the class of the networks

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:

network 192.168.4.0

on both sides, it will happily work. See for yourself.

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

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

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. :smith:

# ¿ Jul 14, 2007 15:24

atticus: Nov 7, 2002; this is how u post~

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:

2w2d: %SYS-5-CONFIG_I: Configured from console by console
RouterA#
RouterA#
2w2d: RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet1/0/1 (192.168.4.25)
2w2d: RIP: build flash update entries
2w2d:   192.168.4.24/30 via 0.0.0.0, metric 1, tag 0
2w2d: RIP: Update contains 1 routes
2w2d: RIP: Update queued
2w2d: RIP: Update sent via GigabitEthernet1/0/1
2w2d: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet1/0/1 (192.168.4.25)
2w2d: RIP: build update entries
2w2d:   192.168.4.24/30 via 0.0.0.0, metric 1, tag 0
2w2d: RIP: Update contains 1 routes
2w2d: RIP: Update queued
2w2d: RIP: Update sent via GigabitEthernet1/0/1

On router B, this results in RIP adding the associated interface to it's database:

code:

2w2d: RIP: add GigabitEthernet1/0/1 to RIP idb list

Now, Router B is receiving RIP updates from Router A:

code:

2w2d: RIP: received v2 update from 192.168.4.25 on GigabitEthernet1/0/1
2w2d:      192.168.4.24/30 via 0.0.0.0 in 1 hops
2w2d: RIP: Update contains 1 routes

Now look what happens when we change the subnet mask on Router A to a /30:

code:

2w2d: RIP: sending request on GigabitEthernet1/0/1 to 224.0.0.9
2w2d: rip_route_adjust for GigabitEthernet1/0/1 coming up
2w2d: RIP: sending request on GigabitEthernet1/0/1 to 224.0.0.9
2w2d: RIP: received v2 update from 192.168.4.25 on GigabitEthernet1/0/1
2w2d:      192.168.4.24/30 via 0.0.0.0 in 1 hops
2w2d: RIP: Update contains 1 routes
2w2d: RIP: received v2 update from 192.168.4.25 on GigabitEthernet1/0/1
2w2d:      192.168.4.24/30 via 0.0.0.0 in 1 hops
2w2d: RIP: Update contains 1 routes
2w2d: %SYS-5-CONFIG_I: Configured from console by console
2w2d: RIP: received v2 update from 192.168.4.25 on GigabitEthernet1/0/1
2w2d:      192.168.4.24/30 via 0.0.0.0 in 1 hops
2w2d: RIP: Update contains 1 routes
2w2d: RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet1/0/2 (10.31.13.1)
2w2d: RIP: build flash update entries
2w2d:   192.168.0.0/16 via 0.0.0.0, metric 16, tag 0
2w2d:   192.168.4.0/24 via 0.0.0.0, metric 1, tag 0
2w2d: RIP: Update contains 2 routes
2w2d: RIP: Update queued
2w2d: RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet1/0/1 (192.168.4.26)
2w2d: RIP: build flash update entries
2w2d:   192.168.0.0/16 via 0.0.0.0, metric 16, tag 0
2w2d:   192.168.4.24/30 via 0.0.0.0, metric 1, tag 0
2w2d: RIP: Update contains 2 routes
2w2d: RIP: Update queued
2w2d: RIP: Update sent via GigabitEthernet1/0/2
2w2d: RIP: Update sent via GigabitEthernet1/0/1

Now Router B is sending and receiving updates on both interfaces. When we change the mask on the interface back to a /16, we see the same "route adjust message" :

code:

2w2d: rip_route_adjust for GigabitEthernet1/0/1 coming up

Ok. Let's look at the RIP database on router B.

code:

RouterB#show ip rip database
10.0.0.0/8    auto-summary
10.31.13.0/24    directly connected, GigabitEthernet1/0/2
192.168.0.0/16    redistributed
    [0] via 0.0.0.0,
192.168.4.0/24    auto-summary
192.168.4.24/30
    [1] via 192.168.4.25, 00:00:16, GigabitEthernet1/0/1

Now let's look at the RIP database on Router A.

code:

RouterA#show ip rip database
192.168.4.0/24    auto-summary
192.168.4.24/30    directly connected, GigabitEthernet1/0/1

Before we go and change the mask again, let's try to force Router A and Router B to become neighbors.

code:

RouterB(config)#router rip
RouterB(config-router)#neighbor 192.168.4.25
RouterB(config-router)#end

RouterA(config)#router rip
RouterA(config-router)#neighbor 192.168.4.26
RouterA(config-router)#end

Now we see Router A both sending updates to 224.0.0.9 (multicast address reserved for RIP updates) and 192.168.4.26:

code:

2w2d: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet1/0/1 (192.168.4.25)
2w2d: RIP: build update entries - suppressing null update
2w2d: RIP: sending v2 update to 192.168.4.26 via GigabitEthernet1/0/1 (192.168.4.25)
2w2d: RIP: build update entries - suppressing null update
2w2d: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet1/0/1 (192.168.4.25)
2w2d: RIP: build update entries - suppressing null update
2w2d: RIP: sending v2 update to 192.168.4.26 via GigabitEthernet1/0/1 (192.168.4.25)
2w2d: RIP: build update entries - suppressing null update

Let's look at what's happening on Router B. Interesting. It looks like Router B is still not advertising anything out of that interface, yet the neighbor is still configured.

code:

RouterB#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 12 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Neighbor(s):
    192.168.4.25
  Default version control: send version 2, receive version 2
    Interface                 Send  Recv  Triggered RIP  Key-chain
    GigabitEthernet1/0/1      2     2
    GigabitEthernet1/0/2      2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
    192.168.4.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.4.25         120      00:08:34
  Distance: (default is 120)

code:

2w2d: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet1/0/2 (10.31.13.1)
2w2d: RIP: build update entries
2w2d:   192.168.0.0/16 via 0.0.0.0, metric 1, tag 0
2w2d: RIP: Update contains 1 routes
2w2d: RIP: Update queued
2w2d: RIP: Update sent via GigabitEthernet1/0/2
2w2d: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet1/0/2 (10.31.13.1)
2w2d: RIP: build update entries
2w2d:   192.168.0.0/16 via 0.0.0.0, metric 1, tag 0
2w2d: RIP: Update contains 1 routes
2w2d: RIP: Update queued
2w2d: RIP: Update sent via GigabitEthernet1/0/2

So! Let's go ahead and remove the neighbor statements since they don't seem to be doing any good whatsoever, and see what happens when we fix the mask on Router B. Once the mask is fixed I'll clear out the route table...

code:

RouterB#clear ip route *
RouterB#
2w2d: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet1/0/1 (192.168.4.26)
2w2d: RIP: build update entries
2w2d:   10.31.13.0/24 via 0.0.0.0, metric 1, tag 0
2w2d:   192.168.4.24/30 via 0.0.0.0, metric 1, tag 0
2w2d: RIP: Update contains 2 routes
2w2d: RIP: Update queued
2w2d: RIP: Update sent via GigabitEthernet1/0/1
2w2d: RIP: sending request on GigabitEthernet1/0/1 to 224.0.0.9
2w2d: rip_route_adjust for GigabitEthernet1/0/1 coming up
2w2d: RIP: sending request on GigabitEthernet1/0/1 to 224.0.0.9
2w2d: RIP: sending request on GigabitEthernet1/0/2 to 224.0.0.9
2w2d: rip_route_adjust for GigabitEthernet1/0/2 coming up
2w2d: RIP: sending request on GigabitEthernet1/0/2 to 224.0.0.9
2w2d: RIP: remove GigabitEthernet1/0/1 from RIP idb list
2w2d: RIP: remove GigabitEthernet1/0/2 from RIP idb list
2w2d: RIP: add GigabitEthernet1/0/2 to RIP idb list
2w2d: RIP: sending request on GigabitEthernet1/0/2 to 224.0.0.9
2w2d: RIP: add GigabitEthernet1/0/1 to RIP idb list
2w2d: RIP: sending request on GigabitEthernet1/0/1 to 224.0.0.9
2w2d: RIP: received v2 update from 192.168.4.25 on GigabitEthernet1/0/1
2w2d:      192.168.4.24/30 via 0.0.0.0 in 1 hops
2w2d: RIP: Update contains 1 routes
2w2d: RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet1/0/2 (10.31.13.1)
2w2d: RIP: build flash update entries
2w2d:   192.168.4.24/30 via 0.0.0.0, metric 1, tag 0
2w2d: RIP: Update contains 1 routes
2w2d: RIP: Update queued
2w2d: RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet1/0/1 (192.168.4.26)
2w2d: RIP: build flash update entries
2w2d:   10.31.13.0/24 via 0.0.0.0, metric 1, tag 0
2w2d:   192.168.4.24/30 via 0.0.0.0, metric 1, tag 0
2w2d: RIP: Update contains 2 routes
2w2d: RIP: Update queued
2w2d: RIP: Update sent via GigabitEthernet1/0/2
2w2d: RIP: Update sent via GigabitEthernet1/0/1
2w2d: RIP: received v2 update from 192.168.4.25 on GigabitEthernet1/0/1
2w2d:      192.168.4.24/30 via 0.0.0.0 in 1 hops
2w2d: RIP: Update contains 1 routes

Ta Daa! So now RIP's all like "HEY WOW LOOK AT WHAT I HAVE" and is happily sending updates out of both interfaces. Let's look at the database:

code:

RouterB#show ip rip database
10.0.0.0/8    auto-summary
10.31.13.0/24    directly connected, GigabitEthernet1/0/2
192.168.4.0/24    auto-summary
192.168.4.24/30    directly connected, GigabitEthernet1/0/1

That looks different than when we looked at it before. Here's both before and after:

code:

RouterB#show ip rip database
10.0.0.0/8    auto-summary
10.31.13.0/24    directly connected, GigabitEthernet1/0/2
192.168.0.0/16    redistributed
    [0] via 0.0.0.0,
192.168.4.0/24    auto-summary
192.168.4.24/30
    [1] via 192.168.4.25, 00:00:16, GigabitEthernet1/0/1

code:

RouterB#show ip rip database
10.0.0.0/8    auto-summary
10.31.13.0/24    directly connected, GigabitEthernet1/0/2
192.168.4.0/24    auto-summary
192.168.4.24/30    directly connected, GigabitEthernet1/0/1

Because one end of the link is a /30 and the other end is a /16 - the FIB sees the /16 but the address on the other interface is just too long for the mask. Even if you wanted to add a static route on Router A towards Router B maintaining your addressing scheme, you won't be able to:

code:

RouterA(config)#ip route 192.168.4.26 255.255.0.0 gi1/0/1
%Inconsistent address and mask

So let's change the interface on Router B back to a /16 and change the interface on router A to a /16, change the RIP network statements accordingly and clear the routing table on both sides and see what happens.

Router B is still not sending updates on the interface:

code:

RouterB#
2w2d: RIP: sending request on GigabitEthernet1/0/2 to 224.0.0.9
2w2d: rip_route_adjust for GigabitEthernet1/0/2 coming up
2w2d: RIP: sending request on GigabitEthernet1/0/2 to 224.0.0.9
2w2d: RIP: remove GigabitEthernet1/0/2 from RIP idb list
2w2d: RIP: add GigabitEthernet1/0/2 to RIP idb list
2w2d: RIP: sending request on GigabitEthernet1/0/2 to 224.0.0.9
2w2d: RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet1/0/2 (10.31.13.1)
2w2d: RIP: build flash update entries - suppressing null update

Neither is Router A

code:

RouterA#
RouterA#
RouterA#
RouterA#
RouterA#
RouterA#show debug
IP routing:
  RIP protocol debugging is on
  RIP event debugging is on
RouterA#
RouterA#
RouterA#
RouterA#clear ip route *
RouterA#
RouterA#
RouterA#show run | b r rip
router rip
 version 2
 network 192.168.0.0
 no auto-summary

Router A might as well not be running RIP, because the network statement on both sides breaks the classful rules of configuring the network statements.

I guess in conclusion, you're pretty much hosed unless you change the addressing.

# ¿ Jul 16, 2007 17:40

atticus: Nov 7, 2002; this is how u post~

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. :smith:

# ¿ Jul 16, 2007 19:55

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

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? :confused:

I'm almost positive that he's correct, as only switches in VTP server mode can modify VLAN information. Wikipedia confirms...

From wikipedia:

quote:

VTP operates in one of three modes: server, client and transparent.

* Server � In this VTP mode you can create, remove, and modify VLANs. You can also set other configuration options like the VTP version and also turn on/off VTP pruning for the entire VTP domain. VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize their VLAN configuration with other switches based on messages received over trunk links. VTP server is the default mode.

* Client � VTP clients behave the same way as VTP servers, but you cannot create, change, or delete VLANs

* Transparent � When you set the VTP mode to transparent, then the switches do not participate in VTP. A VTP transparent switch will not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received messages. However, in VTP version 2, transparent switches do forward VTP messages that they receive out their trunk ports.

# ¿ Jul 22, 2007 20:43

atticus: Nov 7, 2002; this is how u post~

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. :argh:

# ¿ Jul 25, 2007 17:53

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

para posted:

This may be a question for its own thread, but what kind of admin tools do you guys prefer?

I haven't really gotten into the IOS yet (I'm new to networking in general), but when I do it might be helpful to know what kinds of tools are the most efficient and feature rich. Do you just use the terminal and use telnet/ssh, or do you use something a little more specific to the task.

For analyzing network traffic I've read of the NetFlow protocol and a program called Scrutinizer, but I've been told that it only logs traffic through the router in one direction (I've forgotten if he said it was either in or out) and it seems rather pointless to not have both if you are looking at network utilization.

Also telnet and ssh don't seem to let me redirect std input into them so I can't send a bunch of prewritten commands to the router. If I want to run a bunch of prewritten commands on a router and perhaps capture the output (equivalent to '# cat input.txt | ssh admin@router > output.txt' if ssh would let me do that) what would be the choice method of doing it?

I hope this question wasn't too long for this thread. Thanks.

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

atticus: Nov 7, 2002; this is how u post~

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:

dynamips -H 127.0.0.1:7200

And that works as expected.

code:

# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 127.0.0.1:7200              0.0.0.0:*                   LISTEN
tcp        0      0 127.0.0.2:7200              0.0.0.0:*                   LISTEN

There's always a catch though. Using that syntax, Dynamips will happily force the binding of 7200 to localhost, but what if you want to run more than one Dynamips instance? No dice. Dynamips won't allow this:

code:

# dynamips -H 127.0.0.1:7201

For reasons unknown to me.

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:

box# ifconfig lo:1 127.0.0.2 netmask 255.0.0.0
box# ifconfig lo:2 127.0.0.3 netmask 255.0.0.0
box# ifconfig lo:3 127.0.0.4 netmask 255.0.0.0

Step Two:

Invoke dynamips on all of the loopbacks

code:

dynamips -H 127.0.0.1:7200
dynamips -H 127.0.0.2:7200
dynamips -H 127.0.0.3:7200
dynamips -H 127.0.0.4:7200

Then, you want to modify your .net file so that instead of referencing "localhost" you reference the loopback IP addresses, like so:

code:

# router params for instance 1
[127.0.0.1]

[[7200]]
   image = /root/IOS/uncompressed/c7200-adventerprisek9-mz.124-11.T2.extracted.bin
   npe = npe-400
   slot1 = PA-8E
   slot2 = PA-8T

blah blah blah

# router params for instance 2
[127.0.0.2]
udp = 11000

[[7200]]
   image = /root/IOS/uncompressed/c7200-adventerprisek9-mz.124-11.T2.extracted.bin
   npe = npe-400
   slot1 = PA-8E
   slot2 = PA-8T

blah blah blah blah

Works like a charm.

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

atticus: Nov 7, 2002; this is how u post~

Can you clarify what this means?

InferiorWang posted:

I'm under the understanding that without using BGP and creating an AS, email and other internet services would go to poo poo, but I'd like to be able to maintain web traffic without having to go reconfigure anything manually in the event of a failure

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

atticus: Nov 7, 2002; this is how u post~

FatCow posted:

code:
#show platform hardware pfc mode
PFC operating mode : PFC3A
Is it possible to shut the DFCs down so the PFC can run at full speed?

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

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

Smegmatron posted:

Close: VWIC2-1MFT-G703 - 1-Port RJ-48 Multiflex Trunk - T1/E1 & G.703

Not an option, unfortuantely.

Why would you advise against doing this? I would think that as long as metrics and whatnot are set to appropriately report one link's quality/speed versus the other, it would work itself out.

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

atticus: Nov 7, 2002; this is how u post~

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. :smith:

Does anyone have any that they can move, or should I start trolling ebay?

# ¿ Jul 10, 2008 18:28

atticus: Nov 7, 2002; this is how u post~

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.

6500 and 7600 were the same until Cisco decided that they should be different- which is to say, someone finally realized that competing against yourself because you tried to woo the carrier market on a semantic difference, didn't make a lot of sense. At least, that's my take on it.

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

atticus: Nov 7, 2002; this is how u post~

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.

bpduguard probably can be useful when you want to really prevent (and punish) users plugging in nonallowed switches, but I've never had any problems with just running spanning-tree portfast. A switching loop would cause some broadcast bursts for a few seconds, but I've never seen that cause anything serious.

I'll ask the other side if they run bpduguard, just to get the issue explained, and if they can just take it off. Sure, it works fine as it is, but I can imagine what will happen next time when someone needs to move it to another port or something

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

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

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 priority

code:

show switch detail

If it's set to one, change it to something higher, say 15

code:

switch 1 priority 15

You need a reload for this to take effect.

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

atticus: Nov 7, 2002; this is how u post~

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

atticus: Nov 7, 2002; this is how u post~

Tab8715 posted:

How much is everyone making? From what I've read entry/newbie CCNA'rs are making ~50k/y.

This just seems way too good to be true for several months of studying, or am I wrong?

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

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 06:52

atticus: Nov 7, 2002; this is how u post~

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

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

«‹›2 »