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: [email protected]
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: [email protected]
>> 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 <[email protected]>
>> > 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: [email protected]
>> >> 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 [email protected]
>> >> <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/
>> >>
>> >>
>>
>> _______________________________________________
>> cisco-nsp mailing list [email protected]
>> <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/
>
>
>
>
> Tim Stevenson, [email protected]
> 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.
>
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
