Re: [nox-dev] Handling corrupted TCP header
KK,
I think the implementer will read the spec the other way around.
Spec requires nothing special about OFPP_TABLE action (it does not say
"don't generate pkt_in, if there is no match"). So the switch
just follows the default behavior, i.e., pkt_in will be generated.
I would expect the reference design also does the same.
Masa
On 01/13/2011 06:38 PM, kk yap wrote:
Because the action of pkt_out is "OFPP_TABLE".
(the packet in pkt_out does not match to the entry that is installed by
flow_mod, since the matching entry says nw_proto=0).
Is there anything in the spec that says that the switch should send
another packet-in if there is no matching entry for a OFPP_TABLE? I
am failing to find that. Can someone point to why this behavior is
specified by the spec?
Regards
KK
On 13 January 2011 18:28, Masayoshi Kobayashi wrote:
KK,
I thought about it a little. Why is the switch doing step 7?
Because the action of pkt_out is "OFPP_TABLE".
(the packet in pkt_out does not match to the entry that is installed by
flow_mod, since the matching entry says nw_proto=0).
Masa
On 01/13/2011 06:06 PM, kk yap wrote:
Hi Srini,
I thought about it a little. Why is the switch doing step 7?
Anyway, I do agree that NOX is not handling malformed packets right.
I have included an invalid field in the struct flow, and created a
component that ignore invalid packets. If anyone will double-check
and test the patches attached, I will push it.
Regards
KK
On 13 January 2011 16:13, Srini Seetharamanwrote:
I explained this to KK in person. For others, here is the sequence of
events:
1. Packet arrives with (nw_proto=6, tp_src=0, tp_dst=0). Store in bufid
'X'
2. flow.cc identifies that the arrived TCP packet is corrupted, and
generates
pkt_in event with flow structure having (nw_proto=0, tp_src=0,
tp_dst=0)
3. Authenticator generates a flow_in with flow_in.flow being same as
above
3. routing.cc generates a flow_mod for the flow_in with the match pattern
defined using the fields of the flow_in.flow
4. Switch inserts a flow table entry for matching (nw_proto=0,
tp_src=0, tp_dst=0)
5. routing.cc generates a pkt_out for the bufid 'X' with action =
OFPP_TABLE
6. Switch notices that the packet in bufid 'X' has no matching flow table
entry,
because there is a mismatch on the nw_proto field
7. Switch generates a new pkt_in event
8. Go to step (2)
This is the infinite loop.
Srini.
On Thu, Jan 13, 2011 at 1:08 PM, kk yapwrote:
Hi Srini,
I think you are fixing this in the wrong place. Putting nw_proto=0
does not cause an infinite loop. Where is the loop happening? Can
you provide more detailed NOX output so that we can even start looking
at this.
Regards
KK
On 13 January 2011 11:02, Srini Seetharaman
wrote:
We don't know who sent it, but it came from outside our network. If it
is easy to take down a network by just sending 1 invalid packet, I'd
be worried!
On Thu, Jan 13, 2011 at 10:59 AM, kk yapwrote:
Hi Srini,
What is this packet? The length of TCP is zero?!?! I wish to
understand the circumstance for which we are getting the packet before
commenting on the right way to handle this.
Regards
KK
On 13 January 2011 10:38, Srini Seetharaman
wrote:
When someone sends the attached packet to a switch, it generates an
infinite loop of packet_ins in our production network. This is
because
this incoming tcp packet has nw_proto=6 and tcp port numbers of "0",
but outgoing flow_mod has nw_proto of "0" and tcp port numbers of
"0".
So, the packet_out generates a new packet_in and this loop continues
forever.
I see the following code in src/lib/flow.cc (both in NOX-Zaku and
SNAC). I believe this is what is causing the nw_proto to be "0" in
the
flow_mod. I'm not sure who wrote that piece of code. This is not
handling corrupted packets well and rejecting this packet as a
invalid
TCP packet. Does anyone see problems with removing the "else" clause?
if (nw_proto == ip_::proto::TCP) {
const tcp_header *tcp = pull_tcp(b);
if (tcp) {
tp_src = tcp->tcp_src;
tp_dst = tcp->tcp_dst;
} else {
/* Avoid tricking other code into thinking that
* this packet has an L4 header. */
nw_proto = 0;
}
}
FYI, pull_tcp is defined as below:
static const tcp_header * pull_tcp(Buffer&b)
{
if (const tcp_header *tcp = b.try_at(0)) {
int tcp_len = TCP_OFFSET(tcp->tcp_ctl) * 4;
if (tcp_len>= sizeof *tcp) {
return reinterpret_cast(b.try_pull(tcp_len));
}
}
return 0;
}
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
___
nox-
Re: [nox-dev] Handling corrupted TCP header
KK,
I read that you'll discard this packet, but I don't think we should do
so. The correct behavior would be to install flow table with nw_proto=6,
tp_src=0 and tp_dst=0, and does pkt_out (i.e. forward it). I agree this
packet looks strange (tcp_header length=0), but L2/L3 switch/router will
forward this (otherwise we won't see this packet).
Masa
On 01/13/2011 06:28 PM, Masayoshi Kobayashi wrote:
KK,
> I thought about it a little. Why is the switch doing step 7?
Because the action of pkt_out is "OFPP_TABLE".
(the packet in pkt_out does not match to the entry that is installed by
flow_mod, since the matching entry says nw_proto=0).
Masa
On 01/13/2011 06:06 PM, kk yap wrote:
Hi Srini,
I thought about it a little. Why is the switch doing step 7?
Anyway, I do agree that NOX is not handling malformed packets right.
I have included an invalid field in the struct flow, and created a
component that ignore invalid packets. If anyone will double-check
and test the patches attached, I will push it.
Regards
KK
On 13 January 2011 16:13, Srini Seetharaman wrote:
I explained this to KK in person. For others, here is the sequence of
events:
1. Packet arrives with (nw_proto=6, tp_src=0, tp_dst=0). Store in
bufid 'X'
2. flow.cc identifies that the arrived TCP packet is corrupted, and
generates
pkt_in event with flow structure having (nw_proto=0, tp_src=0, tp_dst=0)
3. Authenticator generates a flow_in with flow_in.flow being same as
above
3. routing.cc generates a flow_mod for the flow_in with the match
pattern
defined using the fields of the flow_in.flow
4. Switch inserts a flow table entry for matching (nw_proto=0,
tp_src=0, tp_dst=0)
5. routing.cc generates a pkt_out for the bufid 'X' with action =
OFPP_TABLE
6. Switch notices that the packet in bufid 'X' has no matching flow
table entry,
because there is a mismatch on the nw_proto field
7. Switch generates a new pkt_in event
8. Go to step (2)
This is the infinite loop.
Srini.
On Thu, Jan 13, 2011 at 1:08 PM, kk yap wrote:
Hi Srini,
I think you are fixing this in the wrong place. Putting nw_proto=0
does not cause an infinite loop. Where is the loop happening? Can
you provide more detailed NOX output so that we can even start looking
at this.
Regards
KK
On 13 January 2011 11:02, Srini Seetharaman
wrote:
We don't know who sent it, but it came from outside our network. If it
is easy to take down a network by just sending 1 invalid packet, I'd
be worried!
On Thu, Jan 13, 2011 at 10:59 AM, kk yap wrote:
Hi Srini,
What is this packet? The length of TCP is zero?!?! I wish to
understand the circumstance for which we are getting the packet
before
commenting on the right way to handle this.
Regards
KK
On 13 January 2011 10:38, Srini Seetharaman
wrote:
When someone sends the attached packet to a switch, it generates an
infinite loop of packet_ins in our production network. This is
because
this incoming tcp packet has nw_proto=6 and tcp port numbers of "0",
but outgoing flow_mod has nw_proto of "0" and tcp port numbers of
"0".
So, the packet_out generates a new packet_in and this loop continues
forever.
I see the following code in src/lib/flow.cc (both in NOX-Zaku and
SNAC). I believe this is what is causing the nw_proto to be "0"
in the
flow_mod. I'm not sure who wrote that piece of code. This is not
handling corrupted packets well and rejecting this packet as a
invalid
TCP packet. Does anyone see problems with removing the "else"
clause?
if (nw_proto == ip_::proto::TCP) {
const tcp_header *tcp = pull_tcp(b);
if (tcp) {
tp_src = tcp->tcp_src;
tp_dst = tcp->tcp_dst;
} else {
/* Avoid tricking other code into thinking that
* this packet has an L4 header. */
nw_proto = 0;
}
}
FYI, pull_tcp is defined as below:
static const tcp_header * pull_tcp(Buffer& b)
{
if (const tcp_header *tcp = b.try_at(0)) {
int tcp_len = TCP_OFFSET(tcp->tcp_ctl) * 4;
if (tcp_len>= sizeof *tcp) {
return reinterpret_cast(b.try_pull(tcp_len));
}
}
return 0;
}
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
_______
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
--
Masayoshi Kobayashi
Visiting Scholar at Stanford University
System Platform Research Labs, NEC Corporation.
T/M: 650-714-3154
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] Handling corrupted TCP header
KK,
> I thought about it a little. Why is the switch doing step 7?
Because the action of pkt_out is "OFPP_TABLE".
(the packet in pkt_out does not match to the entry that is installed by
flow_mod, since the matching entry says nw_proto=0).
Masa
On 01/13/2011 06:06 PM, kk yap wrote:
Hi Srini,
I thought about it a little. Why is the switch doing step 7?
Anyway, I do agree that NOX is not handling malformed packets right.
I have included an invalid field in the struct flow, and created a
component that ignore invalid packets. If anyone will double-check
and test the patches attached, I will push it.
Regards
KK
On 13 January 2011 16:13, Srini Seetharaman wrote:
I explained this to KK in person. For others, here is the sequence of events:
1. Packet arrives with (nw_proto=6, tp_src=0, tp_dst=0). Store in bufid 'X'
2. flow.cc identifies that the arrived TCP packet is corrupted, and generates
pkt_in event with flow structure having (nw_proto=0, tp_src=0, tp_dst=0)
3. Authenticator generates a flow_in with flow_in.flow being same as above
3. routing.cc generates a flow_mod for the flow_in with the match pattern
defined using the fields of the flow_in.flow
4. Switch inserts a flow table entry for matching (nw_proto=0,
tp_src=0, tp_dst=0)
5. routing.cc generates a pkt_out for the bufid 'X' with action = OFPP_TABLE
6. Switch notices that the packet in bufid 'X' has no matching flow table entry,
because there is a mismatch on the nw_proto field
7. Switch generates a new pkt_in event
8. Go to step (2)
This is the infinite loop.
Srini.
On Thu, Jan 13, 2011 at 1:08 PM, kk yap wrote:
Hi Srini,
I think you are fixing this in the wrong place. Putting nw_proto=0
does not cause an infinite loop. Where is the loop happening? Can
you provide more detailed NOX output so that we can even start looking
at this.
Regards
KK
On 13 January 2011 11:02, Srini Seetharaman wrote:
We don't know who sent it, but it came from outside our network. If it
is easy to take down a network by just sending 1 invalid packet, I'd
be worried!
On Thu, Jan 13, 2011 at 10:59 AM, kk yap wrote:
Hi Srini,
What is this packet? The length of TCP is zero?!?! I wish to
understand the circumstance for which we are getting the packet before
commenting on the right way to handle this.
Regards
KK
On 13 January 2011 10:38, Srini Seetharaman wrote:
When someone sends the attached packet to a switch, it generates an
infinite loop of packet_ins in our production network. This is because
this incoming tcp packet has nw_proto=6 and tcp port numbers of "0",
but outgoing flow_mod has nw_proto of "0" and tcp port numbers of "0".
So, the packet_out generates a new packet_in and this loop continues
forever.
I see the following code in src/lib/flow.cc (both in NOX-Zaku and
SNAC). I believe this is what is causing the nw_proto to be "0" in the
flow_mod. I'm not sure who wrote that piece of code. This is not
handling corrupted packets well and rejecting this packet as a invalid
TCP packet. Does anyone see problems with removing the "else" clause?
if (nw_proto == ip_::proto::TCP) {
const tcp_header *tcp = pull_tcp(b);
if (tcp) {
tp_src = tcp->tcp_src;
tp_dst = tcp->tcp_dst;
} else {
/* Avoid tricking other code into thinking that
* this packet has an L4 header. */
nw_proto = 0;
}
}
FYI, pull_tcp is defined as below:
static const tcp_header * pull_tcp(Buffer& b)
{
if (const tcp_header *tcp = b.try_at(0)) {
int tcp_len = TCP_OFFSET(tcp->tcp_ctl) * 4;
if (tcp_len>= sizeof *tcp) {
return reinterpret_cast(b.try_pull(tcp_len));
}
}
return 0;
}
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
_______
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
--
Masayoshi Kobayashi
Visiting Scholar at Stanford University
System Platform Research Labs, NEC Corporation.
T/M: 650-714-3154
___
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
Re: [nox-dev] NOX not deleting flows correctly
Glen, About a month ago, I and Natasha discussed this mobility handling scheme. What you observed actully agrees with the expected behavior (Natasha: correct me if I'm wrong). Current scheme is not designed for zero packet loss. In the current scheme, NOX removes only the flow entry of the old attach point of a mobile terminal (of1 in this case). In your observation, this is done by Pkt33. So, packets are still forwarded upto (downto?) the old attach point and they will be sent to NOX controller (because there is no flow entry), which triggers the installation of the new path (Pkt50-55). Your observation agrees with this expected behavior. Basically, in the current scheme, only the packets flying between the crossover switch (ofroot in this case) to the old attachment point (of1 in this case) may be lost. But I think it is okay for gaming application. If we really want to reduce packet losses, I think flushing all the flow entries will not help -- we will lose more flying packets. In addition to installing the new path, installing a path from the old attachment point to the crossover switch (i.e., from of1 to ofroot in this case) may be a good idea. We actually don't even need to find the crossover switch. Installing the path from old ttachmet point to the new attachment point will do this automatically, because this path merges to the new path at the crossover switch. -Masa Glen Gibb wrote, (2008/07/24 0:19): > Hi all, > > I've got an instance where NOX is not correctly deleting flows. This > occurs when a host changes which switch it is connected to. > > Again, the setup is as follows: > > Three OF switches: > mvm-ofroot (171.67.74.78) is at the top of a tree > mvm-of1 (171.67.74.66) is the left branch of a tree > mvm-of2 (171.67.74.50) is the right branch of a tree > > Two clients: > mvm-17 (171.67.74.17) is connected to mvm-ofroot > mvm-27 (171.67.74.27) moves between mvm-of1 and mvm-of2 in the packet trace > > Apps: > pyrouting > pyauthenticator > > The problem that I am seeing is that when mvm-27 connects via mvm-of1 to > mvm-17 a path is established (correctly) by NOX via of1 and ofroot. When > mvm-27 moves to of2, NOX deletes the path in of2 but fails to delete the > path in ofroot, causing the reply packet to traverse the wrong path when > leaving ofroot. > > I'll now walk you through my packet trace: > Pkts 1-14: ARP and echo-request from mvm-27 to mvm-17 with appropriate > flow-mods when connected to of1 > Pkt 15: Echo reply from mvm-17 to mvm-27 via ofroot > Pkt 16,17: Flow mods from NOX to ofroot and of1 to establish path for > echo reply. > Pkt 18: Pkt out of echo reply. > > Skip to pkt 32: In this interval mvm-27 has physically moved from of1 to > of2. > Pkt 32: ARP request from mvm-27 to mvm-17 coming in from of2 > Pkt 33: Flow mod from NOX to of1 to delete flows to mvm-27. > Pkt 39: ARP reply from mvm-17 to mvm-27 received from OF1. This get to > of1 as ofroot still has a path for ARP replies that sends the packet to > of1. (Created in pkt 7.) > Pkt 40,41: NOX sends flow-mods to ofroot and of2 for ARP replies. > Note: ARP reply is "lost" as it never gets to mvm-27 > > Pkt 50-55: Second ARP attempt that actually succeeds this time as the > path is correctly set up. > > Pkt 56-59: Echo request, appropriate flow mods to establish path mvm-27 > to mvm-17 and packet out. > > Pkt 60: Echo reply from mvm-17 to mvm-27. Received via of1. Again, this > is because the return path in ofroot for echo replies is listed as of1. > (Created in pkt 17.) > Pkt 61, 62: Flow mods to set up correct return path from mvm-17 to > mvm-27 for echo replies. > > > I haven't dived into the code to see how the flow mod delete is > generated. I'm guessing that when you detect a host host moved locations > you send a delete to the old location for any flows destined to that > host. Perhaps the easiest thing to do is to flood a delete throughout > the network to ensure that all old paths are flushed. > > Let me know what you guys think, > Glen > > > ---- > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org -- Masayoshi KOBAYASHI Computer Forum Visiting Scholar, Stanford University System Platforms Research Laboratories, NEC Corporation [EMAIL PROTECTED] [EMAIL PROTECTED] (secondary) T: 650-724-6550 M: 650-714-3154 F: 650-725-6409 ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
