When you implement broadband access services for a lot of clients - you use ES+
cards to control internet access speed.
When you have about 30K VPLS services sold out among all the city - you use ES+
cards to control speed of these services and build QoS hierarchy for marked
traffic within one
7600 routers have almost no reason to use ip flow ingress / ip flow egress
commands. They use NDE through PFC, because it's hardware architecture is very
different from 7200 routers.
On Jan 25, 2010, at 11:59 PM, Atif Sid wrote:
New code 12.2(33)SRE have removed the command ip flow egress
On 01/25/2010 08:59 PM, Atif Sid wrote:
New code 12.2(33)SRE have removed the command ip flow egress from the
interfaces. it shows the command but does not configure it?
example:
7600s with PFC-based linecards don't support egress netflow, because the
hardware does not - only ingress. Is
This morning we had a crash on a remote site router, a single-sup720
6504 running 12.2(33)SXI (I know, it needs upgrading).
I got in over our out-of-band network and found the sup sitting at
rommon, so typed reset, and it said:
System Bootstrap, Version 12.2(17r)S4, RELEASE SOFTWARE (fc1)
Hi Charles,
Firstly, disclosure time, over a year ago, I was UK
SE/Implementation-engineer for Bluecat's sole disty in the UK, up until
the point they pulled distribution and went direct-to-reseller. During
that time I rolled out implementations including a UK ISP, a UK-wide
distributed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Pavel, rest,
sorry for coming back on the topic. I had now the time to play with the setup
a bit more and run into a problem: pvlans are not working well.
The config:
having a core router 6509 with a port channel on two gigE Ports (Gi3/13 and 15)
Hi Sven,
I had not exactly the same but similar issues but with 7606 - see
http://www.mail-archive.com/cisco-nsp@puck.nether.net/msg26651.html. I
learned from TAC that the issue was with the fact that I used it in
combination with VRFs and the traffic got incorrectly punted into 7606
MSFC CPU
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Pavel,
Pavel Skovajsa schrieb:
Hi Sven,
I had not exactly the same but similar issues but with 7606 - see
http://www.mail-archive.com/cisco-nsp@puck.nether.net/msg26651.html. I
learned from TAC that the issue was with the fact that I used it
I have experienced this exact same issue as well. I was told by my SE
that it had to do with the way the input was connected to the rest of
the unit.
Scott
On Jan 25, 2010, at 8:55 PM, Vincent C Jones wrote:
Another possibility, given that it is a PIX501, is a loose power
connection.
On Tue, Jan 26, 2010 at 3:15 PM, Sven 'Darkman' Michels s...@darkman.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Pavel,
Pavel Skovajsa schrieb:
Hi Sven,
I had not exactly the same but similar issues but with 7606 - see
Is any one running SDR on the CRS platform? Are there any issues?
One area that I am unclear on is the linecard requirements, documenation
states that an additional DRP or DRP pair must be utilized, so does that
mean
you require at least one DRP for overall chassis management and
additional DRP
Anyone know if 802.1x is supported on this line card? Not finding the answer
on Cisco's web site or anywhere else. My Sup's gig port looks like this:
PSRB-U01-AS-01#sh int g1/1 cap
GigabitEthernet1/1
Model: WS-X4515-Gbic
Type: 1000BaseSX
You need 1. The second DRP would be standby if so desired.
In your example you should be able to get away with 2.
Your RPs still handle overall system management.
Aaron
On Tue, Jan 26, 2010 at 10:06, My Name denac...@gmail.com wrote:
Is any one running SDR on the CRS platform? Are there any
I'm trying to troubleshoot connectivity problems between a virtual server at a
central site and PCs in the same vlan at a remote site. At the central site is
several VMWare servers connected to a 3560 switch. The PCs at the remote site
need to reach this virtual server, and while most do, some
On 26/01/10 16:34, Steven Pfister wrote:
I'm trying to troubleshoot connectivity problems between a virtual
server at a central site and PCs in the same vlan at a remote site.
At the central site is several VMWare servers connected to a 3560
switch. The PCs at the remote site need to reach this
Just wanted to follow up with some more details on this network set up...
[remote side 4500] (CSME) [central side 4500] (ATM)
[central side 8540] [vmware 3560] [vmware server]
the remote side has a vlan, let's call it 321, and the vmware server has a
virtual
Steven Pfister wrote:
Just wanted to follow up with some more details on this network set up...
[remote side 4500] (CSME) [central side 4500] (ATM) [central
side 8540] [vmware 3560] [vmware server]
Steve, is that CSME link the managed ethernet product from
@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4807 (20100126) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Antivirus, version of virus
signature
database 4807 (20100126) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4808 (20100126) __
The message was checked
What devices do the VPN tunnels terminate on? If they are Cisco routers, it
should be pretty straightforward to run BGP between the VPN endpoints as
well. You can use AS padding and local preference for manipulating the
preferred path for the incoming and outgoing traffic respectively.
Regards,
* Configure EBGP sessions over IPSec between remote sites and central site.
* On remote sites use EEM to detect MPLS VPN EBGP neighbor loss (either default
route is gone or you might rely on SNMP traps)
* When the MPLS VPN EBGP neighbor is down, enable IPSec tunnel. Only then will
the EBGP
21 matches
Mail list logo
