Re: Fwd: Interesting problems with using IPv6
On 9/14/2014 11:20 AM, Matthew Petach wrote: > On Sun, Sep 14, 2014 at 10:45 AM, Sam Stickland wrote: > >> Slightly off topic, but has there ever been a proposed protocol where hosts >> can register their L2/L3 binding with their connected switch (which could >> then propagate the binding to other switches in the Layer 2 domain)? >> Further discovery requests (e.g. ARP, ND) from other attached hosts could >> then all be directly replied, eliminating broadcast gratuitous arps. If the >> switches don't support the protocol they would default to flooding the >> discovery requests. >> >> It seems to me that so many network are caused because of the inability to >> change the host mechanisms. >> >> Sam >> > > > It looks like in 2011 Cisco proposed a > technology called "OTV" that would do > just that, according to this page: > http://network-101.blogspot.com/2011/03/otv-vs-vpls.html > Granted, it was aimed for wide-area > networking, rather than control within > a datacenter; but as everyone who has > started doing BGP to their top of rack > switches has learned, there's often good > value in adopting techniques and protocols > used in the wide area network within the > datacenter as well. > > However, I haven't heard recent mention > of it, so I'm guessing it failed to make a > big enough splash to get any widespread > adoption. > Also consider the emergence of eVPN and PBB-eVPN. https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=5998&tclass=popup -- = bep smime.p7s Description: S/MIME Cryptographic Signature
Re: 2000::/6
On Sun, Sep 14, 2014 at 04:19:42PM -0500, Jimmy Hess wrote: > On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan wrote: > > 2000::/64 has nothing to do with it. > > > > Any address between 2000::::::: and > > 23ff::::::: together with misconfigured prefix > > length (6 instead 64) becomes 2000::/6 prefix. > > It should be rejected for the same reason that 192.168.10.0/16 is > invalid in a prefix list or access list. RTR(config)#ip prefix-list TEST permit 192.168.10.0/16 RTR(config)#do sho ip prefix-list TEST ip prefix-list TEST: 1 entries seq 5 permit 192.168.0.0/16 This isn't surprising to people who've been using IOS for a while ... > Any decent router won't allow you to enter just anything in that range > into the export rules with a /6, except 2000:: itself, and will > even show you a failure response instead of silently ignoring the > invalid input, for the very purpose of helping you avoid such errors. Well, unfortunately, a lot of us have (as you define the term) indecent routers. RTR(config)#ipv6 prefix-list TEST permit 2000:::/6 RTR(config)#do sho ipv6 prefix-list TEST ipv6 prefix-list TEST: 1 entries seq 5 permit 2000::/6 >2001::1/6 would be an example of an invalid input -- there are > one or more non-zero bits listed outside the prefix, or where bits in > the mask are zero. > > Only 2000:::::::/6properly conforms, > not just "any IP" in that range can have a /6 appended to the end. -- Brett
Re: 2000::/6
On 14/09/2014 22:19, Jimmy Hess wrote:
> Any decent router won't allow you to enter just anything in that range
> into the export rules with a /6, except 2000:: itself
tarko is right in suggesting that config typos can cause this sort of
thing, e.g.
--
router bgp 6
address-family ipv6
redistribute static
ipv6 route 2001:418:3ef:1000::/6 2001:db8::1
--
Bear in mind that the "network" statement in the router bgp stanza on cisco
routers is only one of several methods of injecting prefixes into a bgp
rib, and is a method that many people routinely avoid because it means
duplication of configuration: each network statement requires a grounding
"ip{v6} route" statement in order to work stably. So why not combine the two?
Nick
Re: 2000::/6
On Sat, Sep 13, 2014 at 5:33 AM, Tarko Tikan wrote: > 2000::/64 has nothing to do with it. > > Any address between 2000::::::: and > 23ff::::::: together with misconfigured prefix > length (6 instead 64) becomes 2000::/6 prefix. It should be rejected for the same reason that 192.168.10.0/16 is invalid in a prefix list or access list. Any decent router won't allow you to enter just anything in that range into the export rules with a /6, except 2000:: itself, and will even show you a failure response instead of silently ignoring the invalid input, for the very purpose of helping you avoid such errors. 2001::1/6 would be an example of an invalid input -- there are one or more non-zero bits listed outside the prefix, or where bits in the mask are zero. Only 2000:::::::/6properly conforms, not just "any IP" in that range can have a /6 appended to the end. -- -JH
Re: Fwd: Interesting problems with using IPv6
On Sun, Sep 14, 2014 at 10:45 AM, Sam Stickland wrote: > Slightly off topic, but has there ever been a proposed protocol where hosts > can register their L2/L3 binding with their connected switch (which could > then propagate the binding to other switches in the Layer 2 domain)? > Further discovery requests (e.g. ARP, ND) from other attached hosts could > then all be directly replied, eliminating broadcast gratuitous arps. If the > switches don't support the protocol they would default to flooding the > discovery requests. > > It seems to me that so many network are caused because of the inability to > change the host mechanisms. > > Sam > It looks like in 2011 Cisco proposed a technology called "OTV" that would do just that, according to this page: http://network-101.blogspot.com/2011/03/otv-vs-vpls.html Granted, it was aimed for wide-area networking, rather than control within a datacenter; but as everyone who has started doing BGP to their top of rack switches has learned, there's often good value in adopting techniques and protocols used in the wide area network within the datacenter as well. However, I haven't heard recent mention of it, so I'm guessing it failed to make a big enough splash to get any widespread adoption. Matt
Re: Fwd: Interesting problems with using IPv6
Slightly off topic, but has there ever been a proposed protocol where hosts can register their L2/L3 binding with their connected switch (which could then propagate the binding to other switches in the Layer 2 domain)? Further discovery requests (e.g. ARP, ND) from other attached hosts could then all be directly replied, eliminating broadcast gratuitous arps. If the switches don't support the protocol they would default to flooding the discovery requests. It seems to me that so many network are caused because of the inability to change the host mechanisms. Sam On Mon, Sep 8, 2014 at 7:30 PM, Christopher Morrow wrote: > On Mon, Sep 8, 2014 at 1:28 PM, Barry Shein wrote: > > > > Reading the article what occurs to me is: > > > > IPv4 requires a certain amount of administrative personnel overhead. > > > > It's relatively low which is certainly one reason for the success of > > IPv4. People are expensive so any new, pervasive technology will be > > judged at least in part on its personnel requirements. > > > > I'd go so far as to say that administering large IPv4 networks grows > > in personnel roughly as the log of the number of nodes. > > surely this depends a LOT on the quality of the folk doing this job > and their foresight in automating as much as possible, no? (probably > this point isn't for debate, but the point is any network can be run > badly) > > > If what this is telling us, or warning us, is that IPv6 networks > > require higher personnel costs then that could become a big issue. > > is this a reflection of 'new technology' to the users (network folk) > in question? > What in ipv6 networking is inherently 'more people required' than ipv4 > networking? > > > > > Particularly among management where they've become used to a few to > > several people in a team running the heart of quite large networks. > > > > What if IPv6 deployment doubles or triples that personnel requirement > > for the same quality of administration? > > this sounds, to me, like: "People need training or comfort with : > instead of . in 'ip address' stuff..." (and other similar differences > between how v4 and v6 operate at scale) > > > Does anyone know of any studies along these lines? My guess is that > > there isn't enough data yet. > > that sounds reasonable. >
