Hi Ylara,
Thank for you the elaborate explanation.
To me the routing looks sound, i picked out the routes involved down below thats being leaked between the instances.
root@JKP-SW01> show route table inet.0
inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 00:00:25, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.31/32 *[Direct/0] 6w3d 12:41:57
> via lo0.1
101-Data.inet.0: 300 destinations, 300 routes (300 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 2d 15:14:47, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.0/24 *[OSPF/150] 2d 15:15:02, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.2/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.4/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.20/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.21/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.22/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.23/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.24/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.25/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.26/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.27/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.29/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.30/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.31/32 *[Direct/0] 00:01:05
> via lo0.1
10.250.250.32/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.33/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.34/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.35/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.36/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.37/32 *[OSPF/150] 5d 04:21:49, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.38/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.39/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.40/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.41/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.42/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.43/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.44/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.45/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.46/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.47/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.49/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.50/32 *[OSPF/150] 10:36:05, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.51/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.52/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.53/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.55/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.57/32 *[OSPF/150] 5d 09:50:43, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.250.250.61/32 *[OSPF/150] 3d 03:24:35, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
10.255.255.0/24 *[OSPF/150] 2d 15:15:02, metric 100, tag 3301
> to 10.99.93.17 via vlan.111
I'm having issues with the complexity of the other solutions, the third option with rib-groups is what i basically had before but i wanted a consistant solution for all sites since the 'next-table' doesnt seem to be available for the EX3300 even tough it has the latest version.
{master:0}
root@JKP-SW01> show configuration |display set |grep version
set version 15.1R7.9
{master:0}[edit]
root@JKP-SW01# set routing-options static route 0.0.0.0/0 next-?
Possible completions:
+ next-hop Next hop to destination
Could i get some help with the firewall filters?
I cant seem to figure out what 'then' option needs to be used:
[edit]
+ firewall {
+ family ethernet-switching {
+ filter "From lo0.1" {
+ term "Route to Data-101" {
+ from {
+ destination-address {
+ 0.0.0.0/0;
+ }
+ }
+ }
+ }
+ }
Also an example with the logical interfaces would be much appreaciated..
------------------------------
Andreas
------------------------------
Original Message:
Sent: 11-19-2020 14:29
From: Yasmin Lara
Subject: lo0 inteface responds on every other TTL ex 6,8,10,12...etc
From what I am understanding is not that you are not reaching the loopback but that you have to increase the TTL to get to it. That sounds like extra hops are being introduced to the path. Maybe because of the way you are leaking the routes and distributing the routing information to other devices. Have you try traceroute or simply checking the routing tables along the path, to see how the packets are being forwarded?
You can try what Ben suggested: removing the leaking and directing packets from one table to the other. However, you cannot configure next-table in both directions. Junos prevents you from doing that to avoid loops. You can instead use a firewall filter to direct traffic arriving at one table to the other table (in one direction), and using next-table in the other direction . Something like this:
The firewall filter option can be used in both directions as well. I read in one of your replies that next-table might not be available (I am actually surprised).
Another option is to use an lt interface to connect the two tables, and then use static routes to point to the other end of the lt interface. You could also use a routing protocol and control which routes get advertised between tables using routing policies.
You could also use rib-groups to share the interfaces to reach certain destinations, though you still need either next-table or a FF to direct the return traffic.
Regards,
------------------------------
Yasmin Lara
Juniper Ambassador
JNCIE-SP, JNCIE-ENT, JNCIE-DC, JNCIE-SEC
JNCDS-DC, JNCIA-DevOps, JNCIP-CLOUD, CCNP-ENT
Original Message:
Sent: 11-19-2020 00:27
From: BEN DALE
Subject: lo0 inteface responds on every other TTL ex 6,8,10,12...etc
Hi Andreas,
Can you perhaps provide a diagram?
Just so I'm clear:
- You have an EX33/3400s at each site
- The gateway out of each site is inside a routing-instance
- You have a loopback in inet.0 which is being leaked into the instance with your gateway and the gateway is being leaked back into inet.0
- When you ping from some central location to each of the 33/3400s, they all respond except for 3
- Of the 3 that don't respond, you can make them respond by changing the TTL on your pings
1. Can you ping the lo0.0 interface address that is already inside the routing-instance with the gateway in it at all sites? Can you try adjusting the TTL to 10 and 11 and seeing if you can still ping it? If you still get the TTL expired in transit, then it is likely that the problem is with your ISP gateway device.
2. If you can ping it, try removing the route-leaking configuration and instead try something like:
set routing-options static route 0.0.0.0/0 next-table <routing-instance.inet.0>
set routing-instances <routing-instance> routing-options static route <x.x.x.x> next-table inet.0
on one of the sites and see if that fixes the issue (where x.x.x.x is the /32 on lo0.1)
------------------------------
Cheers,
Ben Dale
JNCIE-SEC #63
JNCIP-SP
JNCIP-ENT
JNCIP-DC
Original Message:
Sent: 11-18-2020 09:31
From: Andreas
Subject: lo0 inteface responds on every other TTL ex 6,8,10,12...etc
Hello,
In our environment all vlans and interfaces are tagged to a routing-instance on our EX3300-3400's depending on if its a DATA or Guest network to the ISP's Guest or Data VLAN, to be able to perfom host services as ftp/ntp/dns and such i need an interface in the master-instance as the lo0.0 is tagged to vlan DATA for instance.
So i created an lo0.1 interface in master instance with an IP and leaked the default route from <Name> routing-instance into the master instance and the route to lo0.1 into the <Name> routing-instance. and exported out to our ISP's routers with OSPF.
This works on 57/60 sites, im currently investigating a site that responds to ICMP if i alter the TTL, so if there are 5 hops i can ping it on every uneven number from TTL 7, if there are 6 hops i can ping on every even number from TTL 6.
Example with 6 hops to the EX3400:
ping 10.250.250.31 -i 10
Pinging 10.250.250.31 with 32 bytes of data:
Reply from 10.250.250.31: bytes=32 time=30ms TTL=58
ping 10.250.250.31 -i 11
Pinging 10.250.250.31 with 32 bytes of data:
Reply from <ISP ROUTER>: TTL expired in transit.
Does anyone have any clue how this could happen?
If i set up a monitor the ICMP doesnt reach the EX3400 when i get a TTL expired from the ISPs router.
All the routes are present and our ISP can see the routes in their OSPF, everything is working well on the other sites.
Regards
Andreas
------------------------------
Andreas
------------------------------