[j-nsp] What is this ethernet switching trace telling us?

Harold 'Buz' Dale buz.dale at usg.edu
Fri Jun 7 19:05:02 EDT 2013


Are you running spanning tree ? 

Sent from my iPhone

On Jun 7, 2013, at 18:37, "Gavin Henry" <ghenry at suretec.co.uk> wrote:

> Is this a server connected via two ports?
> 
> Sent from my iPad 2
> 
> On 7 Jun 2013, at 23:12, John Neiberger <jneiberger at gmail.com> wrote:
> 
>> Also, another interesting thing about this is that the output of "show
>> ethernet mac-learning-log" stops at April 13th. I have no idea why. If a
>> MAC address were jumping around, we'd see it in the MAC learning log...if
>> it were up to date. What would cause a Juniper switch to stop logging to
>> the MAC learning log?
>> 
>> By the way, this is an EX4200 running 10.4R6.5.
>> 
>> 
>> On Fri, Jun 7, 2013 at 4:07 PM, John Neiberger <jneiberger at gmail.com> wrote:
>> 
>>> We're trying to troubleshoot an odd issue and this log output makes it
>>> appear that a MAC address is flipping between interfaces. There are other
>>> interfaces involved later in the logs. I'm starting to think this isn't
>>> telling us what we think it's telling us. Does this indicate that the MAC
>>> address really is being learned from multiple interfaces? The confusing
>>> thing about the logs is the mention of l3nh. Is that layer three next hop?
>>> If so, why are we seeing that in ethernet-level trace options and what is
>>> the significance?
>>> 
>>> I'm a little confused. Here is an example:
>>> 
>>> Jun  4 13:07:22.953201 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82,
>>> ifname ge-0/0/6.0, pnac_status 0, 0
>>> Jun  4 13:07:22.953312 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif =
>>> ge-0/0/6.0: present in FDB
>>> Jun  4 13:07:22.953374 (3, 00:08:25:fa:3c:82) next-hop index change [1344
>>> -> 1328]
>>> Jun  4 13:07:22.953562 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328
>>> Jun  4 13:07:22.953712 krt_dequeue: type FDB op change 3,
>>> 00:08:25:fa:3c:82 Direct nh 1328
>>> Jun  4 13:07:22.954372 l3nh_fdb_notify: FDB CHANGE vlan <sbc-core> mac
>>> 00:08:25:fa:3c:82
>>> Jun  4 13:21:18.041160 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82,
>>> ifname ge-0/0/5.0, pnac_status 0, 0
>>> Jun  4 13:21:18.041271 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif =
>>> ge-0/0/5.0: present in FDB
>>> Jun  4 13:21:18.041332 (3, 00:08:25:fa:3c:82) next-hop index change [1328
>>> -> 1327]
>>> Jun  4 13:21:18.041670 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82,
>>> ifname ge-0/0/6.0, pnac_status 0, 0
>>> Jun  4 13:21:18.041767 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif =
>>> ge-0/0/6.0: present in FDB
>>> Jun  4 13:21:18.041807 (3, 00:08:25:fa:3c:82) next-hop index change [1327
>>> -> 1328]
>>> Jun  4 13:21:18.041962 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328
>>> 
>>> It looks to me like the MAC address is jumping around. What do you think?
>>> 
>>> Thanks,
>>> John
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list