On 11/30/2014 12:22 AM, Victor Sudakov wrote:
Daniel Roesen wrote:
Check for enabled IGMP snooping on this switch. Try disabling snooping.
We have already tried that, with no effect. Besides, IGMP snooping
should not affect packets with only one unicast source address on only
one switch.
Daniel Roesen wrote:
On Sat, Nov 29, 2014 at 09:41:45PM +0600, Victor Sudakov wrote:
We have set up port monitor sessions in various parts of the network
and have found out the following. One of the C3560X-24P in the chain
of identical switches does not let through packets with
Cool story.
We have set up port monitor sessions in various parts of the network
and have found out the following. One of the C3560X-24P in the chain
of identical switches does not let through packets with
src=10.65.127.246dst=224.0.0.5. Neither when such packets transit the
switch nor when
Lukas Tribus wrote:
Are there any IP filters on the layer 2 side of this? Are you using CoPP
and
the IP is denied there?
No. PASOLINK does not do IP filtering.
It can only do some Ethernet frame filtering, like filtering out LLDP
or STP frames, but no such filters are even
On Sat, Nov 29, 2014 at 09:41:45PM +0600, Victor Sudakov wrote:
We have set up port monitor sessions in various parts of the network
and have found out the following. One of the C3560X-24P in the chain
of identical switches does not let through packets with
src=10.65.127.246dst=224.0.0.5.
Hello Victor
Seems to be some multicast receiving problem 224.0.0.5/6? Are there filters /
IGMP stuff?
What kind of L2 design do you have in the segment? Some years ago we had
problems with multicast and SDH MUX systems.
Regards Gregor
Good point, thank you. After looking at debug
Friedrich, Gregor wrote:
Seems to be some multicast receiving problem 224.0.0.5/6?
Seems like it. The main engima is why only multicast packets with
src=10.65.127.246 are affected and not from other source addresses.
Packets from x.x.x.246 addresses in other networks also work without
Do you have control of the devices at each L2 hop? Can you run packet captures
and see where the hello is dropped?
Date: Thu, 27 Nov 2014 17:08:45 +0600
From: v...@mpeks.tomsk.su
To: friedr...@pdv-sachsen.net
CC: vlaso...@sibptus.tomsk.ru; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp
Lars Fenneberg wrote:
We are at a loss what could be blocking packets with this particular
src addr.
Are there any IP filters on the layer 2 side of this? Are you using CoPP and
the IP is denied there?
No. PASOLINK does not do IP filtering.
It can only do some Ethernet frame filtering,
Are there any IP filters on the layer 2 side of this? Are you using CoPP and
the IP is denied there?
No. PASOLINK does not do IP filtering.
It can only do some Ethernet frame filtering, like filtering out LLDP
or STP frames, but no such filters are even configured.
Just because its not
Murat Kaipov wrote:
Hello Victor.
Very interesting issue. Can you provide show ip ospf 12 database
issue like this can occur when you have 10.65.127.246 address on
other device.
Here you are from two routers (sw-vertikos and Raskino):
sw-vertikos#sh ip ospf 12 neighbor
Neighbor ID Pri
Antonio Querubin wrote:
There are a dozen routers connected to a common 10.65.127.224/27 L2
backbone. All are running OSPF area 0. Any router which has the IP
address 10.65.127.246 cannot establish OSPF adjacency with some other
routers, showing them forever in the INIT/DROTHER or
Joshua Riesenweber wrote:
Out of curiosity, is this the highest IP address on the router?
On some routers there is no loopback interface, so yes, on some
routers 10.65.127.246 may become the router ID.
Is it possible that this is being chosen as the OSPF router ID and causing
problems?
Hello Victor.
Very interesting issue. Can you provide show ip ospf 12 database issue like
this can occur when you have 10.65.127.246 address on other device.
Отправлено с iPad
26 нояб. 2014 г., в 9:42, Victor Sudakov v...@mpeks.tomsk.su написал(а):
Colleagues,
We have found a very
...@outlook.com; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Cursed IP address
Joshua Riesenweber wrote:
Out of curiosity, is this the highest IP address on the router?
On some routers there is no loopback interface, so yes, on some
routers 10.65.127.246 may become the router ID
Joshua Riesenweber wrote:
Nothing is wrong with that IP address specifically, but I was wondering if it
is being chosen as the ID whether there is a conflict with another router ID,
perhaps manually set.
A conflict of router IDs causes a well known message which I am not
observing.
--
If you sh arp do you see the right MAC address for the ip. Could that address
be in use on some dumb device?
Sent from my iPhone
On Nov 26, 2014, at 2:43, Victor Sudakov v...@mpeks.tomsk.su wrote:
Colleagues,
We have found a very interesting problem.
There are a dozen routers
Antonio Querubin wrote:
Are you absolutely positively sure 10.65.127.246 still does not exist
somewhere else on one of the devices on that network, for example as a
stale router ID?
I know that a duplicate router ID should cause a message like
%OSPF-4-DUP_RTRID, and I have not seen
Harold 'Buz' Dale wrote:
If you sh arp do you see the right MAC address for the ip.
Certainly. I can even ping it from any other device and telnet into it.
Could that address be in use on some dumb device?
No, it could not.
We have even recreated the problem in a separate VRF, created as
As no one asked yet, is it possible to get ospf related debug from the
not working router and the DR router of the subnet?
Am 26.11.2014 14:44, schrieb Victor Sudakov:
Harold 'Buz' Dale wrote:
If you sh arp do you see the right MAC address for the ip.
Certainly. I can even ping it from any
Davis, Philip wrote:
When you made your testbed did you have the same problem if the
subnet mask was different?
The problem persists regardless of the subnet mask:
sw-parabel#sh ip ospf 20 neighbor
Neighbor ID Pri State Dead Time Address Interface
10.65.127.241
Karsten Thomann wrote:
As no one asked yet, is it possible to get ospf related debug from the
not working router and the DR router of the subnet?
Good point, thank you. After looking at debug OSPF hello, we have
found out that Hello packets with src=10.65.127.246 are being sent by
the device
22 matches
Mail list logo
