Hi,
On Sun, Aug 28, 2011 at 09:32:55PM -0700, cisco group wrote:
> I have looked around on the cisco site and have found procedures for
> upgrading IOS on redundant supervisors but am unable to find
> procedures on upgrading supervisor engines themselves?
"save config to tftp, switch off box, rem
We have a 6513 in our network with 2x Catalyst 6000 Sup 2 engines
running in SSO (Active, Standby Hot). The supervisors are currently
in slot 1 and 2.
We would like to replace the supervisors with 2x WS-SUP720-3B in SSO
mode. These sups are required to be inserted into slots 7 and 8.
I have loo
...nothing wrong with using-consultants.
Once-again, consultants can only offer-advice based on what-is-known/un-known
based on vendor-doc.( unless ofcourse, said-consultant also writes the
applicable-code within Cisco!)
..that is the whole point!
./Randy
--- On Sun, 8/28/11, Frank Bulk wrote:
I agree with you: what ought to be, isn't.
I don't make buying decisions based on what I would like vendors to do or
what they should do, but what is. Until documentation matches reality, I
will use consultants to help us with our due-diligence.
Frank
-Original Message-
From: cisco-ns
perhaps you didn't read my-response in its entirety.
As mentioned before, post your configs(R1,R2,R3) publicly or privately
./Randy
From: Ranjith R
Subject: Re: [c-nsp] Input errors on GRE tunnel interface
To: "Randy"
Cc: "cisco-nsp@puck.nether.net" , "Andrew Jones"
Date: Sunday, August 28, 2
I have been following this thread and it is upto the *vendor* to
*Clearly-Document* what-combinations work and what doesn't!
It has nothing to do with what you or other OP have said wrt regard to
due-diligence or for that matter - ...hiring-someone-who-knows
What &*^% diligence are you ta
Thanks Randy .
As i described earlier , the IPSEC VPN router comes behind the GRE tunnel as
depicted below
R1 ( VPN router ) - R2 -GRE tunnel - R3 ( internet
router ) --- Internet
so if i am correct , we have control only over the IPSEC packets generated
from
Products at this level of complexity either need an internal team with
extensive experience, or a consulting company that has that expertise. But
on top of that, all important features need to be documented and formally
confirmed by ones Cisco account team. That way if it doesn't work as
promised
LAF is enabled by default and it is a global-ipsec-config command - not
interface-based.
If memory serves, it had to be turned-off(crypto ipsec fragmentation
after-encryption) in the days when crypto-maps had to be applied to both
tunnel&physical ints. to make ipsec work(..a throwback to remnant
Its all to do with encryption export restrictions.
Andrew Jones
Alphawest
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: Friday, 26 August 2011 11:50 PM
To: Oliver Boehmer (oboehmer)
Cc: cisco-nsp@puck.
On Sun, Aug 28, 2011 at 08:04:00PM +0200, Gert Doering wrote:
>
> On Sun, Aug 28, 2011 at 11:12:44AM -0500, Tony Varriale wrote:
> > Then hire someone that knows what they are doing.
>
> Am I the only one to find that sort of remark a bit nasty?
>
> While not sporting any nice certificates, I co
A low-end ISR router would be best for this task.
something like a 1941 perhaps.
Andrew Jones
Alphawest
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Arie Vayner (avayner)
Sent: Monday, 29 August 2011 4:45 AM
To: Gert
Make sure you have the following command on the WAN interfaces:
crypto ipsec fragmentation before-encryption
This ensures you only fragment the packet once, instead of twice, ie without it
the router fragments the packet to fit into the interface mtu, then encrypts
it, which then may require fu
The only thing that is obvious is that you haven't accounted for the ipsec and
gre overheads correctly - ie, the need to clear df-bit.
There isn't any such thing as an ideal-mtu. The idea is to make sure that the
the mtu of original packet(payload+tcp header+ip header) + ipsec-overhead+gre
over
Some say that he wears a suit and never shows who's under the helmet and
continuously pushes playing cards with the picture of Rubins Barriccelo through
his desk fan!
Other's say that he moon lights as a mild mannered Network Engineer familiar
with the finer points of routing and switching.
Al
On 8/27/11 10:49 PM, "Jon Harald Bøvre" wrote:
> add command 'channel-group 5 mode on' to interface. This creates
> port-channel interface
On Sat, 2011-08-27 at 23:36 -0700, Gregori Parker wrote:
> Best practice is to enable udld on these and set channel-group mode to
> desireable
I'd say mode "
Jay,
>From what I could find, LACP is not supported on 7200 (where did you see
a reference for it being supported?)
You could use PAgP if the other platform supports it...
Arie
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf
Just to complement Gert's answer, what you could do, assuming the
Cataylst 6500 is already there, and doing other stuff, is to get a
cheaper external device (switch or router) to perform the egress
shaping/HQOS function.
I have recommended a few times to use switches such as ME3400 or more
recently
Hi,
On Sun, Aug 28, 2011 at 02:09:08PM +0200, Cisco NSP List wrote:
> I am thinking about the best practice to feed some low bandwitdh 4 Mb/s
> Ethernet over SDH links from a Cisco 6500/Sup720 with SXI IOS.
>
> The carrier equipment has 100Base-TX ports, does no noticable
> queuing/shaping and
Hi,
On Sun, Aug 28, 2011 at 11:12:44AM -0500, Tony Varriale wrote:
> Then hire someone that knows what they are doing.
Am I the only one to find that sort of remark a bit nasty?
While not sporting any nice certificates, I consider myself to be
somewhat experienced with Cisco platforms, and Cisc
Hi,
On Sun, Aug 28, 2011 at 10:23:57AM -0400, Matthew Huff wrote:
> Netflow *collection* of flows traversing the NAT-ed interface.
Thanks for clarification. Yes, indeed, that makes more sense (in a way)
and is not that easy to work around.
One could try some VRF tricks (NAT in one VRF, netflow
I have no idea if/whee this is supported on the 7200 but my first suggestion
would be to try T train code if you don't see it in mainline.
On Friday, August 26, 2011, Jay Hennigan wrote:
> I'm running IOS 12.4-12c advanced IP services.
>
> LACP is supposedly supported, and I can create a port-cha
> Then hire someone that knows what they are doing.
Hire someone who knows of undocumented limitations of future hardware
purchases. Right.
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tony
> Varriale
> Sent: Su
This is something I've pushed for in the past and is incredibly difficult to
do. I agree 100% that the CLI should be the first line of defense against
misconfiguration. One of the first challenges with this kind if check is the
need for the paraer to scan the entire config for compatiability everyt
On 8/27/2011 4:31 PM, Matthew Huff wrote:
If it was made apparent, could you point to any public documentation that
states that? I've scoured Cisco's site, google, and mail archives, and can't
find any mention (other than specific caveats) that state that NDE and hardware
assisted nat are not
likely we will either replace the entire hardware or leave it the way it is.
Having to increase latency to add monitoring is the tail wagging the dog.
Do you have the tools in place to comment on the latency it will
generate and the impact and loss of revenue to your customers?
As far as r
Hi All ,
Could you please provide inputs on this .
Thanks,
Ranjith
On Sat, Aug 27, 2011 at 11:04 PM, Ranjith R wrote:
> Hi All ,
>
> As part of a Failover scenario we have the below setup.
>
> R1 ( VPN router ) - R2 -GRE tunnel - R3 (
> internet router ) --- Int
> Bottom line: you *should* be able to trust vendor marketing, but you
> *can't*, and I strongly advise you don't, for Cisco or any other vendor
> - they simply don't convey accurate information reliably enough :o(
I agree. Caveat Emptor.
I would understand the limitation if I was using some unu
Netflow *collection* of flows traversing the NAT-ed interface. Sorry, I can see
why that would be confusing.
-Original Message-
From: Gert Doering [mailto:g...@greenie.muc.de]
Sent: Sunday, August 28, 2011 5:14 AM
To: Matthew Huff
Cc: 'Dale W. Carder'; 'cisco-nsp@puck.nether.net'
Subje
We don't have fragmented packets. I checked all the caveats. You missed my
point. I'm very aware of the restrictions with conflicting flowmasks, etc.
The problem is that the hardware assisted NAT uses netflow to insert a custom
tcam entry that doesn't get aged out. In other words, NDE will neve
Hello QoS experts,
I am thinking about the best practice to feed some low bandwitdh 4 Mb/s
Ethernet over SDH links from a Cisco 6500/Sup720 with SXI IOS.
The carrier equipment has 100Base-TX ports, does no noticable
queuing/shaping and aggressively drops everything over 4096 kb/s.
The link
Hi,
On Sun, Aug 28, 2011 at 03:39:54PM +0430, h bagade wrote:
> > You could have multiple inside and outside interfaces, and the router
> > needs to know when to NAT and when *not* to NAT.
>
> Yes, this is true that router should know about on which interfaces nat
> should be applied but it could
On Sun, Aug 28, 2011 at 2:24 PM, Gert Doering wrote:
> Hi,
>
> On Sun, Aug 28, 2011 at 01:38:53PM +0430, h bagade wrote:
> > I'm wondering why we should define both inside and outside interfaces to
> get
> > nat worked when we just only want to run inside source natting? In the
> case
> > of insi
On 08/27/2011 10:31 PM, Matthew Huff wrote:
As far as speaking to a TME, I work in small trading firm. We don't
have the luxury of long, involved RFP with detailed descriptions or
time to work with a TME to discuss every detail of every
configuration we use. We expect if a vendor advertise featu
You may have more interfaces where you do not want to nat.
> From: baga...@gmail.com
> Date: Sun, 28 Aug 2011 13:38:53 +0430
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] why to define both inside and outside interfaces when
> setting up nat?
>
> Hi all,
>
> I'm wondering why we sh
Hi,
On Sun, Aug 28, 2011 at 01:38:53PM +0430, h bagade wrote:
> I'm wondering why we should define both inside and outside interfaces to get
> nat worked when we just only want to run inside source natting? In the case
> of inside source nat, only outside interface is important for natting; the
>
Hello,
I have some Cisco 3825 Routers with VRF-lie active.
Inside the VRF I have BGP and OSPF with IPv4 running very well.
Is there also support to do that with IPv6?
Best regards
Lucien
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puc
Hi all,
I'm wondering why we should define both inside and outside interfaces to get
nat worked when we just only want to run inside source natting? In the case
of inside source nat, only outside interface is important for natting; the
packets are natted on their way outside so there is no need to
Hi,
On Sat, Aug 27, 2011 at 05:31:09PM -0400, Matthew Huff wrote:
> If it was made apparent, could you point to any public documentation
> that states that? I've scoured Cisco's site, google, and mail
> archives, and can't find any mention (other than specific caveats)
> that state that NDE and ha
39 matches
Mail list logo
