MPLS - How are external/internal routes distinguished?

garrettc134 · ‎03-14-2013

Hi all

I was setting up an MPLS environment and wanted to get some more information about how MPLS VPN's work. Basically I have three sites connected to the MPLS cloud. Site A runs EIGRP on the customer side and Site B runs OSPF on the customer side. Site C is the one in question. The way I have it designed, Sites A and C have full visability into one another and sites B and C have full visibility into one another. When I configure site C with eigrp, all proper routes are seen, but the OSPF routes from site B are seen as EIGRP external routes. When I switch site C to OSPF, EIGRP routes from site A are seen as OSPF External type 2 routes. I guess my ultimate question is, How does the PE router at site C know the originating protocol? All the routes it receives are from BGP. Does a certain attribute carry this? If so, is this feature specific to Cisco gear or an RFC standard? Thanks in advance for all your help. I can include configs if that would help, below I'll show you my RD and RT's for each VRF and the routing tables of the CE router at Site C before and after the change.

Site A

ip vrf a

rd 1:111

route-target export 1:100

route-target import 1:101

Site B

ip vrf c

rd 3:333

route-target export 3:301

route-target import 1:101

Site C

ip vrf a

rd 1:111

route-target export 1:101

route-target import 1:100

route-target import 3:301

Change from EIGRP to OSPF

Gateway of last resort is not set

6.0.0.0/32 is subnetted, 1 subnets

D 6.6.6.6 [90/435200] via 10.2.1.1, 00:05:26, Ethernet0/0

7.0.0.0/32 is subnetted, 1 subnets

C 7.7.7.7 is directly connected, Loopback1

8.0.0.0/32 is subnetted, 1 subnets

D EX 8.8.8.8 [170/2560025856] via 10.2.1.1, 00:02:13, Ethernet0/0

D EX 111.0.0.0/8 [170/2560025856] via 10.2.1.1, 00:02:13, Ethernet0/0

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C 10.2.1.0/24 is directly connected, Ethernet0/0

D 10.1.1.0/24 [90/307200] via 10.2.1.1, 00:05:56, Ethernet0/0

D 10.20.0.0/16 [90/435200] via 10.2.1.1, 00:05:56, Ethernet0/0

C 10.77.0.0/16 is directly connected, Loopback2

D EX 192.168.1.0/24 [170/2560025856] via 10.2.1.1, 00:02:43, Ethernet0/0

R7(config)#no router eigrp 22

*Mar 1 02:10:20.747: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 22: Neighbor 10.2.1.1 (Ethernet0/0) is

down: interface down

R7(config)#router ospf 3

R7(config-router)#network 10.0.0.0 0.255.255.255 area 0

R7(config-router)#network 7.7.7.7 0.255.255.255 area 0

R7(config-router)#end

R7#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

6.0.0.0/32 is subnetted, 1 subnets

O E2 6.6.6.6 [110/409600] via 10.2.1.1, 00:00:27, Ethernet0/0

7.0.0.0/32 is subnetted, 1 subnets

C 7.7.7.7 is directly connected, Loopback1

8.0.0.0/32 is subnetted, 1 subnets

O IA 8.8.8.8 [110/21] via 10.2.1.1, 00:00:27, Ethernet0/0

O IA 111.0.0.0/8 [110/21] via 10.2.1.1, 00:00:27, Ethernet0/0

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C 10.2.1.0/24 is directly connected, Ethernet0/0

O E2 10.1.1.0/24 [110/1] via 10.2.1.1, 00:00:26, Ethernet0/0

O E2 10.20.0.0/16 [110/409600] via 10.2.1.1, 00:00:26, Ethernet0/0

C 10.77.0.0/16 is directly connected, Loopback2

O IA 192.168.1.0/24 [110/11] via 10.2.1.1, 00:00:26, Ethernet0/0

R7#trace 6.6.6.6

Type escape sequence to abort.

Tracing the route to 6.6.6.6

1 10.2.1.1 652 msec 396 msec 192 msec

2 40.1.1.9 [MPLS: Labels 18/24 Exp 0] 2264 msec 2640 msec 2532 msec

3 30.1.1.3 [MPLS: Labels 18/24 Exp 0] 2320 msec * *

4 10.1.1.1 [MPLS: Label 24 Exp 0] 1816 msec 1792 msec 2148 msec

5 10.1.1.2 1940 msec * 2200 msec

R7#

Peter Paluch · ‎03-14-2013

Hello Edward,

I see nothing strange in the results you have posted. They are completely natural to the process of carrying customer routes over MPLS L3 VPN.

You know yourself that the customer routes are carried between PE routers using BGP, and from PE towards CE, these routes are redistributed from BGP into the particular routing protocol running between PE and CE. Each of these routing protocols automatically marks redistributed networks as external networks. For OSPF, this is a normal part of the open protocol specification - that routes injected into OSPF via redistribution shall be represented as external routes (and carried in LSA-5). Similarly, when you redistribute into EIGRP from a different routing protocol, these routes will be carried by EIGRP as external networks. So what you see here is natural and normal. Even if all sites ran the same routing protocol (EIGRP or OSPF), one site would see networks from other sites as external routes.

In fact, there are extensions to BGP using extended community attributes that try to preserve the original nature of the redistributed routes. The prerequisite is that all sites run the same IGP, either OSPF or EIGRP. In that case, EIGRP routes carried over MPLS can be made look like internal routes although they are redistributed, and OSPF will make the routes appear as inter-area routes, not as external routes. There is even a modification to OSPF allowing you to see other sites as intra-area routes (though this requires configuring so-called OSPF sham links between PEs). All of this is done because an internal network is always preferred to an external network. This causes trouble if there is a backup link directly interconnecting two sites, bypassing the MPLS cloud. As the routing protocol run over this link advertises all networks as internal, this link would always be preferred to the MPLS VPN which is exactly the opposite of what you want to do.

Please feel welcome to ask further!

Best regards,

Peter

garrettc134 · ‎03-15-2013

What you say makes complete sense, and is exactly what was exhibited in my situation. I guess I was just a little confused because I had never read that the BGP extended community attributes exchanged between the PE routers allowed each end to distinguish between different routing protocols and instances and wasn't sure if this was per RFC or a Cisco implementation. Guess I need to get reading the RFC. Thanks for the explanation.

Ed

Peter Paluch · ‎03-16-2013

Hello Ed,

You are welcome.

I had never read that the BGP extended community attributes exchanged  between the PE routers  allowed each end to distinguish between  different routing protocols and instances

Be careful to not get confused here. The BGP extended communities are used to make the routes carried over MPLS cloud to appear as internal or inter-area routes within the same IGP routing protocol they originally come from. Without these attributes, these routes would be considered external. Regardless of whether the BGP extcomm attributes are present or not, you always perform the BGP-to-IGP redistribution. Without the extcomm attribute, the route would surely be advertised as an external route. With these communities, the route will be advertised as EIGRP internal (if originated from and redistributed back to EIGRP) or OSPF inter-area (if originated from and originated back to OSPF).

The use of BGP communities for OSPF is described in the RFC 4577 Section 4.2.6. For EIGRP, these communities are described in these documents:

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsbgpcce.html#wp1067175

http://www.cisco.com/en/US/docs/ios/ios_xe/iproute_eigrp/configuration/guide/ire_mpls_vpn_xe.html

http://www.cisco.com/en/US/docs/ios/ios_xe/iproute_bgp/configuration/guide/irg_cost_comm_xe.html

Best regards,

Peter

Muhammad Thanveer · ‎03-17-2013

Nice info Peter

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

garrettc134 · ‎03-30-2013

I finally, figured it out. The attributes are carried in the bgp community string. For example:

R2#show bgp vpnv4 unicast all 10.10.1.0

BGP routing table entry for 134:1:10.10.1.0/24, version 26

Paths: (1 available, best #1, table VPN1)

Not advertised to any peer

Local

10.10.45.4 from 10.10.45.4 (10.10.45.4)

Origin incomplete, metric 2, localpref 100, valid, internal, best

Extended Community: RT:134:1 OSPF DOMAIN ID:0x0005:0x0000000E0200

OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.10.14.4:0

mpls labels in/out nolabel/21

Just an FYI for posterity. I'm sure you guys already knew that. Anyway's thanks for the help. Now I just need to figure out how to trick it into thinking routes are internal...

blau grana · ‎04-01-2013

Hello Edward,

Now I just need to figure out how to trick it into thinking routes are internal...

It is called OSPF sham-link ->

http://blog.ipexpert.com/2010/06/14/ospf-sham-links/

Best Regards

Please rate all helpful posts and close solved questions

Best Regards Please rate all helpful posts and close solved questions