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
"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)
Believe it or not, even not too old (12.1T) IOS versions have issues forwarding packets to .255 addresses.
Believe it or not, even not too old (12.1T) IOS versions have
> 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
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.
<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
Yeah. It definitely has "ip classless" and "ip subnet-zero" in the config.
Yeah. It definitely has "ip classless" and "ip subnet-zero"
> 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
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.
[...]
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.