The MPLS WG Archive

["Alexander Marhold" <alexander@marhold.at>]

see inline comments

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Paul
Billinghurst
>Sent: Sunday, April 29, 2001 10:23 PM
>To: 'mpls@UU.NET'
>Subject: Use of NSSAs & Stub areas with downstream unsolicited LDP
>
>Can anyone verify or correct my understanding of the following scenario.
The
>MPLS domain is LDP, configured as downstream unsolicited. When I use the
>term ABR - I am referring to the ABR of the stub or NSSA area unless I
state
>differently.
>
>A router internal to a stub or NSSA potentially will only have an
>advertisement from ABRs for the default route. If routers internal to the
>stub area wish to reach destinations for which they do not have a FEC entry
>then they will have to send the data unlabelled to the ABR. Is that correct
>?
------------->
 no a default route is also a FEC, so it sends the labelled packet to the
ABR.
But this LSP ends at the ABR, which did the summarization.
But the ABR has to do a L3 lookup, so he needs a full routing table also for
routes external to the cloud.
So if the ABR runs the full BGP routing table this works for MPLS ( not for
VPN)

However this does not work for MPLS/VPN as the packet itself with only SA
and DA is not unique and the according destination and the correct VPN
cannot be determined
---------------->
But you can cheat the system and make it run, I just tested the thing today
with
Cisco IOS 12.1.5T and it worked perfectly:
---------------->
If you make the ABR also a RR for vpnv4 (MP-BGP) and you specify
NEXT_HOP_SELF
then this node will swap the vpn label , leaving the vpnspecific information
okay and the packet can be correctly sent to the destination.
For your OSPF multiarea topology you only need to additonally define 2
loopback interfaces ( one in each area ) on the ABR and use the correct ones
for the MP-iBGP connections, so that the MP-BGP connection is always within
an area.
The mechanisms used are the same needed for MPLS/VPN in confederations or
for interprovider VPNs.

This works exactly like MPLS/VPN in a confederation environment with various
IGP domains.

I tested this and these are the positive results:
the only difference is that I did not have 2 IGPs running ( so no ABR) but
when specifying things as explained above it should also work:

CE1------PE3-----GSR1-----GSR2----PE2----CE6
cust        label    label    label     cust
                  RR
              = domainedge

CE1: Tracing the route to 194.10.10.54 (=CE6)

PE3   1 195.10.10.85 [AS 100] 16 msec 16 msec 16 msec
GSR1  2 193.10.10.77 [MPLS: Label 25 Exp 0] 200 msec 196 msec 196 msec
GSR2  3 193.10.10.66 [MPLS: Labels 17/27 Exp 0] 184 msec 184 msec 184 msec
PE2   4 195.10.10.73 [AS 100] [MPLS: Label 27 Exp 0] 164 msec 344 msec 160
msec
CE6   5 195.10.10.74 [AS 100] 72 msec *  76 msec

(note the penultimate hop-popping)

--- this is the VPN-label table on the domain-edge GSR1

WG1-GSR1#sho ip bgp vpnv4 all tag
   Network          Next Hop      In tag/Out tag
Route Distinguisher: 100:1
   11.0.0.0/24      194.10.10.45    23/26
   12.0.0.0/24      194.10.10.44    22/16
   194.10.10.48/32  194.10.10.45    27/27
   194.10.10.54/32  194.10.10.44    25/27  <--- this is the swap of
vpn-label
   195.10.10.72/30  194.10.10.44    24/26
   195.10.10.84/30  194.10.10.45    26/16

WG1-GSR1#show tag for
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Pop tag     194.10.10.45/32   0          Se1/0      point2point
17     Pop tag     194.10.10.42/32   0          Se1/3      point2point
18     17          194.10.10.44/32   0          Se1/3      point2point
19     Pop tag     193.10.10.68/30   0          Se1/3      point2point
20     Pop tag     193.10.10.72/30   0          Se1/3      point2point
21     Pop tag     193.10.10.96/30   0          Se1/3      point2point
22     17          100:1:12.0.0.0/24    \
                                     1228       Se1/3      point2point
23     26          100:1:11.0.0.0/24    \
                                     744        Se1/0      point2point
24     17          100:1:195.10.10.72/30    \
                                     0          Se1/3      point2point
25     17          100:1:194.10.10.54/32    \
                                     456        Se1/3      point2point
26     16          100:1:195.10.10.84/30    \
                                     0          Se1/0      point2point
27     27          100:1:194.10.10.48/32    \
                                     1724       Se1/0      point2point

this is the MP-BGP table on PE3 (notice the next-hop of 194.10.10.41 which
is the GSR)

WG1-PE3#sho ip bgp vpnv4 all tag
   Network          Next Hop      In tag/Out tag
Route Distinguisher: 100:1 (vpn)
   11.0.0.0/24      0.0.0.0         26/aggregate(vpn)
   12.0.0.0/24      194.10.10.41    notag/22
   194.10.10.48/32  195.10.10.86    27/notag
   194.10.10.54/32  194.10.10.41    notag/25
   195.10.10.72/30  194.10.10.41    notag/24
   195.10.10.84/30  0.0.0.0         16/aggregate(vpn)

>Is there any mechanism short of static routes which would allow the stub
>area router(s) to use an LSP to the default route which
>I assume would be pretty dangerous to use because if there is a default
>route across the OSPF domain and that LSP is used, then all data from stubs
>or NSSA would use that LSP whereas the ABRs could make far more intelligent
>routing decisions if they were not simply swapping labels for the default
>route.

I think the above example solves such a problem, for BGP and MPLS/VPN
but generally a stub area is a stubarea and has no optimal interarea routing
!!!

>If use of a default route LSP is possible, is there a mechanism which would
>allow an ABR, to pop the label instead of swapping and making that
>"intelligent decision" if indeed it does have default route LSP which
>extends beyond itself into the domain, but it would be better served
sending
>the data on an LSP for which it has a more direct FEC entry.

the only important thing is that for external routes in MPLS/VPN you are not
allowed to summarize the NEXT-HOP address, so using the above stated trick
you stay on next-hop addresses whithin each area and have no problem about
summarization of this address.

By the way this also proofs that the statement in Pepelnjaks and Guichards
book "MPLS and VPN architectures" page 280 is not true (anymore): they
stated in the book that the next-hop cannot be changed on a route-reflector
and they say that you would need confederations where the confed boundary
matches the OSPF area boundaries, which would be another more complicated
way of solving the problem as for OSPF the boundary is withina node and for
BGP it is between nodes (like in ISIS).


with best regards

Alexander

__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
     __/
    __/   Dipl.Ing. Alexander Marhold MBA
   __/   CCIE #3324, CCNP, CCNA, CCDP, CCDA, CCSI #20642
  __/   PRO IN <Senior Consultant, PM and Trainer>
 __/   Mobile: ++43-(0)664-16 28 234
__/