clustering opendaylight-boron - openflow

I am new to Opendaylight (Boron) clustering using Mininet. I followed the instructions provided through "http://docs.opendaylight.org/en/stable-boron/getting-started-guide/common-features/clustering.html" and I configured three nodes cluster. All three nodes show the full topology of connected switches in the dlux GUI. However, when I try to ping all hosts using the "pingall" command. I am losing most of the packets. and the controller is only showing the part of the hosts in the topology.
h1 -> X X h4 h5 X h7 h8 h9 h10 h11 h12 h13 X h15 h16
h2 -> h1 h3 h4 h5 X h7 h8 h9 h10 h11 h12 h13 X h15 h16
h3 -> h1 h2 h4 h5 X h7 h8 h9 h10 h11 h12 h13 X h15 h16
h4 -> h1 h2 h3 h5 X h7 h8 h9 h10 h11 h12 h13 X h15 h16
h5 -> h1 h2 h3 h4 X h7 h8 h9 h10 h11 h12 h13 X h15 h16
h6 -> X X X X X X X X X X X X h14 X X
h7 -> h1 h2 h3 h4 h5 X h8 h9 h10 h11 h12 h13 X h15 h16
h8 -> h1 h2 h3 h4 h5 X h7 h9 h10 h11 h12 h13 X h15 h16
h9 -> h1 h2 h3 h4 h5 X h7 h8 h10 h11 h12 h13 X h15 h16
h10 -> h1 h2 h3 h4 h5 X h7 h8 h9 h11 h12 h13 X h15 h16
h11 -> h1 h2 h3 h4 h5 X h7 h8 h9 h10 h12 h13 X h15 h16
h12 -> h1 h2 h3 h4 h5 X h7 h8 h9 h10 h11 h13 X h15 h16
h13 -> h1 h2 h3 h4 h5 X h7 h8 h9 h10 h11 h12 X h15 h16
h14 -> X X X X X h6 X X X X X X X X X
h15 -> h1 h2 h3 h4 h5 X h7 h8 h9 h10 h11 h12 h13 X h16
h16 -> h1 h2 h3 h4 h5 X h7 h8 h9 h10 h11 h12 h13 X h15
*** Results: 24% dropped (182/240 received)
the topology works fine when testing under a single controller, I tested different topology sizes, and got the same results. I noticed that My akka.conf file is missing the class "dl-cluster-rpc" when compared to the example in the provided link.
I used the addSwitch and addHost functions to create the switches and hosts before starting the topology
sw = self.addSwitch('c{}'.format(i + 1),cls=OVSKernelSwitch, protocols='OpenFlow13')
host = self.addHost('h{}'.format(count))
the following is how I tried to add multiple controllers in my mininet:
topo = FatTreeTopo()
net = Mininet(topo=topo, controller=None, link=TCLink)
cnt1 = net.addController( 'cnt1',controller=RemoteController,ip='159.203.64.13')
cnt2 = net.addController( 'cnt2',controller=RemoteController,ip='159.203.10.11')
cnt3 = net.addController( 'cnt3',controller=RemoteController,ip='159.203.18.68')
info('*** Starting network\n')
cnt1.start()
cnt2.start()
cnt3.start()
switches = net.switches
for sname in switches:
sname.start([cnt1,cnt2,cnt3]
net.start()
I checked all switches being connected to the three controllers using the OVS-VSCTL command:
Bridge "e16"
Controller "tcp:159.203.103.171:6653"
is_connected: true
Controller "tcp:159.203.118.68:6653"
is_connected: true
Controller "tcp:159.203.64.133:6653"
is_connected: true
Moreover, the following shows the openflow table for a switch and I see rules for forwarding packet to all three controllers.
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x2b00000000000013, duration=511.822s, table=0, n_packets=206, n_bytes=17510, priority=100,dl_type=0x88cc actions=CONTROLLER:65535
cookie=0x2b0000000000001a, duration=506.785s, table=0, n_packets=3106, n_bytes=462409, priority=2,in_port=2 actions=output:4,output:3
cookie=0x2b0000000000001b, duration=506.785s, table=0, n_packets=69, n_bytes=4354, priority=2,in_port=4 actions=output:2,output:3,CONTROLLER:65535
cookie=0x2b0000000000001c, duration=506.757s, table=0, n_packets=81, n_bytes=4970, priority=2,in_port=3 actions=output:2,output:4,CONTROLLER:65535
cookie=0x2b00000000000013, duration=511.822s, table=0, n_packets=129, n_bytes=22447, priority=0 actions=drop
thanks a lot and best wishes

there might be multiple cause for the issue
1) Check the karaf logs
2) Check the entity ownership details
3) Check the datastore shard status
4) Is there any connection flap between controllers, controller and switches
5) check for the flows or entries in operational and config DS.
This should give you fair idea on what is the issue.

Related

How does Fin "know" not to go past its type bound?

How does Fin actually work?
data Nat = Z | S Nat
data Fin : (n : Nat) -> Type where
FZ : Fin (S k)
FS : Fin k -> Fin (S k)
Where does k come from?
Why isn't FZ always the value of (n: Nat) + 1?
How does Fin "know" not to exceed its type bound?
This mailing list talks about implicits, but I'm lost as to how and where these values come from.
Given this basic example:
t1 : Fin 3
t1 = FZ
What is t1's value? t1's type is Fin 3, but FZ experimentally (appears) to represent zero. Which is why we can "count" with it just like we do with Nat:
t2 : Fin 3
t3 = FS (FS FZ) -- this is equal to 2?
But this confuses me given the constructor!
FZ : Fin (S k)
If we're saying that t1 has type Fin 3, does that mean that k takes on the value of the n in the type? If that were the case, and FZ calls S on that Nat, then why isn't FZ representing 4?
This is obviously not the case.
So I'm completely and absolutely lost on how FZ acts like 0, and where k comes from, and how the compiler knows when k has become >= n just based on this data type.
I think what's confusing you is that you're thinking k is the value of the Fin n. It's not. It's just book-keeping to make sure the Fin n is always less than n.
Where does k come from?
In
FZ : Fin (S k)
k is an (erased) implicit argument. It's shorthand for
FZ : {0 k : _} -> Fin (S k)
so it's passed implicitly, but it's still an argument to FZ. In most cases, it can be unambiguously inferred from the context. The compiler will tell you if it can't.
Why isn't FZ always the value of (n: Nat) + 1?
FZ always represents zero*. This
t1 : Fin 3
t1 = FZ
is the same as
t1 : Fin 3
t1 = FZ {k = 2}
It's a zero that's less than three. These are also all zero
a : Fin 1
a = FZ
b : Fin 4
b = FZ
c : Fin 100
c = FZ
How does Fin "know" not to exceed its type bound?
Since FZ is always zero, and FS FZ is always one, and so on, it's impossible to express a Fin n with value greater than or equal to n. Let's try to create a Fin 2 of value two.
x : Fin 2
x = FS (FS FZ) -- this won't compile
To see why this won't compile, fill in the implicits (note that FS also has an implicit argument called k):
x : Fin 2
x = FS {k = 1} (FS {k = 0} (FZ {k = ?!?}))
We're creating a Fin 2 so the outer-most FS must have S k = 2 so k = 1. Each successive FS we go down we reduce k by one (see the argument to FS is Fin k to produce a Fin (S k) - so one less). Eventually we reach FZ but by this point there's isn't a Nat to represent this value of k. The compiler balks with such a statement
If Data.Fin.FZ: When unifying:
Fin (S ?k)
and:
Fin 0
Mismatch between: S ?k and 0.
(Interactive):1:17--1:19
1 | :let x = FS (FS FZ)
^^
You can do the same for a Fin 2 of value three etc. Have a try.
Other qus
Given
t1 : Fin 3
t1 = FZ
What is t1's value? It's FZ, and FZ represents zero.
t2 : Fin 3
t2 = FS (FS FZ) -- this is equal to 2?
Yes, it's two.
If we're saying that t1 has type Fin 3, does that mean that k takes on the value of the n in the type? If that were the case, and FZ calls S on that Nat, then why isn't FZ representing 4? S k takes on the value of n.
*this is actually a matter convention, but I'll avoid confusing things by going into that

Is there a way to apply the rule to a specific assumption in Isabelle?

Here is my goal
...
∀a b. P1 a b ⟹
∀a b. P2 a b ⟹
...
⟹ some goal
I want to apply the lemma to the second assumption
lemma K: ⟦ ∀a b. P a b⟧ ⟹ ∀b. P a b"
by using
apply (drule_tac a = "x" in K)
but Isabelle always firstly applies the tactic to the first assumption, how can I only apply the tactic to the second assumption?
Actually, my goal is
...
∀b. Γ b ≠ Γ' b ⟶
b ∉ set (llocked C1) ∧ (Γ b, Γ' b) ∈ RGUnion R G2 b ∧ disjoint (dom h1) (dom (Γ' b)) ⟶
rgsep_safe n C1 s h1 Γ' (RGUnion R G2) G1 Q1 ⟹
∀b. Γ b ≠ Γ' b ⟶
b ∉ set (llocked C2) ∧ (Γ b, Γ' b) ∈ RGUnion R G1 b ∧ disjoint (dom h2) (dom (Γ' b)) ⟶
rgsep_safe n C2 s h2 Γ' (RGUnion R G1) G2 Q2 ⟹
rgsep_safe n C2 s h2 Γ' (RGUnion R G1) G2 Q2
and I want to use the lemma on the second assumtion
theorem K1: ∀b. ?P b ⟶ ?Q ⟹ ∀b. ?P b ⟹ ?Q
to make the goal become
...
∀b. Γ b ≠ Γ' b ⟶
b ∉ set (llocked C1) ∧ (Γ b, Γ' b) ∈ RGUnion R G2 b ∧ disjoint (dom h1) (dom (Γ' b)) ⟶
rgsep_safe n C1 s h1 Γ' (RGUnion R G2) G1 Q1 ⟹
∀b. Γ b ≠ Γ' b ⟶
b ∉ set (llocked C2) ∧ (Γ b, Γ' b) ∈ RGUnion R G1 b ∧ disjoint (dom h2) (dom (Γ' b))
There are a lot of ugly hacks that can allow you to bypass the first assumption (e.g. by deleting it or reordering them). Already drule_tac is heading in that direction. Better by far is to use a structured proof, if it's practical for your problem. Then it's easy to name your assumptions and join them to "K" using the OF attribute.
Your theorem K1 is useless: it doesn't do what you think it does because of how the scope of quantifiers works. I tried an experiment with a simpler version of your goal and made quite a bit of progress by typing
apply (simp flip: imp_conjL)
This admittedly obscure step converts your implications into conjunctions; the simplifier notices that the quantified variable doesn't appear on the right-hand side, so all you need to do now is exhibit a b satisfying the three conditions
Γ b ≠ Γ' b
b ∉ set (llocked C2)
(Γ b, Γ' b) ∈ RGUnion R G1 b ∧ disjoint (dom h2) (dom (Γ' b))
You will get a much nicer looking proof if you prove these facts first. If they are available then you may find that the automation proves the goal you wanted automatically.

How to define observational equality in Agda

Let's say I have a render function:
rasterize : ℕ → ℕ → Tile → List (List Color
I need to prove this statement:
if rasterize w h t1 = rasterize w h t2 then t1 ≡ t2
in other words if t1 and t2 render to the same value given the same width and height, then they are equal.
I dont know how to say this in agda, I came up with the following:
obs-eq : ∀ (t₁ t₂ : Tile) (w h : ℕ) →
rasterize w h t₁ ≡ rasterize w h t₂ → t₁ ≡ t₂
but I suspect this is not what I mean and from googling around I think I need to define an operator that compares the rendered values? Also some kind of sigma type is involved?
Your parenthesization is wrong: when you write
obs-eq :
∀ (t₁ t₂ : Tile) (w h : ℕ) →
rasterize w h t₁ ≡ rasterize w h t₂ →
t₁ ≡ t₂
it means that if I give you any two tiles and any two dimensions, such that the tiles rasterize to the same picture at those dimensions, then you can prove that they are equal.
Consider what happens if I choose w = 0 and h = 0 for you...
But what you want to say is that if I give you any two tiles, and a proof that for any two dimensions they rasterize to the same picture, then you can prove that the tiles are equal:
obs-eq :
∀ (t₁ t₂ : Tile) →
(∀ w h → rasterize w h t₁ ≡ rasterize w h t₂) →
t₁ ≡ t₂

Invariant Generation Constraint-based approach

I have been read the paper "Constraint-Based Linear-Relations Analysis" from "Sriram Sankaranarayanan, Henny B. Sipma, and Zohar Mann" to check fixpoint equations arising from abstract interpretation by applying Farkas Lemma in a Given template inequality with unknown coefficients, which computes constraints on the values of the coefficients, such that substituting any solution back into the template yields a valid invariant relationship.
I have Followed example 1 (on that paper)
Let V = {x, y} and L = { 0 }. Consider the transition system shown below. Each transition models a concurrent process, that updates the variables x, y automatically.
Θ = (x = 0 ∧ y = 0)
T = {τ1 , τ2 }
τ1 = <l0 , l0 , [x' = x + 2y ∧ y' = 1 − y]>
τ2 = <l0, l0 , [x' = x + 1 ∧ y' = y + 2]>
I have encoded Initiation, by using Farkas Lemma (example 2 on that paper) as well consecution (through transitions τ1 and τ2).
The authors say:
We fix a linear transition system Π with variables {x1 , . . . , xn }, collectively referred to as x. The system is assumed to have a single location to simplify the presentation. The template assertion at location , is α(c) = c1 x1 + · · · + cn xn + d ≥ 0. The coefficient variables {c1 , . . . , cn , d} are collectively referred to as c. The system's transitions are {τ1 , . . . , τm }, where τi : , , ρi. The initial condition is denoted by Θ. The system in Example 1 will be used as a running example to illustrate the presented ideas.
I have reached the overall constraint obtained by the conjunction of the constraints obtained from initiation and consecution for each transition (example 4 on that paper).
At that point I guess it is possible to solve the constraint by encoding all of that in a solve like Z3.
In fact I did that by encoding linear arithmetic directly into Z3:
(define-sort MyType () Int)
(declare-const myzero MyType)
(declare-const mi1 MyType)
(declare-const mi2 MyType)
(declare-const c1 MyType)
(declare-const c2 MyType)
(declare-const d MyType)
(assert (= myzero 0))
;initiation
(assert (>= d 0) )
;transition 1
(assert (and
(= (- (* mi1 c1) c1) 0)
(= (- (+ (* mi1 c2) c2) (* 2 c1) ) 0)
(<= (- (- (* mi1 d) d) c2) 0)
(>= mi1 0)
))
;transition 2
(assert (and
(= (- (* mi2 c1) c1) 0)
(= (- (* mi2 c2) c2) 0)
(<= (- (- (- (* mi2 d) d) c1) (* 2 c2) ) 0)
(>= mi2 0)
))
(check-sat)
(get-model)
I guess I am not doing well once I have not figured out any inductive invariant at location l0 through c1, c2, ..., cn, d as an individual (o range) values.
Z3 has answered me zero for all coefficients:
sat
(model
(define-fun mi2 () Int 0)
(define-fun c2 () Int 0)
(define-fun mi1 () Int 0)
(define-fun c1 () Int 0)
(define-fun d () Int 4)
(define-fun myzero () Int 0)
)
I have tried to found examples related with, but until now no luck to get it.
If I understand what you are doing correctly in your Z3 encoding, you are indeed
getting correct but trivial invariants like 0 <= 4.
To get interesting invariants, I suggest adding constraints like c1 <> 0 to see if the solver gives you something interesting back.
Our work was done long before Z3 existed: we used the solver REDLOG as part of REDUCE, which is still available. Welcome to email me with your queries.
Best,
Sriram

Sempahores and Deadlocks

This is an exercise that was suggested for my upcoming exam, the bottom is what I have gathered thus-far. All constructive input will be appreciated.
P1, P2 and P3 share three semaphores (x, y and z) each with 1 as initial value and three variables (a, b and c).
P1:
(1.1) wait(x);
(1.2) a = a + 1;
(1.3) wait(y);
(1.4) b = b - a;
(1.5) wait(z);
(1.6) c = a + 2*b -c;
(1.7) signal(z);
(1.8) signal(y);
(1.9) signal(x)
Code for P2:
(2.1) wait(y);
(2.2) b = b*2;
(2.3) wait(z);
(2.4) c = c - b;
(2.5) signal(y);
(2.6) wait(x);
(2.7) a = a + c;
(2.8) signal(x);
(2.9) signal(z)
Code for P3:
(3.1) wait(y);
(3.2) b = b*2;
(3.3) wait(z);
(3.4) c = c - b;
(3.5) signal(z);
(3.6) signal(y);
(3.7) wait(x);
(3.8) a = a / 10;
(3.9) signal(x)
A. If P1 and P2 run concurrently on a computer with only a single CPU, is it possible for these two processes to get into a deadlock? If so, show one execution sequence of the code that results in the deadlock, and show how to revise P2 only (P1 is not changed) to prevent deadlock.
B. If P1 and P3 are run concurrently on a computer with only a single CPU, is it possible for these two processes to get into a deadlock? If so, show one execution sequence of the code that results in the deadlock, and show how to revise P3 only (P1 is not changed) to prevent deadlock.
The changes you make should not violate the mutual exclusion requirement on shared variable access.
A) I'm not sure what it means by an example of when they would get into a deadlock? To me, it appears that y will cause a deadlock because line 1.3 will cause y to become -1 an would not be unlocked until 2.5 of P2.
To resolve this, 1.3 should be moved below 1.5 because that is when y is released in P2. It looks like there will be other conflicts though with x, but I don't know what a good way to rearrange P1 would be to resolve this without changing P2.
B) Here it appears 1.3 (wait(y)) causes a problem again since it is not signaled until 3.6. The resolution would then be to move it to after 1.6?
I'm trying to use Wiki's pages on Deadlock and Semaphore Programming to do this exercise.
Well, in the first case as an example;
Sequence Holds lock on
(1.1) wait(x); P1 x, P2 -
(1.2) a = a + 1; P1 x, P2 -
(2.1) wait(y); P1 x, P2 y
(2.2) b = b*2; P1 x, P2 y
(2.3) wait(z); P1 x, P2 yz
(2.4) c = c - b; P1 x, P2 yz
(2.5) signal(y); P1 x, P2 z
(2.6) wait(x); P1 x, P2 z - P2 locks waiting for x
(1.3) wait(y); P1 xy, P2 z
(1.4) b = b - a; P1 xy, P2 z
(1.5) wait(z); P1 xy, P2 z - P1 locks waiting for z
It could - for example - be fixed by locking P2 in the order same order as P1 (x, y, z instead of y, z, x). It may mean that you'll have to lock x before you really need to for mutual exclusion, but it will prevent deadlock.
As far as I can see, P1 and P3 can't mutually deadlock, since P3 is locked in the sequence y, z (which follows the x, y, z sequence, just skips the lock on x), then releases the locks and only locks/unlocks x.