03-14-2013 03:22 PM
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#
03-14-2013 04:23 PM
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
03-15-2013 12:34 PM
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
03-16-2013 02:18 PM
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
03-17-2013 01:38 PM
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."
03-30-2013 06:08 PM
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...
04-01-2013 10:49 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide