RE: MPLS Backbone over Frame-Relay Issues

Bryan gets the gold star for today hehe : ) The issue was my OSPF in the
frame cloud. as soon as I made the ospf network type point/multipoint , I
got /32 host routes for the other spokes and boom..damnit! the little
things.hehe

Regards,

Joe Astorino
CCIE #24347 (R&S)
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com
  

From: Bryan Bartik [mailto:bbartik_at_ipexpert.com]
Sent: Monday, June 15, 2009 10:48 AM
To: Joe Astorino
Cc: PANDI MOORTHY; CCIE Groupstudy
Subject: Re: MPLS Backbone over Frame-Relay Issues

Joe,

Change you network to point-to-multipoint so you get /32 routes for each
end.

On Mon, Jun 15, 2009 at 8:02 AM, Joe Astorino <jastorino_at_ipexpert.com>
wrote:

Hey Pandi,

First, let me clarify something, as I did make a small typo in my original
post. R2, R4, and R5 are all PE routers and also are frame-relay spokes.
R6 is a P router, is only running MPLS (no BGP) , and is the frame-relay
hub. As far as frame-relay and OSPF go, everything is default. All the
frame-relay routers are using just a physical interface, and the OSPF
network type is non-broadcast. I have frame maps on all the frame routers
with the broadcast parameter. Maybe that will point out my issue. I was
thinking it might have something to do with using physical interfaces
instead of separate sub-interfaces? Thanks for your help.

Regards,

Joe Astorino
CCIE #24347 (R&S)
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com

From: PANDI MOORTHY [mailto:moorthypandi_at_gmail.com]
Sent: Monday, June 15, 2009 4:47 AM
To: Joe Astorino
Cc: CCIE Groupstudy
Subject: Re: MPLS Backbone over Frame-Relay Issues

HI Joe Astorino

I understood your lab design.

I think MP-iBGP behave correctly, R2 should see the R4 and R6 as the
next-hop for the routes learned from VPN-A and B

I assume the LDP work perfectly

How is the fram-rely setup, are you using the point-to-point connection
between the hub and spokes. Is the ospf configured as point-to-point network
type?

What is the output show mpls forwarding-table at R2, R4 and R6

At R2 you should see the outgoing labels for R4 and R6 loopback IP, same
thing for R4 and R6 you should see the labels for other PEs

Do debug mpls packets at R6, and then try to ping from one site to other
remote site. you should see the MPLS packet pass through R6

If you can send us the config of all router, that would be great

Regards

Pandi

On Mon, Jun 15, 2009 at 3:54 PM, Joe Astorino <jastorino_at_ipexpert.com>
wrote:

Hey guys, I am hoping somebody can help me understand a bit of an issue I am
having. I am actually just starting out learning MPLS and MPLS VPN
technology, and set out to give it a go tonight in the lab. I have 4
routers connected in a frame-relay hub/spoke topology: R2, R4, R5, R6 with
R6 being the hub. Each spoke router only has a PVC to the hub router, R6,
so any spoke to spoke connectivity will have to pass through R6. For my
MPLS VPN experiment, I wanted the R2,R4,R5 frame routers to be PEs.
Additionally, so that I could fully experiment with a MPLS "cloud" I needed
a P router...since R6 is my frame-relay hub, and all traffic through the
MPLS cloud has to go through it, I figured R6 would be a fine P router.

Off of R2 I have 2 VPNs, one on each fastethernet interface. I call them
VPNA and VPNB (how creative hehe). Off of R4, I have a VPNA CE router. Off
of R5, I have a VPNB CE Router. The CE/PE IGP is RIPv2. Inside of my
frame-relay cloud, I am running OSPF.

Next, I setup MP-BGP between the PE routers, using R2 as a RR. I did the
mutual redistribution into MP-BGP / RIP and everything appeared to be
fine...I could see the proper routes in on all my VPN routers! Awesome.

The problem came when I actually tried to ping...<sigh>. After a long night
of troubleshooting I actually did find the issue, but don't know how to
solve it yet. If I try to ping from a VPNA CE router across the MPLS to
reach one on the other side, it fails. The reason it fails is this from
what I can tell: R2/R5/R6 are all learning the vpnv4 routes through MP-BGP
fine, but they see the next hop as the other end's loopback. For example
R2 (2.2.2.2) peers with R4 (4.4.4.4) and R5 (5.5.5.5) ... so when I attempt
to ping a vpnv4 route that lives in VPNA off of R4 on the other side, R2
sees the next hop as 4.4.4.4 ...it then recursively looks up 4.4.4.4 in it's
routing table and finds a next hop of 150.100.100.4 (R4's frame interface)
and NO LABEL IS FOUND. My LDP session is up between R6 and all my spokes.
My loopbacks are in OSPF...it seems when OSPF advertises from one spoke to
the hub, and the hub (also the DR) advertises that route down to the other
spokes, the next hop does not change....so instead of my next hop in the
recursive lookup being the frame hub , it is the spoke. The entire frame
cloud uses only physical interfaces, and everything in the same subnet.

I hope I explained that well enough for somebody to help out. Has anybody
else out there ran into this? Is it possible to have your frame-relay HUB
be a P router and not run BGP at ALL like this?

Regards,

Joe Astorino
CCIE #24347 (R&S)
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com

Blogs and organic groups at http://www.ccie.net
Received on Mon Jun 15 2009 - 11:14:55 ART