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)

«‹›25 »

jwh: Jun 12, 2002

SuperJens posted:

I "inherited" a bunch of great Cisco equipment (two 3560's, two 3550's) through contracts that were cancelled, so what are my options for upgrading the IOS on these and getting real Cisco support? I'm guessing I have to pay for something now?

edit: Also, I have four 1600 routers but have absolutely no use for them. Are they worth anything or should I just chuck them in the dumpster?

Switch images tend to be fairly robust, compared to the router images. I wouldn't worry with upgrading unless you're missing specific features, or are running into problems. In the case of the 3560's, those are very new, and probably have a reasonably current image anyhow. They're also very nice switches. The only thing you might want to check is whether you have the Standard Multilayer Image (SMI) or Enhanced Multilayer Image (EMI). There's layer-3 stuff in the EMI that isn't in the SMI.

If you do want to get them under maintenance, you'll have to buy a smartnet contract, which is going to be more money than you'll want to spend, more than likely.

1600's aren't worth very much, sadly.

# ¿ Apr 15, 2007 07:34

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 01:10

jwh: Jun 12, 2002

InferiorWang posted:

I'm looking at a 2960G as the "backbone" for an iScsi HA cluster. What sort of configuration considerations should I have as far as VLANs go? Also, should I keep it isolated from the rest of the network, just have it connect via uplink, or have other non clustered servers on the switch as well? I'm worried about bandwidth issues on the switch.

All of the 2960G family has a 32 gbps switching fabric, while the non "G" has 16.

� 16 Gbps switching fabric (Catalyst 2960-8TC, Catalyst 2960-24TT, Catalyst 2960-24TC, Catalyst 2960-48TT, Catalyst 2960-48TC)
� 32 Gbps switching fabric (Catalyst 2960G-8TC, Catalyst 2960G-24TC, Catalyst 2960G-48TC)

Doesn't look like the 2960 family can switch layer-3, although I could be looking at it wrong.

Here's a datasheet: http://www.cisco.com/en/US/products/ps6406/products_data_sheet0900aecd80322c0c.html

Daddyo posted:

I've got a pretty new 3570 that's just decided to reboot itself on a random basis. Whats the best logging option to capture exactly whats going on so I can either a) resolve it or b) return it?

When you do a 'sh ver', what does the "System returned to ROM by" say? That's usually the first place I go, when something is rebooting, ie., power-on versus bus error. Do you have a service contract on the device?

# ¿ Apr 16, 2007 19:29

jwh: Jun 12, 2002

inignot posted:

Unfortunately Cisco has abandoned the easily understood EMI vs SMI classification and moved to a router IOS like feature classification system of IP base vs IP services vs IP security vs etc. It's substantially more confusing.

This caught me completely by surprise; I didn't even know this was coming. I knew Cisco was planning on going to license-key based feature sets (instead of specific feature-set images), maybe this is just lining themselves up to make it happen.

inignot posted:

True, but I'd suggest keeping them around for lab testing or study purposes.

I'm curious what WICs are in the 1600s- A WIC-1DSU-T1 is probably worth more than the 1600 itself.

# ¿ Apr 16, 2007 19:42

jwh: Jun 12, 2002

InferiorWang posted:

Does that mean I'm going to have issues VLANing with QoS?

If the 2960G doesn't do layer-3 switching, it means that you can't switch between VLANs on the 2960G. In other words, no inter-vlan routing (layer-3 switching) on the platform. You can carry multiple VLANs just fine, but they'll need to terminate elsewhere (ie., somewhere else you have 'int vlan5, ip address 1.2.3.4').

As for QoS, the 2960 has what appears to be pretty fancy stuff, like four hardware queues per-port, your usual policing controls, and dscp manipulation.

Like I said, I don't have a 2960 here to poke at, but it doesn't look like it's a layer-3 switch, based on the data sheet.

# ¿ Apr 16, 2007 20:46

jwh: Jun 12, 2002

I'm curious what kind of failure rates people are seeing with Cisco CF cards and ISR motherboards.

We just lost another field 1841 today to a bad 64Mb CF card, bringing our twelve-month total up to four.

And last week, we burned out two WIC-2MFT-T1's to a posessed HWIC slot in a 2811.

On the whole, our failure rates are still well below 5% of our deployed base, but I get clammy hands when thinking about how new our field routers are (130 or so ISRs), and what might be coming down the road.

# ¿ Apr 17, 2007 16:00

jwh: Jun 12, 2002

LordHop posted:

Is there any type of software emulator i can use that pretends to be a cisco box so i can start to learn how to use these things?

There's dynamips, which you can google for, except it requires you supply your own IOS image. Alternatively, there's the Boson NetSim demo.

Without an IOS image, your best bet is to buy some cheap hardware. You could also buy a 3600 series router, which can be had for about two-hundred dollars, and then steal it's IOS image for use with dynamips. You can occasionally find a real bargain on ebay.

Caged posted:

It says I need a service contact to be able to download the latest firmware for it. Where can I buy these service contracts from, and what's the part number I'm after? Cisco's CCO site is less than helpful.

You'll want to contact a Cisco reseller and ask them to quote you a smartnet contract. Not for the faint of heart.

# ¿ Apr 18, 2007 16:38

jwh: Jun 12, 2002

Girdle Wax posted:

I'm not sure you can do this as the flow records are generated on packet ingress- before translation.

Here's an interesting workaround I dug up: http://www.netup.biz/articles.php?n=10

It involves using policy routing to force traffic to a loopback interface after nat translation, and enabling netflow on the loopback.

Sounds pretty clever.

# ¿ Apr 19, 2007 16:10

jwh: Jun 12, 2002

I'm wondering if anybody has any advice for DMVPN tunnel monitoring. Because the mGRE tunnels don't ever go down/down (unless the associated physical interface goes down), it's not very practical to simply watch the tunnel interface itself.

We've been working around this problem by using syslog to report EIGRP adjacency changes, and then alerting based on this information.

Still, I'm wondering if anybody has any ideas, or if they've heard of a snmp mib for IPSec SA's.

# ¿ Apr 23, 2007 18:44

jwh: Jun 12, 2002

Girdle Wax posted:

Don't forget default-originate on the 1720 with the WAN connection (does EIGRP require an explicit default-originate or is that just OSPF?)

You can redistribute 0.0.0.0/0 into eigrp without any troubles (unlike OSPF). But that's redistribution- I'm not sure about an originate mechanism. That's a good question.

Girdle Wax posted:

I think the standard response to tunnel monitoring on the c-nsp list these days is: TCL/EEM (if you're running code that supports it).

Ugh, I was afraid of that. I'm wondering if the DMVPN usability improvements are going to do anything about this.

# ¿ Apr 24, 2007 03:24

jwh: Jun 12, 2002

Powercrazy posted:

How do I configure QoS on my Cisco network?

That's a big question. Do you need qos on your 3550? Because if you can get away with only doing it on the 817, it's going to be easier. With the switches, you have to think about hardware queues and dscp to cos maps, and which queues are priority queues, and it's just generally not a very fun experience.

Anyway, priority queueing should be fine, provided you know which ports are being used for bittorrent. If you can't be sure which ports are being used for bittorrent, you might have to go dig around for the bittorrent PDLM for use with NBAR. You could also classify bittorrent and use cbwfq, as an alternative.

Here's a helpful link: http://www.opalsoft.net/qos/WhyQos-2422.htm

# ¿ Apr 24, 2007 21:54

jwh: Jun 12, 2002

Thermopyle posted:

I've got a Cisco 804. I really know nothing about IOS, I googled enough to come up with a config for my home LAN with an ISDN internet connection.

My question is: How do I enable the DHCP server?

Here you go: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t1/easyip2.htm

That should get you going.

# ¿ Apr 24, 2007 22:51

jwh: Jun 12, 2002

Paul Boz_ posted:

I finally spent the time to get my CCNA yesterday

Congratulations! How was the test? I've been thinking about trying to go do the CCNA sometime this summer.

# ¿ Apr 25, 2007 15:22

jwh: Jun 12, 2002

Frame-relay is still very much alive and well. Even in MPLS environments, frame-relay is a very common access method for low-speed (<DS1) leased lines.

I just labbed l2tpv3, and it blew my mind.

Topology is CER1-Ser1/0 <-> Ser1/0 PE1 Ser2/0 <-> Ser2/0 PE2 Ser1/0 <-> Ser1/0 CER2

code:

CER1:

!
interface Serial1/0
 ip address 192.168.1.1 255.255.255.252
 serial restart-delay 0
!
!
router ospf 1
 log-adjacency-changes
 network 192.168.1.0 0.0.0.3 area 0
!

PE1:

!
pseudowire-class pw1
 encapsulation l2tpv3
 sequencing both
 ip local interface Loopback0
!
interface Loopback0
 ip address 10.0.0.1 255.255.255.255
!
interface Serial1/0
 no ip address
 serial restart-delay 0
 no fair-queue
 no cdp enable
 xconnect 10.0.0.2 1 encapsulation l2tpv3 pw-class pw1
!
interface Serial2/0
 ip address 10.1.1.1 255.255.255.252
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.255.255.255 area 0
!

PE2:

!
pseudowire-class pw1
 encapsulation l2tpv3
 sequencing both
 ip local interface Loopback0
!
interface Loopback0
 ip address 10.0.0.2 255.255.255.255
!
interface Serial1/0
 no ip address
 serial restart-delay 0
 no fair-queue
 no cdp enable
 xconnect 10.0.0.1 1 encapsulation l2tpv3 pw-class pw1
!
interface Serial2/0
 ip address 10.1.1.2 255.255.255.252
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.255.255.255 area 0
!

CER2:
!
interface Serial1/0
 ip address 192.168.1.2 255.255.255.252
 serial restart-delay 0
 no fair-queue
!
router ospf 1
 log-adjacency-changes
 network 192.168.1.0 0.0.0.3 area 0
!



CER1#sh ip ospf neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.2       0   FULL/  -        00:00:39    192.168.1.2     Serial1/0
CER1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 212/239/264 ms
CER1#

How cool is that?

jwh fucked around with this message at 17:38 on Apr 27, 2007

# ¿ Apr 27, 2007 17:01

jwh: Jun 12, 2002

coconono posted:

so I've got a whole stack of 2610 routers and zilch for documentation. where can I find stuff like how to access their console and stuff?

You'll want one of the blue cisco console cables, or just build a 8P8C/RJ45 rollover cable. Console is 9600/8/N/1 by default. Use hyperterm for lack of a better option.

Here's the 2600 quick-start guide, and some other stuff, although most of the time, your best bet is just typing 'cisco blah blah blah' into google.

http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis2600/index.htm

Herv posted:

So JWH will you be using the L2TP instead of GRE now for routing over tunnels? Not sure about the details, haven't played with it yet, although that's what I am gleaning.

No plans to replace our GRE and mGRE tunnels with anything, since they're supported on lower-end ISRs, and really flexible. Plus they're easy to secure with IPSec. I mostly just wanted to see how l2tpv3 worked, and whether I could use it for anything. Layer-2 transport over an IP backbone is really neat. It's like ATM CES without the ATM!

# ¿ Apr 27, 2007 21:43

jwh: Jun 12, 2002

sirchode posted:

Mind explaining these two to me real quick? I've never seen them before and can't seem to find information in my books here

Also what's CER and PE

Sure thing. CER and PE are just names I used to denote Customer Edge Router and Provider Edge routers. In reality, they're just dynamips instances of 7200 routers with a 12.4 ios, and the names don't really matter.

the 'xconnect' command under an interface (could also be a sub-interface, like an ethernet dot1q interface) creates a layer-2 cross connect using l2tpv3 encapsulation to remote router 10.0.0.2 (the loopback IP of PE2) virtual-circuit ID 1, and pseudo-wire class 'pw1'. The same thing is set up in reverse on PE2, only it uses the IP address of PE1's loopback.

So when CER1 sends a frame over it's serial interface, the PE1 router grabs it, stuffs it into a l2tpv3 packet, and shoots it over to PE2, who then strips the original frame back out and sticks it on the serial interface to CER2. Same thing happens in the other direction, too.

CER1 and CER2 think they're directly connected at layer-2, and have no idea they're actually being carried over an intermediary IP backbone. If you look at the IP addresses on CER1 and CER2, they're both numbered in a single /30, but topologically, they're physically disconnected, and that shouldn't work.

I thought it was pretty cool stuff.

edit: here's the doc I basically copied: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_2/gtl2tpv3.htm

jwh fucked around with this message at 00:05 on Apr 28, 2007

# ¿ Apr 28, 2007 00:01

jwh: Jun 12, 2002

Yeah, the lab was really just four dynamips instances of a 7200, running a 12.4 IOS image. You can check out dynagen, which is a front-end for dynamips, here: http://www.dynagen.org/. You'll need to provide either a 7200 or 3600 IOS image.

l2tpv3 is kind of the bastard step-son of a real MPLS pseudowire, since it doesn't require an MPLS environment. When you configure the xconnect, there's an option to use either l2tpv3 or mpls as the carrier protocol. I imagine that if you use MPLS, it just becomes label-switched natively, as opposed to packet-switched in l2ptv3 packets. I don't honestly know.

VRF-lite to VRF analogy sounds right. I think the only major downside of l2ptv3 is that there isn't multipoint support, which means you'd have to go to something like VPLS (AToM) if you wanted more than one site all plugged in together.

# ¿ Apr 28, 2007 04:51

jwh: Jun 12, 2002

I just had to do the math to convert some DSCP values into TOS, so I figured I'd share them, in case they might be useful.

An IOS extended ping can be fed with a TOS value, and it's easier (for me, anyway) to be able to generate packets with explicit DSCP values than relying on another class-map to handle it somewhere.

Anyway, I only bothered to do the three most common to our environment:

EF 0xb8 (decimal 184, binary 10111000)
AF31 0x68 (decimal 104, binary 01101000)
AF21 0x48 (decimal 072, binary 01001000)

Example:

quote:

#ping
Protocol [ip]:
Target IP address: 4.2.2.2
Repeat count [5]: 10
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 0x68
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 88/94/108 ms
#show pol
#show policy-map int atm0/ima0.50 | begin qos-hi
Class-map: qos-hi (match-any)
10 packets, 1120 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp af31 (26)
10 packets, 1120 bytes
5 minute rate 0 bps
Match: access-group 162
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 137
Bandwidth remaining 60 (%)
(pkts matched/bytes matched) 10/1120
(depth/total drops/no-buffer drops) 0/0/0
exponential weight: 9
mean queue depth: 0

Kind of a handy trick.

# ¿ May 2, 2007 20:45

jwh: Jun 12, 2002

Thermopyle posted:

Anything obviously wrong with the following?

Hop on the router and do:

router> enable
router# conf t
router(config)# service dhcp
router(config)# exit
router# wr mem

# ¿ May 2, 2007 22:31

jwh: Jun 12, 2002

What specifically is pointing you towards the 2851?

If you only need an ethernet interface and WIC slot, you can do it cheaper than a 2851. 1841, for instance, or lower end 2800 series.

# ¿ May 4, 2007 05:12

jwh: Jun 12, 2002

How are you going to power the AP's? Inline power injectors? PoE?

# ¿ May 4, 2007 15:48

jwh: Jun 12, 2002

Isn't autonegotiation required for 1000base-t? I know you can force it off on fiber interfaces, but I don't think I can turn down autonegotiation on my X6548-GE-TX modules.

edit: I think I'm wrong about the module. I seem to remember there was something out there that would only take a 'speed auto', but now I can't figure out what it was.

jwh fucked around with this message at 02:21 on May 11, 2007

# ¿ May 11, 2007 02:09

jwh: Jun 12, 2002

Tremblay posted:

Were you thinking the PA-4E modules for VXRs?

I can't seem to remember. I think I'm confusing memories of one thing with something else. I just checked most of the copper modules I have around here, and they all seem fine, but didn't check any of the PA's.

In other news, we finally pulled our 'haunted' 7206VXR out of production today. If anybody wants an early PA-8T1-IMA that is possessed by evil spirits, you know who to talk to. I won't be sad to see it go, that's for sure.

# ¿ May 11, 2007 15:40

jwh: Jun 12, 2002

karttoon posted:

If it's free or cheap I'd love to get it. If you're serious jwh, hit me up via aim or icq (profile).

The card is seriously screwy; trust me when I say you don't want it. I think the company is going to try and sell the whole 7206 "as-is", haunted IMA card and all, by tucking it in with a lot of Passport 8600's. I pity the poor bastard that ends up with that IMA card. And the Passports.

What is this Cisco myspace thing you mentioned?

# ¿ May 11, 2007 19:54

jwh: Jun 12, 2002

karttoon posted:

Well if the chasis is good I'd still take it.

Chassis and NPE is still worth a good chunk of change; I think the company is going to try and sell it. If they are planning on tossing it, and for some reason nobody gets their paws on it first, I'll keep an eye on it for you.

InferiorWang posted:

How about some theory?

Lets say you have a stack of 2950s. They are all layer2. You want vlan2 to attach to some public kiosks for example. To be able to have those vlans extend beyond each device, you would want them trunked, correct?

2950 -trunk- 2950 -trunk- 2950

Yes, at least, that's one way of doing it. You're better off with a hierarchical distribution than a daisy-chain, but yes. Alternatively, you could look at something like qinq to extend vlan2 over a another switched backbone, or l2tpv3 to extend vlan2 over an IP backbone, or VPLS to extend vlan2 over an MPLS backbone.

quote:

To be able to access that proxy server so your kiosks can have net access, you would then want that trunk to extend to a router which will have 2 interface cards? One on a vlan1 switchport, and one on a vlan2 switchport? And then from there, you can use ACLs to let only ports 80/8080 route through?

Do I have that all right or am I missing something?

You could instead present an 802.1q trunk to the router device that carries both vlan1 and vlan2, and configure dot1q subinterfaces, if you're trying to cut down on interface consumption.

Arguably, a better idea would be to invest in a layer-3 switch, and apply access-lists to layer-3 SVI's, or use vacls.

# ¿ May 11, 2007 20:59

jwh: Jun 12, 2002

InferiorWang posted:

By that do you mean each switch has individual "home run" uplinks back to a "core" switch?

Generally, yes. If tends to be easier to manage, and results in a more predictable point of congestion. The ability to then solve bandwidth problems from access switch distribution/core switch by use of etherchannel is compelling. It really depends on how much traffic you're doing, and whether you intend to build distribution/core redundancy. Like anything else, I guess it depends on what you want to do, but I'd bet that the SH/SC cisco crowd consensus would be for a hierarchical switching infrastructure. If cost is prohibitive due to long-distance leased fiber, for instance, you may want to instead buy layer-3 switches and move to an IP model.

If you do daisy-chain, be aware that you shouldn't expand wider than seven devices (switches, spanning-tree aware bridges, etc) and also use spanning tree. Spanning-tree will flip out on you.

# ¿ May 11, 2007 21:25

jwh: Jun 12, 2002

I'm reworking our qos framework for low-speed branch sites, and as part of the process, I've started second guessing myself about the recommended application of service-policies on frame-relay interfaces.

If you go back to about 2002-2003, it looks like the recommendations was frame-relay traffic shaping and frame-relay map-classes, after which the recommendation was a nested hierarchical policy-map. Ok, I have nested hierarchical policy-maps configured already, no big deal.

But, literature from 2005 lists best-practices as frame-relay traffic shaping! I thought MQC got rid of all that garbage?

Truth is, I don't really care where I put the policy-map, but I do want to know recommendation is. Because it's GTS and CBWFQ in a nested policy-map, I'm inclined to think I'm correct in applying this to the sub-interface, but now I'm having serious doubts.

# ¿ May 15, 2007 21:34

jwh: Jun 12, 2002

Herv posted:

code:
C827(config-subif)#service-policy output esp
CBWFQ : Not supported on subinterfaces
I was able to get it on the pvc though, but it's not showing up as cbwfq.

That's normal; or at least, that might be normal. If you nest the cbwfq policy-map under a generic traffic shaping (GTS) policy-map, it'd probably let you apply it.

Funny aside, while it will work for frame-relay sub-interfaces, it won't work for ATM pvc's, because they shape natively, and it won't let you do it. But, cbwfq can be applied directly to an ATM pvc.

Good times.

# ¿ May 16, 2007 00:40

jwh: Jun 12, 2002

Girdle Wax posted:

Cisco goons, you're my only hope

That's not a good sign

Girdle Wax posted:

Since they're 3750 stacks though, they have a snowball's chance in hell of doing anything decent BGP wise to get them to make smart routing decisions at distribution

Meaning, TCAM size is too small for full tables?

Girdle Wax posted:

- Get rid of spanning tree. How? Everything coming out of the distribution switches (pondering between 6509/Sup720 and 7609/RSP720 for this- arguments for/against these would also be welcome) is a layer 3 link, layer 3 links up to the core routers. layer 3 links down to the customer access routers. layer 3 links down to the access/aggregation switches. layer 3 links 'across' to my existing distribution switches to get the legacy network uplinked through the new network.

That's a lot of layer 3. Are you confident that your IGP is going to reconverge AS-wide faster than spanning-tree in event of a link failure? Similarly, would these problems go away if you instead replaced your older gear with switches that supported RPVST+?

As for 6500/7600, your guess is as good as mine. I think people are still feeling this one out.

Girdle Wax posted:

To accomodate getting rid of spanning tree, I want to move the layer3 termination down into the customer access switch (probably using 3560s). 2 routed uplinks, 1 to each distribution switch. Then a handful of SVI's with /28s or /29s serving a handful of customers. These switches will participate in the OSPF loopback program, and limited iBGP as listed below.

I'm not much of an ethernet wizard, honestly, and I spend more time on the WAN side these days, but I almost feel like you're putting a heavy burden on your access layer. More intelligence at the access layer might mean more revenue opportunities, ease of management, and greater provisioning flexibility, but it also means more things that can break. Plus, if you need a customer VLAN to span multiple access layer devices, are you going to have to cross-connect those switches on an as-needed basis?

Girdle Wax posted:

- All internet traffic in the access/distribution switches will be in an internet VRF (vrf-lite in all the switches basically). This is mainly a management thing- I plan to use the main routing table for management access only- haul a single eth from every switch back to an isolated switch for a new management network. So I can actually get into the switches over ssh/telnet when the poo poo hits the fan. Part of this project will also be making sure we have working consoles in case that switch fails *grumble*. This introduces somewhat of a learning curve (remembering to type 'vrf internet' all the time), but I feel the management advantages outweigh the disadvantages.

Have you worked up all of the relevant routing protocol configurations with the vrf stuff? It can be a little screwy, ie, OSPF's vrf per-process instantiation versus mBGP address-family vpnv4.

Girdle Wax posted:

- OSPF is optimized as described in the Cisco doc above (200ms hellos for fast failure detection- in the future we will probably also look at doing BDF if the 3560 ever supports it), in addition to ispf to speed up spf calculations.

Well, you probably saw it too on c-nsp the other day, but apparently BFD has trouble getting below 250ms. That could have been a platform anomaly, I don't remember. If your tuned OSPF dead timer is 4 x hello interval, that's still really quick.

Girdle Wax posted:

I've come across a couple of problems, the biggest one was resulting from a distribution switch reboot and ECMP. Basically since OSPF comes up faster than BGP, my core was sending traffic for an access switch down to DistA, which didn't know how to handle it, so it sent it back up to the Core, back down to DistA etc. I managed to resolve this by adding a high metric static in each of the distribution switches, pointing to each other over the link between them. This way when a switch is still 'becoming active' after a reload, it will continue to pass traffic across to the other distribution switch which is still up, which will be able to forward the traffic as normal.

I thought you were getting customer prefixes out of OSPF? Or am I misunderstanding? Are you talking about control plane traffic?

Girdle Wax posted:

My full table BGP customers I can continue to serve out of my customer access routers like I do now. I'll probably hang a dedicated switch off each of those GigE interfaces just for that, and keep them isolated from the distribution/core. There was a proposal to perhaps hang some these customers off 10/100/1000 aggregation switches, terminate L3 in the agg switch then have them to eBGP multihop to the distribution switches but this bugs me in 2 ways.
-- we need to redistribute the customer's routes down to that agg switch via BGP. So if they drop their session it'll be 2+ minutes until the path back to them is good.
-- Customers in distribution, get off my lawn.

Yeah, ebgp-multihop is gross unless you're doing the neighbor loopback thing.

You could take a tip from the carriers here, and simply provide the customer a session, and tell them to do whatever they want with it. So, in other words, if they drop their session, that's their own drat fault. It's not polite, but it makes a certain sense.

Girdle Wax posted:

We do have some colocation customers who do HSRP with us for failover on our and their equipment, to continue to offer this I came up with the following solution:
-- The customer will 'purchase' 4 switchports (in 2 adjacent switches), and a dedicated SVI/VLAN in 2 switches. 1 port out of each switch will go to the customer, the other 2 ports will be a dedicated 'tie' link to connect the 2 islands. Since I don't have any trunks up to the core this is the best I can think of, plus it gives the customer a dedicated link at their purchased speed to carry traffic which comes in over the secondary switch in the unlikely event that we lose all uplink on their primary switch.

This one gives me the shakes. I guess if you can charge customers for the cross-connect, it won't matter, and won't be like you're losing out on revenue producing interfaces.

There's a lot to think about here, and you're obviously much more familiar with what you've worked up than I am, not to mention familiar with your business practices. That said, it sounds like you're in the business of providing colocation at the switchport level, as well as routed interfaces. Maybe an exercise would be to take your layer-2 access-layer out of the picture completely, and develop a framework that could accomodate both layer-2 colocation and layer-3 routed interface customers identically, sans ethernet access-layer infrastructure. Then, attach access-layer devices as if they were customer owned, but provider managed.

I guess what I'm saying is, would it be easier if your colocation access devices were end-of-rack 6500's providing routed interfaces to top-of-rack customer managed switches? They could purchase HSRP and uplink diversity without your having to get stuck in spanning-tree nightmare world, because that'd be up to them.

jwh fucked around with this message at 20:27 on May 18, 2007

# ¿ May 18, 2007 19:45

jwh: Jun 12, 2002

Girdle Wax posted:

also only have 128M (non upgradeable) of DRAM, I'm not sure if I can fit a full table into that y'know

Oh yeah, that's a good point.

Girdle Wax posted:

I'm really liking the advantages of moving layer3 down to the access layer in the form of simplified troubleshooting (ping and traceroute), and not having to deal with the headaches that come along with spanning-tree, rapid or no.

Can't argue with that. More importantly, it sounds like you're comfortable with what you've proposed, and that should translate into operational efficacy. That's never a bad thing.

Girdle Wax posted:

As soon as my switches boot up I'll grab some configs off them to see if anyone can poke some holes in that

That'd be neat to look at; I managed to dodge route-target import/exports too, which turned out to be a good thing. I've been meaning to go back and lab the route-target stuff just in case we have a falling-out with Nokia, and decide to move our wan firewalls to another platform.

Girdle Wax posted:

but if I have a feature that could make link failure detection more reliable (fast hellos, udld, bfd), and doesn't cost me much to implement, I'd have to be insane not to use it right?

Well, you know what they say, the road to good intentions is paved with hell.

Girdle Wax posted:

Why does the 7600 BU hate us.

I think a better question is why Cisco thought it was a good idea to compete with itself, just to capture a market that used a different nomenclature. It must have felt like a good idea at the time, but nowadays it's yucky for customers. I'm just glad I'm not in the market for one.

# ¿ May 18, 2007 22:31

jwh: Jun 12, 2002

Girdle Wax posted:

handing a dot1q subif out of that VRF, over a GigE trunk into our VRF switch, then access ports to the customer.

Yeah, isn't that great? I love it. Opened up a whole world of options when that came down the line. Being able to isolate and preserve customer aggregation across a transit area is huge.

Girdle Wax posted:

The last time we changed vendors we ended up with a pair of Extreme Summit 48is (the distribution switches before the ones before the current ones) which was just a terrible, terrible experience (they failed and rebooted fairly regularly, and always took over OSPF DR).

Ugh, that sounds like bad times. Everybody who works with the Juniper M-series seems to really fall for them, but I've never had the chance. I would be interested in seeing how they work. I'm not sure what Foundry's up to these days (besides backdating stock options), but I used to like their ServerIrons a whole bunch. I really want to play with Alcatel gear, but the likelihood of that happening is fairly small unless I move to France, I guess.

# ¿ May 18, 2007 23:50

jwh: Jun 12, 2002

Girdle Wax posted:

configs for the test layer3 access network

Looks good! Your OSPF tuning has given me some ideas for my own network. Bear in mind, if you go to more than one VRF, you might have to start using the 'capability vrf-lite' command under each OSPF process to disable the PE checks (your guess is as good as mine as to what actually are).

I have to admit, I was on the fence about your layer-3 to the access layer after reading your lengthy post, but after seeing the configs, I really like it. Any thought to getting your own ASN from ARIN, or did you sanitize your AS to a private?

# ¿ May 20, 2007 05:16

jwh: Jun 12, 2002

karttoon posted:

what would you guys recommend as the best way to 'practice' to keep the skills and knowledge relatively fresh in my head?

I would recommend buying a used 3640 with a 12.4 IOS. Then you can steal the IOS image and use it with Dynamips/Dynagen to emulate a handful of 3640's.

# ¿ May 29, 2007 15:05

jwh: Jun 12, 2002

atticus posted:

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.

It's a bit of a historical hold-over from the days before VLSM.

For instance:

code:

sanitized#sh ip ro | i sub
     168.173.0.0/16 is variably subnetted, 5 subnets, 3 masks
     66.0.0.0/24 is subnetted, 1 subnets
     192.168.78.0/32 is subnetted, 1 subnets
     172.20.0.0/24 is subnetted, 1 subnets
     172.23.0.0/24 is subnetted, 2 subnets
     10.0.0.0/8 is variably subnetted, 432 subnets, 8 masks

If you subnet into classful space, ie., 10.0.0.0/8, but all of your subnets are /24's, then IOS likes to report "10.0.0.0/24 is subnetted, X subnets".

If you subnet variably within the same space, ie., 10.0.1.0/24, 10.1.0.0/16, then IOS reports the natural classful mask, and says "10.0.0.0/8 is variably subnetted, X subnets, Y masks"

You're good to pick up on it in the first place, since most people don't even notice.

I hope that sort of explains what's going on.

# ¿ May 30, 2007 16:06

jwh: Jun 12, 2002

Does "connection drop" mean the client suspects the tunnel is failing, or his application socket is failing? The latter seems more likely.

# ¿ Jun 7, 2007 16:57

jwh: Jun 12, 2002

I'm looking for some feedback on a current project.

We're migrating our user vpn to a pair of ASA5540's, and we intend to terminate users into separate pools, which will correspond to separate 802.1q vlan subinterfaces. I think that will work at least.

However, I'm confused about whether the client gateway is the ASA, and if that's set via tunnel-group parameters, or if the client gateway is the next-hop from the ASA on that specific 802.1q subinterface.

I'm trying to figure out if this is going to work at all, because the ASA is sitting on a heavily segregated VRF-lite environment, and the ASA isn't like an IOS device with multiple routing tables. Contexts would maybe solve this, except for the fact that apparently you can't run multiple contexts and terminate remote access VPN on the same ASA. Or run OSPF. Boo.

I can't even just turn up OSPF in single-context mode because there's identical routes in each VRF that would collide, and I don't even want to think about what kind of unlivable hell that would cause.

Long story short, I want per-tunnel group default routes, or something like that I guess.

# ¿ Jun 8, 2007 22:15

jwh: Jun 12, 2002

Try going to 12.4(11)XJ or newer. It looks like that's when AES CCMP showed up on the 1800s.

# ¿ Jun 15, 2007 14:37

jwh: Jun 12, 2002

ASA 8.0(2) up on cco as of today.

Looks like lots of SSL VPN enchancements, and the thing I had been waiting for:

Platform Enhancements

VLAN support for remote access VPN connections

Provides support for mapping (tagging) of client traffic at the group or user level. This feature is compatible with clientless as well as IPsec and SSL tunnel-based connections.

# ¿ Jun 19, 2007 18:31

jwh: Jun 12, 2002

Biggz posted:

However i'm wanting to implement QoS

One of the challenges with shaping on consumer broadband is that your router doesn't generally know what kind of bandwidth is actually available, versus the reported link speed. For instance, I'm willing to bet the 871's wan interface isn't really sitting on 10, or 100mbps upstream.

You could artificially shape to a predetermined rate, and then implement a queuing scheme within that, but my recommendation would be to not bother with QoS unless you feel you really need it.

The 'interface-time' of outbound packets leaving the 871 is really short, so there's little chance of a queue building, as opposed to a T1, for instance. If you really want to do it anyway, I'd look at nested hierarchical policy-maps (CBWFQ inside GTS): http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt4/qcfcbshp.htm

I'm not even sure if that's supported on an 871, someone correct me if I'm wrong.

# ¿ Jun 19, 2007 23:54

jwh: Jun 12, 2002

StabbinHobo posted:

ooooooohhhh. Now I have to go re-think my plan. I had talked myself out of needing this, but it was half sour grapes.

edit: this is dot1q tagging right?

Yeah, dot1q tags, but there's a problem- I was really close to posting on c-nsp about it, but I thought I better open a TAC case tomorrow before I go shooting my mouth off.

What I can't figure out is this: 8.0(2) offers support for trapping remote access users in 802.1q vlans, but the ASA still only has one tunnel default gateway / routing table. So, unless I'm seeing this wrong, "vlan mapping" doesn't buy you much at second glance. In other words, you can trap people to vlans on the inside, but the ASA still only knows how to route users with a single routing table. This might be fine if your network lines up right (ie., vlans correspond correctly to customer networks), but I need more routing flexibility. Mostly, I need to drop users in vlans, and then supply them with specific routes.

So I dunno, TAC case tomorrow to find out whether this will work, or if I'm going to instead use ipsec DVTI's with ivrf/fvrf on an IOS based platform.

jwh fucked around with this message at 03:55 on Jun 20, 2007

# ¿ Jun 20, 2007 03:46

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 01:10

jwh: Jun 12, 2002

Godfrey posted:

Alright is not really a short question but.... I am retarded when it comes to VPNs I've only set one or two up correctly but this does not stop me from thinking my boss is doing it completely backasswards.

What do you mean? What is he doing?

I like to use ipsec protected GRE tunnels. It's super easy to configure, and they configure up like actual routed interfaces. None of this dynamic crypto map wacky nonsense.

http://www.cisco.com/univercd/cc/td/doc/solution/p2pgre_x.pdf

# ¿ Jun 20, 2007 19:10

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

«‹›25 »