Re: [c-nsp] Juniper - Cisco Catalyst Fast Ether Channel Load Balancing
a. rahman isnaini r.sutan ha scritto: Hi Gian, Both direction, output/input direction. And currently working on two ports. Is there any specific additional commands on catalyst except belows : With a cat 2950 you can olny do lb with source or dest mac-address. So with a few destination, or single if it'a router, below the juniper, traffic will be quite umbalanced, all traffic sent by a source will always follow one channel path. In this scenario src-mac balancing could help, but you haven't cleared network topology, so I can only guess. Gian ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] telecommuting support jobs for BGP guys?
On Fri, 25 Jan 2008, neal rauhauser wrote: There are thriving markets for remote workers in the software field but its far less common for infrastructure support. Regarding accessibility in the event of BGP troubles all of my customers have a little collection of static /32s on their border routers coming back to a couple of different hosts - troubles do arise, but I've never been completely shut out. If it were genuinely that serious there would be a dial in line to the facility in place, or better yet DSL from a totally unrelated carrier. I guess the problem might be a shortage of networks who utilize BGP yet don't have somebody on staff or an existing relationship with a consultant to manage their BGP. Besides, correct me if I'm wrong, but don't the vast majority of networks that use outside help with BGP have relatively static configurations? Best of luck regardless. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] CRS-1 too complicated?
Also physical installation needs careful planning for the 16 slot kit at least in one installation we did the floor needed extra metal work to support the weight. Also getting there through doors and up ramps can be interesting. We spoke to someone from CA about the physical bits but there was no charge for that it was a half hour meeting and a show around a lab they had built just giving us there personal experiences. Regards Kevin On Jan 26, 2008 12:32 AM, Aaron [EMAIL PROTECTED] wrote: Once you get one and understand the cabling, then you are good. On Jan 25, 2008 5:13 PM, Andrew Alston [EMAIL PROTECTED] wrote: We just bought 4 16 slot CRS-1's. Cisco would not sell them to us without Cisco CA involvement. But the involvement was purely on the installation and deployment side and has nothing to do with the configurations and future running of them. Thanks Andrew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Mauch Sent: 25 January 2008 09:30 PM To: Greg Schwimer Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] CRS-1 too complicated? On Fri, Jan 25, 2008 at 11:49:49AM -0700, Greg Schwimer wrote: We've been looking at the CRS-1 for a while now as our next generation routing platform. However, my Cisco account team is going out of their way to tell me we need, must have, can't ever get it to work without professional services. I don't get it. They're nuts and trying to upsell you. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/http://puck.nether.net/%7Ejared/ My statements are only mine. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] VPLS and AToM Failure Recovery Time
Facing the following issue:
A VPLS (also tested with EoMPLS) pseudowire indicates up state but does
not send/receive frames during link failure simulation for up to 30
seconds.
It was tested severy features: only VPLS with IGP, EoMPLS over Traffic
Engineering, EoMPLS over TE protected by FRR.
Recovery of VPLS and AToM by itself is very fast, in all conditions. But
effectively, there is no frames going through the pseudowire.
I am wondering if it is SUP/Module hardware issue or have you faced this
in other platform?
Software tested is 12.2.33.SRB2.
Here is some details of config and monitoring during failure simulation:
PC1-7604(sup720)7640(sup32)-PC2
|__|
First, pseudowire is taking interface gi 4/0/1. When failure in this
link is forced, VC immediatelly takes interface gi 4/0/0. The VC status
is UP, but there is no frame crossing the pseudowire from PC1 to PC2.
The amount of time it takes for traffic go through pseudowire again is
very big, up to 30 seconds, which remembers me Spanning Tree issue.
sh mpls l2transport vc 100 det
Local interface: VFI vlan100 VFI up
MPLS VC type is VFI, interworking type is Ethernet
Destination address: 200.222.117.41, VC ID: 100, VC status: up
Output interface: Gi4/0/1, imposed label stack {16}
Preferred path: not configured
Default path: active
Next hop: 200.164.97.33
Create time: 16:47:30, last status change time: 00:58:41
Signaling protocol: LDP, peer 200.222.117.41:0 up
Targeted Hello: 200.222.117.42(LDP Id) - 200.222.117.41
MPLS VC labels: local 16, remote 16
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 8869, send 422530
byte totals: receive 839752, send 29011888
packet drops: receive 0, send 0
int gigabitEthernet 4/0/1
flamengo(config-if)#shut
sh mpls l2 vc 100 det
Local interface: VFI vlan100 VFI up
MPLS VC type is VFI, interworking type is Ethernet
Destination address: 200.222.117.41, VC ID: 100, VC status: up
Output interface: Gi4/0/0, imposed label stack {16}
Preferred path: not configured
Default path: active
Next hop: 200.164.178.233
Create time: 16:50:09, last status change time: 01:01:20
Signaling protocol: LDP, peer 200.222.117.41:0 up
Targeted Hello: 200.222.117.42(LDP Id) - 200.222.117.41
MPLS VC labels: local 16, remote 16
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 8902, send 423880
byte totals: receive 842842, send 29104224
packet drops: receive 0, send 0
Following is the basic config when it was tested for VPLS:
l2 vfi vlan100 manual
vpn id 100
neighbor 200.222.117.41 encapsulation mpls
!
interface Vlan100
ip address 100.100.100.1 255.255.255.0
xconnect vfi vlan100
And here is the basic config when it was tested for AToM with MPLS TE
and FRR. The result was the same, up to 30 seconds of no traffic between
PC1 to PC2, even though Tunnel1 came up in 600ms due to G4/0/1
protection by Tunnel2.
interface Vlan600
ip address 160.4.4.2 255.255.255.0
xconnect 200.222.117.42 600 encapsulation mpls pw-class usetunnel1
interface Vlan601
ip address 161.4.4.2 255.255.255.0
xconnect 200.222.117.42 601 encapsulation mpls pw-class usetunnel2
pseudowire-class usetunnel1
encapsulation mpls
preferred-path interface Tunnel1 disable-fallback
pseudowire-class usetunnel2
encapsulation mpls
preferred-path interface Tunnel2 disable-fallback
sh ip route 20.20.20.0
Routing entry for 20.20.20.0/24
Known via ospf 2, distance 110, metric 2, type intra area
Last update from 160.4.4.2 on Vlan600, 00:07:24 ago
Routing Descriptor Blocks:
* 161.4.4.2, from 200.164.178.233, 00:07:24 ago, via Vlan601
Route metric is 2, traffic share count is 1
160.4.4.2, from 200.164.178.233, 00:07:24 ago, via Vlan600
Route metric is 2, traffic share count is 1
From OSPF point of view, there is no issue. It keeps point traffic to
extended Vlan 601, as Vlan 601 VC status is UP. But effectively, traffic
seems to go to black hole.
Tks,
Alaerte
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Reflexive ACLs or CBAC on 6500
On Jan 25, 2008, at 5:19 PM, Tassos Chatzithomaoglou wrote: If i understand right (according do the documentation) both are processed in software in the MSFC, so that's going to hurt a little. It has the potential to hurt a lot. I highly recommend that you not do this if you're passing any kind of real traffic through these boxes. Stick with the hardware-enabled features. ; --- Roland Dobbins [EMAIL PROTECTED] // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] CRS-1 too complicated?
kevin gannon wrote: Also physical installation needs careful planning for the 16 slot kit at least in one installation we did the floor needed extra metal work to support the weight. Also getting there through doors and up ramps can be interesting. We spoke to someone from CA about the physical bits but there was no charge for that it was a half hour meeting and a show around a lab they had built just giving us there personal experiences. There was whole session on Networkers dedicated to real-life stories about running the CRS-1 up. Everything up from ordering to physically installing it in the building was covered by some Cisco guy that did that along with partner (don't turn the box upside down!). As far as CA story (actually - Professional Services as they called now) goes - IOS-XR that runs CRS-1 falls under Cisco ATP program[1]. Partner that sells the hardware to you must be either ATP certified or needs to call CA/PS for installation. They're involved into the process to not let the customer down when partner knowledge or experience puts the whole deal at risk. That's all, no hidden magic here. Hope that clears the confusion. 1.http://www.cisco.com/web/partners/pr46/pr0/partners_pgm_concept_home.html#iosxr -- Don't expect me to cry for all the | Łukasz Bromirski reasons you had to die -- Kurt Cobain |http://lukasz.bromirski.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] counterfeit?
Jason Gurtz wrote: I don't know if the secret key has been compromised, or if the cloners just have access to a really large sample set, but these days they seem to have no problem defeating the check and producing Cisco-branded optics which work in any system. Back when I was doing my pre-ebay research (was buying some used Cisco gear for home) I came across stories of the actual Cisco contracted manufacturers running a fourth shift, with which they churn out some numbers of off the book production that goes directly on the black market. That's hardly truth, as whole process is strictly supervised. However, there are known companies far away in China, that are actually producing the copies of 1700, 2600 routers, Catalyst 2950 switches, some 4500 linecards and most of the older modules (NMs, WICs, etc). So, Cisco added hadware counterfeit protection starting from the older 3560/3750 switches, and now it's present in all modern switches and modules. Another batch of original comes from equipment that was repaired by technically-skilled people and actually works (but who may know how long). -- Don't expect me to cry for all the | Łukasz Bromirski reasons you had to die -- Kurt Cobain |http://lukasz.bromirski.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] telecommuting support jobs for BGP guys?
On Sat, 26 Jan 2008, Roy wrote: It isn't just BGP jobs. I do routers, switches, firewalls, VPNs, etc. There are jobs out there, but most of the ones I've come across are usually short engagements or generally quick hit type work, such as we're having a connectivity problem, could you help us fix it? or we need to get a new firewall built to replace our old one. I've been doing work like that on the side for the past few years and at least in this area, there is a niche for people with those skills and companies who don't need or can't afford to have a 'router guy' on staff full time. So far I've never run into a full time telecommuting network gig. This is probably starting to veer off topic for cisco-nsp but I'd be happy to continue the discussion privately if you want. jms ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] counterfeit?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Richard A Steenbergen Sent: Friday, January 25, 2008 11:51 AM To: Steve Feldman Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] counterfeit? Many optic vendors will even give you a choice of what you want your EEPROM vendor field to say, so you can even make your own store brand line of optics the same way that Cisco does. Note of course, that if it doesen't say Cisco on the label it is NOT counterfeit. It is a shame that Cisco's insertion of secret key technology to defeat counterfeiters has made it more difficult to manufacture legitimate non-Cisco branded SFP's. Frankly the only solution to counterfeiting is to agressively enforce the existing laws. Unfortunately, the US federal government's insistence on putting all of enforcement resources on this futile effort to go after terrorists has allowed all the other criminals almost free rein. Ted ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] CRS-1 too complicated?
It sounds like they want to guarantee that each of these sales turns into a successful installation. It's relationship and satisfaction protection. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Schwimer Sent: Friday, January 25, 2008 12:50 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] CRS-1 too complicated? We've been looking at the CRS-1 for a while now as our next generation routing platform. However, my Cisco account team is going out of their way to tell me we need, must have, can't ever get it to work without professional services. I don't get it. I understand that there are some major differences from, say, a 7600: - IOS-XR - new interface and all the configuration vagaries - Hardware - substantially different architecture - Color (!) My plan is to bring a CRS-1 into the lab, dissect it, learn it, adapt the configuration details to our needs, build a training plan around it, and slowly deploy it. My Cisco team seems stuck on having to sell us services to get this working. Am I missing something here, or is the CRS-1 so unbelievably complicated that mere mortals cannot figure it out and make it work on their own networks? What have others experienced with implementing them? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Key-chain and MD5 authentication for IS-IS
On Thu, Jan 24, 2008 at 08:02:59AM +0100, Oliver Boehmer (oboehmer) wrote: I recall there was a bug somewhere in 12.2S where this was required for all keys (IIRC).. 12.2(18)S* had password level 7 obfuscation broken (incompatible with all other IOS releases). Best regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Reflexive ACLs or CBAC on 6500 (Tassos Chatzithomaoglou)
Hi Tassos- While YMMV, the IOS Firewall product management team has been discouraging use of IOS Firewall Inspection (CBAC) on the Cat6K for some time. For whatever reason, I can't locate the IOSFW EoL page, but please have a look at a link from last year: http://puck.nether.net/pipermail/cisco-nsp/2007-June/041176.html You may find that Classic FW is entirely adequate for your application. However, in the event that it works badly (as Roland pointed out that it may), there won't be much recourse for a resolution. ASA is Cisco's best option for inspection with a Cat 6K. Regards, Brian Brian Stiff 720.562.6462 IOS Firewall Technical Marketing Eng. Security Technology Group http://www.cisco.com/go/iosfw Date: Fri, 25 Jan 2008 12:19:20 +0200 From: Tassos Chatzithomaoglou [EMAIL PROTECTED] Has anyone real world experience of using these 2 features (Reflexive ACLs or CBAC) on 6500 with MSFC2 (SUP2) or MSFC3 (SUP720)? If i understand right (according do the documentation) both are processed in software in the MSFC, so that's going to hurt a little. Are there any hidden limitations? Does MSFC3 perform better than MSFC2? Should we prefer one instead of the other? Can we use both at the same time? We're already using FWSM on our main 6500s, but we have some spare 6500s (for test servers mainly) and we'd like to implement something better (and easier to maintain) than simple ACLs. -- Tassos ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
