Dear all, We are currently in the progress of migrating the existing BAC (v126.96.36.199) & CNR (v188.8.131.52) towards v4.2 and v7.2. Now these two systems have been setup in parallel and we would to redirect all of the CMs towards the new BAC/CNR. In the meantime we are also upgrading all of the different CMTS's (routing engine, linecards, timing cards, etc ...). At the moment we are encountering the following issue: - One CM present on one CMTS --> online(pt) - One CM present on another CMTS --> reject(ip) Both of these CMs are using exactly the same BAC/CNR and the hardware/software is identical of both CMTS's. Has anyone seen this specific behaviour already? The official CM status of reject(ip) is the following: "The CM attempted to register, but registration failed because the IP address in the CM request did not match the IP address that the TFTP server recorded when it sent the DOCSIS configuration file to the CM. IP spoofing could be occurring." This doesn't make any sense since the there is one CM online and functioning without any issues. Kind Regards, Eno
... View more
Dear all, I'm currently investigating what the VRF-lite limitations are on the following platform: The setup consists of two of these devices dedicated for the DMZ infrastructure. Cat6509-E: ---------------- 4 * WS-X6148-GE-TX 1 * WS-SUP720-3B 1 * WS-X6748-SFP 1 * ACE20-MOD-K9 1 * WS-X6748-SFP (WS-F6K-PFC3B) You can see on the specs of the Sup720-3B that the FIB is limited to 256k entry's (by default configured to 192k). I know that the Sup720-3B supports up to 512 VRFs in hardware. Each of the chassis is configured with 14 VRFs (VRF-lite, no MPLS) with each approximately 300 static routes. Obviously there is currently no problem in regards to available resources atm. The question is only which items have an influence on this (available memory/NVRAM/available IDBs/... Is there some kind of best practice in regards to the amount of VRFs you can deploy/provision taking into account the resources they require? I'm searching for an easy way to explain this to the customer without having to detail the whole cat6500/Sup architecture. Kind Regards!
... View more