Re: Cisco 7206 IOS for PPPoE Termination
I know how to use Google dear Mark, but I mean which configuration is working succesfully in their network. I am currently using this config: bba-group pppoe TEST virtual-template 1 sessions per-mac limit 2 sessions per-vlan limit 5000 sessions per-vc throttle 15 30 300 sessions per-mac throttle 15 30 300 sessions auto cleanup On Mon, Sep 24, 2012 at 4:32 AM, Sean Lazar kn...@toaster.net wrote: http://lmgtfy.com/?q=site%3Acisco.com+ios+broadband+aggregation+guide On 9/23/12 1:50 PM, Shahab Vahabzadeh wrote: why joking Mark? On Mon, Sep 24, 2012 at 12:19 AM, Mark Gauvin mgau...@dryden.ca wrote: You are joking I hope Sent from my iPhone On 2012-09-23, at 3:38 PM, Shahab Vahabzadeh sh.vahabza...@gmail.com wrote: Dear Paul, Thanks for you reply, May I have those optimization knobs for virtual-template and throttles? Maybe looking into your configurations help me in this field. I will look for the service provider image too. Thanks On Sun, Sep 23, 2012 at 11:17 PM, PC paul4...@gmail.com wrote: For this application, you may wish to consider the service provider images. The latest 15.x(S) image works, as it is the derivative of what was formerly the service-provider oriented 12.2(SRx) images. However, it's unlikely to drop steady state CPU, but it may contain some optimizations for concurrent PPP (re)negotiations on the G2 platform during session recovery. PPPoE will generally handle more users on ethernet as it is easier to push packets on when not dealing with the ATM encapsulations, but to what extent this holds true on the 7200, I can't tell you for sure. I'd also read the broadband aggregation guide under the IOS documentation on cisco.com, and tune all the knobs that may help you, there are some pointers on what items on virtual-templates are punitive in performance, other optional items such as disabling SNMP counters on virtual access interfaces to reduce cpu usage, and other items that may help little by little. There are also various knobs to throttle PPPoE renegotiation rates during recovery. I wish you luck (and consider getting another and/or bigger router to split the load). On Sun, Sep 23, 2012 at 1:23 PM, Shahab Vahabzadeh sh.vahabza...@gmail.com wrote: Which software you used before for them? On Sun, Sep 23, 2012 at 10:43 PM, Rinse Kloek rinse.kl...@isp.solcon.nl wrote: 6000 PPP users on a NPE-G2 is way too much imho. Currently we do no more than 3000 users on a NPE-G2 with PPPoA. (Max cpu 50%). 5 years ago, we did about 5000 users on a NPE-G2, but as traffic ratio's grow each year the maximum users a NPE-G2 can handle will drop each year. Don't forget an NPE-G2 is a software based plaform, so traffic forwarding is done in software CPU. regards, Rinse Kloek Op 23-9-2012 20:51, Shahab Vahabzadeh schreef: Hello everybody, I am using C7206 VXR NPE-G2 routers as BRAS in my network and the current IOS is *c7200p-adventerprisek9-mz.**124-24.T.bin* on them. Also their memory upgraded to 2GB instead of 1GB. And I have near 6500 online user on each of my BRAS and there is no speciefic feature except aaa with radius and ordinary features. There router is also terminating dot1q too because my PSTN centers traffic comes through dot1q vlans to BRAS es. I think I have some problem with current IOS, My CPU Usage is abnormal and Its near %70 or %80. And when I have a network problem and some of PSTN centers goes down CPU go to %99 and it gets problem to recovery. Do you know any good IOS for me as a service provider to use? I heard that some service providers have near 8000 online user on 7206. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
Re: Big Temporary Networks
just a small comment: As far as I understand AP isolation doesn't work if you don't have a WLAN controller but do have more than one APs. E.g. in the following setup ap1--sw1--sw2--ap2 with AP isolation turned on, clients associated to ap1 cannot communicate directly with other clients associated to ap1, however they can communicate directly with those associated to ap2. Broadcast from ap1's clients does also get to all clients at ap2. Hi András, This is one place where Cisco's switchport protected comes in handy. Yes, but only as long as all APs are connected to the same switch, as I understand. (That's why I put two switches in the example above.) You can get the same effect with other brands. For example, in one on-the-cheap 5-AP hotspot I did, I vlaned the APs (using an older 802.1q capable switch) back to a Linux bridge with ebtables --insert FORWARD --jump DROP. The Linux bridge was also the default router out of the wlan, so anything *to* the router worked but anything that would be forwarded was dropped instead. Works great. Nice, that should do the trick with multiple switches too. Regards, András
Re: Real world sflow vs netflow?
Peter Phaal peter.ph...@gmail.com wrote on 09/23/2012 12:23:57 PM: Exporting packet oriented measurements doesn't mean that you have to loose ingress/egress interface data. In the specific example being discussed (sFlow export), detailed forwarding information from the router forwarding plane is exported with each sampled packet header (full AS-path if you are using BGP). Wrt AS-path, I don't get how this happens. Since this is important to this community, could you explain? Thanks, Joe
Re: Real world sflow vs netflow?
On 2012-09-24 14:48 , Joe Loiacono wrote: Peter Phaal peter.ph...@gmail.com wrote on 09/23/2012 12:23:57 PM: Exporting packet oriented measurements doesn't mean that you have to loose ingress/egress interface data. Note that you get these in NetFlow too. Depends on which version you pick or how you combine your template and of course if the hard and software allows it, but it is there. In the specific example being discussed (sFlow export), detailed forwarding information from the router forwarding plane is exported with each sampled packet header (full AS-path if you are using BGP). Wrt AS-path, I don't get how this happens. Since this is important to this community, could you explain? As sFlow runs on the same box that knows the BGP tables the packets sflow packets get that information too. No magic there. This can also be done with NetFlow/IPFIX though, as shown in: http://www.pmacct.net/building_traffic_matrices_n49.pdf thus by combining a BGP feed with the NetFlow/IPFIX feed. There is of course a small chance in such a setup that the tables mismatch and is not the same as the router would have made it. Then again with sFlow you typically sample and thus you have windows of loss anyway... Note that there are IPFIX/NetFlow enabled boxes which also include BGP details if one is worried about that, though if your path changes mid-flow you have a slight error there too again. Greets, Jeroen
Re: Real world sflow vs netflow?
On Mon, Sep 24, 2012 at 5:48 AM, Joe Loiacono jloia...@csc.com wrote:
Peter Phaal peter.ph...@gmail.com wrote on 09/23/2012 12:23:57 PM:
Exporting packet oriented measurements doesn't mean that you have to
loose ingress/egress interface data. In the specific example being
discussed (sFlow export), detailed forwarding information from the
router forwarding plane is exported with each sampled packet header
(full AS-path if you are using BGP).
Wrt AS-path, I don't get how this happens. Since this is important to this
community, could you explain?
Sure. I think it's worth discussing in some detail since this is
relevant to the NANOG community and it is important to understand how
it works.
When a switch/router decides to sample a packet it records the
ingress/egress interfaces and accumulates information about how it
decided to forward the packet by examining its FIB tables. Each packet
may take a different path, some may by switched at layer 2, others may
be forwarded based on a local routing protocol like OSPF, and still
others may be forwarded based on BGP.
The forwarding data associated with each packet is irregular (e.g. a
switched packet won't have BGP information), and so sFlow doesn't try
to flatten it into tables, but instead encodes the data using XDR (RFC
1832), expressing each element of the forwarding decision as a tag,
length, value encoded structure that contains attributes relevant to
each type of forwarding decision. The AS-Path itself is a fairly
complicated, variable length structure and again, this is encoded as
XDR.
These are all optional fields in sFlow, so you should check with your
switch vendor to see which ones they support. If they don't currently
export the FIB data you are looking for, you should ask them to
upgrade their agent because as Jeroen pointed out, populating each
structure is just an extra lookup performed by the management CPU on
the router.
FYI I have see full AS-path data exported from a busy 100G router, so
there should be no problem collecting these measurements in a
production setting.
The following extract from the sFlow version 5 specification shows
what forwarding information is exported:
/* Extended Flow Data
Extended data types provide supplimentary information about the
sampled packet. All applicable extended flow records should be
included with each flow sample. */
/* Extended Switch Data */
/* opaque = flow_data; enterprise = 0; format = 1001 */
/* Note: For untagged ingress ports, use the assigned vlan and priority
of the port for the src_vlan and src_priority values.
For untagged egress ports, use the values for dst_vlan and
dst_priority that would have been placed in the 802.Q tag
had the egress port been a tagged member of the VLAN instead
of an untagged member. */
struct extended_switch {
unsigned int src_vlan; /* The 802.1Q VLAN id of incoming frame */
unsigned int src_priority; /* The 802.1p priority of incoming frame */
unsigned int dst_vlan; /* The 802.1Q VLAN id of outgoing frame */
unsigned int dst_priority; /* The 802.1p priority of outgoing frame */
}
/* IP Route Next Hop
ipForwardNextHop (RFC 2096) for IPv4 routes.
ipv6RouteNextHop (RFC 2465) for IPv6 routes. */
typedef next_hop address;
/* Extended Router Data */
/* opaque = flow_data; enterprise = 0; format = 1002 */
struct extended_router {
next_hop nexthop;/* IP address of next hop router */
unsigned int src_mask_len; /* Source address prefix mask
(expressed as number of bits) */
unsigned int dst_mask_len; /* Destination address prefix mask
(expressed as number of bits) */
}
enum as_path_segment_type {
AS_SET = 1,/* Unordered set of ASs */
AS_SEQUENCE = 2 /* Ordered set of ASs */
}
union as_path_type (as_path_segment_type) {
case AS_SET:
unsigned int as_set;
case AS_SEQUENCE:
unsigned int as_sequence;
}
/* Extended Gateway Data */
/* opaque = flow_data; enterprise = 0; format = 1003 */
struct extended_gateway {
next_hop nexthop; /* Address of the border router that should
be used for the destination network */
unsigned int as;/* Autonomous system number of router */
unsigned int src_as;/* Autonomous system number of source */
unsigned int src_peer_as; /* Autonomous system number of source peer */
as_path_type dst_as_path; /* Autonomous system path to the destination */
unsigned int communities; /* Communities associated with this route */
unsigned int localpref; /* LocalPref associated with this route */
}
POLL: 802.1x deployment
I'm tech-reading an upcoming book, and it makes the implication that 802.1x is not very widely deployed... which seems possibly an overly narrow view of the Real World. If you regularly use one or more 802.1x protected networks, could you take a moment to reply off-list, and tell me the size of the network (homelab, smb, enterprise, carrier), and, if you know, how long 802.1x has been deployed there? I'm also interested in whether any network you use has dropped .1x. I'll summarize to the list if there's interest. Thanks. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
* Tore Anderson I would pay very close attention to MAP/4RD. FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending: https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Re: POLL: 802.1x deployment
Hi, I´d suggest you to ask the guys from Enterasys mailing list. Sorry, couldn´t resist ;-) Michael P.S.: No, I don´t have 802.1x enabled on LAN for my users sitting in their offices.
Re: Real world sflow vs netflow?
Peter Phaal peter.ph...@gmail.com wrote on 09/24/2012 10:39:26 AM: When a switch/router decides to sample a packet it records the ingress/egress interfaces and accumulates information about how it decided to forward the packet by examining its FIB tables. Each packet may take a different path, some may by switched at layer 2, others may be forwarded based on a local routing protocol like OSPF, and still others may be forwarded based on BGP. OK, Well I guess I was thinking sFlow was primarily a switch oriented technology versus on a layer-3 peering router.
Re: Real world sflow vs netflow?
On Mon, Sep 24, 2012 at 11:19 AM, Joe Loiacono jloia...@csc.com wrote: OK, Well I guess I was thinking sFlow was primarily a switch oriented technology versus on a layer-3 peering router. The sFlow technology is a good fit for any device that performs a packet forwarding function (including routers) and the sFlow.org web site maintains a list of switches and routers that implement the technology, http://sflow.org/products/network.php However, you are correct that today sFlow is more broadly implemented in switching platforms than routing platforms, but I expect this will change as network speeds increase and platforms converge.
Re: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog
On Sep 23, 2012, at 4:42 PM, Joe Hamelin wrote: PSAV is the company. I just installed about 20 Cisco WiFi radios at the Doubletree (a Hilton prop) at Sea-Tac. These covered only the convention space, conf rooms, ball rooms, whatnot. It would seem that the hotel is running their own system in the other public areas such as check-in, coffee shops and bars. Mostly they were well placed, often in the same spot as the existing radios. But I'd never throw a geek-con at that system. Yeah, I just stayed at SeaTac a month back and had to shift to working offline and syncing upward, since I was getting modem-like speed through the network there. I think I ended up using my phone more than their wifi :( -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 24 Sep 2012, at 17:57, Tore Anderson tore.ander...@redpill-linpro.com wrote: * Tore Anderson I would pay very close attention to MAP/4RD. FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending: https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf Interesting video; thanks for posting the link. This does seem a strange proposal though. My understanding from the video is that it is a technology to help not with the deployment of IPv6 but with the scarcity of IPv4 addresses. In summary; it simply allows a number of users (e.g. 1024) to share a single public IPv4 address. My feeling is therefore, why are the IPv4 packets to/from the end user being either encapsulated or translated into IPv6 - why do they not simply remain as IPv4 packets? If the data is kept as IPv4, this seems to come down to just two changes, * The ISP's router to which the user connects being able to route packets on routes that go beyond the IP address and into the port number field of TCP/UDP. * A CE router being instructed to constrain itself to using a limited set of ports on the WAN side in its NAT44 implementation. Why all the IPv6 shenanigans complicating matters? Cheers, aid
Re: Real world sflow vs netflow?
On Mon, Sep 24, 2012 at 11:52:28AM -0700, Peter Phaal wrote: On Mon, Sep 24, 2012 at 11:19 AM, Joe Loiacono jloia...@csc.com wrote: OK, Well I guess I was thinking sFlow was primarily a switch oriented technology versus on a layer-3 peering router. The sFlow technology is a good fit for any device that performs a packet forwarding function (including routers) and the sFlow.org web site maintains a list of switches and routers that implement the technology, Minus a whole pile of babble from people who don't actually know what a router vs layer 3 switch is...The difference at this point is mostly that NetFlow has provisions to allow exporting all data about an ENTIRE flow, whereas sFlow is designed to only take statistical samples for overall traffic analysis. Tracking an entire flow is much harder, it requires keeping state on the router, so if you only care about overall traffic analysis sampling is just fine. Originally sFlow introduced features like raw packet export (including layer 2 headers), and extensible formatting, which NetFlow later copied with v9 and v10/IPFIX. At this point they're mostly on the same footing technically, though sFlow does have a counter export feature which is essentially a push version of polling SNMP IF-MIB counters. Only Cisco and Juniper are still trying to push NetFlow though, sFlow has been adopted by nearly ehter other vendor at this point. Even some Juniper products, like EX (which is really Marvell ASICs with a JUNOS wrapper), support sFlow only. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 24 September 2012 21:11, Adrian Bool a...@logic.org.uk wrote: On 24 Sep 2012, at 17:57, Tore Anderson tore.ander...@redpill-linpro.com wrote: * Tore Anderson I would pay very close attention to MAP/4RD. FYI, Mark Townsley had a great presentation about MAP at RIPE65 today, it's 35 minutes you won't regret spending: https://ripe65.ripe.net/archives/video/5 https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf Interesting video; thanks for posting the link. This does seem a strange proposal though. My understanding from the video is that it is a technology to help not with the deployment of IPv6 but with the scarcity of IPv4 addresses. In summary; it simply allows a number of users (e.g. 1024) to share a single public IPv4 address. My feeling is therefore, why are the IPv4 packets to/from the end user being either encapsulated or translated into IPv6 - why do they not simply remain as IPv4 packets? If the data is kept as IPv4, this seems to come down to just two changes, * The ISP's router to which the user connects being able to route packets on routes that go beyond the IP address and into the port number field of TCP/UDP. * A CE router being instructed to constrain itself to using a limited set of ports on the WAN side in its NAT44 implementation. Why all the IPv6 shenanigans complicating matters? While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers, by using IPv6 packets it can be routed around your network by existing routers. And it's not like anyone is going to be deploying such a system without also deploying IPv6, so it's not adding any additional requirements doing it that way. - Mike
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 24 Sep 2012, at 22:42, Mike Jones m...@mikejones.in wrote: While you could do something similar without the encapsulation this would require that every router on your network support routing on port numbers, Well, not really. As the video pointed out, the system was designed to leverage hierarchy to reduce routing complexity. Using the hierarchy, port number routing is only required at the level where a routes diverge on a port basis - which if you're being sensible about such a deployment would only be at the edge of the access layer. aid
IPv6 Address allocation best practises for sites.
Question about what other service/network providers are doing in relation to allocation of addresses for websites. With IPv6 starting to trickle its way in, what is considered the industry best practise now for IP(v6) addresses bonded to websites. In the past the standard practise was to have a single IPv4 address shared between multiple sites using a name based virtual host directive in Apache/IIS, unless of course the site was SSL in which case it normally needed a IP of its own (unless you had a client who was happy to only support SSL on IE7+ browsers with SNI). Does the best practise switch to now using one IPv6 per site, or still the same one IPv6 for multi-sites? - Mitch
Re: IPv6 Address allocation best practises for sites.
On Mon, Sep 24, 2012 at 6:52 PM, John Mitchell mi...@illuminati.org wrote: Question about what other service/network providers are doing in relation to allocation of addresses for websites. With IPv6 starting to trickle its way in, what is considered the industry best practise now for IP(v6) addresses bonded to websites. In the past the standard practise was to have a single IPv4 address shared between multiple sites using a name based virtual host directive in Apache/IIS, unless of course the site was SSL in which case it normally needed a IP of its own (unless you had a client who was happy to only support SSL on IE7+ browsers with SNI). Does the best practise switch to now using one IPv6 per site, or still the same one IPv6 for multi-sites? Hi John, Given web browser issues with javascript and DNS changes (see DNS pinning) I'm not sure why you wouldn't want to pick a configuration strategy where the IP could follow the site name from server to server. I'm not in the multi-site web server business any more. The stuff I build these days needs a load balancer. If I was I suspect I'd start at routing a /64 to each web server. Then I'd take a long hard look at whether it was a better plan to put all the multiply-addressed servers on a single /64 and let neighbor discovery find the right one for each site, or to implement /64''s per server and put /128 overrides in the adjacent router for sites that move from the original server (because the customer upgraded of course). Then I'd consider whether to route a /112 to each server instead of a /64 and assign a single /64 for the set of web servers. I don't know of any specific problem with routing 2^64 addresses to a single host but I also can't imagine hosting more than 65,000 sites on a single server. So, not a BCP but perhaps some food for thought when choosing your approach. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 Address allocation best practises for sites.
Does the best practise switch to now using one IPv6 per site, or still the same one IPv6 for multi-sites? As I've been migrating my sites to IPv6, each site gets its own IP. Works great. I did find that I needed to improve my tools so I could track the individual IP addresses and assign the appropriate DNS names to them, as I took several dozen (it's a small machine) sites and put them on IPv6. Other than not wanting to go to the effort to change all the config files, it's hard to think of a reason to share IPv6 addresses for anything. Virtual hosts were specifically invented to conserve IPv4 addresses; they don't provide any added function. R's, John PS: Well, there is my spider trap at http://web.sp.am which would be hard to do without using a shared IP. But that's perverse.
Re: IPv6 Address allocation best practises for sites.
William Herrin b...@herrin.us wrote: but I also can't imagine hosting more than 65,000 sites on a single server. Demon's homepages service was based on IPv4 virtual hosting and had IIRC a /16 and two /18s allocated to it. It was a single web server with a few reverse proxies that took most of the load and that also had all the IP addresses. The Irix version used a cunning firewall configuration to accept connections to all the addresses without stupid numbers of virtual interfaces; the BSD version used a kernel hack. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/12071 On the web server we stuffed the IP address into the filesystem path name to find the document root. (Or used various evil hacks to map the IP address to a canonical virtual server host name before stuffing the latter in the path.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
You can avoid the giant NAT box as long as you don't have to add a new customer for whom you don't have an available IPv4 address. At that point, you either have to implement the giant NAT box for your future (and possibly an increasing percentage of your existing) customers, or, stop adding new customers. In terms of the CPE situation, until you solve that, IPv6-only isn't going to work for them, either, so the CPE issues simply can't be avoided no matter what. We need to find a way to get the vendors to make that float. Owen On Sep 21, 2012, at 12:42 , Mark Radabaugh m...@amplex.net wrote: On 9/21/12 9:40 AM, Jeroen Massar wrote: On 2012-09-21 15:31 , Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations. Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it... Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways. Greets, Jeroen We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense. Dual stack isn't all that hard to deploy in the enterprise, perhaps even IPv6 only with NAT for backward compatibility. Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. I don't think saying we missed the boat really applies - and the consumer CPE ship is sinking at the dock. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: IPv6 Address allocation best practises for sites.
On Mon, Sep 24, 2012 at 6:52 PM, John Mitchell mi...@illuminati.org wrote: Does the best practise switch to now using one IPv6 per site, or still the same one IPv6 for multi-sites? Certainly it would be nice to have IPv6 address per vhost. In many cases, this will be practical. It also sometimes will NOT be practical. Imagine that I am one of the rather clueless hosting companies who are handing out /64 networks to any customer who asks for one, and using NDP to find the machine using each address in the /64. Churn problems aside, if you have any customer doing particularly dense virtual hosting, say a few thousand IPv6 addresses on his one or more machines, then he will use up the whole NDP table for just himself. You probably won't want to be a customer on the same layer-3 device as that guy. Now that there might be dozens of VMs per physical server and maybe 40 physical servers per each top-of-rack device, you can quickly exhaust all of your NDP entries even with normal, legitimate uses like www virtual hosting. Now imagine the hosting company has decided the stacking trend is a good idea, and stacked up a row of 10 EX4200s so they can all share the same configuration, uplinks, etc. They also share the same NDP table, so it will be quite easy to run out of NDP (there is only room for a few thousand entries) not just on one top-of-rack switch, but on the whole row. Further, imagine you decided to use a 6500 for a room full of customers, or even your whole datacenter, which will often work just fine for IPv4. Suddenly it won't for IPv6, because each customer may want to make hundreds of NDP entries for his various virtual-hosts. Just one busy customer with a lot of virtual hosting will run out a resource shared by every other customer. So yes, having an IPv6 address per each www virtual-host is certainly a nice idea. If you have to use NDP to get your addresses to your web server, though, it might not be practical. It certainly will be foolish in a dedicated server type of environment where you are renting individual machines or VMs and not owning your own layer-3 box. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: IPv6 Address allocation best practises for sites.
Morning, The way to allocate IPv6 addresses per website depends more on the technologies already in use at the hosting site. An existing hoster will move slowly to any alternative method. I predict a bigger, faster change in the way medium sized sites do load balancing. IPv6 allows hosters to go back to DNS round robin based load balancing, which still works much better than often reported. It became an unfashionable way to do things because there weren't enough IPv4 addresses for everyone to be doing it, but this limitation won't be an issue in IPv6. I had a customer case a couple of years back where the client tried it out and was amazed at the results. In that particular case each server announced 2 /128s to the closest router, one with a better metric and the other with a worse metric. So during failovers, one server got twice the normal traffic until that DNS entry was pulled from the round robin set. Said client went back to the old ways tho because they couldn't do the same thing on IPv4 and they didn't want to have two different load balancing methods for two different IP versions. They are very fervent believers in the KISS principle. They are now waiting and hoping for the IPv4 traffic to die down and IPv6 traffic to pick up so that they can start doing things on IPv6's terms instead. :-) Hoping against all odds that they won't have to wait long, -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting Cellular: +358 45 670 2048 World Wide Web: www.axu.tm
