[j-nsp] EXP based LSP selection

[Adam Vitkovsky]

Hi Dragan,
Thank you very much for the response
Please see the comments inline

> Dragan Jovicic [mailto:draganj84 at gmail.com]
> Sent: Sunday, August 14, 2016 11:36 AM
>
> Hello,
> In lab, tested and works as following. Traffic arrives as MPLS (LDP in control
> plane) on a core router , and then is forced to whichever RSVP LSP
> depending on EXP bits. The key is to run LDP tunneling over RSVP LSPs - as
Oh yes without LDP over RSVP there wouldn't be an end-to-end LSP.


> the route in control plane must point over these tunnels. Traffic that is not
> matching any of the RSVP LSPs specified in specified policy will be forwarded
> using next best forwarding method (it can be default RSVP LSP, LDP, or reject
> is specified). Something like this:
>
> > show configuration policy-options policy-statement lsp-policy1
> then cos-next-hop-map cos-map1;
>
But since the policy is matching everything, then all routes in inet.3 will be altered right?


> > show configuration class-of-service forwarding-policy
> next-hop-map cos-map1 {
>     forwarding-class BE {
>         lsp-next-hop lsp-be;
>     }
>     forwarding-class REALTIME {
>         lsp-next-hop lsp-realtime;
>     }
> }
>
> > show configuration class-of-service interfaces
> ge-1/0/9 {
>     unit * {
>         classifiers {
>             exp BA-exp;
>         }
>     }
> }
>
> > show configuration routing-options forwarding-table
> export lsp-policy1;
>
> > show configuration protocols mpls
> label-switched-path lsp-be {
>     to 120.10.255.1;
>     ldp-tunneling;
> }
> label-switched-path lsp-realtime {
>     to 120.10.255.1;
>     ldp-tunneling;
> }
>
>
>
> This is on core router will LDP tunneling:
>
> > show route table inet.3 120.10.255.1
>
> inet.3: 20 destinations, 24 routes (4 active, 0 holddown, 19 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 120.10.255.1/32    *[RSVP/7/1] 1d 21:00:43, metric 1000
>                     > to 120.10.50.2 via ge-1/0/9.500, label-switched-path lsp-be
>                       to 120.10.50.2 via ge-1/0/9.500, label-switched-path lsp-realtime
>                     [LDP/9] 00:12:40, metric 1000
>                     > to 120.10.50.2 via ge-1/0/9.500, label-switched-path lsp-be
>                       to 120.10.50.2 via ge-1/0/9.500, label-switched-path lsp-realtime
>
I suspect that this is how the inet.3 table looks like for all the prefixes in it.
But then I'm wondering how come the return traffic for ping to 120.10.255.1 is not caught by the policy and looped back?  Do you know what I mean please?
Or maybe if the tunnel is not terminated at the PE (120.10.255.1) but exists only in the core and all /32 routes in inet.3 have these two LSPs associated with them wouldn't the traffic loop when passing through this core router?
Or is there some kind of split horizon rule, i.e. if packet cam through interface-A it can't be sent out via int-A even if inet.3 says it should?
If the policy would have been applied to an interface then you'd have a direction but if it's applied in the forwarding table it has to be applied to all directions no?

Thank you.

adam



        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------