Routing

Hi, Is it possible to send a specific application port to a LSP/MPLS services. To provide some context we have two internet gateways, R1 and R2 with a dedicated interlink between them, same rack. R1 has a 300 Mbps over radio to R3 and R2 has a 600 Mbps over fiber to R4. R3 and R4 connected back to back, same rack. These links between the north(R1R2) and south routers (R3R4) are L2 services provided by 3rd party ISP's. We run ISIS over these links as well as family mpls. So R1 is the entry point for all inbound and outbound internet traffic, we have a FW located behind R3R4 with IP 196.1.1.2 (example) and we use BGP to advertise our 196.1.1.0/24 to R1R2 which are RR. So that is all traffic arrives at R1 and gets forwarded to South based on IGP shorteds path. Traffic returns same. 

This FW is also the FW to our company for outbound internet access as well as terminating VPN user from home. So the same source IP for internet based traffic is also the same destination IP for SSL anchor interface. What i want to achieve is to send all traffic via the default current path 300Mbps service, however SSL traffic needs to go via the 600 Mbps fiber route. So is it possible to match destination port 443 incoming on R1 and send that down a LSP/MPS service, use TE to steer SSL traffic over the 600Mbps Fibre line back to R3, then return source 443 back the same TE route to R1, for all other ports/ traffic is can just use the current shortest patch down/up the 300Mbps link.

Looking forward to your feedback.

Hello,

---

@MFB wrote:

Hi, Is it possible to send a specific application port to a LSP/MPLS services. 

---

Yes, it is possible in JUNOS. What is your HW/product model and JUNOS version?

---

@MFB wrote:

So is it possible to match destination port 443 incoming on R1 and send that down a LSP/MPS service, use TE to steer SSL traffic over the 600Mbps Fibre line back to R3, then return source 443 back the same TE route to R1, for all other ports/ traffic is can just use the current shortest patch down/up the 300Mbps link.

The "canonic" and most compatible way is to use JUNOS Filter Based Forwarding feature with dedicated VRF routing instance and RSVP-TE LSP.

The high-level algorithm is as follows:

1/ create a dedicated RSVP LSP that goes the way You want from R1 to R3

2/ create a MPLS VRF on R1 and R3, let's call it VRF443 for example. Do NOT put any interfaces into it.

3/ on R1, map this VRF443 to dedicated RSVP-TE LSP You created in step 1 and map all other traffic to other RSVP-TE LSPs https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/install-nexthop-edit-policy-options.html 

4/ on R1, create a FW filter which matches on Your access interfaces, say, ge-0/0/0.0 and ge-0/0/2.0; and TCP/dst.port 443 like below

set firewall family inet filter FBF443 term t1 from destination-port 443
set firewall family inet filter FBF443 term t1 from protocol tcp
set firewall family inet filter FBF443 term t1 from interface ge-0/0/0.0
set firewall family inet filter FBF443 term t1 from interface ge-0/0/0.2.0
set firewall family inet filter FBF443 term t1 then routing-instance VRF443
set firewall family inet filter FBF443 term t1 then accept
set firewall family inet filter FBF443 term else then accept

5/ assign this filter to the R1 forwarding-table

set forwarding-options family inet filter input FBF443

6/ on R1, leak the return routes from inet.0 to VRF443, advertise these return routes via MP-BGP to R3

7/ repeat the steps1-3 for R3  

8/ on R3, create a static 0/0 route inside VRF443 pointing to inet.0:

set routing-instances VRF433 routing-options static route 0/0 next-table inet.0

9/ on R3, advertise this 0/0 route via MP-BGP from R3 to R1

10/ on R3, create a FW filter that matches on TCP/src.port 443 and access interfaces , similar to step 4, and assign it to forwarding table

11/ You should be good to go - in case of any issues ask Your Juniper Account team for help from Juniper Professional Services!

One more thing - do not waste Your time with another flavor of JUNOS FBF where "then next-ip" filter action is used, it does  not work with "next-ip" IP that is NOT directly connected. People usually get excited when this discover this option, thinking it saves them time and effort, but it is not the case.

Finally, if You are really brave and Your HW supports it, You can explore colored Segment Routing Traffic Engineering (colored SRTE) instead of RSVP-TE - it will save You a few lines of code and will make future FBF efforts more scalable 😀

HTH

Thx

Alex

Thanks Alex for your valuable feedback. As you mentioned i did get stuck on the next-hop-ip option, but as you said it will not work when not directly connected and also not very good if you have downstream service outage. So after some thought i did this and tested in a virtual LAB only, but it seems to work based on the PCAPS i took. Tested with port SSH. I will test this on a MX5 not sure which version yet.

R2

set firewall family inet filter SSH-REDIRECT term 0 from destination-port ssh
set firewall family inet filter SSH-REDIRECT term 0 then next-ip 100.100.100.1/32
set firewall family inet filter SSH-REDIRECT term 1 then accept

INTERNET INTERFACE

set interfaces ge-0/0/3 unit 0 family inet filter input SSH-REDIRECT 
set interfaces ge-0/0/3 unit 0 family inet address 196.1.1.1/29

set interfaces lt-0/0/0 unit 0 encapsulation ethernet
set interfaces lt-0/0/0 unit 0 peer-unit 1
set interfaces lt-0/0/0 unit 0 family inet address 100.100.100.2/30
set interfaces lt-0/0/0 unit 1 encapsulation ethernet-ccc
set interfaces lt-0/0/0 unit 1 peer-unit 0

set protocols l2circuit neighbor 4.4.4.4 interface lt-0/0/0.1 virtual-circuit-id 5

R4

set firewall family inet filter SSH-REDIRECT term 0 from source-port ssh
set firewall family inet filter SSH-REDIRECT term 0 then next-ip 100.100.100.2/32
set firewall family inet filter SSH-REDIRECT term 1 then accept

INTERFACE TO FW

set interfaces ge-0/0/0 unit 0 family inet filter input SSH-REDIRECT
set interfaces ge-0/0/0 unit 0 family inet address 41.2.2.2/24

set interfaces lt-0/0/0 unit 0 encapsulation ethernet
set interfaces lt-0/0/0 unit 0 peer-unit 1
set interfaces lt-0/0/0 unit 0 family inet address 100.100.100.1/30
set interfaces lt-0/0/0 unit 1 encapsulation ethernet-ccc
set interfaces lt-0/0/0 unit 1 peer-unit 0

set protocols l2circuit neighbor 2.2.2.2 interface lt-0/0/0.1 virtual-circuit-id 5

Using this method i can now use a community to steer the CCC using a dedicated LSP. From a firewall filter perspective the NH will always be reachable as it is not an actual physical interface next hop and the service will always be up so i dont need to worry about downstream failure due to the CCC being resilient to failures.

Will appreciate your feedback on this.

Hello,

You are missing configuration for mapping of L2circuit into dedicated RSVP LSP which follows the strict path.

This LT method is good for lab or JNCIE exam but for production, it has several critical flaws:

1/ LT interface usage causes packet recirculation which means Your linecard PPS capacity usage by TCP/443 is doubled.

2/ when LT is malfunctioning (ARP is not answered), the "next-ip" action blackholes traffic

3/ when LT is down, the traffic falls through to next FW filter action which could be last "default deny"

4/ L2circuit is p2p which means You cannot load-balance towards 2 or more egress PEs.

5/ L2circuit overhead is greater than L3VPN overhead.

HTH

Thx

Alex