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