[j-nsp] layer 3 vpn issue
Harry Reynolds
harry at juniper.net
Tue Mar 27 09:56:38 EST 2007
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