[j-nsp] layer 3 vpn issue
Amos Rosenboim
amos at oasis-tech.net
Sun Apr 1 15:36:07 EDT 2007
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:amos at oasis-tech.net]
>> Sent: Monday, March 26, 2007 9:25 PM
>> To: Harry Reynolds
>> Cc: juniper-nsp at 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:
>>>
>>> regress at wiggum> 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]
>>> regress at nelson# set label-switched-path r1-r3 install
>> 1.23.1.2 active
>>>
>>> <<< And its now displays an active route:
>>>
>>> edit protocols mpls]
>>> regress at nelson# 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]
>>> regress at nelson# 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-bounces at puck.nether.net
>>>> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Amos
>>>> Rosenboim
>>>> Sent: Friday, March 23, 2007 8:18 AM
>>>> To: juniper-nsp at 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}
>>>> oasis at M10i-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
>>>>
>>>> {master}
>>>> oasis at M10i-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
>>>>
>>>> {master}
>>>> oasis at M10i-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
>>>>
>>>> {master}
>>>> oasis at M10i-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
>>>>
>>>> {master}
>>>> oasis at M10i-THESS1-re0>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>
More information about the juniper-nsp
mailing list