Routing

Expand all | Collapse all

lo0 inteface responds on every other TTL ex 6,8,10,12...etc

  • 1.  lo0 inteface responds on every other TTL ex 6,8,10,12...etc

    Posted 10 days ago

    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
    ------------------------------


  • 2.  RE: lo0 inteface responds on every other TTL ex 6,8,10,12...etc

     
    Posted 9 days ago
    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
    ------------------------------



  • 3.  RE: lo0 inteface responds on every other TTL ex 6,8,10,12...etc

    Posted 9 days ago
    Hi Bdale, thanks for you reply!
    Yes to your statements.
    This is only the case found for 1/3 devices so far.
    Qiuck description, lo0.1 only exists in master-instance on each EX3400 and is not linked to main routing-instance 101, as said it has routes imported inbetween and then exported to the OSPF to get routes.
    set policy-options policy-statement "Master to 101-Data" term 1 from instance master
    set policy-options policy-statement "Master to 101-Data" term 1 from route-filter 10.250.250.0/24 upto /32
    set policy-options policy-statement "Master to 101-Data" term 1 then accept
    set policy-options policy-statement "Master to 101-Data" term 2 then reject
    set policy-options policy-statement "101-Data to Master" term 1 from instance 101-Data
    set policy-options policy-statement "101-Data to Master" term 1 from route-filter 0.0.0.0/0 exact
    set policy-options policy-statement "101-Data to Master" term 1 then accept
    set policy-options policy-statement "101-Data to Master" term 2 then reject
    set routing-instances 101-Data routing-options instance-import "Master to 101-Data"
    set routing-instances 101-Data protocols ospf export "Master to 101-Data"
    set routing-options instance-import "101-Data to Master"
    Problem site: H2
    Working site:H3
    VPN: H1
    H1 can ping H2's EX3400 in the 10.250.250.X/32 IP since it has 6 hops instead of 5, it can only ping on even TTL's 6,8,10,12 etc
    H3 can not ping H2's EX3400 in the 10.250.250.X/32 IP since it has 5 hops, it can however ping on uneven TTL's 7,9,11,13,15 etc
    H1,H2,H3 can ping H3's EX3400 in the 10.250.250.X/32 IP on any TLL.

    Your questions:

    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.
    That works fine on both.

    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
    This doesnt seem to solve my issue with the sites that are on for EX3300 (which is this peticulary site) so i cant even test it on this issue...
    In what release of JunOS does it include "next-table" ? 
    Current: JUNOS EX Software Suite [15.1R7.9]


    ------------------------------
    Andreas
    ------------------------------



  • 4.  RE: lo0 inteface responds on every other TTL ex 6,8,10,12...etc

     
    Posted 8 days ago
    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
    ------------------------------



  • 5.  RE: lo0 inteface responds on every other TTL ex 6,8,10,12...etc

    Posted 5 days ago

    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
    ------------------------------