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:
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
------------------------------
Original Message:
Sent: 06-21-2024 02:20
From: Anonymous
Subject: Query on default and static route behaviour
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)