The problem mainly has to do with troubleshooting. Sometimes you need
to know whether a customer's CPE is genuinely down on the WAN side, and
not necessarily the LAN interface where the head of the routed block
typically is. To make that work, it helps to have real transport IPs on
the WAN interface.
There is no reason why you need to "waste" IP address on the /30s - who
said they have to be public IPs? Just carve out some address space out
of a 10.0.0.0/8 range and use private transport IPs. All you need them
for is to test end-to-end connectivity from the aggregation router on
your side, not for any other reachability purpose. If they pay for 1
static IP you can throw it up on a loopback interface on the other side
and add a /32 route for it over the transport /30 block.
Justin Shore wrote:
I'm curious to see what everyone's take is on handling the addressing of
customer-facing DS1s. Rather than provision a /30 per customer and
waste IP space I'm planning on using IP unnumbered to a loopback for the
vast majority of our most basic DS1 customers. They'll get assigned 1
IP out of the pool and if they request (and pay for) any more then I'll
static route their allocation to their pool IP. We'll also request that
they only use the statically-routed subnet for server assignments and
not PAT their pool IP; that way they can be migrated to our LRE solution
with minimal IP and DNS changes as LRE becomes available in their local
CO.
I'm prepared to offer /30s where needed of course, in case their CPE
runs into trouble for some reason or in case they wig out over the
thought of their external interface being in the same bcast domain as
other customers. I'm actually looking at options to restrict bcasts
between IP unnumbered serial interfaces too. We need to allow direct
access between the sites but not bcast.
One of my concerns is QoS. We'll be offering QoS-enabled VoIP over
these DS1s in some cases. Can I still use service-policies on physical
interfaces or would it have to be on the loopback and apply to all
users? I have not tried QoS and IP unnumbered yet. Perhaps VoIP
circuits will have to be addressed with /30s (or /31s since we're
managing the CE in VoIP installations).
I know that IP unnumbered works in general; I'm just wondering if anyone
has already done it in production and ran into problems? My goal is to
not waste IP space on network and bcast addresses where possible. No,
I'm not going to assign /31s; customers just won't be able to comprehend
that, especially when the IOS through our a warning message when you
assign a /31 to an interface. I use /31s internally but not for
customer links. IP unnumbered wastes the least amount of IP space.
Since we're targeting our services at the low-end of the SMB market who
most likely it already on CATV or RBE DSL and share a bcast domain with
their neighbors already, I don't envision IP unnumbered to be a big
deal. I'm looking for guidance though. Thoughts?
Thanks
Justin
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/