[c-nsp] Multicast replication over GRE on 7600s
Tim Stevenson
tstevens at cisco.com
Tue Sep 28 16:59:20 EDT 2010
I'm gonna have to admit I'm getting rusty on some of these details,
but IIRC, for standard GRE OIF, it is ingress replicated and
recirculated to do a lookup on the outer IP header; but other
non-tunnel OIFs can still be egress replicated. For MVPN
configurations, the entire box is forced to ingress mode.
Hope that helps,
Tim
At 10:34 AM 9/28/2010, Ben Lovell (belovell) declared:
>Tim,
>
>Just to make sure I am understanding. For a certain group,
>non-tunnel OIFs would still use egress replication and only tunnel
>OIFs would be ingress or the whole group falls back to ingress?
>
>-Ben
>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> . . Benjamin Lovell
> | | AS Video Practice
> ||| ||| Cisco Customer Advocacy
> .|||||. .|||||. Research Triangle Park, NC
> .:|||||||||:..:|||||||||:. Email:
> <mailto:belovell at cisco.com>belovell at cisco.com
> cisco desk:919.392.8255 cell:203.509.1562
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>On Sep 28, 2010, at 1:13 PM, Tim Stevenson wrote:
>
>>With a tunnel you don't know which is the egress card until the
>>encap is done. That's why tunnel OIFs are always ingress replicated.
>>
>>Tim
>>
>>At 09:43 AM 9/28/2010, Ben Lovell (belovell) declared:
>>
>>>You would not have to force the box back to ingress. These packet
>>>would take the ingress forwarding path instead of egress. Other
>>>groups would still function in egress.
>>>
>>>I agree. it's hard to see how this would work in egress as the
>>>idea of replication is all packets are getting the same rewrite(on
>>>ingress) and egress card just needs to make copies. I suppose you
>>>could replicate in the normal fashion to each egress LC plus one
>>>more copy for the GRE tunnel would would then loop through lookup
>>>process again for GRE encap but this is purely conjecture on my part.
>>>
>>>-Ben
>>>
>>>
>>>
>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> . . Benjamin Lovell
>>> | | AS Video Practice
>>> ||| ||| Cisco Customer Advocacy
>>> .|||||. .|||||. Research Triangle Park, NC
>>> .:|||||||||:..:|||||||||:. Email:
>>> <mailto:belovell at cisco.com>belovell at cisco.com
>>> cisco desk:919.392.8255 cell:203.509.1562
>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>On Sep 28, 2010, at 12:34 PM, John Neiberger wrote:
>>>
>>> > Now that I think about it, I bet that egress mode isn't allowed in
>>> > this scenario. It would make sense that only ingress mode would work,
>>> > that way the ingress Janus/Metro would take care of replicating out to
>>> > all the receivers, including the GRE tunnel. I'm having trouble
>>> > visualizing how that would work in egress mode.
>>> >
>>> > It was worth checking into, though. We have a situation where this
>>> > might be useful temporarily. But since we're running egress on our
>>> > 7600s, moving back to ingress is just not an option.
>>> >
>>> > Once again, thanks for your help!
>>> > John
>>> >
>>> > On Tue, Sep 28, 2010 at 10:25 AM, Benjamin Lovell
>>> <<mailto:belovell at cisco.com>belovell at cisco.com> wrote:
>>> >> The same hardware(janus/metro) is responsible for the
>>> replication(no punt to
>>> >> CPU) but due to the GRE ecanp required the packet will have to
>>> go through a
>>> >> longer forwarding process(more lookups) and performance will
>>> be reduced. I
>>> >> don't have any solid numbers but my guess is that forwarding
>>> rate would be
>>> >> approx 1/2.
>>> >> The part I am not sure about is if egress replication is still
>>> possible. In
>>> >> the mVPN scenario only ingress replication is possible due to the GRE
>>> >> encap/decap but I am not sure if this same limitation applies to P2P GRE
>>> >> tunnels. Let me know if this piece would be important to you
>>> and I can look
>>> >> into it.
>>> >> The one caveat to be careful of here(applies to unicast as well) is that
>>> >> each GRE tunnel must be sourced from a unique IP address on
>>> the box. Using
>>> >> the same source IP on more than one GRE tunnel will cause all
>>> traffic in GRE
>>> >> decap path to be punted to CPU and maybe multicast on encap path in some
>>> >> scenarios.
>>> >> -Ben
>>> >>
>>> >>
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> . . Benjamin Lovell
>>> >> | | AS Video Practice
>>> >> ||| ||| Cisco Customer Advocacy
>>> >> .|||||. .|||||. Research Triangle Park, NC
>>> >> .:|||||||||:..:|||||||||:. Email:
>>> <mailto:belovell at cisco.com>belovell at cisco.com
>>> >> cisco desk:919.392.8255 cell:203.509.1562
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> On Sep 28, 2010, at 10:02 AM, John Neiberger wrote:
>>> >>
>>> >> I have an architectural question. As an example, let's say you have
>>> >> two 7600s directly connected via routed links running PIM and you have
>>> >> primarily multicast traffic. If you're running egress replication
>>> >> mode, you either have a Janus ASIC or Metropolis ASIC responsible for
>>> >> the multicast replication, which happens on the line card. But how
>>> >> would things change if you were not running multicast directly on the
>>> >> routed link, but instead used a GRE tunnel between the two routers?
>>> >>
>>> >> I guess I have a couple of questions:
>>> >>
>>> >> 1. How is GRE traffic processed in this scenario? Can it be forwarded
>>> >> at high rates on the line card or is it punted to the CPU?
>>> >>
>>> >> 2. Which hardware is responsible for multicast replication
>>> over GRE tunnels?
>>> >>
>>> >> Any ideas?
>>> >>
>>> >>
>>> >> Thanks!
>>> >> John
>>> >> _______________________________________________
>>> >> cisco-nsp mailing
>>> list <mailto:cisco-nsp at puck.nether.net>cisco-nsp at puck.nether.net
>>> >>
>>> <https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> >> archive at
>>> <<http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
>>> >>
>>> >>
>>>
>>>_______________________________________________
>>>cisco-nsp mailing
>>>list <mailto:cisco-nsp at puck.nether.net>cisco-nsp at puck.nether.net
>>><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>archive at
>>><<http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
>>
>>Tim Stevenson, <mailto:tstevens at cisco.com>tstevens at cisco.com
>>Routing & Switching CCIE #5561
>>Distinguished Technical Marketing Engineer, Cisco Nexus 7000
>>Cisco - <http://www.cisco.com>http://www.cisco.com
>>IP Phone: 408-526-6759
>>********************************************************
>>The contents of this message may be *Cisco Confidential*
>>and are intended for the specified recipients only.
Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Distinguished Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.
More information about the cisco-nsp
mailing list