* a...@baklawasecrets.com
- I could ask the question as to whether I can peer with separate
routers on each of the upstreams. i.e. to protect against router
failures on their side.
If you're getting transit from two different upstreams, you're pretty
much guaranteed to be connected to two
hello
i am playing with qos on some devices
- cisco 3560
- cisco 7609
and i have some things that i don't seem to understand.
1. in 3560, i enable mls qos, on the ingress port applyed policy map,
classify the packets with acl, mark, all good. on the egress ports i use
srr-queue with shape/share,
On second thoughts, thinking about this I am probably looking for some
kind of Layer2 encryption devices. This will make things a lot easier
for the deployment. Any experiences, thoughts on these types of devices,
would be much appreciated.
You could use OpenVPN, but that would be
You should make sure that any links that go between devices have trust
set. In your case if your doing DSCP,
then make sure each link that goes between devices which must carry
tagged packets have trust dscp set.
Brian
On Nov 12, 2009, at 5:11 AM, Bogdan wrote:
hello
i am playing with
KDDI, NTT, and WIDE are all on or adjacent to LAIIX.
if you hit those, your pretty much covered.
--bill
On Wed, Nov 11, 2009 at 12:34:24PM -0800, Operations wrote:
Greetings,
Im sure someone here is GREAT with connecting to Japan so I ask the
following:
We have a POP in 600 West
hello
indeed, a fellow nanoger gave me this hint.
1. i had to enable mls qos globally in network switches
2. set the mls qos trust dscp on the uplinks (ingress port)
thanks
ps thanks to andrey.gordon too :)
On 11/12/2009 03:21 PM, Brian Feeny wrote:
You should make sure that any links
Look at show mls qos map to see the defaults that may be rewriting
your information depending on trust (or non-trust) mechanisms you have
configured.
If you trust CoS, a frame received with cos5 and dscp46 will get
rewritten to dscp 40 with default maps...
show mls qos interface (intf) is also
All,
This may not be the right audience but I do not know of a better set of experts
to ask this question.
We monitor antivirus and spyware activity very close on our desktop and laptop
environment. Often you can correlate this activity with an increase in
bandwidth. The bandwidth is not an
Christian Seitz wrote:
There ist also a loose and a strict filter recommendation by Gert Doering [1],
but the strict filter is very strict at the moment. It allows only /48s from
RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also
assignes /47 or /46 from this range. Also
We've been getting more and more requests for ESPN360 from our
customers. From what i understand, ESPN requires that the ISP
subscribe to their content and pay a fee to do so. I have been unable
to find much information on what it takes to subscribe and what the fees
are to do so. Does anyone
On Wed, Nov 11, 2009 at 11:18:20AM -0800, Steve Gibbard wrote:
If you have three components, the chances of all three being broken at
once are even less than the chances of two of them being broken at
once. With four, you're even safer, and so on and so forth. But once
you get beyond two,
Guys,
I am wondering how many of you are doing layer 3 to top of rack switches and
what the pros and cons are. Also, if you are doing layer 3 to top of rack do
you guys have any links to published white papers on it?
Thanks,
Raj Singh
We are heading towards that type of deployment beginning next year with
Juniper EX4200 switches in a redundant configuration. This will be pure
Layer2 in nature on the switches and they will uplink to Juniper
M10i's for layer3... the power savings, space savings etc over
traditional Cisco 6500
On Nov 12, 2009, at 2:48 PM, Raj Singh wrote:
Guys,
I am wondering how many of you are doing layer 3 to top of rack
switches and what the pros and cons are. Also, if you are doing
layer 3 to top of rack do you guys have any links to published
white papers on it?
Dani Roisman gave an
We are actually looking at going Layer 3 all the way to the top of rack and
make each rack its own /24. This provides us flexibility when doing maintenance
(spanning-tree). Also, troubleshooting during outages is much easier by using
common tools like ping and trace routes.
I want to make sure
Steve Feldman wrote:
On Nov 12, 2009, at 2:48 PM, Raj Singh wrote:
Guys,
I am wondering how many of you are doing layer 3 to top of rack
switches and what the pros and cons are. Also, if you are doing layer
3 to top of rack do you guys have any links to published white papers
on it?
On Thu, Nov 12, 2009 at 12:19:36PM -0800, Seth Mattinen wrote:
I'd always wondered how you make a subnet available across racks with L3
rack switching. It seems that you don't.
~Seth
It's possible, with prior planning. You can have the uplinks be layer 2
trunks, with a layer 3 SVI in the
* David Ulevitch:
On 11/11/09 12:48 PM, Florian Weimer wrote:
Since people need to *explicitly* choose using the OpenDNS servers, I
can hardly see how anybody's wishes are foisted on these people.
If you don't like the answers you get from this (free) service, you
can of course choose to
If you use stackable switches, you can stack across cabinets (up to 3 with 1
meter Cisco 3750 Stackwise), and uplink on the ends. It's a pretty solid
layout if you plan your port needs properly based on NIC density and cabinet
size, plus you can cable cleanly to an adjacent cabinet's switch if
On Thu, Nov 12, 2009 at 2:40 PM, Bulger, Tim tim_bul...@polk.com wrote:
If you use stackable switches, you can stack across cabinets (up to 3 with
1 meter Cisco 3750 Stackwise), and uplink on the ends. It's a pretty solid
layout if you plan your port needs properly based on NIC density and
On 12/11/2009 20:40, Bulger, Tim wrote:
Slightly off-topic.. Consider offloading 100Mb connections like PDUs,
DRAC/iLO, etc. to lower cost switches to get the most out of your
premium ports.
Not just that, you can also use lower cost switches to move your management
fully out-of-band with
Seth Mattinen wrote:
I'd always wondered how you make a subnet available across racks with L3
rack switching. It seems that you don't.
You could route /32s within your L3 environment, or maybe even leverage
something like VPLS - Not sure of any TOR-level switches that MPLS
pseudowire a port
Hej,
Am 12.11.2009 21:04 Uhr schrieb Raj Singh:
We are actually looking at going Layer 3 all the way to the top of rack and
make each rack its own /24.
what a waste of IPs and unnecessary loss of flexibility!
This provides us flexibility when doing maintenance (spanning-tree).
If you use a
Raj Singh wrote:
We are actually looking at going Layer 3 all the way to the top of rack and make each rack its own /24. This provides us flexibility when doing maintenance (spanning-tree). Also, troubleshooting during outages is much easier by using common tools like ping and trace routes.
I'm
Excerpts from David Coulson's message of Thu Nov 12 13:07:35 -0800 2009:
You could route /32s within your L3 environment, or maybe even leverage
something like VPLS - Not sure of any TOR-level switches that MPLS
pseudowire a port into a VPLS cloud though.
I was recently looking into this
Jonathan Lassoff wrote:
I was recently looking into this (top-of-rack VPLS PE box). Doesn't seem
to be any obvious options, though the new Juniper MX80 sounds like it
can do this. It's 2 RU, and looks like it can take a DPC card or comes
in a fixed 48-port GigE variety.
The MX-series are
Hi,
Am 12.11.2009 22:29 Uhr schrieb Jonathan Lassoff:
Are there any applications that absolutely *have* to sit on the same
LAN/broadcast domain and can't be configured to use unicast or multicast
IP?
yes. There are at least some implementations of iSCSI and the accompanying
management
I believe the issue will become a moot point in the next 12 months when
vendors begin to ship switches with TRILL.
TRILL is basically a layer 2 routing protocol that will replace spanning
tree. It will allow you to connect several uplinks, utilize all the
bandwidth of the uplinks, prevent loops,
I believe TRILL will render this discussion moot. It should be shipping
on gear from various vendors within the next year.
-Original Message-
From: Malte von dem Hagen [mailto:m...@hosteurope.de]
Sent: Thursday, November 12, 2009 1:09 PM
To: Raj Singh
Cc: nanog@nanog.org
Subject: Re:
On 2009-11-12 22:37, David Coulson wrote:
The MX-series are pretty nice. That should be able to do VPLS PE,
however I've never tried it - MX240 did it pretty well last time I
tried. I've no clue how the cost of that switch compares to a cisco 4900
or something (not that a 4900 is anything
Randy Bush wrote:
It has been routinely observed in nanog presentations that settlement
free providers by their nature miss a few prefixes that well connected
transit purchasing ISPs carry.
just trying to understand what you mean,
o no transit-free provider actually has all (covering)
Kevin Oberman ober...@es.net writes:
I find it mildly amusing that my first contact with Paul was about 25
years ago when he was at DEC and I objected to his use of a wildcard for
dec.com.
I was only an egg.
The situations are not parallel and the Internet was a very different
animal in
Well,
If it counts Paul, thanks for vixie cron. ;)
-Original Message-
From: Paul Vixie [mailto:vi...@isc.org]
Sent: Thursday, November 12, 2009 4:58 PM
To: na...@merit.edu
Subject: Re: What DNS Is Not
Kevin Oberman ober...@es.net writes:
I find it mildly amusing that my first
I would suggest doing a VC with the TOR switches. That way you can
have one switch for a lot of racks (I believe 10 would be the upper
limit if using Juniper). If you have a VC you could do L3 and L2
where needed on every rack that the VC covers.
// Olof
2009/11/13 Łukasz Bromirski
34 matches
Mail list logo
