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 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?
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
