[j-nsp] layer 3 vpn issue
Harry Reynolds
harry at juniper.net
Sun Apr 1 17:08:39 EDT 2007
Well, back before all this high-faluten vrf-table and vt interface stuff
the fix was a static route pointed to the CE device. The static has to
be more specific than the pe-ce subnet, else the direct route will be
active keeping the static from being advertised. I can't recall now if
the static will suffice to get the pe-ce direct also advertised, but
think that it does count as "having learned a route from the ce". Back
in the day we would be happy to see the static go out and did not seem
to worry about the direct.
As long as you do not have /30 addressing on the pe-ce link, try it:
10.0.1/24
Pe--------ce
.1 .2
<< On pe, in vrf, under routing-options:
Static route 10.0.0.0.30 next-hop 10.0.1.2
Then have a vrf-export policy that advertises the static. Possible that
vrf-export will work and also advertise the direct. Let us know, and
HTHs
> -----Original Message-----
> From: Amos Rosenboim [mailto:amos at oasis-tech.net]
> Sent: Sunday, April 01, 2007 1:41 PM
> To: Erdem Sener
> Cc: Harry Reynolds; juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] 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:
> >
> > 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