On 6/3/13 10:04 PM, Ivan Pepelnjak wrote:
Did you read the part about DC switches in general and Nexus 5500 in particular?
Nexus 5500 is not a particularly capable layer 3 switch, due to the
magic of cam partitioning it supports only 128 LPM (longer than 64bit
route) entries for v6 so you'd better be prepared to summarize. Lets go
back to the statement...
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on longer
than
/64 prefixes, so attempting to do so starts to either heat up the
software slow path, or consume ACL entries, or is simply not
supported at all. While this is arguably a bug, it is also pretty
much ubiquitous in the current generation of ethernet switches,
which are the basis for the majority of routers.
none of those statements are true when applied to the nexus 5500.
-----Original Message-----
From: joel jaeggli [mailto:joe...@bogus.com]
Sent: Tuesday, June 04, 2013 6:27 AM
To: Ivan Pepelnjak
Cc: Andrew McGregor; Brian E Carpenter; v6...@ietf.org WG; ipv6@ietf.org;
manning bill
Subject: Re: [v6ops] Could IPv6 address be more than locator?//draft-
jiang-v6ops-semantic-prefix-03
On 6/3/13 7:11 PM, Ivan Pepelnjak wrote:
Read the recent "p2p /64" thread of ipv6-ops cluenet mailing list
You are refering to:
http://lists.cluenet.de/pipermail/ipv6-ops/2013-June/thread.html
I stand by my statement...
The inability to properly apply ACLs on the 3750 for routes longer than
/64 on some 3750 variants is a problem. A route is not an ACL. Using an
mock modifed eui64 address for your loopback address so that your control-
plane acl works properly seems asine I will give you that.
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release
/12.2_55_se/commmand/reference/cli2.html#wp11682185
cam tables are designed or partitioned in general to favor ipv4 route
count over ipv6, while route table size is impacted that does not affect
throughput.
=====
Mistyped and autocorrected on a clunky virtual keyboard
On 4. jun. 2013, at 01:08, joel jaeggli <joe...@bogus.com> wrote:
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on longer than
/64 prefixes, so attempting to do so starts to either heat up the software
slow path, or consume ACL entries, or is simply not supported at all.
While this is arguably a bug, it is also pretty much ubiquitous in the
current generation of ethernet switches, which are the basis for the
majority of routers.
please cite specifics. I have no devices in the field that have such a
limitation.
joel
On Tue, Jun 4, 2013 at 6:27 AM, Brian E Carpenter
<brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>> wrote:
On 04/06/2013 03:44, manning bill wrote:
> On 2June2013Sunday, at 16:47, Sander Steffann wrote:
>
>> On 03/06/2013 11:06, manning bill wrote:
>>> /48's are a horrible policy - one should only advertise what
one is actually using.
>> Now *that* would cause a nice fragmented DFZ...
>> Sander
>>
>
>
> I'm going to inject a route. One route. why do you care if its a
/9, a /28, a /47, or a /121?
I've heard tell that there are routers that are designed to handle
prefixes up to /64 efficiently but have a much harder time with
prefixes longer than that, as a reasonable engineering trade-off.
Not being a router designer, I don't know how true this is.
Brian
Its -one- route.
> That one route covers everything I'm going to use… and nothing
I'm not.
>
> Is there a credible reason you want to be the vector of DDoS
attacks, by announcing dark space (by proxy aggregation)?
> Is that an operational liability you are willing to assume, just
so you can have "unfragmented" DFZ space?
>
>
> /bill
------------------------------------------------------------------
--
IETF IPv6 working group mailing list
ipv6@ietf.org <mailto:ipv6@ietf.org>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
v6ops mailing list
v6...@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
