SRX

Hi  All,

Got a weird issue here.  I have two SRX connected together.  They are connected through a VR.  Each SRX has two VR's (one of them used to connect the devices together).

Here is an example

                          SRX-A                                                       SRX-B

HostA ---> [VR1 ---> VR-2  ] --------OSPF--------  [VR-2<-------VR-1] <--------Host B

When I pring from HostA or SRXA VR1, or VR2  to the IP address of a subnet on SRX-B in VR1 I get a reply from the source IP of SRX-B VR2. 

Even as I write this it sounds confusing but basicly   My ping reply is coming from the interface in VR-2 instead of having a source of the interface in VR-1 ( what im actually pinging).  This causes the ping to fail in windows (Because the source of the icmp reply is different then the ip it was sent too).

Anyone ever see this before?

Silly question -- are you doing NAT?

Actually, strike that.  I just reread your post:

---

@Magraw wrote:

 

Even as I write this it sounds confusing but basicly   My ping reply is coming from the interface in VR-2 instead of having a source of the interface in VR-1 ( what im actually pinging).

---

If I understand this correctly, if you ping the interface address of VR-1 on SRX-B, then I think the device will respond from the interface where the packet was received, because it's a "self" packet and to the SRX, the addresses for VR-1 and VR-2 are both equivalent to "self."

Perhaps I'm misunderstanding...  what if you ping Host B?  The reply should come from Host B, not from any of the routed interfaces.

Hi Keithr

Yes you are correct on all points.  I can ping Host B and get the reply from Host B.  My concern is why is the ping reply coming from VR-1 interface when it was the VR-2 interface that I pinged.

My concern is that most host inbound services to that VR2 IP will not work since the reply comes from somewhere else ( SSH, IKE) are not going to like this and fail.

Thoughts?

*Update* Not sure if its worth noting but these devices are all in HA.  Nothing is in the main routing table ( except fxp0 interfaces)

---

@Magraw wrote:

 

Yes you are correct on all points.  I can ping Host B and get the reply from Host B.  My concern is why is the ping reply coming from VR-1 interface when it was the VR-2 interface that I pinged.

---

My theory on that is like I said -- the SRX considers "self" to be equivalent across all its ingress ports.  I could be wrong, but it's the conclusion I've reached after investigating various things.

If you traceroute to the VR-2 interface, what do you see?

That all being said, I have an SRX 650 cluster that I'm looking at that looks something like this:

reth0.0 (10.1.1.1) -- SRX 650 Cluster -- reth2.0 (1.1.1.1)
(sec zone untrust)                       (sec zone dc1)

With this scenario, if I ping the reth2.0 interface IP, I get replies from it, not from reth0.0.  The only difference here is that I'm not using VRs.  I wonder if this doesn't have something to do with how traffic is crossing the VRs and back?  How are your VR-VR routes set up?  Are you using firewall filters to do FBF?  Any kind of NAT anywhere?

---

@Magraw wrote:

 

My concern is that most host inbound services to that VR2 IP will not work since the reply comes from somewhere else ( SSH, IKE) are not going to like this and fail.

---

Yeah, that would certainly be a problem.  It seems to point to something relating to the fact that you're using VRs.  I've not had this problem in my deployments as I'm not using VRs like this.

Within an SRX I use the instance-import command to bring routes from one routing table into another.  Then I use ibgp to exchange routes between the two SRX.

At the end of the day basiclly all routing tables have all routes ( Being able to bring from one host to another host prooves that routing and security is working) its just traffic destined to the SRX itself which lives in another VR that acts this way.

No NAT anywhere.

On an interesting note doing a flow debug on SRX-B when the original ping packet comes in its source has actually been changed from Host-A's IP to the outgoign interface IP.  This just gets stranger and stranger.

I had a theory on this, and spent a good 20+ minutes typing it all out... but as I was typing it I realized parts of it weren't making sense to me, so rather than make a confusing situation even worse, I decided that my theory *may* be right, but probably not.  Let's dig a little deeper before I can figure out if it's even logical or not at this point.

If we ignore VRs for a minute, this behavior doesn't happen on my boxes.  Like I mentioned in my previous post, if I ping an interface address of one of my SRXs, that's where the reply comes from.

Are you doing any FBF (filter-based forwarding) / policy-based routing between VRs?  Can you run the flow debug on both SRXs and see where the address seems to change and how many times it changes, and compare that with how the traffic looks if you ping from Host A to Host B rather than to the SRX itself?

Can you add another interface into the same VR-2 as your untrust interface and ping that, and see if you get the same address-changing oddness?  That might help determine if this is related to VRs or VR crossing or not.

Also, can you post your configs, any more detail on the diagram, and any helpful output such as a "show route" and the debug flow outputs so we can see how traffic is moving through the systems?

When you do you the instance-import of routes on SRX-B, are you importing 'static' routes, 'direct' routes, 'local' routes, or all of the above?

It may be that when SRX B responds to the ping and does the route lookup to return to Host A, it sees the route is via the VRF but as the address it wants to respond from does not exist in that vrf, it cannot bind to that address for the ping reply, s picks its only other address in that vrf.

You may be able to fix this by ensuring hat the 'local' routes (the /32 routes that represent the SRX's own IP address on taht subnet) are imported in addition to your direct/statics.

Are your SRX's in packet mode or firewall mode?

Thanks,

Joel

Hi All,

Thanks for the replies.  I just got off with ATAC and here is the synopsis of this issue.

"There is a limitation in the current implementation of host-inbound-traffic routing across different routing instances. If we setting static route with next-hop specified as another routing-instance, we tread the next-hop type as "table" and since can do recursive route look-up to determine final VR-id, where we can find the corresponding interface. If we use "import" command to import route from one VR to another we tread next-hop as "unicast" and as a result, we can not find correct VR-id through which to send the return traffic."

So I guess this is a limition of the box.  I was told the only working solution is to hard wire (hairpin) your VR's together so that the self traffic can find a proper source interface.

Thanks again!

Glad you at least got an answer as to why it was happening.

If you come up with a workaround or solution for this, please post your changes and configs here as I think it could be useful for others who may run into this type of thing.

wandererjs's theory is correct.

Once I import the "local" routes from VR-1 to VR-2 on SRX-B, the ping start working.

So I guess like wandererjs said: the ping stop at VR-2 on SRX-B, the VR-2 cannot bind to that address for the ping reply, so it picks the only other address in that VR. By importing that "local" address from VR-1 into VR-2, resolved the issue.

I doubt the explanation from JTAC is 100% correct. (as always)

I think JTAC's statement was technically correct: implementation of static route next-table vs route-import and how it's seen by the ingress routing-instance, just slightly off on how to solve it.

I admit I'm pleased that theory proved itself out, though 🙂

If that had not worked, though, I'm interested in how this would have affected your project.  Do the end users need to ping every endpoint in the path, or is it just something that you noticed while building this out?  In the old, old, days, when L3VPNs were first being deployed, the PE-CE subnet of the remote connection was not reachable by the local hosts without routing off the far CE router.  Now, we have features like vrf-table-label to allow this, and other knobs to help troubleshoot across MPLS clouds (mpls-ttl-propagate), but there are still many ISPs who *may* allow IPs to show up in a traceroute, but will not allow you to intiate traffic to them.

Just curious,

Joel

I was testing host-inbound-traffic, and planning to terminate ike gateway in a VR, but it turned out to be a limitation in JUNOS. I found out that JUNOS ver 11.1 or above start supporting such kind of configuration.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB21423&actp=search&viewlocale=en_US&searchid=1327590132042

---

@Michael_Zhao wrote:

I was testing host-inbound-traffic, and planning to terminate ike gateway in a VR, but it turned out to be a limitation in JUNOS. I found out that JUNOS ver 11.1 or above start supporting such kind of configuration.

 

http://kb.juniper.net/InfoCenter/index?page=content&id=KB21423&actp=search&viewlocale=en_US&searchid=1327590132042

---

Your research is correct.  11.1 supports both dhcp client and IKE termination in a VR, two features I am very fond of for branch office deployments and VPN head-ends for branch offices.