Comware Based
1832984 Members
2718 Online
110048 Solutions
New Discussion

Tracking down a mystery patching.

 
Keverso
Occasional Visitor

Tracking down a mystery patching.

Hi all,

 

I have recently been put i charge of a medium sized network with little to no handover or documentation (long story). I am slowly getting to grips with ComWare but it's slow work as I dont have any training or much time to do independant study.

 

Which brings us to todays issue...

 

I have been asked to unpatch a PC. There is no way if identifying the floor socket by number as has no sitcker (nothing near it either) and it goes via a pinfull route involving celing voids and all sorts of interesting stuff. So my thoughts were get an IP/MAC table and see if I can identify the socket that way. I did get the table and the device is on there but for the port it is only showing

 

BAGG4

 

which understand means it is a bridge aggrigation. This makes sence as there are a few switches stacked.

 

So - how do I get the physical port? Can someone point me it the right direction please?

 

Thanks

Keverso

5 REPLIES 5
cgu
Frequent Advisor

Re: Tracking down a mystery patching.

display link-agg verbose br4

parnassus
Honored Contributor

Re: Tracking down a mystery patching.

Hi!
The task of unpatching a PC generally involves to just unpatch a single physical link to (the first) Switch the host is connected to...and it generally also means that no BAGG (aggregated ports) is involved...at least if you're pretty sure that that host is single linked to your network (single linked = 1 NIC port used on the host).

Here I exclude the corner case - totally possible - that you are dealing with a BAGG switch side working with just one downlink to the host where that very host is not really set to work with any bonded interfaces it eventually owns (it is a rare corner case but it is also a possible scenario --> it requires a special configuration - the lacp edge-port trick - switch side and it requires probably an unconfigured/misconfigured host on the access side).
Long story short 1 cable from host should mean 1 access interface switch side (not an aggregation interface).

That's to say that it's pretty strange to see the IP/MAC binding to interface linking you to a BAGG interface. Are you sure?

Maybe the switch you believe the host is connected to is not the one you have checked...and so the MAC is seen throught the BAGG to that very switch.

I'm not an HPE Employee
Kudos and Accepted Solution banner
Keverso
Occasional Visitor

Re: Tracking down a mystery patching.

Hi Parnassus

I don't really care where in the route I break the patching - I just need the socket dead. It's in a public area that was manned but now is not. This network was handed to me almost as an aside (it's not my "day job") and there is no training or documentation. So while I don't doubt what you are saying for a second I am afraid it's way above my head (I am a programmer - not a network bod).

If I can't identify where this thing is plugged in (which is not looking good) I think I will just unscrew the face place and cut the cable then put it back. Not elegant but it will get the job done.

 

Thanks for your reply - I hope one day I can understand it  

 

Keverso,

Keverso
Occasional Visitor

Re: Tracking down a mystery patching.

Hi Cgu,

 

I was kind of expecting a list of IP/MAC addreses with the associated port but what I received was this (changed to xxx..)

Local:
Port Status Priority Oper-Key Flag
--------------------------------------------------------------------------------
GE1/2/0/7 S 32768 4 {ACDEF}
GE1/2/0/8 S 32768 4 {ACDEF}
GE2/2/0/7 S 32768 4 {ACDEF}
GE2/2/0/8 S 32768 4 {ACDEF}
Remote:
Actor Partner Priority Oper-Key SystemID Flag
--------------------------------------------------------------------------------
GE1/2/0/7 56 32768 1 0x8000, xxxx.xxxx.xxxx.xxxx {ACDEF}
GE1/2/0/8 109 32768 1 0x8000, xxxx.xxxx.xxxx.xxxx {ACDEF}
GE2/2/0/7 1 32768 1 0x8000, xxxx.xxxx.xxxx.xxxx {ACDEF}
GE2/2/0/8 57 32768 1 0x8000, xxxx.xxxx.xxxx.xxxx {ACDEF}

 

So I am afraid I am no further forward.

Thank you for your time - I'm sure the issue is my end and that should have worked.

 

parnassus
Honored Contributor

Re: Tracking down a mystery patching.

Hi @Keverso, we're here to help you.

Physically eliminating a cable's termination by cutting its known end is a little bit drastic in my opinion...and if it solves your main purpose (to secure an unsupervised zone) it also leave you with a network in an unknown state (what-is-connected-where-and-how).

Your BAGG (Bridge AGgregation Group) details show you that you're dealing with an IRF made of two member switches (where you executed the display command) which use four of its interfaces (1/2/0/7+1/2/0/8+2/2/0/7+2/2/0/8) to connect to another switch...this peer - still unknown - switch is probably the one your host is directly connected to and the logical interface bagg4 on the IRF is the interface through which your core (which, at this point, is your IRF virtual switch by doing routing) recognizes the IP you looked for (IP/MAC binding) for that host.

I'm not an HPE Employee
Kudos and Accepted Solution banner