Routing

 View Only
last person joined: 15 hours ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Query on default and static route behaviour

    This message was posted by a user wishing to remain anonymous
    Posted 27 days ago
    This message was posted by a user wishing to remain anonymous

    Team,

    gateway device connected to Juniper device ( not sure directly or not), however i have IP of gateway device. I would like to understand below CLI output to know the connectivity. Please guide.

    show route 172.17.120.234

    inet.0: 58186 destinations, 115651 routes (58185 active, 471 holddown, 1 hidden)
    + = Active Route, - = Last Active, * = Both

    0.0.0.0/0          *[Static/5] 2d 06:39:09, metric2 6000
                        >  to 83.88.16.138 via ae1.0, Push 0

    VRF16036.inet.0: 7163 destinations, 13636 routes (7163 active, 0 holddown, 0 hidden)
    Limit/Threshold: 50000/40000 destinations
    + = Active Route, - = Last Active, * = Both

    0.0.0.0/0          *[BGP/170] 2d 06:38:31, localpref 100, from 195.249.0.80
                          AS path: I, validation-state: unverified
                        >  to 83.88.16.138 via ae1.0, Push 40, Push 16782(top)
                        [BGP/170] 2d 06:38:31, localpref 100, from 195.249.0.81
                          AS path: I, validation-state: unverified
                        >  to 83.88.16.138 via ae1.0, Push 40, Push 16782(top)



  • 2.  RE: Query on default and static route behaviour

    Posted 24 days ago

    I assume that 172.17.120.234 is the gateway ip address you are researching.

    The result is showing that the only route to 172.17.120.234 is the default route.  Which indicates that 172.17.120.234 is NOT directly connected.  If it were then the interface subnet that includes 172.17.120.234 would show up in this request.

    The output shows that the inet0 default route is with interface ae1.0.  This is the main routing table at the base of Junos.

    the virtual router VRF16036 is learning that same default route via BGP from two neighbors 195.249.0.80 and 195.249.0.81 with the first one being the active route for this virtual router table and the second a backup should the first be lost.



    ------------------------------
    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)
    http://puluka.com/home
    ------------------------------



  • 3.  RE: Query on default and static route behaviour

    Posted 24 days ago

    Routing and forwarding functions on Juniper Networks devices have been implemented in a compartmental fashion from the day when Junos OS was conceived, 25 years ago. Compartmental design means that the router is capable of handling multiple parallel routing tables, known as Routing Information Bases (RIBs). When you boot a Juniper device for the first time, you will typically have only one RIB called inet.0, which corresponds to the default routing context of the router. Some people refer to this one as "GRT" (Global Routing Table). Historically, 25 years ago, most vendors had only one routing context and everything happened in there.

    When MPLS was invented, along with MPLS VPNs, the need for multiple routing universes on the same device came to the agenda. So vendors started to think of mechanisms to hold multiple routing tables on the same device, independent from each other. In Junos. this is implemented using routing instances and RIBs. The full explanation of this is provided here. In short:

    • Routing Table (RIB) - is a list of routes, each route being an element having a next-hop IP address and next-hop interface.
    • Routing Instance - is a collection of RIBs together composing a service abstraction (such as MPLS VPN, Virtual Router and so on).

    Vaguely, this concept looks like this:

    Routing Instances and RIBs

    So what you have here are actually two routing tables, both of them containing the default route (0.0.0.0/0). In the default routing instance, the routing table inet.0, containing IPv4 prefixes in the GRT, you have a default route having next-hop (NH) IPv4 address 83.88.16.138 and NH logical interface being ae1.0. By default, all interfaces on the device belong to the default routing instance (GRT), so if a packet enters the router via one of those interface and there is no more specific match of the destination IPv4 address in the RIB inet.0 - the packet will be forwarded to the egress interface ae1.0.

    Otherwise, if the packet enters the router via one of the interfaces assigned into the routing-instance VRF16036, it will follow the default route in that routing instance - i.e. the packet will be forwarded to the NH in that routing table. In your case, it is the same NH address and the same NH interface. However, in that latter case the packet will not be forwarded as a pure IP packet, but rather as an MPLS-labeled packet, since VRF16036 is probably an MPLS L3 VPN. As indicated at the output above, that packet will get two labels on top of the original IPv4 packet - VPN service label (40) and the top-level MPLS transport label 16782. After adding those two labels, the packet is shipped towards the inteface ae1.0 to the next router, which is probably a core (P) router in the network, where the top-level label will be swapped with another label or - in the case of penultimate hop - will be popped etc. Therefore, if your packet enters into the VRF16036 it will follow its way to the egress PE router, while if the packet comes in via the default routing instance it will follow the static route to the P router and then, it will be routed elsewhere.

    Hope this explains things sufficiently for your further troubleshooting.

    Regards,
    Beri



    ------------------------------
    Berislav Todorovic
    ------------------------------