Hello,

thanks for your comment!

We are not using a RR at the edge of this scenario but the problem is located on another location.

1. The routes are received from a RR and advertised to one of our core systems.

2. From here the routes are propageted to our iBGP which is IPv6 enabled. All received routes are usable at this location (at the RR). Our other systems, which are getting the prefixes via iBGP aren't able to install the routes into the table inet6.0 - but there is no hint like "unusable next-hop".

Excerpt from the machine connected to the RR:

m...@machine1> show route table inet6.0 2001:7b0::/32

inet6.0: 422 destinations, 424 routes (180 active, 0 holddown, 242 hidden)
+ = Active Route, - = Last Active, * = Both

2001:7b0::/32 *[BGP/170] 3d 09:34:37, MED 101, localpref 100, from 2001:7f8::1a27:5051:c09d
                      AS path: 8881 I
                    > to 2001:7f8::22b1:192:80 via ge-7/1/0.0


Excerpt from the machine meshed in the iBGP:

m...@machine2> show route table inet6.0 2001:7b0::/32 hidden

inet6.0: 184 destinations, 189 routes (37 active, 0 holddown, 147 hidden)
+ = Active Route, - = Last Active, * = Both

2001:7b0::/32 [BGP ] 11:39:05, MED 101, localpref 100, from 2001:4110::fc1
                      AS path: 8881 I
                    > to fe80::214:f6ff:fea4:9df2 via xe-1/2/0.0


Does this help us to get a step forward with this problem?


Thanks in advance,

Hendrik


Am 20.07.2009 um 16:34 schrieb Andy Wu:

are you using RR ? make sure your RR has routes for PE's loopback address in inet.3 table, or inet6.3 table , ( by placing RR in LSP path , or create a static 0/0 route and put into inet.3 / inet6.3 table ) , otherwise RR won't reflect the routes and all IPv6 routes are shown as hidden




On Mon, Jul 20, 2009 at 10:05 AM, Hendrik Kahmann <hendrik.kahm...@ewetel.de > wrote:

Hello,

we have a problem with a IPv6 route in the lab, which is hidden for us. What
could be the reason for that? In the most documents we can only find
information around "next-hop unusable" but this does not seem to be the
reason for us.

Following excerpt has been grabbed from one of our machines:


m...@ourmachine> show route table inet6.0 2001:4178::/32 hidden extensive

inet6.0: 184 destinations, 189 routes (37 active, 0 holddown, 147 hidden)
2001:4178::/32 (1 entry, 0 announced)
        BGP                 /-101
               Next hop type: Indirect
               Next-hop reference count: 147
               Source: xxxx:xxxx::xxx
               Next hop type: Router, Next hop index: 1355
Next hop: xxxx::xxx:xxxx:xxxx:xxxx via xe-1/2/0.0, selected
               Protocol next hop: xxx:xxxx::fc1
               Indirect next hop: fa12958 1048605
               State: <Hidden Int Ext>
               Local AS:  OurAS Peer AS:  OurAS
               Age: 4:50:19    Metric2: 10
               Task: BGP_OurAS.xxx:xxxx::fc1+179
               AS path: 8767 15456 I
               Localpref: 100
               Router ID: x.x.x.x
               Indirect next hops: 1
                       Protocol next hop: xxxx:xxxx::fc1 Metric: 10
                       Indirect next hop: fa12958 1048605
                       Indirect path forwarding next hops: 1
                               Next hop type: Router
                               Next hop: xxxx::xxx:xxx:xxxx:xxxx via
xe-1/2/0.0
                       xxx:xxxx::xxx/128 Originating RIB: inet6.0
Metric: 10 Node path count: 1
                         Forwarding nexthops: 1
                               Nexthop: xxxx::xxx:xxx:xxxx:xxxx via
xe-1/2/0.0


Is there something pointing to a reason or a solution for this?


Kind regards,

Hendrik

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp








_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to