Harry, Thank you very much. It was the vrf-table-label that did this. Where can I find this kind of information (compatibility between a junos feature and specific hw)?
Thanks again, Amos On Mar 27, 2007, at 4:56 PM, Harry Reynolds wrote: > Well, it could be quite a few things now. The only thing that jumps > out > is use of vrf-table-label, which depending on core-facing interface > and > fpc type, may not work. If the router has a tunnel pic I'd suggest > a vt > interface in the vrf. Also, if you can test without AE as pe-ce > interface that may shed some light. > > With latest code vrf-table does not work on agg-sonet for core-facing, > and needs enhanced fpc type for core-facing interface. If the pe-ce > bgp > session is up, and you are learning a route from the ce, you can > usually > forgo vrf-table, if main goal is being able to ping the pe-ce vrf > interface direct route. If you need IP II feature at egress, such > as FW > filters, then you will need vt interface or vrf-table. > > > Might also help to get a capture of show route advertising- > protocol bgp > <pe address> extensive from the problem pe. I'd like to confirm its > advertising the loopback ifl route, and then a show route detail > routing-instance <instance-name> on remote pe to confirm the loopback > route was installed. > > HTHs > > > PS> TE shortcuts explains the ospf route in inet.3 also. RIB groups > are > a way of leaking routes between tables. Not sure te shortcuts are > needed > in your app, but not clear its causing any harm. > > > >> -----Original Message----- >> From: Amos Rosenboim [mailto:[EMAIL PROTECTED] >> Sent: Monday, March 26, 2007 9:25 PM >> To: Harry Reynolds >> Cc: juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] layer 3 vpn issue >> >> Hello Harry, >> >> Thanks for your advice, and sorry it took me so long to respond. >> Initially I was tracing to the addresses of the bgp peers >> themselves but as i understood from your mail that this is a >> mistake I added inet routes to be exchanged between those >> peers. now I trace to destination learned over the bgp >> session and I see the labels. >> >> Regarding the ospf route in inet.3 - I don't know what rib >> groups are, I have ospf traffic engineering shortcuts under >> protocols ospf . >> >> After adding the bgp inet route to the session between the PE >> routers, I can see an active route on the LSP. >> >> However, my main problem, which is connectivity to the VRF on >> that PE remains - I'm still unable to ping anything within >> that VRF from other PE routers. >> >> below is my VRF config and my bgp config: >> >> >> VRF-TESTING { >> description "Test VRF"; >> instance-type vrf; >> interface lo0.501; >> interface ae0.50; >> route-distinguisher 16022:64501; >> vrf-target { >> import target:16022:64501; >> export target:16022:64501; >> } >> vrf-table-label; >> } >> >> >> inactive: group INTERNAL-IBGP { >> type internal; >> local-address 217.69.0.3; >> export ibgp-export; >> peer-as 16022; >> local-as 16022; >> neighbor 217.69.0.2 { >> description "M10i Syggrou"; >> multihop; >> multipath; >> } >> } >> group VPN4-PEERS { >> type internal; >> local-address 217.69.0.3; >> family inet-vpn { >> unicast; >> } >> peer-as 16022; >> local-as 16022; >> neighbor 217.69.0.4 { >> description "Med M10i"; >> } >> neighbor 217.69.0.5 { >> description "London M10i"; >> family inet { >> unicast; >> } >> family inet-vpn { >> unicast; >> } >> export LSP; >> } >> neighbor 217.69.0.2 { >> description "Athens M10i"; >> inactive: multipath; >> } >> } >> >> >> >> Regards >> >> Amos >> >> >> >> On Mar 23, 2007, at 9:49 PM, Harry Reynolds wrote: >> >>> Hello, >>> >>> When you say your "bgp traffic is not taking the lsp", can >> you confirm >>> if you are tracing to the BGP protocol-next-hop address >> itself, or to >>> a bgp destination learned *over* that bgp peering session, >> for which >>> the BGP peering address is present in inet.3 as a LSP next hop? >>> >>> If the former, this is normal. Below you show a route to >> 217.69.0.5, >>> which is the BGP peering address. Can you do a "show route >>> receive-protocol bgp 217.69.0.5, and then trace a route to >> one of the >>> BGP routes learned over that peering address. This trace >> should take >>> the lsp. When a lsp is in inet3 only traffic that resolved >> to a bgp >>> NH matching an inet.3 destination will take the lsp. If you add >>> protocol mpls traffic-engineering bgp-igp, the contents of >> inet.3 are >>> dumped into inet.0, and all traffic can make use of the >> lsp. I note an >>> ospf route is in inet.3 pointing to the lsp. Are you using >> rib groups >>> to place that route into inet.3? >>> >>> As for the active route count deal, I think this is normal for vpn/ >>> inet3 >>> routes but need to investigate further. >>> >>> In a quick l3 vpn setup: >>> >>> >>> Ce1---pe1---p1---pe2---ce2 >>> >>> 10.255.16.46 10.255.16.47 >>> >>> A trace from ce1-ce2 confirms we are taking LSP: >>> >>> [EMAIL PROTECTED]> traceroute 10.255.16.47 source 10.255.16.46 >> traceroute >>> to 10.255.16.47 (10.255.16.47) from 10.255.16.46, 30 hops >> max, 40 byte >>> packets >>> 1 1.1.1.2 (1.1.1.2) 0.833 ms 0.700 ms 0.591 ms >>> 2 1.23.1.2 (1.23.1.2) 0.951 ms 0.919 ms 0.799 ms >>> MPLS Label=100096 CoS=0 TTL=1 S=1 >>> 3 10.255.16.47 (10.255.16.47) 1.144 ms 1.434 ms 1.162 ms >>> >>> But on both Pes, the lsp shows 0 for active routes: >>> >>> >>> 10.255.16.39 >>> From: 10.255.16.36, State: Up, ActiveRoute: 0, LSPname: r1-r3 >>> ActivePath: (primary) >>> LoadBalance: Random >>> Encoding type: Packet, Switching type: Packet, GPID: IPv4 >>> *Primary State: Up >>> SmartOptimizeTimer: 180 >>> Computed ERO (S [L] denotes strict [loose] hops): (CSPF >> metric: 2) >>> 1.12.1.2 S 1.23.1.2 S >>> Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node >>> 10=SoftPreempt): >>> 1.12.1.2 1.23.1.2 >>> Total 1 displayed, Up 1, Down 0 >>> >>> Egress LSP: 1 sessions >>> >>> 10.255.16.36 >>> From: 10.255.16.39, LSPstate: Up, ActiveRoute: 0 >>> LSPname: r3-r1, LSPpath: Primary >>> Suggested label received: -, Suggested label sent: - >>> Recovery label received: -, Recovery label sent: - >>> Resv style: 1 FF, Label in: 3, Label out: - >>> Time left: 154, Since: Fri Mar 23 12:39:41 2007 >>> Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 >>> Port number: sender 1 receiver 47017 protocol 0 >>> PATH rcvfrom: 1.12.1.2 (so-0/0/0.0) 10 pkts >>> Adspec: received MTU 1500 >>> PATH sentto: localclient >>> RESV rcvfrom: localclient >>> Record route: 1.23.1.2 1.12.1.2 <self> Total 1 displayed, >> Up 1, Down >>> 0 >>> >>> Transit LSP: 0 sessions >>> Total 0 displayed, Up 0, Down 0 >>> >>> <<< I tried manually adding a prex as active, which means >> it will be >>> in inet.0 and pointing to the lsp: >>> >>> [edit protocols mpls] >>> [EMAIL PROTECTED] set label-switched-path r1-r3 install >> 1.23.1.2 active >>> >>> <<< And its now displays an active route: >>> >>> edit protocols mpls] >>> [EMAIL PROTECTED] run show route 1.23.1.2 >>> >>> inet.0: 23 destinations, 24 routes (22 active, 0 holddown, 1 hidden) >>> + = Active Route, - = Last Active, * = Both >>> >>> 1.23.1.2/32 *[RSVP/7] 00:00:33, metric 2 >>>> via so-0/0/0.0, label-switched-path r1-r3 >>> >>> [edit protocols mpls] >>> [EMAIL PROTECTED] run show mpls lsp detail ingress Ingress LSP: 1 >>> sessions >>> >>> 10.255.16.39 >>> From: 10.255.16.36, State: Up, ActiveRoute: 1, LSPname: r1-r3 >>> ActivePath: (primary) >>> LoadBalance: Random >>> Encoding type: Packet, Switching type: Packet, GPID: IPv4 >>> *Primary State: Up >>> SmartOptimizeTimer: 180 >>> Computed ERO (S [L] denotes strict [loose] hops): (CSPF >> metric: 2) >>> 1.12.1.2 S 1.23.1.2 S >>> Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node >>> 10=SoftPreempt): >>> 1.12.1.2 1.23.1.2 >>> Total 1 displayed, Up 1, Down 0 >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] On Behalf Of Amos >>>> Rosenboim >>>> Sent: Friday, March 23, 2007 8:18 AM >>>> To: juniper-nsp@puck.nether.net >>>> Subject: [j-nsp] layer 3 vpn issue >>>> >>>> Hi >>>> >>>> I have configured an network of 4 M10i routers for mpls using RSVP >>>> for label distribution. >>>> the topology is as follows: >>>> >>>> R1----E3 line----R2----Ethernet----R3-----3xE1----R4 >>>> >>>> I have configured a test VRF on all 4 routers and associated a >>>> loopback unit in each router to the test VRF. >>>> I have ping between all loopbacks inside the VRF on R1,R2 >> and R3, but >>>> not to R4. >>>> >>>> My LSP seems to be working (show mpls lsp on R4 shows all >> LSP are up, >>>> and I get successful MPLS ping using the ping mpls rsvp command). >>>> However, when I use the show mpls lsp detail command I see >> the lsp as >>>> up, but active routes is 0. >>>> >>>> Also when I'm tracing to the remote PE I don't see any >> labels on the >>>> trace. I believe that my BGP traffic does not use the LSP as the >>>> egress point towards the remote PE, although the RSVP route is the >>>> preferred route in inet.3 >>>> >>>> Below are some show commands from R4. any help would be >> appreciated. >>>> >>>> >>>> Regards >>>> >>>> >>>> Amos >>>> >>>> >>>> >>>> {master} >>>> [EMAIL PROTECTED]> show mpls lsp >>>> Ingress LSP: 3 sessions >>>> To From State Rt ActivePath P >>>> LSPname >>>> 217.69.0.2 217.69.0.3 Up 0 * TO- >>>> ATH-FROM-THESS >>>> 217.69.0.4 217.69.0.3 Up 0 * TO- >>>> MED-FROM-THESS >>>> 217.69.0.5 217.69.0.3 Up 0 * TO- >>>> LND-FROM-THESS >>>> Total 3 displayed, Up 3, Down 0 >>>> >>>> Egress LSP: 3 sessions >>>> To From State Rt Style Labelin Labelout >>>> LSPname >>>> 217.69.0.3 217.69.0.5 Up 0 1 FF 3 >> - TO- >>>> THESS-FROM-LND >>>> 217.69.0.3 217.69.0.2 Up 0 1 FF 3 >> - TO- >>>> THESS-FROM-ATH >>>> 217.69.0.3 217.69.0.4 Up 0 1 FF 3 >> - To- >>>> THESS-FROM-MED >>>> Total 3 displayed, Up 3, Down 0 >>>> >>>> Transit LSP: 0 sessions >>>> Total 0 displayed, Up 0, Down 0 >>>> >>>> {master} >>>> [EMAIL PROTECTED]> show mpls lsp name TO-LND-FROM-THESS detail >>>> Ingress LSP: 3 sessions >>>> >>>> 217.69.0.5 >>>> From: 217.69.0.3, State: Up, ActiveRoute: 0, LSPname: >>>> TO-LND-FROM- THESS >>>> ActivePath: (primary) >>>> LoadBalance: Random >>>> Encoding type: Packet, Switching type: Packet, GPID: IPv4 >>>> *Primary State: Up >>>> SmartOptimizeTimer: 180 >>>> Computed ERO (S [L] denotes strict [loose] hops): >> (CSPF metric: >>>> 524) >>>> 217.69.0.133 S 217.69.0.70 S 217.69.0.130 S >>>> Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node >>>> 10=SoftPreempt): >>>> 217.69.0.133 217.69.0.70 217.69.0.130 Total 1 >> displayed, >>>> Up 1, Down 0 >>>> >>>> Egress LSP: 3 sessions >>>> Total 0 displayed, Up 0, Down 0 >>>> >>>> Transit LSP: 0 sessions >>>> Total 0 displayed, Up 0, Down 0 >>>> >>>> {master} >>>> [EMAIL PROTECTED]> show bgp summary >>>> Groups: 1 Peers: 3 Down peers: 0 >>>> Table Tot Paths Act Paths Suppressed History Damp >>>> State Pending >>>> bgp.l3vpn.0 8 8 0 0 >>>> 0 0 >>>> Peer AS InPkt OutPkt OutQ >> Flaps Last Up/ >>>> Dwn State|#Active/Received/Damped... >>>> 217.69.0.2 16022 45274 45287 0 1 >>>> 2w1d16h Establ >>>> bgp.l3vpn.0: 5/5/0 >>>> VRF-TESTING.inet.0: 2/2/0 >>>> VRF-THESS.inet.0: 3/3/0 >>>> 217.69.0.4 16022 45248 45272 0 1 >>>> 2w1d16h Establ >>>> bgp.l3vpn.0: 0/0/0 >>>> 217.69.0.5 16022 20450 20437 0 4 >>>> 1w0d2h Establ >>>> bgp.l3vpn.0: 3/3/0 >>>> VRF-TESTING.inet.0: 2/2/0 >>>> VRF-THESS.inet.0: 1/1/0 >>>> >>>> {master} >>>> [EMAIL PROTECTED]> show route 217.69.0.5 >>>> >>>> inet.0: 129 destinations, 172 routes (128 active, 0 holddown, >>>> 1 hidden) >>>> + = Active Route, - = Last Active, * = Both >>>> >>>> 217.69.0.5/32 *[OSPF/10] 1d 01:32:15, metric 54 >>>> via e1-1/3/0.0 >>>> via e1-1/3/2.0 >>>>> via e1-1/3/4.0 >>>> [IS-IS/169] 1d 01:32:15, metric 544 >>>>> to 217.69.0.133 via e1-1/3/0.0 >>>> to 217.69.0.145 via e1-1/3/2.0 >>>> to 217.69.0.149 via e1-1/3/4.0 >>>> >>>> inet.3: 109 destinations, 112 routes (109 active, 0 holddown, 0 >>>> hidden) >>>> + = Active Route, - = Last Active, * = Both >>>> >>>> 217.69.0.5/32 *[RSVP/7] 1d 01:32:20, metric 54 >>>>> via e1-1/3/0.0, label-switched-path >>>> TO-LND- FROM-THESS >>>> [OSPF/10] 1d 01:32:20, metric 54 >>>>> via e1-1/3/0.0, label-switched-path >>>> TO-LND- FROM-THESS >>>> >>>> {master} >>>> [EMAIL PROTECTED]> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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