SD-WAN

Hello everyone!

I apologize for my absence lately. We have been crazy busy over here at Juniper (all good stuff!). We've been out there crushing it with shows like Mobile World Congress in Barcelona, MPLS, SD & AI Net World in Paris, RSA in San Francisco, etc. We've been winning awards. And we've been improving on our amazing products. 

However, I missed speaking with you, so I needed to bring back the Feature Fridays. For this week's Feature Friday, we are actually going to look at a release that happened recently...6.1.0!

6.1.0 came out on April 14 and it is GA. We are changing our whole LA/GA structure, so you don't need special permission to use 6.1.0. You can see a summary of available release here. 

6.1.0 comes with a ton of cool and useful features. You can read all of the features here. Below I will list some of my favorites. 

Traceroute

We now have Traceroute as a troubleshooting tool in the SSR!!!! This is one I have heard asked about FOREVER. I am sure many of you know what Traceroute is, but for those that don't, it's a tool network admins use to test hop by hop connectivity, instead of just connectivity to the destination - like a traditional ping would do. The SSR's Traceroute is a little different than traditional Traceroute in that it can be given a Service and Tenant name to test the hop by hop connectivity for different Services. You can also have it sent as traditional Traceroute as well. I'll definitely be doing a full FF (Feature Friday…yea, I'm abbreviating now…deal with it) on Traceroute in the future, but for now check out how it works and how to configure it here. 

Session Recovery Detection

Session Recovery Detection provides a new way for the SSR to preserve sessions when failures have occurred in the network. Traditionally, traffic destined to flows that no longer exist result in a metadata response from the SSR. This response may falsely indicate that the SSR is listening and responding to wayports - which it does not. With the Sessions Recovery Detection set to inactivity-based, the originating SSR monitors activity on the flow. If no activity is detected for the specified time, the originator will add an additional metadata attribute called session-health-check to the next packet. The session-health-check attribute is validated by the receiving node. If the flow on the receiving node does not exist, it generates an enable-metadata message back to the originator. Check out how to configure this as well as look at a neat diagram here. 

BFD Overlay over SVR

In deployments where the number of SVR sessions between SSRs are limited due to provider settings, the established BFD channel is leveraged to encapsulate SVR sessions. When enabled, the SSR transforms each packet in the SVR session to a UDP packet, matching the IP/Port tuples of the BFD peer connection. The carrier does not see any additional sessions between the SSRs beyond the initial BFD peer connection. Check out how to configure and troubleshoot this feature here. 

Automatic mesh created for route-reflector topology

Use this option to generate a full-mesh BGP over SVR configuration, where all spokes learn the routes from other spokes via the reflector. In this configuration, the hub is a route reflector and all spokes are SVR peers, having been placed in the same mesh neighborhood. The BGP next hop is the originating spoke, and traffic is passed via SVR directly between the spokes. Check out the caveats and how to enable this feature here. 

Outside of the above features, you will find CVE's being addressed, more features being brought over to the Mist-managed routers, and bugs being resolved. 

Alright, that's a lot of words coming from me. I'm tired. I want to hear from you now:

• Which 6.1.0 feature excites you the most?
• Which mode of Session Recovery Detection are you going to use?
• Are you going to start sending sessions on your BFD channel?
• Once you get some experience with some of these new features, let us know what you think about them and if they solve any of your current issues.
  

Oh, btw, I am going to be in Vegas next week for Channel Partners Conference 2023! If you are around, come by and say hi, we could even grab a drink or play some craps or something. I'm there to do some demos, so if you would like to see a demo, you can sign up for one here: https://register.events.juniper.net/cpconference23?utm_userID=c6eeda1a-e9b2-4f2b-99a3-92daa5837f60&utm_source=linkedin&utm_medium=everyonesocial&es_id=fe29e37633. We're raffling off a Solo Stove to one lucky demo watcher. We'll have some other cool stuff to give out too. Anyway, I hope to see you there!

Talk to you soon! I promise.

#FeatureFridays #SVR #BGPoverSVR #6.1.0  #SecureVectorRouting  #troubleshooting #Traceroute #SessionResiliency 

Would it cause any connectivity issues if we were to update the conductor and a few routers to 6.1.0 while still having some routers on older 4 and 5 versions?

Hello everyone!

I apologize for my absence lately. We have been crazy busy over here at Juniper (all good stuff!). We've been out there crushing it with shows like Mobile World Congress in Barcelona, MPLS, SD & AI Net World in Paris, RSA in San Francisco, etc. We've been winning awards. And we've been improving on our amazing products. 

However, I missed speaking with you, so I needed to bring back the Feature Fridays. For this week's Feature Friday, we are actually going to look at a release that happened recently...6.1.0!

6.1.0 came out on April 14 and it is GA. We are changing our whole LA/GA structure, so you don't need special permission to use 6.1.0. You can see a summary of available release here. 

6.1.0 comes with a ton of cool and useful features. You can read all of the features here. Below I will list some of my favorites. 

Traceroute

We now have Traceroute as a troubleshooting tool in the SSR!!!! This is one I have heard asked about FOREVER. I am sure many of you know what Traceroute is, but for those that don't, it's a tool network admins use to test hop by hop connectivity, instead of just connectivity to the destination - like a traditional ping would do. The SSR's Traceroute is a little different than traditional Traceroute in that it can be given a Service and Tenant name to test the hop by hop connectivity for different Services. You can also have it sent as traditional Traceroute as well. I'll definitely be doing a full FF (Feature Friday…yea, I'm abbreviating now…deal with it) on Traceroute in the future, but for now check out how it works and how to configure it here. 

Session Recovery Detection

Session Recovery Detection provides a new way for the SSR to preserve sessions when failures have occurred in the network. Traditionally, traffic destined to flows that no longer exist result in a metadata response from the SSR. This response may falsely indicate that the SSR is listening and responding to wayports - which it does not. With the Sessions Recovery Detection set to inactivity-based, the originating SSR monitors activity on the flow. If no activity is detected for the specified time, the originator will add an additional metadata attribute called session-health-check to the next packet. The session-health-check attribute is validated by the receiving node. If the flow on the receiving node does not exist, it generates an enable-metadata message back to the originator. Check out how to configure this as well as look at a neat diagram here. 

BFD Overlay over SVR

In deployments where the number of SVR sessions between SSRs are limited due to provider settings, the established BFD channel is leveraged to encapsulate SVR sessions. When enabled, the SSR transforms each packet in the SVR session to a UDP packet, matching the IP/Port tuples of the BFD peer connection. The carrier does not see any additional sessions between the SSRs beyond the initial BFD peer connection. Check out how to configure and troubleshoot this feature here. 

Automatic mesh created for route-reflector topology

Use this option to generate a full-mesh BGP over SVR configuration, where all spokes learn the routes from other spokes via the reflector. In this configuration, the hub is a route reflector and all spokes are SVR peers, having been placed in the same mesh neighborhood. The BGP next hop is the originating spoke, and traffic is passed via SVR directly between the spokes. Check out the caveats and how to enable this feature here. 

Outside of the above features, you will find CVE's being addressed, more features being brought over to the Mist-managed routers, and bugs being resolved. 

Alright, that's a lot of words coming from me. I'm tired. I want to hear from you now:

• Which 6.1.0 feature excites you the most?
• Which mode of Session Recovery Detection are you going to use?
• Are you going to start sending sessions on your BFD channel?
• Once you get some experience with some of these new features, let us know what you think about them and if they solve any of your current issues.
  

Oh, btw, I am going to be in Vegas next week for Channel Partners Conference 2023! If you are around, come by and say hi, we could even grab a drink or play some craps or something. I'm there to do some demos, so if you would like to see a demo, you can sign up for one here: https://register.events.juniper.net/cpconference23?utm_userID=c6eeda1a-e9b2-4f2b-99a3-92daa5837f60&utm_source=linkedin&utm_medium=everyonesocial&es_id=fe29e37633. We're raffling off a Solo Stove to one lucky demo watcher. We'll have some other cool stuff to give out too. Anyway, I hope to see you there!

Talk to you soon! I promise.

#FeatureFridays #SVR #BGPoverSVR #6.1.0  #SecureVectorRouting  #troubleshooting #Traceroute #SessionResiliency 

Hey @Austin ! Great question! This should work fine. As you pointed out, just make sure you upgrade the Conductor first and then the 4 and 5 versions should be able to reach the 6.1s with no problem. 

Let us know if you run into any issues.

Would it cause any connectivity issues if we were to update the conductor and a few routers to 6.1.0 while still having some routers on older 4 and 5 versions?

Hello everyone!

I apologize for my absence lately. We have been crazy busy over here at Juniper (all good stuff!). We've been out there crushing it with shows like Mobile World Congress in Barcelona, MPLS, SD & AI Net World in Paris, RSA in San Francisco, etc. We've been winning awards. And we've been improving on our amazing products. 

However, I missed speaking with you, so I needed to bring back the Feature Fridays. For this week's Feature Friday, we are actually going to look at a release that happened recently...6.1.0!

6.1.0 came out on April 14 and it is GA. We are changing our whole LA/GA structure, so you don't need special permission to use 6.1.0. You can see a summary of available release here. 

6.1.0 comes with a ton of cool and useful features. You can read all of the features here. Below I will list some of my favorites. 

Traceroute

We now have Traceroute as a troubleshooting tool in the SSR!!!! This is one I have heard asked about FOREVER. I am sure many of you know what Traceroute is, but for those that don't, it's a tool network admins use to test hop by hop connectivity, instead of just connectivity to the destination - like a traditional ping would do. The SSR's Traceroute is a little different than traditional Traceroute in that it can be given a Service and Tenant name to test the hop by hop connectivity for different Services. You can also have it sent as traditional Traceroute as well. I'll definitely be doing a full FF (Feature Friday…yea, I'm abbreviating now…deal with it) on Traceroute in the future, but for now check out how it works and how to configure it here. 

Session Recovery Detection

Session Recovery Detection provides a new way for the SSR to preserve sessions when failures have occurred in the network. Traditionally, traffic destined to flows that no longer exist result in a metadata response from the SSR. This response may falsely indicate that the SSR is listening and responding to wayports - which it does not. With the Sessions Recovery Detection set to inactivity-based, the originating SSR monitors activity on the flow. If no activity is detected for the specified time, the originator will add an additional metadata attribute called session-health-check to the next packet. The session-health-check attribute is validated by the receiving node. If the flow on the receiving node does not exist, it generates an enable-metadata message back to the originator. Check out how to configure this as well as look at a neat diagram here. 

BFD Overlay over SVR

In deployments where the number of SVR sessions between SSRs are limited due to provider settings, the established BFD channel is leveraged to encapsulate SVR sessions. When enabled, the SSR transforms each packet in the SVR session to a UDP packet, matching the IP/Port tuples of the BFD peer connection. The carrier does not see any additional sessions between the SSRs beyond the initial BFD peer connection. Check out how to configure and troubleshoot this feature here. 

Automatic mesh created for route-reflector topology

Use this option to generate a full-mesh BGP over SVR configuration, where all spokes learn the routes from other spokes via the reflector. In this configuration, the hub is a route reflector and all spokes are SVR peers, having been placed in the same mesh neighborhood. The BGP next hop is the originating spoke, and traffic is passed via SVR directly between the spokes. Check out the caveats and how to enable this feature here. 

Outside of the above features, you will find CVE's being addressed, more features being brought over to the Mist-managed routers, and bugs being resolved. 

Alright, that's a lot of words coming from me. I'm tired. I want to hear from you now:

• Which 6.1.0 feature excites you the most?
• Which mode of Session Recovery Detection are you going to use?
• Are you going to start sending sessions on your BFD channel?
• Once you get some experience with some of these new features, let us know what you think about them and if they solve any of your current issues.
  

Oh, btw, I am going to be in Vegas next week for Channel Partners Conference 2023! If you are around, come by and say hi, we could even grab a drink or play some craps or something. I'm there to do some demos, so if you would like to see a demo, you can sign up for one here: https://register.events.juniper.net/cpconference23?utm_userID=c6eeda1a-e9b2-4f2b-99a3-92daa5837f60&utm_source=linkedin&utm_medium=everyonesocial&es_id=fe29e37633. We're raffling off a Solo Stove to one lucky demo watcher. We'll have some other cool stuff to give out too. Anyway, I hope to see you there!

Talk to you soon! I promise.

#FeatureFridays #SVR #BGPoverSVR #6.1.0  #SecureVectorRouting  #troubleshooting #Traceroute #SessionResiliency 

Hi Justin,

I have deployed SDWAN sub-spoke architecture and everything works fine except trace routes. I am trying to trace a switch which is behind HUB from the switch which is behind spoke but when i do packet capture on interface connected to switch i couldn't see any logs and even trace is not getting complete.

Please works fine and i am getting logs over packet capture.

Hey @Austin ! Great question! This should work fine. As you pointed out, just make sure you upgrade the Conductor first and then the 4 and 5 versions should be able to reach the 6.1s with no problem. 

Let us know if you run into any issues.

Would it cause any connectivity issues if we were to update the conductor and a few routers to 6.1.0 while still having some routers on older 4 and 5 versions?

Hello everyone!

I apologize for my absence lately. We have been crazy busy over here at Juniper (all good stuff!). We've been out there crushing it with shows like Mobile World Congress in Barcelona, MPLS, SD & AI Net World in Paris, RSA in San Francisco, etc. We've been winning awards. And we've been improving on our amazing products. 

However, I missed speaking with you, so I needed to bring back the Feature Fridays. For this week's Feature Friday, we are actually going to look at a release that happened recently...6.1.0!

6.1.0 came out on April 14 and it is GA. We are changing our whole LA/GA structure, so you don't need special permission to use 6.1.0. You can see a summary of available release here. 

6.1.0 comes with a ton of cool and useful features. You can read all of the features here. Below I will list some of my favorites. 

Traceroute

We now have Traceroute as a troubleshooting tool in the SSR!!!! This is one I have heard asked about FOREVER. I am sure many of you know what Traceroute is, but for those that don't, it's a tool network admins use to test hop by hop connectivity, instead of just connectivity to the destination - like a traditional ping would do. The SSR's Traceroute is a little different than traditional Traceroute in that it can be given a Service and Tenant name to test the hop by hop connectivity for different Services. You can also have it sent as traditional Traceroute as well. I'll definitely be doing a full FF (Feature Friday…yea, I'm abbreviating now…deal with it) on Traceroute in the future, but for now check out how it works and how to configure it here. 

Session Recovery Detection

Session Recovery Detection provides a new way for the SSR to preserve sessions when failures have occurred in the network. Traditionally, traffic destined to flows that no longer exist result in a metadata response from the SSR. This response may falsely indicate that the SSR is listening and responding to wayports - which it does not. With the Sessions Recovery Detection set to inactivity-based, the originating SSR monitors activity on the flow. If no activity is detected for the specified time, the originator will add an additional metadata attribute called session-health-check to the next packet. The session-health-check attribute is validated by the receiving node. If the flow on the receiving node does not exist, it generates an enable-metadata message back to the originator. Check out how to configure this as well as look at a neat diagram here. 

BFD Overlay over SVR

In deployments where the number of SVR sessions between SSRs are limited due to provider settings, the established BFD channel is leveraged to encapsulate SVR sessions. When enabled, the SSR transforms each packet in the SVR session to a UDP packet, matching the IP/Port tuples of the BFD peer connection. The carrier does not see any additional sessions between the SSRs beyond the initial BFD peer connection. Check out how to configure and troubleshoot this feature here. 

Automatic mesh created for route-reflector topology

Use this option to generate a full-mesh BGP over SVR configuration, where all spokes learn the routes from other spokes via the reflector. In this configuration, the hub is a route reflector and all spokes are SVR peers, having been placed in the same mesh neighborhood. The BGP next hop is the originating spoke, and traffic is passed via SVR directly between the spokes. Check out the caveats and how to enable this feature here. 

Outside of the above features, you will find CVE's being addressed, more features being brought over to the Mist-managed routers, and bugs being resolved. 

Alright, that's a lot of words coming from me. I'm tired. I want to hear from you now:

• Which 6.1.0 feature excites you the most?
• Which mode of Session Recovery Detection are you going to use?
• Are you going to start sending sessions on your BFD channel?
• Once you get some experience with some of these new features, let us know what you think about them and if they solve any of your current issues.
  

Oh, btw, I am going to be in Vegas next week for Channel Partners Conference 2023! If you are around, come by and say hi, we could even grab a drink or play some craps or something. I'm there to do some demos, so if you would like to see a demo, you can sign up for one here: https://register.events.juniper.net/cpconference23?utm_userID=c6eeda1a-e9b2-4f2b-99a3-92daa5837f60&utm_source=linkedin&utm_medium=everyonesocial&es_id=fe29e37633. We're raffling off a Solo Stove to one lucky demo watcher. We'll have some other cool stuff to give out too. Anyway, I hope to see you there!

Talk to you soon! I promise.

#FeatureFridays #SVR #BGPoverSVR #6.1.0  #SecureVectorRouting  #troubleshooting #Traceroute #SessionResiliency 

Hi @JEEVAK MUKADAM,

Let's see if we can get your situation figured out.

Did you try all the steps in this documentation: https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/ts_traceroute/ ?

Thank you,

Justin 

Hi Justin,

I have deployed SDWAN sub-spoke architecture and everything works fine except trace routes. I am trying to trace a switch which is behind HUB from the switch which is behind spoke but when i do packet capture on interface connected to switch i couldn't see any logs and even trace is not getting complete.

Please works fine and i am getting logs over packet capture.

Hey @Austin ! Great question! This should work fine. As you pointed out, just make sure you upgrade the Conductor first and then the 4 and 5 versions should be able to reach the 6.1s with no problem. 

Let us know if you run into any issues.

Would it cause any connectivity issues if we were to update the conductor and a few routers to 6.1.0 while still having some routers on older 4 and 5 versions?

Hello everyone!

I apologize for my absence lately. We have been crazy busy over here at Juniper (all good stuff!). We've been out there crushing it with shows like Mobile World Congress in Barcelona, MPLS, SD & AI Net World in Paris, RSA in San Francisco, etc. We've been winning awards. And we've been improving on our amazing products. 

However, I missed speaking with you, so I needed to bring back the Feature Fridays. For this week's Feature Friday, we are actually going to look at a release that happened recently...6.1.0!

6.1.0 came out on April 14 and it is GA. We are changing our whole LA/GA structure, so you don't need special permission to use 6.1.0. You can see a summary of available release here. 

6.1.0 comes with a ton of cool and useful features. You can read all of the features here. Below I will list some of my favorites. 

Traceroute

We now have Traceroute as a troubleshooting tool in the SSR!!!! This is one I have heard asked about FOREVER. I am sure many of you know what Traceroute is, but for those that don't, it's a tool network admins use to test hop by hop connectivity, instead of just connectivity to the destination - like a traditional ping would do. The SSR's Traceroute is a little different than traditional Traceroute in that it can be given a Service and Tenant name to test the hop by hop connectivity for different Services. You can also have it sent as traditional Traceroute as well. I'll definitely be doing a full FF (Feature Friday…yea, I'm abbreviating now…deal with it) on Traceroute in the future, but for now check out how it works and how to configure it here. 

Session Recovery Detection

Session Recovery Detection provides a new way for the SSR to preserve sessions when failures have occurred in the network. Traditionally, traffic destined to flows that no longer exist result in a metadata response from the SSR. This response may falsely indicate that the SSR is listening and responding to wayports - which it does not. With the Sessions Recovery Detection set to inactivity-based, the originating SSR monitors activity on the flow. If no activity is detected for the specified time, the originator will add an additional metadata attribute called session-health-check to the next packet. The session-health-check attribute is validated by the receiving node. If the flow on the receiving node does not exist, it generates an enable-metadata message back to the originator. Check out how to configure this as well as look at a neat diagram here. 

BFD Overlay over SVR

In deployments where the number of SVR sessions between SSRs are limited due to provider settings, the established BFD channel is leveraged to encapsulate SVR sessions. When enabled, the SSR transforms each packet in the SVR session to a UDP packet, matching the IP/Port tuples of the BFD peer connection. The carrier does not see any additional sessions between the SSRs beyond the initial BFD peer connection. Check out how to configure and troubleshoot this feature here. 

Automatic mesh created for route-reflector topology

Use this option to generate a full-mesh BGP over SVR configuration, where all spokes learn the routes from other spokes via the reflector. In this configuration, the hub is a route reflector and all spokes are SVR peers, having been placed in the same mesh neighborhood. The BGP next hop is the originating spoke, and traffic is passed via SVR directly between the spokes. Check out the caveats and how to enable this feature here. 

Outside of the above features, you will find CVE's being addressed, more features being brought over to the Mist-managed routers, and bugs being resolved. 

Alright, that's a lot of words coming from me. I'm tired. I want to hear from you now:

• Which 6.1.0 feature excites you the most?
• Which mode of Session Recovery Detection are you going to use?
• Are you going to start sending sessions on your BFD channel?
• Once you get some experience with some of these new features, let us know what you think about them and if they solve any of your current issues.
  

Oh, btw, I am going to be in Vegas next week for Channel Partners Conference 2023! If you are around, come by and say hi, we could even grab a drink or play some craps or something. I'm there to do some demos, so if you would like to see a demo, you can sign up for one here: https://register.events.juniper.net/cpconference23?utm_userID=c6eeda1a-e9b2-4f2b-99a3-92daa5837f60&utm_source=linkedin&utm_medium=everyonesocial&es_id=fe29e37633. We're raffling off a Solo Stove to one lucky demo watcher. We'll have some other cool stuff to give out too. Anyway, I hope to see you there!

Talk to you soon! I promise.

#FeatureFridays #SVR #BGPoverSVR #6.1.0  #SecureVectorRouting  #troubleshooting #Traceroute #SessionResiliency 

Hi Justin,

I have checked and as per update traceroutes are blocked at AWS.

Hi @JEEVAK MUKADAM,

Let's see if we can get your situation figured out.

Did you try all the steps in this documentation: https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/ts_traceroute/ ?

Thank you,

Justin 

Hi Justin,

I have deployed SDWAN sub-spoke architecture and everything works fine except trace routes. I am trying to trace a switch which is behind HUB from the switch which is behind spoke but when i do packet capture on interface connected to switch i couldn't see any logs and even trace is not getting complete.

Please works fine and i am getting logs over packet capture.

Hey @Austin ! Great question! This should work fine. As you pointed out, just make sure you upgrade the Conductor first and then the 4 and 5 versions should be able to reach the 6.1s with no problem. 

Let us know if you run into any issues.

Would it cause any connectivity issues if we were to update the conductor and a few routers to 6.1.0 while still having some routers on older 4 and 5 versions?

Hello everyone!

I apologize for my absence lately. We have been crazy busy over here at Juniper (all good stuff!). We've been out there crushing it with shows like Mobile World Congress in Barcelona, MPLS, SD & AI Net World in Paris, RSA in San Francisco, etc. We've been winning awards. And we've been improving on our amazing products. 

However, I missed speaking with you, so I needed to bring back the Feature Fridays. For this week's Feature Friday, we are actually going to look at a release that happened recently...6.1.0!

6.1.0 came out on April 14 and it is GA. We are changing our whole LA/GA structure, so you don't need special permission to use 6.1.0. You can see a summary of available release here. 

6.1.0 comes with a ton of cool and useful features. You can read all of the features here. Below I will list some of my favorites. 

Traceroute

We now have Traceroute as a troubleshooting tool in the SSR!!!! This is one I have heard asked about FOREVER. I am sure many of you know what Traceroute is, but for those that don't, it's a tool network admins use to test hop by hop connectivity, instead of just connectivity to the destination - like a traditional ping would do. The SSR's Traceroute is a little different than traditional Traceroute in that it can be given a Service and Tenant name to test the hop by hop connectivity for different Services. You can also have it sent as traditional Traceroute as well. I'll definitely be doing a full FF (Feature Friday…yea, I'm abbreviating now…deal with it) on Traceroute in the future, but for now check out how it works and how to configure it here. 

Session Recovery Detection

Session Recovery Detection provides a new way for the SSR to preserve sessions when failures have occurred in the network. Traditionally, traffic destined to flows that no longer exist result in a metadata response from the SSR. This response may falsely indicate that the SSR is listening and responding to wayports - which it does not. With the Sessions Recovery Detection set to inactivity-based, the originating SSR monitors activity on the flow. If no activity is detected for the specified time, the originator will add an additional metadata attribute called session-health-check to the next packet. The session-health-check attribute is validated by the receiving node. If the flow on the receiving node does not exist, it generates an enable-metadata message back to the originator. Check out how to configure this as well as look at a neat diagram here. 

BFD Overlay over SVR

In deployments where the number of SVR sessions between SSRs are limited due to provider settings, the established BFD channel is leveraged to encapsulate SVR sessions. When enabled, the SSR transforms each packet in the SVR session to a UDP packet, matching the IP/Port tuples of the BFD peer connection. The carrier does not see any additional sessions between the SSRs beyond the initial BFD peer connection. Check out how to configure and troubleshoot this feature here. 

Automatic mesh created for route-reflector topology

Use this option to generate a full-mesh BGP over SVR configuration, where all spokes learn the routes from other spokes via the reflector. In this configuration, the hub is a route reflector and all spokes are SVR peers, having been placed in the same mesh neighborhood. The BGP next hop is the originating spoke, and traffic is passed via SVR directly between the spokes. Check out the caveats and how to enable this feature here. 

Outside of the above features, you will find CVE's being addressed, more features being brought over to the Mist-managed routers, and bugs being resolved. 

Alright, that's a lot of words coming from me. I'm tired. I want to hear from you now:

• Which 6.1.0 feature excites you the most?
• Which mode of Session Recovery Detection are you going to use?
• Are you going to start sending sessions on your BFD channel?
• Once you get some experience with some of these new features, let us know what you think about them and if they solve any of your current issues.
  

Oh, btw, I am going to be in Vegas next week for Channel Partners Conference 2023! If you are around, come by and say hi, we could even grab a drink or play some craps or something. I'm there to do some demos, so if you would like to see a demo, you can sign up for one here: https://register.events.juniper.net/cpconference23?utm_userID=c6eeda1a-e9b2-4f2b-99a3-92daa5837f60&utm_source=linkedin&utm_medium=everyonesocial&es_id=fe29e37633. We're raffling off a Solo Stove to one lucky demo watcher. We'll have some other cool stuff to give out too. Anyway, I hope to see you there!

Talk to you soon! I promise.

#FeatureFridays #SVR #BGPoverSVR #6.1.0  #SecureVectorRouting  #troubleshooting #Traceroute #SessionResiliency 

Hi @JEEVAK MUKADAM,

I have brought this to the attention of our Engineering team. Can you share a few diagrams to give us a picture of where the issue is?

Thank you,

Justin

Hi Justin,

I have checked and as per update traceroutes are blocked at AWS.

Hi @JEEVAK MUKADAM,

Let's see if we can get your situation figured out.

Did you try all the steps in this documentation: https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/ts_traceroute/ ?

Thank you,

Justin 

Hi Justin,

I have deployed SDWAN sub-spoke architecture and everything works fine except trace routes. I am trying to trace a switch which is behind HUB from the switch which is behind spoke but when i do packet capture on interface connected to switch i couldn't see any logs and even trace is not getting complete.

Please works fine and i am getting logs over packet capture.

Hey @Austin ! Great question! This should work fine. As you pointed out, just make sure you upgrade the Conductor first and then the 4 and 5 versions should be able to reach the 6.1s with no problem. 

Let us know if you run into any issues.

Would it cause any connectivity issues if we were to update the conductor and a few routers to 6.1.0 while still having some routers on older 4 and 5 versions?

Hello everyone!

I apologize for my absence lately. We have been crazy busy over here at Juniper (all good stuff!). We've been out there crushing it with shows like Mobile World Congress in Barcelona, MPLS, SD & AI Net World in Paris, RSA in San Francisco, etc. We've been winning awards. And we've been improving on our amazing products. 

However, I missed speaking with you, so I needed to bring back the Feature Fridays. For this week's Feature Friday, we are actually going to look at a release that happened recently...6.1.0!

6.1.0 came out on April 14 and it is GA. We are changing our whole LA/GA structure, so you don't need special permission to use 6.1.0. You can see a summary of available release here. 

6.1.0 comes with a ton of cool and useful features. You can read all of the features here. Below I will list some of my favorites. 

Traceroute

We now have Traceroute as a troubleshooting tool in the SSR!!!! This is one I have heard asked about FOREVER. I am sure many of you know what Traceroute is, but for those that don't, it's a tool network admins use to test hop by hop connectivity, instead of just connectivity to the destination - like a traditional ping would do. The SSR's Traceroute is a little different than traditional Traceroute in that it can be given a Service and Tenant name to test the hop by hop connectivity for different Services. You can also have it sent as traditional Traceroute as well. I'll definitely be doing a full FF (Feature Friday…yea, I'm abbreviating now…deal with it) on Traceroute in the future, but for now check out how it works and how to configure it here. 

Session Recovery Detection

Session Recovery Detection provides a new way for the SSR to preserve sessions when failures have occurred in the network. Traditionally, traffic destined to flows that no longer exist result in a metadata response from the SSR. This response may falsely indicate that the SSR is listening and responding to wayports - which it does not. With the Sessions Recovery Detection set to inactivity-based, the originating SSR monitors activity on the flow. If no activity is detected for the specified time, the originator will add an additional metadata attribute called session-health-check to the next packet. The session-health-check attribute is validated by the receiving node. If the flow on the receiving node does not exist, it generates an enable-metadata message back to the originator. Check out how to configure this as well as look at a neat diagram here. 

BFD Overlay over SVR

In deployments where the number of SVR sessions between SSRs are limited due to provider settings, the established BFD channel is leveraged to encapsulate SVR sessions. When enabled, the SSR transforms each packet in the SVR session to a UDP packet, matching the IP/Port tuples of the BFD peer connection. The carrier does not see any additional sessions between the SSRs beyond the initial BFD peer connection. Check out how to configure and troubleshoot this feature here. 

Automatic mesh created for route-reflector topology

Use this option to generate a full-mesh BGP over SVR configuration, where all spokes learn the routes from other spokes via the reflector. In this configuration, the hub is a route reflector and all spokes are SVR peers, having been placed in the same mesh neighborhood. The BGP next hop is the originating spoke, and traffic is passed via SVR directly between the spokes. Check out the caveats and how to enable this feature here. 

Outside of the above features, you will find CVE's being addressed, more features being brought over to the Mist-managed routers, and bugs being resolved. 

Alright, that's a lot of words coming from me. I'm tired. I want to hear from you now:

• Which 6.1.0 feature excites you the most?
• Which mode of Session Recovery Detection are you going to use?
• Are you going to start sending sessions on your BFD channel?
• Once you get some experience with some of these new features, let us know what you think about them and if they solve any of your current issues.
  

Oh, btw, I am going to be in Vegas next week for Channel Partners Conference 2023! If you are around, come by and say hi, we could even grab a drink or play some craps or something. I'm there to do some demos, so if you would like to see a demo, you can sign up for one here: https://register.events.juniper.net/cpconference23?utm_userID=c6eeda1a-e9b2-4f2b-99a3-92daa5837f60&utm_source=linkedin&utm_medium=everyonesocial&es_id=fe29e37633. We're raffling off a Solo Stove to one lucky demo watcher. We'll have some other cool stuff to give out too. Anyway, I hope to see you there!

Talk to you soon! I promise.

#FeatureFridays #SVR #BGPoverSVR #6.1.0  #SecureVectorRouting  #troubleshooting #Traceroute #SessionResiliency