-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
port-channel (aggregate) support #100
Comments
SNMP-Info impementation Original comment by: arcanez |
Logged In: YES netdisco changes in store_interfaces, my $i_lastchange = $device->i_lastchange(); + my $agg_ports = $device->agg_ports(); insert_or_update('device_port', { 'ip' => $ip, 'port' => $store{port} }, table definition Original comment by: arcanez |
Logged In: YES I tried your patch today, but have some problems to see useful output. The discover didn't work from start... SNMP::Info::AUTOLOAD(agg_ports) Attribute not found in this device class. at ./netdisco line 2388 ...but I could solve this after changing C6500.pm. Now I get some more info. SNMP::Info::_load_attr pagp_group_index : pagpGroupIfIndex But I don't see the channel information anywhere on the device view page. I guess there is more work to do? Original comment by: ralfgross |
Logged In: YES this does not include any modifications to the netdisco web frontend. for our implementation, we only use the netdisco backend. but, it should only entail joining device_port_agg against device_port on port & ip. 'aggregate' is the port-channel (etherchannel, etc) and 'port' is the member. netdisco=> SELECT * FROM device_port_agg WHERE ip = 'xxx.xxx.xxx.xxx' AND aggregate = 'Port-channel1'; Original comment by: arcanez |
patch to put uplinks (CDP neighbors) on port-channels Original comment by: arcanez |
Logged In: YES here's a patch against current-cvs (3/3/2008) to put aggregates into CDP neighbors.. --- netdisco.cvs 2008-03-03 08:53:29.000000000 -0700 + ### hack to put uplinks (CDP neighbors) on Port-channel interfaces File Added: netdisco.patch Original comment by: arcanez |
Logged In: YES This checks the port-channel members for neighbors in walk_fwtable (called by macsuck) instead of falsifying neighbors onto port-channels.. perhaps some of the code should be moved further up to where $dbports is created ? --- netdisco (revision 1692) - my $remote_ip = $dbports->{$port}->{remote_ip}; File Added: netdiso-20080304.patch Original comment by: arcanez |
Logged In: YES per ralf gross, Index: netdisco--- netdisco (revision 1692) - my $remote_ip = $dbports->{$port}->{remote_ip}; Original comment by: arcanez |
This checks the port-channel members for neighbors in walk_fwtable Original comment by: arcanez |
Logged In: YES File Added: netdiso-20080304.patch Original comment by: arcanez |
Original comment by: jeneric-placeholder |
Logged In: YES Would like to implement this to transparently support the IEEE standard as well as proprietary implementations. Original comment by: jeneric-placeholder |
Note that I believe there is no OID which reveals ports assigned (in configuration) to an aggregate but in the Down operational state. These MIBs only return ports currently active in an aggregate. This may not be what the user expects! Anyone managed to get all the ports in an aggregate regardless of oper state? Original comment by: ollyg |
I'd like to see this patch applied but hesitate only because it's not yet supporting IEEE standards. However it's probably better to have something which works for some of the people... Original comment by: ollyg |
Original comment by: ollyg |
Original comment by: ollyg |
olly_g: I can take care of the IEEE part; our HP switches implement the IEEE8023-LAG-MIB and we use LACP between HP's and between HP/Cisco in some parts of our network. We need this functionality ourselves so I can spend a bit of time implementing it in Netdisco. btw, I'm not sure if using a separate table to mark aggregated ports is the best way to go, but it's a start. Original comment by: JeroenvIS |
Since port-channel membership is done in different ways on different devices, I think we should have different functions (e.g., instead of one agg_ports() method that tests all of the possible methods, we can have:
and an individual device class can call the right function for that class. (Or, e.g., Layer3::Cisco can combine the results of agg_ports_pagp and agg_ports_lag). One concrete comment about the use of the I'm also curious why the code looks at dot3adAggPortListPorts as well as dot3adAggPortSelectedAggID. They are supposed to be two different views of the same data. Are there devices that support only one or the other? (However, if we do want to use dot3adAggPortSelectedAggID, we should really be using dot3adAggPortAttachedAggID since it is possible that you have selected an aggregator that you can not attach to, in the case where the aggregator has a limit on the number of ports that it can have attached.) Original comment by: fenner |
On Cisco: On Brocade ICX: On Arista: Original comment by: ollyg |
Original comment by: jeneric-placeholder |
Implemented in this commit. Support for CISCO-PAGP-MIB will be added upon request and someone willing to test. Original comment by: jeneric-placeholder |
add support for CISCO-PAGP-MIB and IEEE8023-LAG-MIB
Reported by: arcanez
Original Ticket: snmp-info/patches/31
The text was updated successfully, but these errors were encountered: