Re: Layer 2 vs. Layer 3 to TOR

[Olof Kasselstrand]

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 :
> 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 special - L3 is all in
>> software).
>
> For both 4948/4948-10GE and 4900M L3 is in hardware. For
> 4948/4948-10GE IPv6 is in software, for 4900M it's in hardware.
>
> --
> "Everything will be okay in the end. |                  Łukasz Bromirski
>  If it's not okay, it's not the end. |       http://lukasz.bromirski.net
>
>

RE: What DNS Is Not

[Warren Bailey]

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"  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 those days (and DEC was mostly DECnet), but still I managed 
> to maintain a full set of MX records for all of our DECnet systems.

Based partly on my conversation with you, I ended up pulling over the
list of DECnet nodes and generating MX's for each one, just to remove
that wildcard.  You were right, and I listened.  Probably I forgot to
thank you until now.  Thanks.
--
Paul Vixie
KI6YSY

Re: What DNS Is Not

[Paul Vixie]

"Kevin Oberman"  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 those days (and DEC was mostly DECnet), but still I managed to
> maintain a full set of MX records for all of our DECnet systems.

Based partly on my conversation with you, I ended up pulling over the
list of DECnet nodes and generating MX's for each one, just to remove
that wildcard.  You were right, and I listened.  Probably I forgot to
thank you until now.  Thanks.
-- 
Paul Vixie
KI6YSY

Re: Failover how much complexity will it add?

[Joel Jaeggli]

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) prefixes needed
> to cover the active space, but
> 
>   o one or more reasonably small subsets of the set of transit-free
> providers do cover the whole active space.

If your goal is near-complete coverage, under normal circumstances you
need more than one (your subset). Settlement-free provider peering spats
are a degenerate condition of the normal state of affairs. The
non-settlement-free provider has some subset already.

Pointing default into a settlement-free provider, that is deliberately
not speaking to another is obviously a recipe to lose data, which speaks
to the question of whether one should as for a full table from
settlement free upstreams.

My somewhat obtuse point was that this isn't some wild west frontier
justice sort of affair, but rather, the normal state of affairs.

> randy
> 

Re: Layer 2 vs. Layer 3 to TOR

[Łukasz Bromirski]

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 special - L3 is all in software).


For both 4948/4948-10GE and 4900M L3 is in hardware. For
4948/4948-10GE IPv6 is in software, for 4900M it's in hardware.

--
"Everything will be okay in the end. |  Łukasz Bromirski
 If it's not okay, it's not the end. |   http://lukasz.bromirski.net

RE: Layer 2 vs. Layer 3 to TOR

[George Bonser]

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: Layer 2 vs. Layer 3 to TOR

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!

RE: Layer 2 vs. Layer 3 to TOR

[George Bonser]

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, and find the best path to the
destination through the switch fabric.  Think of it like OSPF for layer
2.

It should be shipping within the next 6 to 9 months.



-Original Message-
From: Raj Singh [mailto:raj.si...@demandmedia.com] 
Sent: Thursday, November 12, 2009 11:49 AM
To: 'nanog@nanog.org'
Subject: Layer 2 vs. Layer 3 to TOR

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

Re: Layer 2 vs. Layer 3 to TOR

[Malte von dem Hagen]

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 services (e.g., for redundancy) that do not work well via routed
connections. Generally, storage services may be difficult being routed.

Further, some aspects of VMware (clusters) including management "need" L2
connectivity, for example when you want to dynamically shift VMs from one
hardware node to another transparently and so on and so forth.

The same applies to several load balancing and/or redundancy/failover 
mechanisms.

rgds,

.m



signature.asc
Description: OpenPGP digital signature

Re: Layer 2 vs. Layer 3 to TOR

[David Coulson]

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 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 special - L3 is all in software).

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?
  
The biggest hurdle we hit when trying to do TOR L3 (Cisco 4948s w/ /24s 
routed to each one) was devices that either required multiple physical 
Ethernet connections that we typically use LACP with, or any 
environments that do IP takeover for redundancy. Both are obviously 
easily worked around if you run an IGP on your servers, but that was 
just insanely complex for our environment. It's hard to convince people 
that a HP-UX box needs to work like a router now.


So now we have a datacenter full of 4948s doing pure L2 and spanning 
tree... What a waste :-)

Re: Layer 2 vs. Layer 3 to TOR

[Jonathan Lassoff]

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 (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.

I like the idea of doing IP routing to a top-of-rack or edge device, but
have found others to be skeptical.

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?

--j

Re: Layer 2 vs. Layer 3 to TOR

[David Coulson]

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 confused where STP fits into this. If you're doing /24s to each 
switch, why even bring STP into the picture? Do /31s to each TOR switch 
and use OSPF or ISIS. I don't know too many people who have not had an 
awful experience with STP at some point.

Re: Layer 2 vs. Layer 3 to TOR

[Malte von dem Hagen]

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 simple setup for aggregation, you do not need xSTP. Even including
redundancy, RTG (big C: flex-link) will be sufficient. Spanning the L2 over more
than one rack is dirty when you do L3 on the TORs, because you need to build a
Virtual Chassis or VPLS tunnels (not sure if EX4200 does that as of today).

> Also, troubleshooting during outages is much easier by using
> common tools like ping and trace routes.

Oh, c'mon. Yes, Layer 2 is a wild jungle compared to clean routing, but tracing
isn't that magic there. You have LLDP, mac-address-tables, arp-tables...

> I want to make sure this is something other people are doing out there and
> want to know if anyone ran into any issues with this setup.

From the design POV, it is a clean and nice concept to do L3 on the
TOR-switches, but in real life, it's not working very well. Everytime I played
with such, with every vendor I've seen, there is just always the same 
conclusion:

Let routers route and let switches switch.

Switches which are supposed to do routing never scale, provide almost always
immature implementations of common L3 features and run into capacity problems
just too fast (too small tables for firewall roules, route entries, no full IPv6
capabilities, sometimes expensive licenses needed for stuff like IS-IS...).

I understand the wish to keep broadcast domains small and network paths
deterministic and clean, but the switches you can buy today for
not-too-much-money aren't ready yet.

So my hint is: Look at model #4 from the mentioned NANOG presentation.

My 2 Euro-Cents,

.m



signature.asc
Description: OpenPGP digital signature

Re: Layer 2 vs. Layer 3 to TOR

[David Coulson]

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 into a VPLS cloud though.


Kinda makes L3 and spanning tree sound like a great option, doesn't it?

Re: Layer 2 vs. Layer 3 to TOR

[Nick Hilliard]

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 respect to your production traffic.  This can work 
well in times of catastrophe.


Nick

Re: Layer 2 vs. Layer 3 to TOR

[Brandon Galbraith]

On Thu, Nov 12, 2009 at 2:40 PM, Bulger, Tim  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 cabinet
> size, plus you can cable cleanly to an adjacent cabinet's switch if
> necessary.
>
> 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.
>

Agreed. We use Netgear gigabit unmanaged switches for what Tim suggests to
save the higher-cost-per-port switchports for server gear.

-brandon



> -Tim
>
> -Original Message-
> From: Seth Mattinen [mailto:se...@rollernet.us]
> Sent: Thursday, November 12, 2009 3:20 PM
> To: 'nanog@nanog.org'
> Subject: Re: Layer 2 vs. Layer 3 to TOR
>
> 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?
> >
> > Dani Roisman gave an excellent talk on this subject at NANOG 46 in
> > Philadelpha:
> >
> >
> >
> http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTQwOCZuYW5vZzQ2&nm=nanog46
> >
>
>
> I'd always wondered how you make a subnet available across racks with L3
> rack switching. It seems that you don't.
>
> ~Seth
>
>


-- 
Brandon Galbraith
Mobile: 630.400.6992
FNAL: 630.840.2141

Re: What DNS Is Not

[Florian Weimer]

* 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 use a different service - for instance your
>>> ISP's name servers.
>>
>> What if your ISP's name servers are those from OpenDNS?
>
> We don't sell service to ISPs.  That's a deliberate decision.  But you
> already knew that.

No, I'm genuinely surprised, really.  After all, there is
.  Generally, I've got
less knowledge about OpenDNS than you might think.

RE: Layer 2 vs. Layer 3 to TOR

[Bulger, Tim]

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 necessary.

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.

-Tim

-Original Message-
From: Seth Mattinen [mailto:se...@rollernet.us] 
Sent: Thursday, November 12, 2009 3:20 PM
To: 'nanog@nanog.org'
Subject: Re: Layer 2 vs. Layer 3 to TOR

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?
> 
> Dani Roisman gave an excellent talk on this subject at NANOG 46 in
> Philadelpha:
> 
>  
> http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTQwOCZuYW5vZzQ2&nm=nanog46
> 


I'd always wondered how you make a subnet available across racks with L3
rack switching. It seems that you don't.

~Seth

Re: Layer 2 vs. Layer 3 to TOR

[Brandon Ewing]

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 trunk acting as your actual routed uplink.

Requires much planning in advance regarding what vlans are trunked where,
etc.  Allows one to do layer 3 termination at top of rack for single
servers, but offer vlans that span multiple layer 3 switches with HSRP at
distribution as an option for systems/services that require a common
broadcast domain.

-- 
Brandon Ewing(nicot...@warningg.com)


pgp3m64VUTGYE.pgp
Description: PGP signature

Re: Layer 2 vs. Layer 3 to TOR

[Seth Mattinen]

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?
> 
> Dani Roisman gave an excellent talk on this subject at NANOG 46 in
> Philadelpha:
> 
>  
> http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTQwOCZuYW5vZzQ2&nm=nanog46
> 


I'd always wondered how you make a subnet available across racks with L3
rack switching. It seems that you don't.

~Seth

RE: Layer 2 vs. Layer 3 to TOR

[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. 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 this is something other people are doing out there and want 
to know if anyone ran into any issues with this setup.


Thanks,
Raj Singh   |Director Network Engineering
_
Demand Media | eNom, Inc.
Direct: 425.974.4679
15801 NE 24th St.
Bellevue, WA 98008
raj.si...@demandmedia.com


-Original Message-
From: Paul Stewart [mailto:pstew...@nexicomgroup.net] 
Sent: Thursday, November 12, 2009 11:53 AM
To: Raj Singh; nanog@nanog.org
Subject: RE: Layer 2 vs. Layer 3 to TOR

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 chassis (plus all the cabling between cabinets
which is in our case a nightmare) made this a pretty easy choice... and
price too..;)

Somewhere on Juniper's website in the product info section they have
deployment whitepapers on this kind of stuff if that's of interest

Hope this helps..

Paul


-Original Message-
From: Raj Singh [mailto:raj.si...@demandmedia.com] 
Sent: November-12-09 2:49 PM
To: 'nanog@nanog.org'
Subject: Layer 2 vs. Layer 3 to TOR

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




 



"The information transmitted is intended only for the person or entity to which 
it is addressed and contains confidential and/or privileged material. If you 
received this in error, please contact the sender immediately and then destroy 
this transmission, including all attachments, without copying, distributing or 
disclosing same. Thank you."

Re: Layer 2 vs. Layer 3 to TOR

[Steve Feldman]

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 excellent talk on this subject at NANOG 46 in  
Philadelpha:


  
http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTQwOCZuYW5vZzQ2&nm=nanog46

Steve

RE: Layer 2 vs. Layer 3 to TOR

[Paul Stewart]

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 chassis (plus all the cabling between cabinets
which is in our case a nightmare) made this a pretty easy choice... and
price too..;)

Somewhere on Juniper's website in the product info section they have
deployment whitepapers on this kind of stuff if that's of interest

Hope this helps..

Paul


-Original Message-
From: Raj Singh [mailto:raj.si...@demandmedia.com]
Sent: November-12-09 2:49 PM
To: 'nanog@nanog.org'
Subject: Layer 2 vs. Layer 3 to TOR

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








"The information transmitted is intended only for the person or entity to which 
it is addressed and contains confidential and/or privileged material. If you 
received this in error, please contact the sender immediately and then destroy 
this transmission, including all attachments, without copying, distributing or 
disclosing same. Thank you."

Layer 2 vs. Layer 3 to TOR

[Raj Singh]

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

Re: Resilience - How many BGP providers

[Richard A Steenbergen]

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, you hit a point of diminishing returns pretty
> quickly.

Not only that, but you have to ask yourself what are the chances that
all these extra components will become extra points of failure and
actually increase the likelihood of something going wrong. I know a lot
of folks who have gotten themselves into a lot of trouble buying transit
from everyone they can possibly buy from, thinking it will make their
network more reliable. In most cases all it does is make their network
more unstable. The more transit paths you have out there, the more
likely you are to have something flap and wipe you out w/flap dampening,
and the more likely you are to see any single event cause a massive
amount of churn. I've seen people with 8 transit providers appear to
others on the internet as though they flapped 100+ times over a single
session flap, because of all the churn as the network reconverges. More
transit providers also means more 95th calculations, and thus a higher
bill, but that is another story for another day. :)

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

ESPN360 Access

[Chris Gotstein]

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 have more info on ESPN360?  Thanks.

-- 
   
Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
http://uplogon.com | +1 906 774 4847 | ch...@uplogon.com

RE: qos 3560

[Bogdan]

> Following on, the best way is to 'trust' on all uplinks between devices
> and filter at the edge. So you have a customer who shouldn't be sending
> tagged traffic, set the port to not trusted (should be the default
> state) and any customer using QoS should have "mls qos trust dscp" on
> the demark port.
>
> If you don't have a trusted core, then all it takes is a simple switch
> in the path traffic takes and you'll find yourself scratching your head
> as to why the DSCP tags are disappearing all of a sudden!



indeed, i do see another dscp value in the counters. (besides mine).
i tried with dscp mutation and re-mapping, but it did't work.
so..start NOT trusting the edge/customers ports.

>
>
> Paul
>
>
>
> -Original Message-
> From: Scott Morris [mailto:s...@emanon.com]
> Sent: 12 November 2009 14:41
> To: Bogdan
> Cc: nanog@nanog.org
> Subject: Re: qos 3560
>
> 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 good to see status.
>
> Scott
>
>
>
> Bogdan wrote:
>> 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 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 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, everything is fine, it is working.


> http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/relea
> se/12.2_20_se/configuration/guide/swqos.html#wp1028614



 2. reset to defaults the 3560
 in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on
 egress of that vlan
 3560 in uplinked in 7609
 in 3560 i can see the "marked" packets, and i have matches on the
> dscp
 set earlier (sh mls qos int xx stat).
 the problem is: when i apply the srr-queue in 3560 on egress
> (towards
 the test port), it does not work.
 if i enable mls qos on 3560, i cannot match anymore the dscp 40 from
> the
 7609

 is it normal? do i have to apply the qos stuff (point1) on all
> switches
 i want qos on? i mean, i cannot set dscp in one "core" device and
> use
 that in the whole network ?


 thanks



>>>
>>
>>
>>
>>
>>
>
>
>
> For more information about the Viatel Group, please visit www.viatel.com
>
> VTL (UK) Limited Registered in England and Wales
> Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR
> Company Registration No: 04287100 VAT Registration Number: 781 4991 88
>
> THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO
> WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED,
> CONFIDENTIAL AND EXEMPT FROM DISCLOSURE.  If the reader of this message is
> not the intended recipient, or an employee or agent responsible for
> delivering the message to the intended recipient, you are notified that
> any dissemination, distribution or copying of this e-mail is prohibited,
> and you should delete this e-mail from your system.
>
> This message has been scanned for viruses and spam by Viatel MailControl -
> www.viatel.com
>
>

Re: Minimum IPv6 size

[Grzegorz Janoszka]

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 there should be some deaggregation
allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for
some reason, because he cannot get a second /32, he should be able to use (eg.)
4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32
prefixes, but I would accept prefixes up to a /36.

[1] http://www.space.net/~gert/RIPE/ipv6-filters.html


I was thinking about such filters still for v4. Does anyone know if
there are any /8's which have no /24 prefixes assigned? I thought about
filtering out all deaggregated /24's from such /8's. (I care more about
memory of my routers than on a traffic profile of a small company on
another continent).

Another thing:

http://www.db.ripe.net/whois?form_type=simple&full_query_string=&searchtext=193.34.199.0&submit.x=0&submit.y=0&submit=Search 




This is a normal /25 assigned as PI with route record /25. Are they
assigned in any given /8 prefix? If yes, you could easily allow /25's
from given /8.

--
Grzegorz Janoszka

Spyware and Antivirus detection increase

[Elijah Savage]

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 issue but this month we see a very big spike 
in antivirus and spyware detection compared to last month, 12,000 detections 
last month compared to 38,000 so far this month.

We have all the data and know what signatures are being tripped and a good idea 
of where they are coming from.

The question I have is this, is anyone else seeing an increase and have any 
idea why? Is it just the time of the year with it being the holiday season? 

RE: qos 3560

[Martin, Paul]

Following on, the best way is to 'trust' on all uplinks between devices
and filter at the edge. So you have a customer who shouldn't be sending
tagged traffic, set the port to not trusted (should be the default
state) and any customer using QoS should have "mls qos trust dscp" on
the demark port.

If you don't have a trusted core, then all it takes is a simple switch
in the path traffic takes and you'll find yourself scratching your head
as to why the DSCP tags are disappearing all of a sudden!


Paul



-Original Message-
From: Scott Morris [mailto:s...@emanon.com] 
Sent: 12 November 2009 14:41
To: Bogdan
Cc: nanog@nanog.org
Subject: Re: qos 3560

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 good to see status.

Scott



Bogdan wrote:
> 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 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 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, everything is fine, it is working.
>>>
>>>
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/relea
se/12.2_20_se/configuration/guide/swqos.html#wp1028614
>>>
>>>
>>>
>>> 2. reset to defaults the 3560
>>> in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on
>>> egress of that vlan
>>> 3560 in uplinked in 7609
>>> in 3560 i can see the "marked" packets, and i have matches on the
dscp
>>> set earlier (sh mls qos int xx stat).
>>> the problem is: when i apply the srr-queue in 3560 on egress
(towards
>>> the test port), it does not work.
>>> if i enable mls qos on 3560, i cannot match anymore the dscp 40 from
the
>>> 7609
>>>
>>> is it normal? do i have to apply the qos stuff (point1) on all
switches
>>> i want qos on? i mean, i cannot set dscp in one "core" device and
use
>>> that in the whole network ?
>>>
>>>
>>> thanks
>>>
>>>
>>>   
>> 
>
>
>
>
>   



For more information about the Viatel Group, please visit www.viatel.com

VTL (UK) Limited Registered in England and Wales
Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR  
Company Registration No: 04287100 VAT Registration Number: 781 4991 88

THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT 
IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND 
EXEMPT FROM DISCLOSURE.  If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering the message to 
the intended recipient, you are notified that any dissemination, distribution 
or copying of this e-mail is prohibited, and you should delete this e-mail from 
your system.

This message has been scanned for viruses and spam by Viatel MailControl - 
www.viatel.com

Re: qos 3560

[Scott Morris]

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 good to see status.

Scott



Bogdan wrote:
> 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 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 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, everything is fine, it is working.
>>>
>>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_20_se/configuration/guide/swqos.html#wp1028614
>>>
>>>
>>>
>>> 2. reset to defaults the 3560
>>> in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on
>>> egress of that vlan
>>> 3560 in uplinked in 7609
>>> in 3560 i can see the "marked" packets, and i have matches on the dscp
>>> set earlier (sh mls qos int xx stat).
>>> the problem is: when i apply the srr-queue in 3560 on egress (towards
>>> the test port), it does not work.
>>> if i enable mls qos on 3560, i cannot match anymore the dscp 40 from the
>>> 7609
>>>
>>> is it normal? do i have to apply the qos stuff (point1) on all switches
>>> i want qos on? i mean, i cannot set dscp in one "core" device and use
>>> that in the whole network ?
>>>
>>>
>>> thanks
>>>
>>>
>>>   
>> 
>
>
>
>
>   

Re: qos 3560

[Bogdan]

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 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 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, everything is fine, it is working.
>>
>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_20_se/configuration/guide/swqos.html#wp1028614
>>
>>
>>
>> 2. reset to defaults the 3560
>> in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on
>> egress of that vlan
>> 3560 in uplinked in 7609
>> in 3560 i can see the "marked" packets, and i have matches on the dscp
>> set earlier (sh mls qos int xx stat).
>> the problem is: when i apply the srr-queue in 3560 on egress (towards
>> the test port), it does not work.
>> if i enable mls qos on 3560, i cannot match anymore the dscp 40 from the
>> 7609
>>
>> is it normal? do i have to apply the qos stuff (point1) on all switches
>> i want qos on? i mean, i cannot set dscp in one "core" device and use
>> that in the whole network ?
>>
>>
>> thanks
>>
>>
>
>

Re: Performance to and from Japan (who to connect to?)

[bmanning]

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 7th street, Los Angeles.
> 
> What provider can I cross-connect to there to get better performance  
> to Japan?
> Are there Japanese providers on net in that building?
> 
> Anyone want to peer with me there that can give me better routing to  
> Japan?
> 
> Thank you very much Nanog.
> 
> NJ
> Critical Data Network
> http://www.critical.net
> 
> 

Re: qos 3560

[Brian Feeny]

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 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, everything is fine, it is working.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_20_se/configuration/guide/swqos.html#wp1028614


2. reset to defaults the 3560
in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on
egress of that vlan
3560 in uplinked in 7609
in 3560 i can see the "marked" packets, and i have matches on the dscp
set earlier (sh mls qos int xx stat).
the problem is: when i apply the srr-queue in 3560 on egress (towards
the test port), it does not work.
if i enable mls qos on 3560, i cannot match anymore the dscp 40 from  
the

7609

is it normal? do i have to apply the qos stuff (point1) on all  
switches

i want qos on? i mean, i cannot set dscp in one "core" device and use
that in the whole network ?


thanks

Re: Gig Throughput on IPSEC

[Florian Weimer]

>  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 cheating. 8-)

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

qos 3560

[Bogdan]

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, everything is fine, it is working.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_20_se/configuration/guide/swqos.html#wp1028614


2. reset to defaults the 3560
in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on
egress of that vlan
3560 in uplinked in 7609
in 3560 i can see the "marked" packets, and i have matches on the dscp
set earlier (sh mls qos int xx stat).
the problem is: when i apply the srr-queue in 3560 on egress (towards
the test port), it does not work.
if i enable mls qos on 3560, i cannot match anymore the dscp 40 from the
7609

is it normal? do i have to apply the qos stuff (point1) on all switches
i want qos on? i mean, i cannot set dscp in one "core" device and use
that in the whole network ?


thanks

Re: Resilience - How many BGP providers

[Tore Anderson]

* 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 different routers.  Unless you're
thinking about establishing redundant connections to each provider, that is.

What you should ensure, though, is that the PoPs of the two upstreams
are not found in the same physical building (or neighbourhood for that
matter), and that the fibres that connects you to those PoPs never
cross - it doesn't really help that much with two trenches on each side
of your building if the paths converge 1km away from it.  You might also
want to consider getting the fibres from two different providers to
guard against contract-related disputes, unexpected bankruptcies, or
similar that would cause the fibre provider to terminating/suspending
your service.

> - I will make sure that neither upstream peers with the other
> directly.

This does not make any sense, if you're talking about peering.  Peering
is a good thing for reliability and performance.  I see from the rest of
your e-mail that you're mixing up the terms peering and transit, though,
so if you're taking about your provider A purchasing transit from
provider B, it makes perfect sense - at least if provider A is _only_
getting transit from B.  If on the other hand provider A is getting
transit from C, D, and E in addition to B, it's not really a problem.

It might also be the case that A and B both get transit from C only,
which would make C a single point of failure for you.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27