2

I've got a somewhat basic iBGP configuration with a routing instance "global" between two Juniper vSRX's - each Juniper vSRX has an uplink of its own from a different transit provider with a default route. The iBGP within the routing instance "global" works as expected, failing over nicely between the two.

However, when adding another routing instance into play, let's say "client-1" with a default route with a next-table of "global.inet.0" traffic does not flow when ingressing or egressing through the other vSRX.

Outbound is sort of fine, because I can put equal preference on the routes out via iBGP and the local transit, but obviously inbound is beyond my control - so in the example below if Transit 2 was my inbound route 1.2.3.4 would not be pingable but 1.2.3.5 would be.

Example

I've checked the basics such as host-inbound stanzas on the security zones, global ping is enabled, etc.

When pinging 1.2.3.4 and Transit 2 is the inbound route in the example, vSRX 1 can see the ping packets arriving (the correct place) but no ICMP response is given:

vsrx2# run show security flow session destination-prefix 1.2.3.4/32    
Session ID: 289005, Policy name: self-traffic-policy/1, Timeout: 6, Valid
  In: home.ip/2103 --> 1.2.3.4/31;icmp, Conn Tag: 0x0, If: ge-0/0/2.203, Pkts: 1, Bytes: 60, 
  Out: 1.2.3.4/31 --> home.ip/2103;icmp, Conn Tag: 0x0, If: .local..7, Pkts: 0, Bytes: 0, 
Total sessions: 1

Interestingly, a loopback on vSRX 1 in this case that sits in the "global" routing instance, with the route in via Transit 2 is reachable.

Any ideas why the ping packets arrive in the right place, but do not get a response?

Improve this question
1
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin ♦
    Dec 25, 2018 at 10:10

1 Answer 1

Reset to default
2

Outbound traffic is jumping between isolated routing-instances with your next-table policy - do you have a return route to 1.2.3.0/26 in inet.0 in vsrx2 (and vice-versa) with a next-table client-1.inet.0? Do you have a more specific route for 1.2.3.4 on vsrx2 with a next-hop of vsrx1?

Otherwise, I don't think this is going to work - specifically for the SRX interface addresses - if I'm not mistaken, return traffic via vsrx2 is going to see a static route for 1.2.3.0/26 with a next-table of client-1.inet.0 and try and egress locally (which will break the flow).

I'm a bit confused by your flow output on vsrx2 though - according to your diagram, 1.2.3.4 is on vsrx1, but the flow output says that it's from vsrx2 and shows a return interface of local (suggesting that the destination address 1.2.3.4 is an IP owned by vsrx2) - I would expect to be seeing the logical interface between vsrx2 and vsrx1 instead?

Improve this answer
3
  • Thanks Benjamin, there are return routes to pull the subnet into the correct routing instance with instance-import's. 1.2.3.0/26 has a route to the interface (which maps to the client-1 instance). I'm not sure it is possible to add a more specific route, because I can't think of what to reference the next-hop / next-table as? Also, adding that would mean if it was flipped and the inbound route is over the other transit, I'd have the same problem.
    – notFound
    Dec 6, 2018 at 23:01
  • I've also just tried to debug by bringing the interface into the "global" routing instance - it has the same problem. The active route is over vsrx1, pinging the address on vsrx1 is fine, but pinging the vsrx2 address isn't fine. It does work if I bring the "client-1" interface into the same security zone as the transit / iBGP. The security policies and zones are identical on both vSRX's.
    – notFound
    Dec 6, 2018 at 23:06
  • Can you update the question and attach the flow session from both nodes when you have the active route over vsrx1 and try to ping the interface address on vsrx2?
    – Benjamin Dale
    Dec 7, 2018 at 2:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.