[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