[j-nsp] layer 3 vpn issue
Erdem Sener
erdems at gmail.com
Sun Apr 1 16:18:57 EDT 2007
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:
lab at garfield# show interfaces vt-1/2/0
unit 0 {
description "Servers VRF";
family inet;
}
lab at garfield# show routing-instances test
[output truncated]
interface vt-1/2/0.0;
Cheers,
Erdem
On 4/1/07, Amos Rosenboim <amos at oasis-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: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
> >>>>
> >>
>
> _______________________________________________
> 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