@jbond, this task isn't editable by most users (so i cannot remove the invalid project), please remove the procurement project.

Not sure why procurement was added (so it showed up in my notifications) as this user isn't in the acl*procurement review, they are in the acl*sre-team so I took the liberty of removing them since I was checking the two groups that give access to the procurement space.

Please note we've run into this issue again today:

Since this is out of warranty, the pending purchase of 5 disks was raised to 7 on T331988 to accommodate this repair.

In T331886#8688402, @ayounsi wrote:

Note that we will only have one mx480 (current cr3-esams), the other router will be the current cr3-knams (mx204).

Future refresh will replaced that mx480 with a device similar to a mx204. So it might be better to keep the mx204 at the top, as well as space for the mx480 replacement.

Ideally we should also have 1 patch panel per rack.

We chatted about this during the last knams sync up call, as our racks there have a higher cap due to this.

This is in 'decom' state with all the other now decommissioned eqsin hardware. I'm resolving this task as everything for decom is now tracking disposal via T330313

+1 to fixing them as separate entries as its easy enough to add more models to netbox. Particularly since Homer can report them as such as well!

They pulled power, plugged it back in, and now its online and responsive.

Case Order #00839073

The scs is also only accessible via mr1-ulsfo, so I'll put in a remote hands for them to power cycle it manually.

both hosts online and ready for your use!

Whatever array you create first on the new 15th gen raid controller gets the higher ID, which is the opposite of 14th generation raid controller.

• dumpdata1007 has ssds raid1 virtual drive id 238, hdds raid10 virtual drive id 239, installs fine.

LVM data still exists on disks from a previous failed install attempt and the dd method didn't seem to remove, suspended instllation on dumpsdata1006 and set it to fully initialize all the disks, so I'll set a timer and come back to this in about 2 hours.

If I have an overwhelming number of notifications in a short period (seems I did around January 18th) I may miss direct pings where the task isn't assigned to me. Accidental of course!

This seems to have stalled with an inconclusive assumption that the NIC firmware update solved it, but we have no confirmation of that (see @ssingh's last comment above).

remote hands successfully removed the optic this AM and placed it in our racks, we'll just have it thrown away next remote hands work we need. router appears fine.

Ok, pulling some peak numbers off the idrac https interface which includes weekly graphing and peaks.

Support,

We have three items for remote hands to accomplish for us on this request:

1. Please pickup DEL0117661, unpackage it into our racks, and photograph both the package contents and the packing slip. Ensure packing slip matches contents.

2. Inventory the spare optics in our racks (placed on top of the servers) and give us a full count of the number/type of spare optics, patch cables, and power cables.

3. Troubleshoot removal of a broken optic in our router cr2-drmrs:xe-0/1/1, located in B13:U45. The optic was reported by remote hands to be stuck, missing its lever to eject the optic.

I've attached photos of the same type of optic in use. Can support attempt to remove this optic by using a small flat screwdriver or probe to manually work the ejection mechanism? The attached photos and video show this operation.

If removal isn't possible, we'll have to put in a support case with Juniper to swap the entire router, causing disruptive maintainance, so we'd prefer to avoid that if possible.

Also can the attempt to remove the optic take place when our Network Admin is around in the event of unexpected downtime. Please have this work take place on Tuesday, February 7th @ 9AM local time to ensure we have network coverage.

Scheduling: 1 & 2 can be done at anytime but please restrict the optic troubleshooting to Tuesday, February 7th starting at 9AM CET.

Neglected to do this earlier this week, I have the photos so I'll work on this today.

Arzhel linked to some docs and commented netbios is called wins in HP ilom, and I had noticed the wins enablement under IPv4 so disabled and the issue went away for db1140. Going to disable on the rest of them.

I've disabled the multicast discovery on the ilom interface for db1140 (10.65.1.134) as a test to see if it stops the netbios port broadcasts from the ilom interfaces.

Please note all 5 of these host are old HP ProLiants. I'm not sure where this setting is on these hosts, but I'm assuming in the bios and each of these will require downtime/reboot to disable.

added details to the recycled tab in the datacenter asset tags tracking google sheet and delted from netbox.

@pfischer: I've added you to #acl*procurement-review and you can now access tasks in the S4 procurement space:

device resurrected itself, decom task declined as its now reporting into ripe portal

in valid this is actually data persistence i had it mislabeled

actually data persistence this was a mis categorization