I'm sure you know the set up by now but just in case here is a quick refresh of the basic topology:
laptop --> Cust router --> CPE --> LNS --> Core --> BGP peer --> Laptop
I have the radius assigning an address now to the CPE from a range we are stipulating for the customer. In this test case it is 10.10.10.0/29. The cust router facing the customer laptop is assigned 10.10.10.2/29 and the laptop 10.10.10.3/29. The CPE is allocated 10.10.10.1/29.
I have configured static NAT on the cust router and I can ping 10.10.10.1 from the customer laptop. Okay so far.
Now, on the LNS I can see the route for the 10.10.10.0/29 network as private access (as it should be as it is inside the L2TP tunnel) so I can ping that address from the LNS.
On the core, I have eBGP running to the BGP peer (simulating an upstream ISP) and on the BGP Peer I have configured several loopback interfaces to simulate upstream internet addresses to test ping to.
On the core, I also have iBGP running from loopback to the other core (setup topology replicated to this one). When I look at the routing table on the core I see the following:
Clive@THW-CORE-01# run show route 10.10.10.3
inet.0: 37 destinations, 41 routes (36 active, 0 holddown, 1 hidden)+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 2w1d 05:29:59 Discard
The route 10.10.10.0/29 network will be in the default route as it is a subscriber. Can anyone please tell me why this would show up as Discard please? This is stopping any testing that we can achieve....
Thank you for the response.
I have indeed and I had been reliably informed that the following discard command was required... I have no idea why as I am not an expert with BGP by any means...
set routing-options static route 188.8.131.52/32 next-hop 184.108.40.206set routing-options static route 0.0.0.0/0 discardset routing-options static route 0.0.0.0/0 no-install
So, should I just remove the discard route and test again?
Actually, I have just tried that and I get the following:
Clive@THW-CORE-01# commit check[edit routing-options static] 'route 0.0.0.0/0' next hop(s) not configured for 0.0.0.0/0error: configuration check-out failed
If you want to remove the static 0.0.0.0/0 default route, you need to delete it completely "delete routing-options static route 0.0.0.0/0". Looks like you deleted using "delete routing-options static route 0.0.0.0/0 discard" which will remove only "discard" keyword and that's why you get that commit error.
Also as stated earlier, if you are expected the 10.10.10.0/29 subnet in the Core router to be resolved via this default 0.0.0.0/0 route, then you need to configure a valid next-hop for it. I am not sure about your design, but if you want to reach the BGP, you can point this default route to the BGP peer on Core. Something like this:
set routing-options static route 0.0.0.0/0 next-hop <ip address of the interface pointing towards BGP peer>
Thank you for the solution. This is indeed what I did before seeing this response and we now have everything working.
I had been reliably informed by a "Juniper Expert" (None of you guys) 🙂 ... That this "Discard" command was a requirement. If it is somewhere down the road then I will use it if required.....
Thank you again