to only support ~50 DSL tails, and also have a limited budget - Are there
any alternatives to the 7200's that we can use for the above tasks? (Maybe
a 2800 or 2900?
We had a few 2821's running as LNS's ok in the past. Between 200 and
350 PPP sessions, OSPF, vrf-lite, 256 mem and hitting
On 10/14/2010 07:33 PM, Grzegorz Janoszka wrote:
On 14-10-10 09:40, Alexander Clouter wrote:
SXI4a is working fine on one of our 6500's and I updated from SXI3 to
SXI4a on the other two on Tuesday. No problems so far, although:
Just discovered an interesting bug on SXI4. Take an interface,
It appears the Anyconnect VPN client can now connect to IOS based VPN
Concentrators - has anyone had any experience on performance or Scaling with
that combination yet ?
IOS Support. Cisco supports Anyconnect 2.5 VPN access to IOS Release
15.1(2)T functioning as the secure gateway; however,
We were running 7200 NPEG1 terminating around 3000+ sessions at a
small-ish ISP I worked for. The CPU was way too high and we off-loaded
the LNS function to an open-source platform called L2TPNS running on a
couple of HP DL380 linux machines. These did the job well for the
bandwidth we offered
On 15-10-10 10:00, Phil Mayers wrote:
On 10/14/2010 07:33 PM, Grzegorz Janoszka wrote:
On 14-10-10 09:40, Alexander Clouter wrote:
SXI4a is working fine on one of our 6500's and I updated from SXI3 to
SXI4a on the other two on Tuesday. No problems so far, although:
Just discovered an
viable and cost-effective approach; any ideas if this package would
support L2TPv3? or if there is another open-source package that would do
L2TPv3?
--
Regards,
Ge Moua
Network Design Engineer
University of Minnesota | OIT - NTS
--
On 10/15/10 8:44 AM, Tom Devries wrote:
The CPU was way
I've got a 2811 running 12.4(24)T3. I'm trying to set it up as PPPoE
client.
Everything works fine when I do this in the global routing table:
interface Dialer1
ip address negotiated
ip mtu 1492
encapsulation ppp
dialer pool 1
dialer-group 1
ppp chap hostname ...
ppp
Hi Ed,
On Fri, 15 Oct 2010, Ed Ronayne wrote:
You need to re apply ip address neg to the dialler interface after
putting the interface into a vrf.
I've tried that. 'ip address negotiated' is accepted on the CLI, but
isn't applied, the dialer interface stubbornly retains no ip address.
I've
The time-honoured Windows solution has provided a fix. After a reload of
the router I am now able to apply 'ip address negotiated' to the dialer
interface and everything is working as expected.
-Ronan
On Fri, 15 Oct 2010, Ed Ronayne wrote:
You need to re apply ip address neg to the dialler
The I/G bit must be cleared in the source address of an Ethernet frame.
Ref: IEEE 802.3-2002, Section 3.2.3(b)
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at
On Fri, Oct 15, 2010 at 2:17 PM, christopher.mar...@usc-bt.com wrote:
The I/G bit must be cleared in the source address of an Ethernet frame.
Ref: IEEE 802.3-2002, Section 3.2.3(b)
I'm finding out more about what this firewall vendor is actually
trying to do. From what I can gather, it's
On 10/15/10, John Neiberger jneiber...@gmail.com wrote:
We have an application involving a firewall cluster where the cluster
has a VIP associated with it, but the VIP apparently replies to ARP
requests with a multicast MAC address. The idea, ultimately, is that
both firewalls in the cluster
On Fri, Oct 15, 2010 at 2:47 PM, Lee ler...@gmail.com wrote:
On 10/15/10, John Neiberger jneiber...@gmail.com wrote:
We have an application involving a firewall cluster where the cluster
has a VIP associated with it, but the VIP apparently replies to ARP
requests with a multicast MAC address.
jneiber...@gmail.com wrote:
On Fri, Oct 15, 2010 at 2:47 PM, Lee ler...@gmail.com wrote:
On 10/15/10, John Neiberger jneiber...@gmail.com wrote:
We have an application involving a firewall cluster where the cluster
has a VIP associated with it, but the VIP apparently replies to ARP
We use a multicast based load sharing cluster and you definitely must create
static ARP and CAM entries for this to work properly and I believe you must
also disable IGMP snooping. Cisco will not accept ARP response with I/G bit
set...
-Original Message-
From:
RFC 1812 section 3.3.2 says it shouldn't work:
A router MUST not believe any ARP reply that claims that the Link
Layer address of another host or router is a broadcast or multicast
address.
Yep, this is a Checkpoint cluster connected to Cisco switches. Once I
discovered the right
The product listing on this page (
http://www.cisco.com/en/US/products/hw/switches/ps5023/prod_models_comparison.html
) shows WS-C3750G-12S as being StackWise+ compatible. This is an older product
and even the literature on the other 3750v2s just references the original
StackWise technology.
Sean Granger wrote:
The product listing on this page (
http://www.cisco.com/en/US/products/hw/switches/ps5023/prod_models_comparison.html
) shows WS-C3750G-12S as being StackWise+ compatible. This is an older product
and even the literature on the other 3750v2s just references the original
On 2010-10-15 23:46, Sean Granger wrote:
The product listing on this page shows WS-C3750G-12S as being
StackWise+ compatible. This is an older product and even the
literature on the other 3750v2s just references the original
StackWise technology.
That's an error. I pinged the PMs for the
On 2010-10-16 01:00, Kevin Loch wrote:
The G models can link with stackwise plus (E,X models) but the
entire stack will operate in regular stackwise (suck) mode.
*Any* model of 3750 can stack with any other model, as long as
port-based features are at the same level. Ring will operate in
20 matches
Mail list logo
