Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:[email protected]] > Sent: Thursday, April 23, 2015 10:57 AM > To: Templin, Fred L; [email protected] > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > Fred, > > Let me restate the question slightly..... > > The following are failure modes for a GRE tunnel that includes ECMP/LAG: > > - one ECMP/LAG member is dropping 100% of IPv6 over GRE traffic, regardless > of packet size. It is doing this because of a firewall filter.
That would be a case of a broken ECMP/LAG configuration. If one path of an equal cost multipath is blocked while the others are open, the blocked path needs to be operationally removed from the ECMP/LAG path selection engine. This is true for both tunneled and non-tunneled traffic. > - one ECMP/LAG member is dropping 100% of IPv6 over GRE traffic when the IPv6 > payload is larger than 1280 bytes. It is doing this due > to an MTU issue. I think you mean "when the GRE payload packet is larger than 1280 bytes minus the GRE overhead"? Thanks - Fred [email protected] > Why is a probing mechanism OK to detect the first and not the second? > > Ron > > > -----Original Message----- > > From: Templin, Fred L [mailto:[email protected]] > > Sent: Thursday, April 23, 2015 12:49 PM > > To: Ronald Bonica; [email protected] > > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > Hi Ron, > > > > > -----Original Message----- > > > From: Ronald Bonica [mailto:[email protected]] > > > Sent: Thursday, April 23, 2015 9:35 AM > > > To: Templin, Fred L; [email protected] > > > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > > > > > Fred, > > > > > > The following are failure modes for a GRE tunnel that includes ECMP/LAG: > > > > > > - one ECMP/LAG member is dropping 100% of traffic, regardless of > > > packet size > > > - one ECMP/LAG member is dropping all packets with MTU > N > > > > > > Why is a probing mechanism OK to detect the first and not the second? > > > > These are two very different conditions. In the first case, if one or more > > paths are dropping all packets, then any communications will black hole and > > not just GRE tunneling. The network operations staff needs to do something > > to ensure that all paths are working. > > > > In the second case, it could black hole even when all paths are working and > > using standards-compliant MTUs on all links. > > > > AFAICT, when there may be ECMP or LAG on the path (which the ingress has > > no way of knowing) about all you can tell from probing is whether the egress > > is alive - probing can't be relied on to tell you anything about the > > path(s). > > > > Again , this does not make me happy but AFAICT it is the reality we need to > > deal with. > > > > Thanks - Fred > > [email protected] > > > > > > > > > Ron > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:[email protected]] > > > > Sent: Thursday, April 23, 2015 11:59 AM > > > > To: Ronald Bonica; [email protected] > > > > Subject: RE: [Int-area] I-D Action: > > > > draft-ietf-intarea-gre-ipv6-07.txt > > > > > > > > Hi Ron, > > > > > > > > > -----Original Message----- > > > > > From: Ronald Bonica [mailto:[email protected]] > > > > > Sent: Thursday, April 23, 2015 8:18 AM > > > > > To: Templin, Fred L; [email protected] > > > > > Subject: RE: [Int-area] I-D Action: > > > > > draft-ietf-intarea-gre-ipv6-07.txt > > > > > > > > > > Fred, > > > > > > > > > > If we can't probe a tunnel, we can't do GRE at all. Ever. Not with > > > > > IPv4, not > > > > with IPv6, not with anything. > > > > > > > > > > MTU issues aside, before activating a tunnel, we must be certain > > > > > that the > > > > tunnel can carry a 1-byte packet from GRE ingress to egress. > > > > > If we don't do that, we risk black-holing traffic. This is why > > > > > nearly all GRE implementations have some type of proprietary > > > > > probing > > > > mechanism. > > > > > > > > I said earlier that I am fine with going ahead and probe with a > > > > small packet (I said 100 bytes, but 1 byte would be fine too) to see if > > > > the > > GRE ingress is alive. > > > > But, that probe does nothing to test for a particular MTU. > > > > > > > > > Beyond suggesting that the probing mechanism use a 1280-byte > > > > > payload, we have put the details of that probing mechanism out of > > > > > scope for this > > > > document. > > > > > > > > If a 1280 byte probe (which becomes 1280+ENCAPS bytes following > > > > encapsulation) succeeds along one path of a multipath, but would > > > > have failed along another path, then there is possibility for black > > > > holing. And, there is no way for the ingress to know that there may > > > > be ECMP or LAG on the path to the egress. Hence, having the ingress > > > > probe for the purpose of minimum MTU detection is problematic if there > > may be some kind of multipath. > > > > > > > > Thanks - Fred > > > > [email protected] > > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > -----Original Message----- > > > > > > From: Templin, Fred L [mailto:[email protected]] > > > > > > Sent: Wednesday, April 22, 2015 6:32 PM > > > > > > To: Ronald Bonica; [email protected] > > > > > > Subject: RE: [Int-area] I-D Action: > > > > > > draft-ietf-intarea-gre-ipv6-07.txt > > > > > > > > > > > > Hi Ron, > > > > > > > > > > > > So, this gives way to the following, which may be the best we > > > > > > can do if we can't probe: > > > > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
