maintain fixed IPv4-Adresses during Node-Splits | docsis.org

You are here

maintain fixed IPv4-Adresses during Node-Splits

5 posts / 0 new
Last post
schg
maintain fixed IPv4-Adresses during Node-Splits

Hello everybody,

current practice when doing node-splits (involving moving a cluster/node to another CMTS) is to call all affected customers with fixed public ipv4 addresses and inform them that their fixed public IPv4 address will change on a certain date.

I want to try to avoid this.
I am willing to accept a complex configuration and maybe routing /32 ipv4-prefixes through our backbone for business customers.

Currently we use ubr10k CMTS.
All routing is done using routing protocols. Sometimes static routing is used.
All fixed public IPv4-Adresses are being leased by our DHCP server.

Has anyone accomplished this?

wittmann
It's possible but tricky

Hi, it's possible. Is a hell of scripting. The entry point is the CM On Off Trap/Inform message, which you can configure at the CMTS.
So the idea is that your backend is receiving the Off and On Events of the particular cable modem. If your cable modem has switched to another CMTS the backend will receive the On Event of this particular cable modem from the other source address, e.g. loopback0 or 1 (whatever you'd configured). So the systems know on which different CMTS the cable modem has come online now. Then the backend goes to the last known CMTS and deconfigure the /30 or /32 in the IP-Bundle interface and configure the same /30 or /32 on the new CMTS IP-Bundle interface. Of course your DHCP configuration has to be adapted, too.
If you don't want to use DHCP for fixed IP you can also use Source Address Verification (SAV) with the TLV 43.7.2.1 (IPv4) or 43.7.2.2 (IPv6). This gives you the chance for static IP configuration without disable DHCP-Authorization.

This is just to give you an idea. There are other ways possibe for sure but this is my example.

Best regards,

mbowe
Yes it is a major pain

Yes it is a major pain

Many times I have wished our customer base was dynamic-ip only

Instead of moving half the split node to another CMTS, do you have any dynamic-ip only nodes that can be moved instead?

bbob
Same issue

We had the same problem when we first moved from a single CMTS to two CMTSs in one of our communities. We first tried using proxy arp to solve the issue but ran into some problems.

Here is the clunky solution we ended up using:
-Provision the customer subnets on both CMTSs
-Create static /32 routes on upstream router that points to the correct CMTS
-Push /32 routes to both CMTSs using BGP

This has worked out well for us so far, but I could see this becoming tedious if we had more static customers.

schg
Similar idea:

I thought about a similar solution as well:

1) Put the subnet for customers with fixed addresses on all CMTS.
2a) Run a script in the DHCP-Server, which adds (DHCPACK) and deletes (DHCPNACK/LEASETIMEOUT) static /32 routes on the CMTS of the current customer.
(I am wondering if one could push static routes via SMNP set....)

or

2b) Use Cisco TCL+EEM to somehow detect valid ARP entries for the subnet. Then let a TCL-Script with EEM create static routes for valid ARP entries and remove them, when the entries are absent or Incomplete.
a) Ping-Sweep with 0 seconds timeout over the Subnet to create ARP entries (Routers may not answer the Ping, but we need to enforce arp learning)
b) create a loop for variable $x from first to last IP-Address
c) if arp entry present, then push cli command "ip route 1.2.3.$x 255.255.255.255 interface Bundle1"
d) if arp entry not present or incomplete, then push cli command "no ip route 1.2.3.$x 255.255.255.255 interface Bundle1"
e) do the loop until all addresses had been checked
3) The IGP with "redistribute static" does the rest and will happily distribute the /32 routes throughout the whole network.

Log in or register to post comments