thank you guys for the answers!
But i found what i was looking for.. but it isn’t possible with routerOS yet ( as far as i know )
here the explanation..
By default, the TTL field value in the packet header is decremented by 1 for every hop the packet traverses in the LSP, thereby preventing loops. If the TTL field value reaches 0, packets are dropped, and an ICMP error packet might be sent to the originating router.
If normal TTL decrement is disabled, the TTL field of IP packets entering LSPs are decremented by only 1 upon transiting the LSP, making the LSP appear as a one-hop router to diagnostic tools, such as traceroute. This is done by the ingress router, which pushes a label on IP packets with the TTL field in the label initialized to 255. The label’s TTL field value is decremented by 1 for every hop the MPLS packet traverses in the LSP. On the penultimate hop of the LSP, the router pops the label but does not write the label’s TTL field value to the IP packet’s TTL field. Instead, when the IP packet reaches the egress router, the IP packet’s TTL field value is decremented by 1.
When you use traceroute to diagnose problems with an LSP, traceroute sees the ingress router, although the egress router performs the TTL decrement. Note that this assumes that traceroute is initiated outside of the LSP. The behavior of traceroute is different if it is initiated from the ingress router of the LSP. In this case, the egress router would be the first router to respond to traceroute.
You can disable normal TTL decrementing in an LSP so that the TTL field value does not reach 0 before the packet reaches its destination, thus preventing the packet from being dropped. You can also disable normal TTL decrementing to make the MPLS cloud appear as a single hop, thereby hiding the network topology.
There are two ways to disable TTL decrementing:
- On the ingress of the LSP, if you include the no-decrement-ttl statement at the [edit protocols mpls label-switched-path lsp-path-name ] hierarchy level, the ingress router negotiates with all downstream routers using a proprietary RSVP object, to ensure all routers are in agreement. If negotiation succeeds, the whole LSP behaves as one hop to transit IP traffic.
[edit protocols mpls label-switched-path lsp-path-name ]
no-decrement-ttl;
Note that the RSVP object is proprietary to the JUNOS software and might not work with other software. This potential incompatibility only applies to RSVP-signaled LSPs, not to LDP-signaled LSPs. When you include the no-decrement-ttl statement, TTL hiding can be enforced on a per-LSP basis.
- On the router, you can include the no-propagate-ttl statement at the [edit protocols mpls] hierarchy level. This statement applies to all LSPs, regardless of whether they are RSVP-signaled or LDP-signaled. Once set, all future LSPs traversing through this router behave as a single hop to IP packets. LSPs established before you configure this statement are not affected.
[edit protocols mpls]
no-propagate-ttl;
If you include the no-propagate-ttl statement, make sure all routers are configured consistently within an MPLS domain; failing to do so might cause the IP packet TTL to increase while in transit within LSPs. This can happen, for example, when the ingress router has no-propagate-ttl configured but the penultimate router does not, so the penultimate router writes the MPLS TTL value (which starts from the ingress router as 255) into the IP packet.
The operation of the no-propagate-ttl statement is more interoperable with other vendors’ equipment. However, you must ensure all routers are configured identically.
