[RRG] Re: TRRP-Via - option header vs. encapsulation

["William Herrin" <bill@herrin.us>]

On 9/18/07, Robin Whittle <rw@firstpr.com.au> wrote:
>    http://bill.herrin.us/network/trrp-via02.html
>
> looks very promising.  I haven't looked at the IPv6 section yet.

Robin,

That's okay; there's nothing there to look at yet. :)


> I think "next best preference ITR" should be "next best preference ETR".

Fixed.


>   "If an ETR is unreachable, the via-tagged packet will follow the
>    default route and fall back into an ITR."
>
> Can you explain this more fully?

TRRP works by removing all but a few thousand "globally routable"
prefixes from the BGP table. The ETR's IP addresses are selected from
these globally routable prefixes. So if you change ISPs you keep your
CIDR block but get a new ETR address.

Any destination which is not in the globally routable space follows a
default route which leads to the nearest ITR. There it is encapsulated
(or in Via's case tagged) with an ETR as its destination address.

If the Via tagged packet reaches a router in the network which has no
route in the table corresponding to that ETR then the packet will
follow the default route and end up back at an ITR. That means the ETR
is unreachable so the ITR should try the next one.


> I am not so sure about this one, at least for Ivip:
>
>   No filtering of ICMP destination unreachable messages between
>   wherever the ITR and ETR are located.

It was actually no filtering of echo request/response messages and
destination unreachable messages between the ITR and ETR. This is
because an ITR trying to discover a larger path MTU to the ETR will
assume the ETR is dead if it can't get a sensible response to a ping.

That requirement can be removed but the price is that the Via ITR will
have no way to independently determine that an ETR is unavailable.
It'd have to rely solely on the DNS route server.


> By the way, I found a good explanation of how ICMP filtering can
> screw up PMTUD:

I had the pleasure of dealing with this on a regular basis back in my
ISP days. One of my upstreams was linked to a small stub of their
network. Their primary path was a T3 but their backup path was a GRE
tunnel through another provider. Every time that T3 went down I'd get
customer calls complaining that certain major web sites were
unavailable. The sites' TCP stacks would negotiate a 1500 byte packet
size with the customers but the sites' firewalls would drop all ICMP
packets on the floor so when they hit that 1470ish byte GRE tunnel
that was the end of the line.

I tell you, folks who think ICMP=Ping ought not be allowed to touch a firewall.

The standing order to customer support was: talk the customer through
adjusting the MSS value in their Windows Registry. I'm sure you can
imagine how well that turned out.


> Your proposal doesn't have any means by which an aggrieved router
> could find out which ITR sent the packet to it in error - as with
> the current Ivip proposal.  I considered using UDP encapsulation so
> I could include the ITRs address in the UDP data to solve this problem.

I considered adding that, but I'm not sure how much more useful to the
aggreived router it is to know where the ITR was than it would be to
know anything else about the other routers the packet passed through
to get there.


> Is there any reason to think that routers in general - BGP and
> internal routers - will be upset by an option header, specifically a
> new kind of option header as you suggest?

Another gentleman mentioned to me privately that currently deployed
routers tend to kick any packets with options to the slow (software)
forwarding path since the options might require the router to take
special action. Perhaps its possible to change that behavior with a
software upgrade that offers a configurable to ignore record-route and
timestamp options in favor of keeping IP packets with options in the
fast path.

Regards,
Bill



-- 
William D. Herrin                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg