[c-nsp] Monitoring ethernet circuits with GRE

[Anton Kapela]

> > > Am I running into silly issues because the 3550 isn't
> > > capable of GRE?
> > 
> > Well, GRE tunnelling isn't supported on the Catalyst 3550...

[SNIP]

> Are you certain about that?  I have 3550's and 3750's in L3 
> mode running Tunnel interfaces.

Clearly with Cisco, 'supported' and 'works' are poles apart, just like
how 8 or 16 SVI's are the stated maximum on said platforms, yet many
folks are functionally terming' hundreds of SVI's on the boxes. I've
used GRE on 3550's for things similar to what the thread initiator had
asked about, and indeed it works. I should note that the first time I
tried this was well after much of the platforms major issues had been
worked out. This was using something like 12.2(25)SEB or SEC (whatever
rev had the "don't punt routed tcp/179 packets to the cpu" fix). 

However, in lab tests, I was unable to achieve greater than ~2mbits/s
via the GRE tunnel which should not be surprising since it's entirely
cpu switched on the 3550. One has to ask if this type of 'support'
counts as useful. In the case where I was using it, it was entirely
worthless and purely academic. I'd never, ever put 'real' customer
traffic over gre on this platform. 

In a non-transit role like that which is being discussed, perhaps it's
not so awfull, and maybe we should count it as usefull. It gets even
better when paired with the "track" feature (i.e. int gi 0/1 tracks
tun0). Regardless, I'd recommend that for end to end link-state one
should look into solutions like UDLD or PaGP instead of deriving it with
GRE + keepalives.

-Tk