[c-nsp] 6500 + Policy Routing

[Mattias Eliasson]

Hi all

I assume that a GRE multipoint is not affected by this.
IE. a GRE multipoint is ONE tunnel even though it has several end 
points?
There for it needs only one IP/tunnel and not one IP/end point?

Best Regards
Mattias Eliasson
Teknikmejeriet AB

> Subject: Re: [c-nsp] 6500 + Policy Routing
>> GRE tunnels are hardware switched".  One important caveat is
>> that every GRE tunnel MUST terminate on a DIFFERENT local IP
>> address - otherwise: software switching.
>
> Emphasis on different local IP's is critical here. Getting the
> double-pass-plus-gre-rewrite to work on PFC means packets need to be
> caught by the control plane in such a way that permits the action of 
> gre
> encaps to happen. This is because the control plane hardware (which is
> what ultimately directs/generates the rewrite information) cannot know
> more about the packet than what is in the IP header of the gre packet.
> To fully support hardware GRE processing AND terminate multiple gre
> tunnels on the same IP, you'd (in theory) need to have line cards that
> could create 'special' compact/truncated headers which contained more
> than the usual five-tuple-plusplus; they'd need to include fields from
> the GRE portion of the IP packet such as the tunnel "key" so as to
> permit logical separation of traffic between tunnels.
>
> If you were to configure multiple 'tunnels' that 'landed' on the same
> destination IP on a PFC-based system today, to the best of my 
> knowledge,
> all the gre packets would need to be punted to the MSFC for processing
> because the PFC could not determine de-encaps/rewrite actions based on
> data in truncated or compact headers.
>
> Favored ways to express this config on cat6/7600 would be multiple
> loopback interfaces, such as:
>
> Int lo10
> Desc tunnel endpoint #1
> Ip addr 10.0.0.1 255.255.255.255
>
> Int lo11
> Desc tunnel endpoint #2
> Ip addr 10.0.0.2 255.255.255.255
>
> Or something like this:
>
> Int lo0
> Desc tunnels term here, weeeee
> Ip addr 10.0.0.1 255.255.255.255
> Ip addr 10.0.0.2 255.255.255.255
> Ip addr 10.0.0.3 255.255.255.255
>
> I prefer the mass-secondary approach as it, again, saves IDB's, and you
> don't get counters for packets which 'arrived' at the tunnel endpoint
> IP's parenty interface. Each gre tun int does have working counters, so
> nothing is gained by having multiple loopbacks. There is minimal 
> utility
> in having multiple dozes of loopbacks to 'hold up' gre endpoints.
>
> -Tk
>
>
>
> ------------------------------
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
>
> End of cisco-nsp Digest, Vol 50, Issue 38
> *****************************************