Subject: [Rift] Possible chain reaction of LIE messages with multiple neighbors on LAN?

From: Bruno Rijsman <[email-masked]>
Date: Sat, 11 Aug 2018 16:11:48 +0000

Hi Tony and list,

I noticed some “interesting" behavior while testing multiple RIFT neighbors on a LAN:

When you have multiple neihghbors on a LAN, you can end up in a situation where the nodes send an exploding storm of LIE messages. The LIE messages are sent in a tight loop (they are triggered by state transitions, not by time expiries) and the number of messages increases exponentially very quickly. Wireshark sees hundreds of packets per second, which continues until you shut the entire topology down.

- For a wireshark traffic graph see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-traffic-graph

- For a wireshark trace see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-trace

- For a visualization of the events see http://bit.ly/rift-multiple-neighbor-chain-reaction-visualization

- For the topology details see http://bit.ly/rift-multiple-neighbor-chain-reaction-topology

I *think* this behavior is not implementation-specific but rather a direct consequence of what is written in the specification.

(It could be that I missed something in the speciciation, in which case I would be happy to stand corrected and fix my implementation.)

Here is the topology:

# Topology: multi_neighbor
#
#  +-----------+    +-----------+    +-----------+
#  | node1     |    | node2     |    | node3     |
#  | (level 0) |    | (level 1) |    | (level 2) |
#  +-----------+    +-----------+    +-----------+
#        | if1            | if1            | if1
#        |                |                |
#  =============================================== LAN
#
#  Adjacency will not reach 3-way because RIFT only allows point-to-point LANs
#  Furthermore, this topology uses the default RIFT multicast addresses and ports

Here is what I think happens:

At boot time, each node sends out a LIE message before it has received any LIE messages from any of the other nodes (because of the SendLie state entry action for state OneWay).

(1) Each node receives two LIE messages, one from each of the other nodes

(2) When the first LIE message is received, it triggers a NewNeighbor event, which causes a transition to state TwoWay and which also pushes a SendLie event (see item #7 on page 81 of draft-rift-02). This immediately (no delay) multicasts a LIE message which is received by both other nodes.

(3) When the second LIE message is received, it triggers a MultipleNeighbors event, which causes the node to transition back from state TwoWay to state OneWay. Because of the state entry action for state OneWay, this causes another immediate (no delay) SendLie which sends out a LIE message which is received by both other nodes.

Thus, when one node (say node 1) sends a LIE, it causes the other nodes (node 2 and 3 in this case) to *immediately* send out *two* LIE messages each. This is a run-away chain reaction in a tight loop: 1 LIE message immediately leads to 2 LIE messages, which immediately leads to 4 LIE messages, etc. etc.

As you scroll down in the visualization, you can see the forest of blue lines (which represent messsages) thickening into a spagheti mess. Note the time-stamps in the 2nd column on the left side: it all happens in a very short amount of time.

It was evidently a conscious decision in the spec to send LIE packets not only periodically but also one certain state transitions (e.g. as a state entry action for the ONE_WAY state). While this does indeed speed up (re)convergence you have to be very careful that there are no scenarios where you end up in an uncontrolled storm of LIE messages as this example demonstrates.

— Bruno

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 11 Aug 2018 16:25:03 +0000

Hey Bruno, ok, so it gets interesting ;-)

Yupp, if you have 2 guys feeding a node we’ll get amplification like this if the timing generates a two-way/one-way ping-pong. Different ways to prevent this:

a)       We sacrifice some of the convergence speed. We could give up the “SENDLIE” on entering one way but that may lead up to a second delay on admin interface down (assuming implementaions have a ‘fast-path’ on interface failure otherwise which is really not part of the spec) …

b)       We hold down and only send a lie on entering one way if a holddown timer is not up. That will complicate the FSM to an extent

Albeit it’s really just miscabling I agree we need to do something here …

So, what you think?

--- tony

Thus spake <[email-masked]<mailto:[email-masked]>>:

Hi Tony and list,

- For a wireshark traffic graph see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-traffic-graph<https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_rift-2Dmultiple-2Dneighbor-2Dchain-2Dreaction-2Dwireshark-2Dtraffic-2Dgraph&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=kNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-z779bvaw&s=mr2s4b9B5pneJ_1zynbnrg1GNto8tXleLWqSbR2YK7M&e=>

- For a wireshark trace see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-trace<https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_rift-2Dmultiple-2Dneighbor-2Dchain-2Dreaction-2Dwireshark-2Dtrace&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=kNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-z779bvaw&s=nGgu7O9IPJdCdSTWpmFAlnAFB8sP7KfuniZzddTumfA&e=>

- For a visualization of the events see http://bit.ly/rift-multiple-neighbor-chain-reaction-visualization<https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_rift-2Dmultiple-2Dneighbor-2Dchain-2Dreaction-2Dvisualization&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=kNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-z779bvaw&s=bBdBb5WQlpNZmPMpFfg9df8lNl1pYDFpUub6P7H8a90&e=>

- For the topology details see http://bit.ly/rift-multiple-neighbor-chain-reaction-topology<https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_rift-2Dmultiple-2Dneighbor-2Dchain-2Dreaction-2Dtopology&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=kNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-z779bvaw&s=PHn8p1ZVWXk4FSt_9snTwVMEQmPayy5-uwdCZo-2q8A&e=>

Here is the topology:

— Bruno

---

From: Bruno Rijsman <[email-masked]>
Date: Sat, 11 Aug 2018 16:54:44 +0000

My initial thoughts (no conclusion yet, and some thoughts conflict with other thoughts):

1) Fast (re)convergence is a very desirable property we should not give up on too easily. That said, the triggered sending of LIEs has always made me more than a little bit nervous because of the potential of run-away storms.

2) In this scenario, we end up in an exponentially growing burst of traffic because we have two nodes feeding into a third node. But even if we have only two nodes feeding into each other (without a third node), I still have an uncomfortable feeling in my gut because it is still possible to imagine a scenario that leads to a sustained burst of traffic (albeit not exponentially growing) if those two nodes get stuck in a OneWay-TwoWay ping pong scenario for any unforeseen reason. I have not actually found any such scenario, but I can imagine one could potentially exist (due to a spec issue or due to buggy code).

3) Introducing a hold-down (= throttling) for the sending of only those LIE message that are a result of entering the OneWay state would solve the exponential growth problem. But I *think* you would still get a sustained burst of traffic. I *think* each of the three nodes would still flip-flop between OneWay and TwoWay, and each flip-flop would cause one message instead of two. Thus, I would still suspect a sustained burst of traffic, just not an exponentially growing one. (I can try, it is easy enough to quickly code up the hold-down and see what happens.)

4) I agree with your comment about (3) complicating the FSM. The code would not be that much more difficult, but it would be much more difficult to reason about the correctness and it would be that much more difficult to test reliably. You would have a piece of code that only gets executed in very extreme corner cases.

5) Some other thoughts about possible solutions:

5a) Introducing a new MultiNeighbor state. Go there when multiple neighbors are detected and stay there for some hold-down time. This has the benefit of making it operationally much easier to detect multi-neighbor scenarios in show commands. (Now, an operator is expected to notice the flip-flop between OneWay and TwoWay and/or notice the MultipleNeighbors event in the log, and conclude that it is a multi-neighbor scenario).

5b) Just bite the bullet and support multiple neighbors as discussed in the Google doc.

5c) While both 5a and 5b solve the specific problem at hand, they don’t address the more general nervousness about potential run-away situations due to triggered sending of LIE messages. Having some sort of hold-down would be more robust in that aspect.

— Bruno

On Aug 11, 2018, at 9:25 AM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

So, what you think?

--- tony

Hi Tony and list,

- For a wireshark traffic graph see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-traffic-graph<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__bit.ly_rift-2Dmultiple-2Dneighbor-2Dchain-2Dreaction-2Dwireshark-2Dtraffic-2Dgraph%26d%3DDwMGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DmaKXfKzgRTpiLitqHnJiww%26m%3DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-z779bvaw%26s%3Dmr2s4b9B5pneJ_1zynbnrg1GNto8tXleLWqSbR2YK7M%26e%3D&data=02%7C01%7C%7Cc7aaccec2b464080c3d708d5ffa70050%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636696015083183093&sdata=RhYsIgxRVhH0s1oVdUsNDQglY1NDKO9vw1Nmc2Uporg%3D&reserved=0>

- For a wireshark trace see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-trace<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__bit.ly_rift-2Dmultiple-2Dneighbor-2Dchain-2Dreaction-2Dwireshark-2Dtrace%26d%3DDwMGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DmaKXfKzgRTpiLitqHnJiww%26m%3DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-z779bvaw%26s%3DnGgu7O9IPJdCdSTWpmFAlnAFB8sP7KfuniZzddTumfA%26e%3D&data=02%7C01%7C%7Cc7aaccec2b464080c3d708d5ffa70050%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636696015083183093&sdata=crnP83%2F3He0hIDus7g1nhAi9fgGyqMYKbTaSmWCNtNM%3D&reserved=0>

- For a visualization of the events see http://bit.ly/rift-multiple-neighbor-chain-reaction-visualization<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__bit.ly_rift-2Dmultiple-2Dneighbor-2Dchain-2Dreaction-2Dvisualization%26d%3DDwMGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DmaKXfKzgRTpiLitqHnJiww%26m%3DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-z779bvaw%26s%3DbBdBb5WQlpNZmPMpFfg9df8lNl1pYDFpUub6P7H8a90%26e%3D&data=02%7C01%7C%7Cc7aaccec2b464080c3d708d5ffa70050%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636696015083183093&sdata=HCiZdzsxKe3vIr4nuk4s8AHIDjOHpPpjlv1Dj%2BuOgM8%3D&reserved=0>

- For the topology details see http://bit.ly/rift-multiple-neighbor-chain-reaction-topology<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__bit.ly_rift-2Dmultiple-2Dneighbor-2Dchain-2Dreaction-2Dtopology%26d%3DDwMGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DmaKXfKzgRTpiLitqHnJiww%26m%3DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-z779bvaw%26s%3DPHn8p1ZVWXk4FSt_9snTwVMEQmPayy5-uwdCZo-2q8A%26e%3D&data=02%7C01%7C%7Cc7aaccec2b464080c3d708d5ffa70050%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636696015083183093&sdata=z9cCCJeuOvmtgeYBqM6HzcbhTIchrULPa%2B0FkOLAELw%3D&reserved=0>

Here is the topology:

— Bruno

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 11 Aug 2018 17:09:12 +0000

1)       Yepp ;-)

2)       I don’t think so unless we start to talk byzantine attacks but then we can also assume we’ll deal with implementations that basically send LIEs as fast they manage as attack ;-) routing is not dealing with byzantine security problems well ;-)

3)       My concern is more with the added complexity

4)       Yepp

5)       A) yeah, that’s how I’d solve it probably rather than a “magic” timer. Like you say, testing that would be a pain and the state would be “just in this error condition” … B) There is no demand for it so we’ll be building a feature no’one cares about

OK, keep on ruminating and we settle on something. Right now I am inclined to give up induced LIE on one-way which will slow the down (first up can be ‘hacked’ by basically feeding FSM a ‘sendlie’ on start outside the spec ;-)

--- tony

— Bruno

So, what you think?

--- tony

Hi Tony and list,

- For a wireshark traffic graph see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-traffic-graph<https://urldefense.proofpoint.com/v2/url?u=https-3A__eur03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fbit.ly-5Frift-2D2Dmultiple-2D2Dneighbor-2D2Dchain-2D2Dreaction-2D2Dwireshark-2D2Dtraffic-2D2Dgraph-2526d-253DDwMGaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DmaKXfKzgRTpiLitqHnJiww-2526m-253DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-2Dz779bvaw-2526s-253Dmr2s4b9B5pneJ-5F1zynbnrg1GNto8tXleLWqSbR2YK7M-2526e-253D-26data-3D02-257C01-257C-257Cc7aaccec2b464080c3d708d5ffa70050-257C84df9e7fe9f640afb435aaaaaaaaaaaa-257C1-257C0-257C636696015083183093-26sdata-3DRhYsIgxRVhH0s1oVdUsNDQglY1NDKO9vw1Nmc2Uporg-253D-26reserved-3D0&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=y8mHXaa7AB3crDnjAWlRdXjgZjiA69Z5bc-4-jY7EUs&s=B_kkZhihiMUocl_aVJSSDDpKrW7bRPaH5PfM9LN6e0g&e=>

- For a wireshark trace see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-trace<https://urldefense.proofpoint.com/v2/url?u=https-3A__eur03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fbit.ly-5Frift-2D2Dmultiple-2D2Dneighbor-2D2Dchain-2D2Dreaction-2D2Dwireshark-2D2Dtrace-2526d-253DDwMGaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DmaKXfKzgRTpiLitqHnJiww-2526m-253DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-2Dz779bvaw-2526s-253DnGgu7O9IPJdCdSTWpmFAlnAFB8sP7KfuniZzddTumfA-2526e-253D-26data-3D02-257C01-257C-257Cc7aaccec2b464080c3d708d5ffa70050-257C84df9e7fe9f640afb435aaaaaaaaaaaa-257C1-257C0-257C636696015083183093-26sdata-3DcrnP83-252F3He0hIDus7g1nhAi9fgGyqMYKbTaSmWCNtNM-253D-26reserved-3D0&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=y8mHXaa7AB3crDnjAWlRdXjgZjiA69Z5bc-4-jY7EUs&s=48PFhJCdhnRoyn8nQn1f3bm3kR-CwRPyttnCM5GHx1g&e=>

- For a visualization of the events see http://bit.ly/rift-multiple-neighbor-chain-reaction-visualization<https://urldefense.proofpoint.com/v2/url?u=https-3A__eur03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fbit.ly-5Frift-2D2Dmultiple-2D2Dneighbor-2D2Dchain-2D2Dreaction-2D2Dvisualization-2526d-253DDwMGaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DmaKXfKzgRTpiLitqHnJiww-2526m-253DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-2Dz779bvaw-2526s-253DbBdBb5WQlpNZmPMpFfg9df8lNl1pYDFpUub6P7H8a90-2526e-253D-26data-3D02-257C01-257C-257Cc7aaccec2b464080c3d708d5ffa70050-257C84df9e7fe9f640afb435aaaaaaaaaaaa-257C1-257C0-257C636696015083183093-26sdata-3DHCiZdzsxKe3vIr4nuk4s8AHIDjOHpPpjlv1Dj-252BuOgM8-253D-26reserved-3D0&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=y8mHXaa7AB3crDnjAWlRdXjgZjiA69Z5bc-4-jY7EUs&s=iubdHKIlEgUiikHJjc9ENk_ky-qyQawlLqLnaNyZRIY&e=>

- For the topology details see http://bit.ly/rift-multiple-neighbor-chain-reaction-topology<https://urldefense.proofpoint.com/v2/url?u=https-3A__eur03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fbit.ly-5Frift-2D2Dmultiple-2D2Dneighbor-2D2Dchain-2D2Dreaction-2D2Dtopology-2526d-253DDwMGaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DmaKXfKzgRTpiLitqHnJiww-2526m-253DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-2Dz779bvaw-2526s-253DPHn8p1ZVWXk4FSt-5F9snTwVMEQmPayy5-2DuwdCZo-2D2q8A-2526e-253D-26data-3D02-257C01-257C-257Cc7aaccec2b464080c3d708d5ffa70050-257C84df9e7fe9f640afb435aaaaaaaaaaaa-257C1-257C0-257C636696015083183093-26sdata-3Dz9cCCJeuOvmtgeYBqM6HzcbhTIchrULPa-252B0FkOLAELw-253D-26reserved-3D0&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=y8mHXaa7AB3crDnjAWlRdXjgZjiA69Z5bc-4-jY7EUs&s=w0CRzfpXTTRrR_3uBMNDJvjYOzOXcpwDw3VufzPsfLE&e=>

Here is the topology:

— Bruno

---

From: Bruno Rijsman <[email-masked]>
Date: Sat, 11 Aug 2018 17:16:53 +0000

I just tried removing the SendLie state-entry action for state OneWay, re-run my test case, and see what happens.

As suspected (see 3 below) you still get an uncontrolled and sustained burst of traffic. It is just fixed size (messages per second) instead of exponentially growing now.

See http://bit.ly/rift-multiple-neighbor-chain-reaction-without-oneway-send-lie-entry-action-visualization for the event graph

— Bruno

On Aug 11, 2018, at 10:09 AM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

1)       Yepp ;-)

--- tony

— Bruno

So, what you think?

--- tony

Hi Tony and list,

- For a wireshark traffic graph see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-traffic-graph<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__eur03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fbit.ly-5Frift-2D2Dmultiple-2D2Dneighbor-2D2Dchain-2D2Dreaction-2D2Dwireshark-2D2Dtraffic-2D2Dgraph-2526d-253DDwMGaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DmaKXfKzgRTpiLitqHnJiww-2526m-253DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-2Dz779bvaw-2526s-253Dmr2s4b9B5pneJ-5F1zynbnrg1GNto8tXleLWqSbR2YK7M-2526e-253D-26data-3D02-257C01-257C-257Cc7aaccec2b464080c3d708d5ffa70050-257C84df9e7fe9f640afb435aaaaaaaaaaaa-257C1-257C0-257C636696015083183093-26sdata-3DRhYsIgxRVhH0s1oVdUsNDQglY1NDKO9vw1Nmc2Uporg-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DmaKXfKzgRTpiLitqHnJiww%26m%3Dy8mHXaa7AB3crDnjAWlRdXjgZjiA69Z5bc-4-jY7EUs%26s%3DB_kkZhihiMUocl_aVJSSDDpKrW7bRPaH5PfM9LN6e0g%26e%3D&data=02%7C01%7C%7C3c304ccc404b4da7b85a08d5ffad2b72%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636696041573253095&sdata=kGdhCWaktA3xUz9iluRcxhFmRZfafhRix1KNQeONJCQ%3D&reserved=0>

- For a wireshark trace see http://bit.ly/rift-multiple-neighbor-chain-reaction-wireshark-trace<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__eur03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fbit.ly-5Frift-2D2Dmultiple-2D2Dneighbor-2D2Dchain-2D2Dreaction-2D2Dwireshark-2D2Dtrace-2526d-253DDwMGaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DmaKXfKzgRTpiLitqHnJiww-2526m-253DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-2Dz779bvaw-2526s-253DnGgu7O9IPJdCdSTWpmFAlnAFB8sP7KfuniZzddTumfA-2526e-253D-26data-3D02-257C01-257C-257Cc7aaccec2b464080c3d708d5ffa70050-257C84df9e7fe9f640afb435aaaaaaaaaaaa-257C1-257C0-257C636696015083183093-26sdata-3DcrnP83-252F3He0hIDus7g1nhAi9fgGyqMYKbTaSmWCNtNM-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DmaKXfKzgRTpiLitqHnJiww%26m%3Dy8mHXaa7AB3crDnjAWlRdXjgZjiA69Z5bc-4-jY7EUs%26s%3D48PFhJCdhnRoyn8nQn1f3bm3kR-CwRPyttnCM5GHx1g%26e%3D&data=02%7C01%7C%7C3c304ccc404b4da7b85a08d5ffad2b72%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636696041573253095&sdata=6HIZ7bMZuKki1NuURGzj25tcp3z5036S0kTNq2rSk70%3D&reserved=0>

- For a visualization of the events see http://bit.ly/rift-multiple-neighbor-chain-reaction-visualization<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__eur03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fbit.ly-5Frift-2D2Dmultiple-2D2Dneighbor-2D2Dchain-2D2Dreaction-2D2Dvisualization-2526d-253DDwMGaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DmaKXfKzgRTpiLitqHnJiww-2526m-253DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-2Dz779bvaw-2526s-253DbBdBb5WQlpNZmPMpFfg9df8lNl1pYDFpUub6P7H8a90-2526e-253D-26data-3D02-257C01-257C-257Cc7aaccec2b464080c3d708d5ffa70050-257C84df9e7fe9f640afb435aaaaaaaaaaaa-257C1-257C0-257C636696015083183093-26sdata-3DHCiZdzsxKe3vIr4nuk4s8AHIDjOHpPpjlv1Dj-252BuOgM8-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DmaKXfKzgRTpiLitqHnJiww%26m%3Dy8mHXaa7AB3crDnjAWlRdXjgZjiA69Z5bc-4-jY7EUs%26s%3DiubdHKIlEgUiikHJjc9ENk_ky-qyQawlLqLnaNyZRIY%26e%3D&data=02%7C01%7C%7C3c304ccc404b4da7b85a08d5ffad2b72%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636696041573253095&sdata=Du65BP67e6SlW3u4Z2I9RXqF3kqqamUNYNQ%2FFfb7CoU%3D&reserved=0>

- For the topology details see http://bit.ly/rift-multiple-neighbor-chain-reaction-topology<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__eur03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fbit.ly-5Frift-2D2Dmultiple-2D2Dneighbor-2D2Dchain-2D2Dreaction-2D2Dtopology-2526d-253DDwMGaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DmaKXfKzgRTpiLitqHnJiww-2526m-253DkNxhEawZQ87EuPWSuX4ACqD3JZZyPQebsZ-2Dz779bvaw-2526s-253DPHn8p1ZVWXk4FSt-5F9snTwVMEQmPayy5-2DuwdCZo-2D2q8A-2526e-253D-26data-3D02-257C01-257C-257Cc7aaccec2b464080c3d708d5ffa70050-257C84df9e7fe9f640afb435aaaaaaaaaaaa-257C1-257C0-257C636696015083183093-26sdata-3Dz9cCCJeuOvmtgeYBqM6HzcbhTIchrULPa-252B0FkOLAELw-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DmaKXfKzgRTpiLitqHnJiww%26m%3Dy8mHXaa7AB3crDnjAWlRdXjgZjiA69Z5bc-4-jY7EUs%26s%3Dw0CRzfpXTTRrR_3uBMNDJvjYOzOXcpwDw3VufzPsfLE%26e%3D&data=02%7C01%7C%7C3c304ccc404b4da7b85a08d5ffad2b72%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636696041573253095&sdata=BYMzn0%2FyDXNR%2B2rRRTn4XEFn0ZBhddFYkfnfgssAqa0%3D&reserved=0>

Here is the topology:

— Bruno

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 11 Aug 2018 20:47:41 +0000

Yepp, stable oscillation @ a rate. The more you squelch the rate of information exchange/rate the more effective an attack will be as well …

Not that different from other configuration mismatches.

I’ll remove the SendLie on Enter One Way in -03 ...

--- tony

See http://bit.ly/rift-multiple-neighbor-chain-reaction-without-oneway-send-lie-entry-action-visualization<https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_rift-2Dmultiple-2Dneighbor-2Dchain-2Dreaction-2Dwithout-2Doneway-2Dsend-2Dlie-2Dentry-2Daction-2Dvisualization&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=vt2KGawUld7zPEgOss5WxodZ9CPO3zs3wc2HYHygHZM&s=t42bbvcEmsEoI9v6qp-wmWVAkUtdpK63qPZAEtq4iAs&e=> for the event graph

— Bruno

1)       Yepp ;-)

--- tony

— Bruno

So, what you think?

--- tony

Hi Tony and list,

Here is the topology:

— Bruno