DSL Network Design Question
I am going to be cutting over about 75,000 DSL lines from one core network to another. Does anyone have recommendations on subnet and DHCP scope size? If I make them /23s I have to do about 145 subents. If I make them /22s I only have to do about 73. Being mainly an always on eyeball network I don't see any problems with making big subnets (/22). <flameproof undies == on> suggestions, recommendations, advice? scott
surfer@mauigateway.com wrote:
I am going to be cutting over about 75,000 DSL lines from one core network to another. Does anyone have recommendations on subnet and DHCP scope size? If I make them /23s I have to do about 145 subents. If I make them /22s I only have to do about 73. Being mainly an always on eyeball network I don't see any problems with making big subnets (/22).
<flameproof undies == on> suggestions, recommendations, advice?
scott
Hi Scott, I am connected through this beast: (1) echnaton.lomiheim (192.168.48.228) 4.822 ms 5.726 ms 6.494 ms 8 echnaton.serveftp.com (84.167.225.223) 88.974 ms 94.556 ms <DSL PPPoE> (2) sepia (217.0.116.49) 75.121 ms 82.987 ms 93.851 ms 7 sepia (217.0.67.101) 26.321 ms 24.930 ms 40.689 ms (3) sepia (217.0.67.98) 97.179 ms 102.032 ms 110.439 ms (3) sepia (217.0.67.102) 98.112 ms 105.508 ms 113.469 ms (3) sepia (217.0.67.106) 92.877 ms 100.621 ms 108.924 ms 6 da-ea1.DA.DE.net.DTAG.DE (62.153.179.54) 29.814 ms 28.022 ms 26.897 ms (4) ams-e4.AMS.NL.net.DTAG.DE (62.154.15.2) 129.854 ms 137.460 ms 145.226 ms 5 amx-gw2.nl.dtag.de (195.69.145.211) 30.964 ms 29.304 ms 27.540 ms (5) gb-2-0-0.amsix1.tcams.nl.easynet.net (195.69.144.38) 153.946 ms 161.722 ms 169.569 ms Numbers in (braces) are my traceroute out. Numbers without are traceroute from outside in. sepia (217.0.116.49) identifies as Access-Concentrator: DARX41-erx AC-Ethernet-Address: 00:90:1a:a0:01:46 I guess it is a Juniper ERX. They used to give me an ip from one of four buckets each of them 16 buckets of 256 excluding xxx.xxx.xxx.0 and xxx.xxx.xxx.255 Since the end of last year it is only one bucket of 64k 84.167.xxx.xxx Again I have never seen 0 or 255. I guess that means they have assigned some 256 routing groups. The whole block is /14 the groups are /24 They used to have 16k addresses but I guess that is close to their number of dsl custmers in the Rhein/Main area, Frankfurt and Darmstadt. There were some buckets that I have never seen assigned to me. I have seen them used statically. Now they seem to have 64k addresses for an area with 250 000 inhabitants. If Frankfurts count too then it is a million. They try to clean up interrupting every session after 24 hours. But I guess they still have a lot of customers who never go offline. At the moment DTAG.DE is kind of a monopoly. Almost everybody has to use their hardware for dsl. Hope that helps you. Regards, Peter and Karin Dambier -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) +1-360-448-1275 (VoIP: freeworldialup.com) mail: peter@peter-dambier.de http://iason.site.voila.fr http://www.kokoom.com/iason
"surfer@mauigateway.com" <surfer@mauigateway.com> writes:
I am going to be cutting over about 75,000 DSL lines from one core network to another. Does anyone have recommendations on subnet and DHCP scope size? If I make them /23s I have to do about 145 subents. If I make them /22s I only have to do about 73. Being mainly an always on eyeball network I don't see any problems with making big subnets (/22).
I'd say aggregate as much as possible based on what your LNS/RAS equipment will handle in terms of actual customers. In my OSPF, I carry a /21 for each 7206VXR/NPE300 which may be a tad optimistic if current P2P trends continue as they have - time to work some NPE-G1s into my budget. Of course, on the other end of the scale I carry /32s for each static address customer, since that gives me maximum flexibility for LNS shuffling in the future (to distribute load). Peter Dambier is right that his ISP is avoiding .255 and .0. Older MS stacks (still plenty prevalent in the wild) get indigestion when handed those final octets, notwithstanding the fact that they aren't broadcast addresses on any network larger than a /24 or for one-ended use like PPP... if you don't exclude them you'll end up putting additional load on your help desk. The necessity to avoid .0 and .2555 results (on ciscos) in idioms such as this: ar01#sho run | inc ip local pool ip local pool ar01-dynamic 223.126.80.1 223.126.80.254 ip local pool ar01-dynamic 223.126.81.1 223.126.81.254 ip local pool ar01-dynamic 223.126.82.1 223.126.82.254 ip local pool ar01-dynamic 223.126.83.1 223.126.83.254 ip local pool ar01-dynamic 223.126.84.1 223.126.84.254 ip local pool ar01-dynamic 223.126.85.1 223.126.85.254 ip local pool ar01-dynamic 223.126.86.1 223.126.86.254 ip local pool ar01-dynamic 223.126.87.1 223.126.87.254 ar01#
<flameproof undies == on> suggestions, recommendations, advice?
scott
Uh... suggest/recommend/advise that you ought to use your full name in posts and not an alias and first name, as required in the NANOG Charter and AUP? http://www.nanog.org/aup.html item 7. Best, ---Rob (member of the list-admin team)
On Sun, 14 Aug 2005, Robert E.Seastrom wrote:
Peter Dambier is right that his ISP is avoiding .255 and .0. Older MS stacks (still plenty prevalent in the wild) get indigestion when handed those final octets, notwithstanding the fact that they aren't broadcast addresses on any network larger than a /24 or for one-ended use like PPP... if you don't exclude them you'll end up putting additional load on your help desk.
Believe it or not, even not too old (12.1T) IOS versions have issues forwarding packets to .255 addresses. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Jon> Believe it or not, even not too old (12.1T) IOS versions have Jon> issues forwarding packets to .255 addresses. Do you know what the issue is, and when it was fixed (or better, have a bug number I can lookup)? I currently use .0 and .255 addresses on our corporate network, and have never _noticed_ any issues (though we're not currently running anything as old as 12.1T for IP). Cheers -roy
On Sun, 14 Aug 2005, Roy Badami wrote:
Jon> Believe it or not, even not too old (12.1T) IOS versions have Jon> issues forwarding packets to .255 addresses.
Do you know what the issue is, and when it was fixed (or better, have a bug number I can lookup)? I currently use .0 and .255 addresses on our corporate network, and have never _noticed_ any issues (though we're not currently running anything as old as 12.1T for IP).
We use a few subnets (usually /27 or so sized) which we have chopped up into /32s for lo0 interfaces on all our core routers. One of these subnets includes a .255 which got assigned as x.y.z.255/32 to one of our routers, and so that router exports it into OSPF as a /32. I found that anything on the other side of one of our T1 & DSL aggregation 7206's running 12.1T could not reach that .255 router. In fact, that 7206 can't reach the .255 and if it tries to, it apparently assumes you meant to send a broadcast to any interface which happens to be in the same x.y.z/24 as x.y.z.255. Pinging x.y.z.255 results in replies from locally connected x.y.z/24 customers. I don't know that it has been fixed. We only run a little 12.1T in places where we needed an odd mix of features only available in 12.1T. AFAIK, we could theoretically upgrade to 12.3M, but we tried it once early in 12.3 and it didn't go well. We ended up rolling back to 12.1T due to too many new bugs. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
<stating the obvious> You have checked that your configs haven't inadvertently inherited a 'no ip classless' back from the days when it was the default? Depending on your network architecture you could well not notice it unless/until you tried to use a .255 in Class C space... </stating the obvious> -roy
On Sun, 14 Aug 2005, Roy Badami wrote:
<stating the obvious>
You have checked that your configs haven't inadvertently inherited a 'no ip classless' back from the days when it was the default? Depending on your network architecture you could well not notice it unless/until you tried to use a .255 in Class C space...
</stating the obvious>
Yeah. It definitely has "ip classless" and "ip subnet-zero" in the config. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Jon> Yeah. It definitely has "ip classless" and "ip subnet-zero" Jon> in the config. Interesting, thanks. TBH, I really don't understand why Cisco have kept the classful support for this long... The bug you're seeing *must* be related to the code that implements classful, since in classless mode no code should be special casing octet boundaries at all, ever... Somehow I suspect "no ip route-cache" would fix it :-) Or perhaps even "no ip cef"... -roy
On Sun, 14 Aug 2005, Roy Badami wrote:
Somehow I suspect "no ip route-cache" would fix it :-)
Or perhaps even "no ip cef"...
Don't know, but I seriously doubt this router could cope without CEF. It's got a pretty good number of T1s (PA-MC-T3s) and an ATM DS3 of DSL and PPPoE DSL from a DSLAM. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Roy Badami <roy@gnomon.org.uk> wrote: [...]
Interesting, thanks. TBH, I really don't understand why Cisco have kept the classful support for this long...
When a friend was doing a CCNA back in 2003-ish, Cisco were still teaching classful addressing. There was plenty of other misinformation there. Apparently my home network is impossible to build with such few IP addresses. (I use proxy ARP to avoid creating unnecessary subnets of the already too small block I have.) Meanwhile, RIPE's training sessions rap you on the knuckles for using terms like "Class C" even though in a world of broken stacks from Cisco and Microsoft, you pretty much need to know about it anyway. -- PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key /:.*posting.google.com.*/HX-Trace:+j
On Mon, 15 Aug 2005 abuse@cabal.org.uk wrote:
Roy Badami <roy@gnomon.org.uk> wrote: [...]
Interesting, thanks. TBH, I really don't understand why Cisco have kept the classful support for this long...
When a friend was doing a CCNA back in 2003-ish, Cisco were still teaching classful addressing. There was plenty of other misinformation there. Apparently my home network is impossible to build with such few IP addresses. (I use proxy ARP to avoid creating unnecessary subnets of the already too small block I have.)
Meanwhile, RIPE's training sessions rap you on the knuckles for using terms like "Class C" even though in a world of broken stacks from Cisco and Microsoft, you pretty much need to know about it anyway.
I recently did the CCNA training courses (Its now broken into two - "INTRO-E" (As the instructor put it.. Intro 'essentials' means fit a 4 day course into 3 days by stripping or abbreviating that which isn't quite as 'essential) and ICND) and IP Classes are still covered. It was basically a history lesson but it helps newcomers to understand the decision making process behind a lot of the historical network configs and legacy options within IOS. (And how you can theoretically set up an interface without a netmask). I dont see the harm in retaining the terms and the training for historical perspective. As long as its clearly explained. Most especially for those who dont understand that class c != /24 . Mark.
participants (7)
-
abuse＠cabal.org.uk -
Jon Lewis -
Mark Foster -
Peter Dambier -
Robert E.Seastrom -
Roy Badami -
surfer＠mauigateway.com