06-26-2008 07:32 AM - edited 06-26-2008 07:33 AM
The problem is that CRTP requires MLPPP, and JUNOS only supports IP over MLPPP on the LSQ interface ("family inet" without "family mpls" ). CRTP will only help UDP flows anyway, and is generally meant as an edge protocol for T1 interfaces or smaller.
Sorry, but there is no way to support these together on the same link.
06-26-2008 09:59 PM
Thanks a lot Jeff for reply. Actually the major traffic type is voice so i want to use CRTP but we are thinking to use MPLS in backbone. How can i fix this??? i mean if we make layer 2 or layer 3 tunnel to carry this traffic.
Please help me out
06-27-2008 07:41 AM
What size circuits make up your backbone? If they are bigger than T1, you are probably better off skipping cRTP on the core anyway, and T3 is the maximum size supported for cRTP. For cRTP to work, the services PIC (or software in the J-series) has to be able to identify the packets that make up the same UDP flow via IP address and port information. If you are not sending UDP (such as because the traffic is MPLS), then the software has no method to group packets of the same flow together. This means you add processing resources on either end of the circuit in favor of reducing the header size to cut down on serialization delay over slow pipes.
The next question is why do you plan to use MPLS? Remember that putting MPLS in the core will actually add another layer of encapsulation to your traffic. Sure, MPLS is suppose to make switching faster at the device level by reducing processing time since you just lookup labels rather than IP info, but at the cost of extra encapsulation overhead. This is generally preferred in core links where the speed of the link can make up for the cost of the extra label overhead.
So in concept, you have two different protocols performing the opposite functions to optimize in different situations. If you really feel you need both, then just configure them at the points where they are optimized. MPLS can stay on the core, and cRTP can still help on your edge-to-CPE links. Trying to add any tunnels in the middle just for the sake of using cRTP would really defeat the purpose.
06-27-2008 10:39 PM
Just to add to this thread, CRTP only works on point-to-point type links. It is designed specifically to improve bandwidth of voice traffic on slow WAN links. It does this by reducing the normal 40 or so byte header of PPP/IP packets down to a 2-4 byte CID value. This leaves more available bandwidth for voice traffic. But both ends of the p-t-p link must support CRTP and have it enabled.
For MPLS on a fast or gigether interface, CRTP wouldn't really improve anything anyway. However, as already mentioned, CRTP is not supported on non-p-t-p links. Is there a specific problem you are having with regards to your voice traffic which is leading to your looking into CRTP?
06-28-2008 02:55 AM
Thanks a lot JJ and richard for replying in such details. Actually its our design requirement but i was not so much aware of CRTP before you people adviced me.
Our design looks like this.........
Media gateway to Access routers (M10i) is Fast ethernet connectivity
Access router to Distribution routers (M120) is E1
Distribution router to Core router (M320) is also x E1
Between core router is E3
So please suggest i need to run CRTP between access router to distribution routers and actually is it possible to run CRTP on fast ethernet and E1 interfaces?
Thanks in advance
06-28-2008 12:04 PM - edited 06-28-2008 12:05 PM
CRTP is not an end-to-end protocol. It is specific between two peers of a point-to-point link only. So between your access router and distribution router with the E1 link, you can run CRTP assuming that you are using PPP encapsulation over the E1. What protocol are you using for your E1 exactly? You would not run CRTP on your fastethernet. As already explained earlier, this can only work between point-to-point links.