We hit a weird issue recently where the FPC and routing table do not
agree on the nexthop for a route:
> show route 68.232.191.191
68.232.191.0/24 *[BGP/170] 6d 23:14:33, localpref 100, from xxxx
AS path: 64515 64514 I, validation-state: unverified
> to 10.65.1.90 via irb.522
FPC0( vty)# show route ip lookup 68.232.191.191
Route Information (68.232.191.191):
interface : irb.35 (681)
Nexthop prefix : 4.7.18.205
Nexthop ID : 2688
MTU : 0
Class ID : 0
The FPCs are ultimately just using the default route, it seems like they
didn't actually manage to program this /24.
Is there any graceful way of recovering from this state? Restarting the
routing process didn't seem to do anything, and we ultimately ended up
switching over to the other routing engine, which reloaded the PFE and
resolved the issue (but that interrupted traffic for a bit)
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
agree on the nexthop for a route:
> show route 68.232.191.191
68.232.191.0/24 *[BGP/170] 6d 23:14:33, localpref 100, from xxxx
AS path: 64515 64514 I, validation-state: unverified
> to 10.65.1.90 via irb.522
FPC0( vty)# show route ip lookup 68.232.191.191
Route Information (68.232.191.191):
interface : irb.35 (681)
Nexthop prefix : 4.7.18.205
Nexthop ID : 2688
MTU : 0
Class ID : 0
The FPCs are ultimately just using the default route, it seems like they
didn't actually manage to program this /24.
Is there any graceful way of recovering from this state? Restarting the
routing process didn't seem to do anything, and we ultimately ended up
switching over to the other routing engine, which reloaded the PFE and
resolved the issue (but that interrupted traffic for a bit)
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp