Ip precedence of GRE packets [7:19125]
Is it possible to cause the IP precedence of a GRE packet to be the same as the IP precedence of the packet which it encapsulates? I have a client who is passing real-time as well as normal data over a 3DES encrypted tunnel. I have had to resort to using separate tunnels for the two data streams, but I consider this to be a sub-optimal solution. For reference, I am using a 2621 at one end and a 3640 at the other with 12.1.5 images. This is a real world problem for me. Would this kind of thing possibly come up on the CCIE R/S exams? Chris Read Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=19125t=19125 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ip precedence of GRE packets [7:19125]
Is it possible to cause the IP precedence of a GRE packet to be the same as the IP precedence of the packet which it encapsulates? A very interesting problem. Without researching it, I'd be inclined to say no on a Cisco router, unless you terminate the tunnel at each router hop, and then set precedence with a route map as you re-encapsulate it. In formal terms, you have to define the desired per-hop behavior (PHB) at each hop rather than end-to-end. There might be a really kludgy way to do it with BGP QoS Policy Propagation, if the destination addresses were different. You MIGHT be able to do it on a Bay/Nortel RS router, because it does allow the equivalent of access lists on pure byte strings. I _think_ the string match is long enough to reach the second IP header. Even if I could, I don't think I would. I have a client who is passing real-time as well as normal data over a 3DES encrypted tunnel. I have had to resort to using separate tunnels for the two data streams, but I consider this to be a sub-optimal solution. But here's where I start to question. Why do you consider two tunnels to be suboptimal? I'd say the general consensus among MPLS traffic engineering people is to associate a priority with a tunnel, merge different flows of the same priority onto what is now called a traffic trunk, then put the multipriority traffic back together at the egress. It's MUCH easier to do traffic engineering when the tunnel/trunk has a single priority. Remember that traffic engineering implies the reservation of bandwidth. For reference, I am using a 2621 at one end and a 3640 at the other with 12.1.5 images. This is a real world problem for me. Would this kind of thing possibly come up on the CCIE R/S exams? Chris Read Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=19131t=19125 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ip precedence of GRE packets [7:19125]
Chris, I've tested that 4-5 months ago, on 2621 with 12.1T. TOS field is propagated from encapsulated packets into TOS of GRE packets. The same happens with IPSec tunnels; TOS from encrypted packets is copied into IPSec headers. Regards, Sasa Chris Read wrote: Is it possible to cause the IP precedence of a GRE packet to be the same as the IP precedence of the packet which it encapsulates? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=19132t=19125 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Ip precedence of GRE packets [7:19125]
I think it is possible to have the GRE tunnel packets have the same IP precedence (or DSCP) as the encapsulated packets. I happened to run into a document that talked about this for VPNs that are built on GRE tunnels. Check this out: http://www.cisco.com/warp/public/cc/pd/iosw/iore/iomjre12/prodlit/816_pb.htm Search for GRE Precedence in that document. It might do what you're talking about. I think there are some other documents that discuss this also if you search at Cisco's site for IP Precedence or DSCP. Priscilla At 01:54 PM 9/8/01, Chris Read wrote: Is it possible to cause the IP precedence of a GRE packet to be the same as the IP precedence of the packet which it encapsulates? I have a client who is passing real-time as well as normal data over a 3DES encrypted tunnel. I have had to resort to using separate tunnels for the two data streams, but I consider this to be a sub-optimal solution. For reference, I am using a 2621 at one end and a 3640 at the other with 12.1.5 images. This is a real world problem for me. Would this kind of thing possibly come up on the CCIE R/S exams? Chris Read Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=19150t=19125 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
