Re: How to manage Static IPs to customers

2020-05-08 Thread Luke Guillory
You can do 32Q plus 2 OFDM blocks as well. But who has that kind of spectrum, 
we surely don’t. A 96Mhz block maybe.

But you can’t take the total at 100G and say that’s beyond your scale, you 
don’t run at full saturation do you? :)

And in order to run DCAM2s you’ll have to upgrade the RSMs to the gen2s as well.



Sent from my iPhone

On May 8, 2020, at 4:27 PM, Blake Hudson  wrote:

 *External Email: Use Caution*
16 connectors per DCAM2 times 6 cards is 96 DS service groups in a chassis. At 
~1.2 Gbps per connector (using 32 SC-QAM DOCSIS 3.0 channels) that's ~ 
100gigabits per chassis. Quite a bit above my scale ;- )

The E6k can also do DOCSIS 3.1, which we use today, though I'm not sure what 
the capacity limit is per DCAM/SG/connector when both SQ-QAM and OFDM are used 
in combination.

--Blake

On 5/8/2020 4:13 PM, Luke Guillory wrote:
E6K using gen 1 DCAMs can do about 32 service groups give or take, not that 
hard to get to a point with splits where you want to go past those numbers. Gen 
2 DCAMs double that by going to 16 connectors compared to 8. cBR8 is less than 
the E6K.

The point of node splits is to lower customers per SG, you can’t just split and 
stay on the same chassis if you’re at capacity on slots.

If you take the Comcast approach and start pushing fiber deeper in order to 
remove actives your node counts sky rocket. All the whole they’re lowering 
counts on SGs as well.

Even us little guys or working on lowering customers per SG, they have to be 
moved somewhere which would be another chassis if you’re out of free connectors 
on like cards.

Like

Sent from my iPhone

On May 8, 2020, at 4:02 PM, Blake Hudson 
 wrote:


Aaron, I was thinking something similar. I've never once had a node
split require moving a customer to a different CMTS. Even the very old
and (relatively) low capacity 7200 VXR could serve several nodes per
line card and supported several line cards per chassis. Newer cBR8, E6k,
and the like can serve many many times more customers across dozens of
nodes. Every L3 CMTS I've worked on uses something akin to ip unnumbered
so as long as the customer stays on the same CMTS, their IP address will
continue to work regardless of what interface or line card their
connection terminates on.

On 5/8/2020 2:34 PM, Aaron Gould wrote:
We have a provisioning system (promptlink) that we use to map cable modems
to their static ip addresses.  The provisioning system has a gui front end
and it sits on linux and also acts as a dhcp server, etc.  This is the same
ip address that we use for cable-helper (like ip-helper on a cmts bundle ip
interface) to forward dhcp requests from cable modem cpe, via the cmts, and
unicasted to promptlink and then the static ip address reservation within
the promptlink is sent back to the cpe

This all continues to work, even during node splits, as long as we don't
move that cm cpe to a different cmts... which would rarely happen since it's
across town to get to our other RF environment served be a different cmts
using a different static ip subnet... since we don't do L2 via cmts's in
order to stitch back that ip into a more globally located static subnet...
again, we don't do that.  If the customers moves locations, into a different
cmts area, that would be required to give back the single static /32 ip and
get a different on.  Unless they were a multi-static customer buying like a
/29... in which case we have no problem moving that /29 subnet off that cmts
and onto another one.  That's easy.

We do however have more centrally located subnets for some of our single
static ip customers in FTTH... but not CMTS docsis.

-Aaron


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Javier Gutierrez
Guerra
Sent: Thursday, May 7, 2020 3:50 PM
To: nanog@nanog.org
Subject: How to manage Static IPs to customers

Hi there,
Just wanted to reach out and get an idea how is people managing customers
with static Ips, more specifically on Docsis networks where the customer
could be moved between cmts's when a node is split

Thanks in advance for all responses,

Javier Gutierrez Guerra









Re: How to manage Static IPs to customers

2020-05-08 Thread Blake Hudson
16 connectors per DCAM2 times 6 cards is 96 DS service groups in a 
chassis. At ~1.2 Gbps per connector (using 32 SC-QAM DOCSIS 3.0 
channels) that's ~ 100gigabits per chassis. Quite a bit above my scale ;- )


The E6k can also do DOCSIS 3.1, which we use today, though I'm not sure 
what the capacity limit is per DCAM/SG/connector when both SQ-QAM and 
OFDM are used in combination.


--Blake

On 5/8/2020 4:13 PM, Luke Guillory wrote:
E6K using gen 1 DCAMs can do about 32 service groups give or take, not 
that hard to get to a point with splits where you want to go past 
those numbers. Gen 2 DCAMs double that by going to 16 connectors 
compared to 8. cBR8 is less than the E6K.


The point of node splits is to lower customers per SG, you can’t just 
split and stay on the same chassis if you’re at capacity on slots.


If you take the Comcast approach and start pushing fiber deeper in 
order to remove actives your node counts sky rocket. All the whole 
they’re lowering counts on SGs as well.


Even us little guys or working on lowering customers per SG, they have 
to be moved somewhere which would be another chassis if you’re out of 
free connectors on like cards.


Like

/Sent from my iPhone/


On May 8, 2020, at 4:02 PM, Blake Hudson  wrote:



Aaron, I was thinking something similar. I've never once had a node
split require moving a customer to a different CMTS. Even the very old
and (relatively) low capacity 7200 VXR could serve several nodes per
line card and supported several line cards per chassis. Newer cBR8, E6k,
and the like can serve many many times more customers across dozens of
nodes. Every L3 CMTS I've worked on uses something akin to ip unnumbered
so as long as the customer stays on the same CMTS, their IP address will
continue to work regardless of what interface or line card their
connection terminates on.

On 5/8/2020 2:34 PM, Aaron Gould wrote:
We have a provisioning system (promptlink) that we use to map cable 
modems
to their static ip addresses.  The provisioning system has a gui 
front end
and it sits on linux and also acts as a dhcp server, etc.  This is 
the same
ip address that we use for cable-helper (like ip-helper on a cmts 
bundle ip
interface) to forward dhcp requests from cable modem cpe, via the 
cmts, and

unicasted to promptlink and then the static ip address reservation within
the promptlink is sent back to the cpe

This all continues to work, even during node splits, as long as we don't
move that cm cpe to a different cmts... which would rarely happen 
since it's

across town to get to our other RF environment served be a different cmts
using a different static ip subnet... since we don't do L2 via cmts's in
order to stitch back that ip into a more globally located static 
subnet...
again, we don't do that.  If the customers moves locations, into a 
different
cmts area, that would be required to give back the single static /32 
ip and
get a different on.  Unless they were a multi-static customer buying 
like a
/29... in which case we have no problem moving that /29 subnet off 
that cmts

and onto another one.  That's easy.

We do however have more centrally located subnets for some of our single
static ip customers in FTTH... but not CMTS docsis.

-Aaron


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Javier 
Gutierrez

Guerra
Sent: Thursday, May 7, 2020 3:50 PM
To: nanog@nanog.org
Subject: How to manage Static IPs to customers

Hi there,
Just wanted to reach out and get an idea how is people managing customers
with static Ips, more specifically on Docsis networks where the customer
could be moved between cmts's when a node is split

Thanks in advance for all responses,

Javier Gutierrez Guerra











Re: How to manage Static IPs to customers

2020-05-08 Thread Luke Guillory
E6K using gen 1 DCAMs can do about 32 service groups give or take, not that 
hard to get to a point with splits where you want to go past those numbers. Gen 
2 DCAMs double that by going to 16 connectors compared to 8. cBR8 is less than 
the E6K.

The point of node splits is to lower customers per SG, you can’t just split and 
stay on the same chassis if you’re at capacity on slots.

If you take the Comcast approach and start pushing fiber deeper in order to 
remove actives your node counts sky rocket. All the whole they’re lowering 
counts on SGs as well.

Even us little guys or working on lowering customers per SG, they have to be 
moved somewhere which would be another chassis if you’re out of free connectors 
on like cards.

Like

Sent from my iPhone

On May 8, 2020, at 4:02 PM, Blake Hudson  wrote:

*External Email: Use Caution*

Aaron, I was thinking something similar. I've never once had a node
split require moving a customer to a different CMTS. Even the very old
and (relatively) low capacity 7200 VXR could serve several nodes per
line card and supported several line cards per chassis. Newer cBR8, E6k,
and the like can serve many many times more customers across dozens of
nodes. Every L3 CMTS I've worked on uses something akin to ip unnumbered
so as long as the customer stays on the same CMTS, their IP address will
continue to work regardless of what interface or line card their
connection terminates on.

On 5/8/2020 2:34 PM, Aaron Gould wrote:
We have a provisioning system (promptlink) that we use to map cable modems
to their static ip addresses.  The provisioning system has a gui front end
and it sits on linux and also acts as a dhcp server, etc.  This is the same
ip address that we use for cable-helper (like ip-helper on a cmts bundle ip
interface) to forward dhcp requests from cable modem cpe, via the cmts, and
unicasted to promptlink and then the static ip address reservation within
the promptlink is sent back to the cpe

This all continues to work, even during node splits, as long as we don't
move that cm cpe to a different cmts... which would rarely happen since it's
across town to get to our other RF environment served be a different cmts
using a different static ip subnet... since we don't do L2 via cmts's in
order to stitch back that ip into a more globally located static subnet...
again, we don't do that.  If the customers moves locations, into a different
cmts area, that would be required to give back the single static /32 ip and
get a different on.  Unless they were a multi-static customer buying like a
/29... in which case we have no problem moving that /29 subnet off that cmts
and onto another one.  That's easy.

We do however have more centrally located subnets for some of our single
static ip customers in FTTH... but not CMTS docsis.

-Aaron


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Javier Gutierrez
Guerra
Sent: Thursday, May 7, 2020 3:50 PM
To: nanog@nanog.org
Subject: How to manage Static IPs to customers

Hi there,
Just wanted to reach out and get an idea how is people managing customers
with static Ips, more specifically on Docsis networks where the customer
could be moved between cmts's when a node is split

Thanks in advance for all responses,

Javier Gutierrez Guerra








Re: How to manage Static IPs to customers

2020-05-08 Thread Blake Hudson
Aaron, I was thinking something similar. I've never once had a node 
split require moving a customer to a different CMTS. Even the very old 
and (relatively) low capacity 7200 VXR could serve several nodes per 
line card and supported several line cards per chassis. Newer cBR8, E6k, 
and the like can serve many many times more customers across dozens of 
nodes. Every L3 CMTS I've worked on uses something akin to ip unnumbered 
so as long as the customer stays on the same CMTS, their IP address will 
continue to work regardless of what interface or line card their 
connection terminates on.


On 5/8/2020 2:34 PM, Aaron Gould wrote:

We have a provisioning system (promptlink) that we use to map cable modems
to their static ip addresses.  The provisioning system has a gui front end
and it sits on linux and also acts as a dhcp server, etc.  This is the same
ip address that we use for cable-helper (like ip-helper on a cmts bundle ip
interface) to forward dhcp requests from cable modem cpe, via the cmts, and
unicasted to promptlink and then the static ip address reservation within
the promptlink is sent back to the cpe

This all continues to work, even during node splits, as long as we don't
move that cm cpe to a different cmts... which would rarely happen since it's
across town to get to our other RF environment served be a different cmts
using a different static ip subnet... since we don't do L2 via cmts's in
order to stitch back that ip into a more globally located static subnet...
again, we don't do that.  If the customers moves locations, into a different
cmts area, that would be required to give back the single static /32 ip and
get a different on.  Unless they were a multi-static customer buying like a
/29... in which case we have no problem moving that /29 subnet off that cmts
and onto another one.  That's easy.

We do however have more centrally located subnets for some of our single
static ip customers in FTTH... but not CMTS docsis.

-Aaron


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Javier Gutierrez
Guerra
Sent: Thursday, May 7, 2020 3:50 PM
To: nanog@nanog.org
Subject: How to manage Static IPs to customers

Hi there,
Just wanted to reach out and get an idea how is people managing customers
with static Ips, more specifically on Docsis networks where the customer
could be moved between cmts's when a node is split

Thanks in advance for all responses,

Javier Gutierrez Guerra

 








RE: How to manage Static IPs to customers

2020-05-08 Thread Luke Guillory
I believe some of the bigger guys do BSoD (business services over DOCSI), L2 
out the CMTS then take it to a central router for the CPEs gateway. Being that 
the GW lives on the CMTS in a normal setup, during node splits that would 
require customers moving to a new CMTS it might mean the customer doesn’t have 
access to that subnet anymore. 

BSoD makes that a non-issue since their GW doesn't reside on the CMTS anymore, 
just move their vlan and they're good. 

 
Luke

-Original Message-
From: NANOG  On Behalf Of Brandon Martin
Sent: Friday, May 8, 2020 2:55 PM
To: nanog@nanog.org
Subject: Re: How to manage Static IPs to customers

*External Email: Use Caution*

I'm curious...

Is it part of the DOCSIS spec that the CMTS terminates L3, or can they bridge 
to IEEE 802(.3) and delegate that to some other piece of gear?
I'm unfortunately not familiar with the MSO world much at all aside from a 
little bit of L1.

--
Brandon Martin


Re: How to manage Static IPs to customers

2020-05-08 Thread K. Scott Helms
The spec allows for bridging or layer 3 but none of the major or certified
manufacturers support bridging on larger platforms.  (>1000 modems)

Scott Helms



On Fri, May 8, 2020 at 3:56 PM Brandon Martin 
wrote:

> I'm curious...
>
> Is it part of the DOCSIS spec that the CMTS terminates L3, or can they
> bridge to IEEE 802(.3) and delegate that to some other piece of gear?
> I'm unfortunately not familiar with the MSO world much at all aside from
> a little bit of L1.
>
> --
> Brandon Martin
>


Re: How to manage Static IPs to customers

2020-05-08 Thread Brandon Martin

I'm curious...

Is it part of the DOCSIS spec that the CMTS terminates L3, or can they 
bridge to IEEE 802(.3) and delegate that to some other piece of gear? 
I'm unfortunately not familiar with the MSO world much at all aside from 
a little bit of L1.


--
Brandon Martin


RE: How to manage Static IPs to customers

2020-05-08 Thread Aaron Gould
We have a provisioning system (promptlink) that we use to map cable modems
to their static ip addresses.  The provisioning system has a gui front end
and it sits on linux and also acts as a dhcp server, etc.  This is the same
ip address that we use for cable-helper (like ip-helper on a cmts bundle ip
interface) to forward dhcp requests from cable modem cpe, via the cmts, and
unicasted to promptlink and then the static ip address reservation within
the promptlink is sent back to the cpe

This all continues to work, even during node splits, as long as we don't
move that cm cpe to a different cmts... which would rarely happen since it's
across town to get to our other RF environment served be a different cmts
using a different static ip subnet... since we don't do L2 via cmts's in
order to stitch back that ip into a more globally located static subnet...
again, we don't do that.  If the customers moves locations, into a different
cmts area, that would be required to give back the single static /32 ip and
get a different on.  Unless they were a multi-static customer buying like a
/29... in which case we have no problem moving that /29 subnet off that cmts
and onto another one.  That's easy.

We do however have more centrally located subnets for some of our single
static ip customers in FTTH... but not CMTS docsis.

-Aaron


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Javier Gutierrez
Guerra
Sent: Thursday, May 7, 2020 3:50 PM
To: nanog@nanog.org
Subject: How to manage Static IPs to customers

Hi there, 
Just wanted to reach out and get an idea how is people managing customers
with static Ips, more specifically on Docsis networks where the customer
could be moved between cmts's when a node is split

Thanks in advance for all responses,

Javier Gutierrez Guerra







Re: How to manage Static IPs to customers

2020-05-08 Thread Yang Yu
On Fri, May 8, 2020 at 8:56 AM Michael Crapse  wrote:
>
> On our network(which isn't docsis, granted) we use PPPoE for all static IP 
> addresses, because it allows /32 ip address allocations for all home CPE 
> routers, upstream, the routers handle routing via ospf to change the path of 
> where that /32 public IP goes. It allows "zero touch" moving of a customer 
> from one PoP to another.

Portable long prefix makes geoip more challenging (e.g. /29s in a
single /24 used in different markets)
I am curious for static IP services, how often does the address come
from a local (PoP/metro) pool, and what the policy is for keeping the
same IP when service address moves.


RE: How to manage Static IPs to customers

2020-05-08 Thread K MEKKAOUI
I am also interested in this. We are using DOCSIS and I am not sure what other 
providers with DOCSIS are using, any help on this will be appreciated.

Thank you

 

From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Michael Crapse
Sent: May 8, 2020 11:54 AM
To: edwin.malle...@gmail.com
Cc: NANOG list
Subject: Re: How to manage Static IPs to customers

 

On our network(which isn't docsis, granted) we use PPPoE for all static IP 
addresses, because it allows /32 ip address allocations for all home CPE 
routers, upstream, the routers handle routing via ospf to change the path of 
where that /32 public IP goes. It allows "zero touch" moving of a customer from 
one PoP to another. 

 

On Fri, May 8, 2020 at 8:34 AM  wrote:

So in most cases I'm aware of, the cable provider did not use RIP directly
to a customer-managed device.  The cable operator would deploy their own
managed device, implement RIP and the appropriate keychains between the
operator-managed premise device and the CMTS.  As for the use cases, RIP was
implemented to address the specific 'recombine' use case where one day (or
evening) cable customer attachments could be moved from one CMTS to another.
Instrumenting that with DHCP or TR69 usually required other teams'
involvement and didn't allow portability.

With IPv6 you get PD which helps immensely.

Ed

-Original Message-
From: NANOG  On Behalf Of Javier Gutierrez Guerra
Sent: Friday, May 8, 2020 8:57 AM
To: NANOG list 
Subject: RE: How to manage Static IPs to customers

That's surprising to me, I have no intentions to do routing with our cable
subscribers, that seems like a headache for both sides Today we have
specific ranges within subnets from where we assign IPs to customers, my
main problem that I'm trying to get around is having to change a customer
static IP if their node gets splitter and I have to mode them to a different
CMTS

Thanks,

Javier Gutierrez Guerra



-Original Message-
From: NANOG  On Behalf Of Bryan Fields
Sent: Thursday, May 7, 2020 5:57 PM
To: nanog@nanog.org
Subject: Re: How to manage Static IPs to customers

CAUTION: This email is from an external source. Do not click links or open
attachments unless you recognize the sender and know the content is safe.

On 5/7/20 5:54 PM, Brandon Jackson via NANOG wrote:
> I have seen (Charter) and heard quite a few run RIP or some other 
> routing protocol on the CPE.

Yep, it's RIP.  They don't support IPv6 on this either.  I've been asking
for
IPv6 since 2006, it's always next year.

--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net



Re: How to manage Static IPs to customers

2020-05-08 Thread Michael Crapse
On our network(which isn't docsis, granted) we use PPPoE for all static IP
addresses, because it allows /32 ip address allocations for all home CPE
routers, upstream, the routers handle routing via ospf to change the path
of where that /32 public IP goes. It allows "zero touch" moving of a
customer from one PoP to another.

On Fri, May 8, 2020 at 8:34 AM  wrote:

> So in most cases I'm aware of, the cable provider did not use RIP directly
> to a customer-managed device.  The cable operator would deploy their own
> managed device, implement RIP and the appropriate keychains between the
> operator-managed premise device and the CMTS.  As for the use cases, RIP
> was
> implemented to address the specific 'recombine' use case where one day (or
> evening) cable customer attachments could be moved from one CMTS to
> another.
> Instrumenting that with DHCP or TR69 usually required other teams'
> involvement and didn't allow portability.
>
> With IPv6 you get PD which helps immensely.
>
> Ed
>
> -Original Message-
> From: NANOG  On Behalf Of Javier Gutierrez Guerra
> Sent: Friday, May 8, 2020 8:57 AM
> To: NANOG list 
> Subject: RE: How to manage Static IPs to customers
>
> That's surprising to me, I have no intentions to do routing with our cable
> subscribers, that seems like a headache for both sides Today we have
> specific ranges within subnets from where we assign IPs to customers, my
> main problem that I'm trying to get around is having to change a customer
> static IP if their node gets splitter and I have to mode them to a
> different
> CMTS
>
> Thanks,
>
> Javier Gutierrez Guerra
>
>
>
> -Original Message-----
> From: NANOG  On Behalf Of Bryan Fields
> Sent: Thursday, May 7, 2020 5:57 PM
> To: nanog@nanog.org
> Subject: Re: How to manage Static IPs to customers
>
> CAUTION: This email is from an external source. Do not click links or open
> attachments unless you recognize the sender and know the content is safe.
>
> On 5/7/20 5:54 PM, Brandon Jackson via NANOG wrote:
> > I have seen (Charter) and heard quite a few run RIP or some other
> > routing protocol on the CPE.
>
> Yep, it's RIP.  They don't support IPv6 on this either.  I've been asking
> for
> IPv6 since 2006, it's always next year.
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>
>


RE: How to manage Static IPs to customers

2020-05-08 Thread edwin.mallette
So in most cases I'm aware of, the cable provider did not use RIP directly
to a customer-managed device.  The cable operator would deploy their own
managed device, implement RIP and the appropriate keychains between the
operator-managed premise device and the CMTS.  As for the use cases, RIP was
implemented to address the specific 'recombine' use case where one day (or
evening) cable customer attachments could be moved from one CMTS to another.
Instrumenting that with DHCP or TR69 usually required other teams'
involvement and didn't allow portability.

With IPv6 you get PD which helps immensely.

Ed

-Original Message-
From: NANOG  On Behalf Of Javier Gutierrez Guerra
Sent: Friday, May 8, 2020 8:57 AM
To: NANOG list 
Subject: RE: How to manage Static IPs to customers

That's surprising to me, I have no intentions to do routing with our cable
subscribers, that seems like a headache for both sides Today we have
specific ranges within subnets from where we assign IPs to customers, my
main problem that I'm trying to get around is having to change a customer
static IP if their node gets splitter and I have to mode them to a different
CMTS

Thanks,

Javier Gutierrez Guerra



-Original Message-
From: NANOG  On Behalf Of Bryan Fields
Sent: Thursday, May 7, 2020 5:57 PM
To: nanog@nanog.org
Subject: Re: How to manage Static IPs to customers

CAUTION: This email is from an external source. Do not click links or open
attachments unless you recognize the sender and know the content is safe.

On 5/7/20 5:54 PM, Brandon Jackson via NANOG wrote:
> I have seen (Charter) and heard quite a few run RIP or some other 
> routing protocol on the CPE.

Yep, it's RIP.  They don't support IPv6 on this either.  I've been asking
for
IPv6 since 2006, it's always next year.

--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net



Re: How to manage Static IPs to customers

2020-05-08 Thread Pierre LANCASTRE
Hi,

In my previous job, we managed static IPs by implementing L2TP tunnels
between CPEs and central Juniper LNS. It wasn't very elegant (at least for
mtu, MSS clamping), but the design was done around 15 years ago :)

BR

Pierre


Le ven. 8 mai 2020 à 00:58, Bryan Fields  a écrit :

> On 5/7/20 5:54 PM, Brandon Jackson via NANOG wrote:
> > I have seen (Charter) and heard quite a few run RIP or some other routing
> > protocol on the CPE.
>
> Yep, it's RIP.  They don't support IPv6 on this either.  I've been asking
> for
> IPv6 since 2006, it's always next year.
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>


Re: How to manage Static IPs to customers

2020-05-08 Thread Bryan Fields
On 5/8/20 8:57 AM, Javier Gutierrez Guerra wrote:
> That's surprising to me, I have no intentions to do routing with our cable
> subscribers, that seems like a headache for both sides

Meh, there are BNG solutions out there;
but RIP's not horrible _in_this_context_

> Today we have specific ranges within subnets from where we assign IPs to
> customers, my main problem that I'm trying to get around is having to
> change a customer static IP if their node gets splitter and I have to mode
> them to a different CMTS

I've seen some business services over DOCSIS where you're using VPLS to come
back to a central router of your choosing, but it's still Ethernet.  There's
DHCP and mac addresses and a connection-less medium.  PPPoE solves that, but
then you're doing PPP.   Oh and you have the fun of doing ldp signaled VPLS
with a CMTS that was made by people who don't understand it.

There's several other BNG solutions out there, and I'm happy to go a bit
deeper if you're down the TR-69 path.  For the business customer, most are
going to balk at anything other than a static IP Ethernet service delivered
over Ethernet.  Depending on your skill-set and network size you might be able
to roll this yourself.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net


Re: How to manage Static IPs to customers

2020-05-08 Thread K. Scott Helms
Javier,

There's really no good way to handle this without routing or tunneling that
I've been able to find in a very long time.  (SD-WAN can help, but it's
just a fancy way to tunnel in this regard.)  It's pretty amazing that this
is such an issue, but it remains so.  I have tried to work around this
using BSoD (
https://specification-search.cablelabs.com/business-services-over-docsis-layer-2-virtual-private-networks
)
but we eventually abandoned the effort because it rapidly became to
expensive to scale to solve a niche problem.

Scott Helms



On Fri, May 8, 2020 at 8:58 AM Javier Gutierrez Guerra <
guer...@westmancom.com> wrote:

> That's surprising to me, I have no intentions to do routing with our cable
> subscribers, that seems like a headache for both sides
> Today we have specific ranges within subnets from where we assign IPs to
> customers, my main problem that I'm trying to get around is having to
> change a customer static IP if their node gets splitter and I have to mode
> them to a different CMTS
>
> Thanks,
>
> Javier Gutierrez Guerra
>
>
>
> -Original Message-
> From: NANOG  On Behalf Of Bryan Fields
> Sent: Thursday, May 7, 2020 5:57 PM
> To: nanog@nanog.org
> Subject: Re: How to manage Static IPs to customers
>
> CAUTION: This email is from an external source. Do not click links or open
> attachments unless you recognize the sender and know the content is safe.
>
> On 5/7/20 5:54 PM, Brandon Jackson via NANOG wrote:
> > I have seen (Charter) and heard quite a few run RIP or some other
> > routing protocol on the CPE.
>
> Yep, it's RIP.  They don't support IPv6 on this either.  I've been asking
> for
> IPv6 since 2006, it's always next year.
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>


RE: How to manage Static IPs to customers

2020-05-08 Thread Javier Gutierrez Guerra
That's surprising to me, I have no intentions to do routing with our cable 
subscribers, that seems like a headache for both sides
Today we have specific ranges within subnets from where we assign IPs to 
customers, my main problem that I'm trying to get around is having to change a 
customer static IP if their node gets splitter and I have to mode them to a 
different CMTS

Thanks,

Javier Gutierrez Guerra



-Original Message-
From: NANOG  On Behalf Of Bryan Fields
Sent: Thursday, May 7, 2020 5:57 PM
To: nanog@nanog.org
Subject: Re: How to manage Static IPs to customers

CAUTION: This email is from an external source. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.

On 5/7/20 5:54 PM, Brandon Jackson via NANOG wrote:
> I have seen (Charter) and heard quite a few run RIP or some other 
> routing protocol on the CPE.

Yep, it's RIP.  They don't support IPv6 on this either.  I've been asking for
IPv6 since 2006, it's always next year.

--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net


Re: How to manage Static IPs to customers

2020-05-07 Thread Bryan Fields
On 5/7/20 5:54 PM, Brandon Jackson via NANOG wrote:
> I have seen (Charter) and heard quite a few run RIP or some other routing
> protocol on the CPE.

Yep, it's RIP.  They don't support IPv6 on this either.  I've been asking for
IPv6 since 2006, it's always next year.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net


Re: How to manage Static IPs to customers

2020-05-07 Thread Brandon Jackson via NANOG
I do not believe it is a GRE tunnel.

I have seen (Charter) and heard quite a few run RIP or some other routing
protocol on the CPE.

Though I have not seen anything specific about Comcast specifically.


Brandon Jackson

On Thu, May 7, 2020, 16:54 Brandon Martin  wrote:

> On 5/7/20 4:49 PM, Javier Gutierrez Guerra wrote:
> > Just wanted to reach out and get an idea how is people managing
> customers with static Ips, more specifically on Docsis networks where the
> customer could be moved between cmts's when a node is split
>
> Around here, Comcast seems to provision a GRE tunnel from the CPE back
> to some router within their network and run it over whatever IP address
> the CMTS hands out to the modem.  Not very efficient, and it mandates
> that you use their CPE (they won't give you the necessary info to set it
> up yourself).
>
> AFAIK, such service is only available on their "business class" DOCSIS
> product and is upcharged even then.
> --
> Brandon Martin
>


Re: How to manage Static IPs to customers

2020-05-07 Thread Brandon Martin

On 5/7/20 4:49 PM, Javier Gutierrez Guerra wrote:

Just wanted to reach out and get an idea how is people managing customers with 
static Ips, more specifically on Docsis networks where the customer could be 
moved between cmts's when a node is split


Around here, Comcast seems to provision a GRE tunnel from the CPE back 
to some router within their network and run it over whatever IP address 
the CMTS hands out to the modem.  Not very efficient, and it mandates 
that you use their CPE (they won't give you the necessary info to set it 
up yourself).


AFAIK, such service is only available on their "business class" DOCSIS 
product and is upcharged even then.

--
Brandon Martin