Re: layer 3 vpn issue

Erdem,

Thanks for the information.
The routers in the network currently has no tunnel/services
pic.
The customer will not be too happy to purchase additional
hardware.
Is there any workaround to this limitation which is
configuration  
only and does not require additional hardware?

Regards

Amos

On Apr 1, 2007, at 11:18 PM, Erdem Sener wrote:

> Hi Amos,
>
> As per Harry's suggestion, you may use a vt interface
(you need a
> tunnel or other services pic for that)
>
> If you have a tunnel/services PIC on the box, you can
see a vt-
> interface on 'show interfaces terse' command.
>
> Then all you have to do is configure a unit with family
inet (no ip
> address) and make this interface member of your vrf,
like this:
>
> labgarfield# show interfaces vt-1/2/0
> unit 0 {
>    description "Servers VRF";
>    family inet;
> }
>
> labgarfield# show routing-instances test
> [output truncated]
> interface vt-1/2/0.0;
>
> Cheers,
> Erdem
>
> On 4/1/07, Amos Rosenboim <amosoasis-tech.net> wrote:
>> Harry,
>>
>> Removing the vrf-table-label indeed solved the vrf
connectivity
>> problem, but it re-introduced an old problem for
which I used vrf-
>> table-label in the first place:
>> The problem is that I don't have any CE device, the
PE is directly
>> connected to a servers segment.
>> When I removed vrf-table-label the direct route is
no longer
>> announced in bgp and I get the
>> BGP label allocation failure: Need a nexthop
address on LAN error
>> message.
>> Any suggestion as how to proceed in such
situation?
>>
>> Regards
>>
>> 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:amosoasis-tech.net]
>> >> Sent: Monday, March 26, 2007 9:25 PM
>> >> To: Harry Reynolds
>> >> Cc: juniper-nsppuck.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 "bond
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:
>> >>>
>> >>> regresswiggum> 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]
>> >>> regressnelson# set
label-switched-path r1-r3 install
>> >> 1.23.1.2 active
>> >>>
>> >>> <<< And its now displays an
active route:
>> >>>
>> >>> edit protocols mpls]
>> >>> regressnelson# 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]
>> >>> regressnelson# 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: juniper-nsp-bouncespuck.nether.net
>> >>>> [mailto:juniper-nsp-bouncespuck.nether.net] On Behalf Of Amos
>> >>>> Rosenboim
>> >>>> Sent: Friday, March 23, 2007 8:18
AM
>> >>>> To: juniper-nsppuck.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
>> >>>>
>> >>>>
>> >>>>
>> >>>> 
>> >>>> oasisM10i-THESS1-re0> 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
>> >>>>
>> >>>> 
>> >>>> oasisM10i-THESS1-re0> 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
>> >>>>
>> >>>> 
>> >>>> oasisM10i-THESS1-re0> 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
>> >>>>
>> >>>> 
>> >>>> oasisM10i-THESS1-re0> 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
>> >>>>
>> >>>> 
>> >>>> oasisM10i-THESS1-re0>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
_______________________________________________
>> >>>> juniper-nsp mailing list
juniper-nsppuck.nether.net
>> >>>> 
https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >>>>
>> >>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsppuck.nether.net
>> 
https://puck.nether.net/mailman/listinfo/juniper-nsp
>>

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: layer 3 vpn issue

Thread: Re: layer 3 vpn issue