Hi Ron, > -----Original Message----- > From: Ronald Bonica [mailto:[email protected]] > Sent: Thursday, April 23, 2015 11:21 AM > To: Templin, Fred L; [email protected] > Subject: RE: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-07.txt > > Fred, > > Let's try again..... > > > 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. > - one ECMP/LAG member is dropping 100% of IPv6 over GRE traffic when the IPv6 > payload is 1280 bytes or larger. It is doing this due to
Again, I think you mean "when the IPv6 payload is larger than 1280 bytes minus the GRE encapsulation overhead". > an MTU issue. If the MTU were one byte larger, we would be OK. > > Why is a probing mechanism OK to detect the first and not the second? The first condition is a network operational misconfiguration, while the second condition is not necessarily a misconfiguration. You can't use fragmentation to mask the first condition, but you can to overcome the second condition. Thanks - Fred [email protected] > > Ron > > > > -----Original Message----- > > From: Templin, Fred L [mailto:[email protected]] > > Sent: Thursday, April 23, 2015 2:10 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 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
