17 September, 2008

Week five

9/15/08
Tried to bring up a 5006 and console into it to configure an SM for ATM; had no luck. Made sure all the cards were using compatible versions of code; Mike was a huge help, but couldn’t figure out why the card was not allowing itself to be configured.
Spoke to Thom about how to adapt the script to account for the new MAC scheme. After a few trial and errors, we got the script to work right.
9/16/08
Continued trouble binding DHCP streams. Loaded an old version (dated 9-11). Tested the script against the 5 streams on 1-15; test successful. Can not find a difference between the two saved sessions, but will use the archive and delete the new saves.
Noticed some ADSL cards were again misidentifying themselves. Was told the ADSL cards were supposed to be at 118 instead of 122. Could not get the tftp server to work. Kenny loaded the necessary files onto his server so I could both troubleshoot the upgrade as well as downgrade to 118.
Had seen some loss of provisioning on cards that I know I had provisioned. Did not know what the cause was. We had done hard reboots of all the cards to fix a CAM table (?) problem, so could not be sure if it was a power issue or if it happened when we upgraded to 122.
We disconnected some cards, and saw no loss of provisioning. I downgraded and saw no loss of provisioning. Updated a single card and saw no loss of provisioning.
Verified that every card was provisioned correctly.
9/17/08
Pam updated the system as a whole and it appears there is no loss of provisioning.
Ken said that perhaps the RPOTS or the VG card were conflicting, so we pulled the VG and RPOTS cards.
Made SCA update on both servers: TA5K_4.1_ADSL_DONE_V118_091708_JM
Built scripts for all cards.
Verified that all VLANs went sequentially across ADSL cards.
Verified that it was ok to have the same VLAN on two different cards.
Still not bonding on the other shelves
I checked again to ensure the ports were configured for IPOE or auto; they were
I checked the VLAN IDs again. It appears that the 2nd (server) VLAN id is incrementing (see 2-11-32 server) , even if there isn’t supposed to be one. This shouldn’t affect the emulations with a C-tag, though, and may be incidental.
I couldn’t find any obvious errors so, per Lloyd, I sent some traffic across and then physically checked the modem. I sent traffic across 3-7, and then checked modem 3-64 (port 32). No traffic was evident
Lloyd said that then it must be a physical layer problem and he showed me where I could check via N2X
Lo and behold, all the links are bad on shelf 3. I then checked the other session. All the links were bad on every shelf. This would explain the problem, I think….
No one in the lab to help me trace, so I will do it tomorrow.
9/18/08
Discovered a problem with the port setup that fixes the linkage.  The phys layer configuration has to be set to SFP and the Link layer has to have ARP disabled under Ethernet and NDP disabled under EthIPv6.  This would explain why no bonding is occurring on any of the shelves that I had added.
 
I was right that there should be no VLANID2 at all if there is no Ctag, but the script is causing it to be created.  I can either go and manually delete each and every Ctag for those emulations or I can rewrite the script to comment out everything about VLANid2 and rerun the script
Found out that for single tags there should only be one server.  After deleting all the other servers, only one port was binding, and no one could tell why.  Figured out that the script was restricting the IP address pool to just 8 (because we used to have one server for one client with 8 MAC addresses).  After bumping the pool up to 256, it seemed to work.  Have not yet tried to stream traffic across it.
Started working on the PPPoE emulations for that card, and noticed that the starting source MAC addresses were identical across two different cards.  Talked to Lloyd and he suggested that they should all be discrete.  Not sure if it will have an adverse effect, but better safe than sorry.  Will have to go back and bring those back into line with the MAC addressing scheme we devised for the DHCP.  Luckily I have only built 8×27 + 8×14 emuilations before I reallized it was happening.
For PPPoE, I may need, instead of 8 servers with 14 clients, go with 1 server with 8 clients, or some other scheme; if my original config doesn’t work, this should be my first check.
PPPoE is not connecting over 3-1 it seems.  Traffic is flowing, (verified by modem check) but connections are not being made.  It might be the MAC scheme, but doesn’t seem likely given that I never fixed the 1-19 scheme and they connected
Namasté,
Sisyphus

No comments: