The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Fwd: BGP-MPLs interface defination and working
Mehwish, I will take a try at answering your question, with Cisco examples. I am sorry I can't provide you with Juniper examples, but the concepts will be the same between Cisco and Juniper as they are MPLS VPN concepts, not platform-specific. Perhaps others on the list can do the same for Juniper examples. Anyone? If I understand, your PE has three intefaces (if_1,2, & 3), each pointing to a different customer's CE. I am not sure by your description whether the interface if_x, and if_z are on CEs or the PE, but it look like you have them on the CE. I will assume that this is what you mean. What we then have is: CE-(if_z)----------(if_2)-PE-(unspecified interface to provider's internal network). In the CE routing table will be entries for all known subnets, along with the interface from which the traffic should be sent in order to reach those subnets. This is normal routing. The fact that a certain subnet is at the other end of a VPN makes no difference to the CE, and the CE knows nothing about any VPN. As far as the CE is concerned, the traffic is just going out an interface using normal IP protocols, and the subnet was learned using normal routing protocols. Let's just say that the CE knows of a subnet S.T.U.V. that happens to be across the VPN. In this case, VPN-bound traffic will go out if_z, and traffic to other subnets on the local network will go out if_x. The CE knows nothing about the VPN, only the subnet and the interface by which to reach it. The CE routing table will have an entry that says: "To reach subnet S.T.U.V, go out interface if_z to the next-hop address A.B.C.D". The address A.B.C.D is the interface address on the connected PE. The CE if_z is connected to a particular interface at the PE (most likely a subinterface). For our purposes here, I will say that CE if_z is connected to PE if_2. You didn't specify, so I will choose one. There is also a VRF related specifically to if_2 and to no other interface, and it will have all same routes/subnets that the CE routing table has. The VRF is a routing table, but not a global routing table. It is specific to the VPN, and it acts just like a normal router's routing table. However, though VRF_2 (to give it a name) is a routing table, it is not the normal routing protocol process that relays routing information across the provider's network. Since this customer's routing information has to be kept separate from all other customer routing information, the routing table has to be kept separate, and the routing updates have to be kept separate. Multi-protocol BGP (MP-BGP) does this work, carrying each customer's routing updates as part of the extended community string and keeping them separated using the RD and RTs that are specific to each VRF. At the far end, because BGP has kept the updates separate, the customer's update gets put in the proper VRF on the 2nd PE, and using normal routing, those updates are forwarded across the specific interface the VRF is tied to, and on to the customer's other CE. This second CE stores the updates just like any other route: "To reach subnet X, go out this particular interface to the next-hop address Q.R.S.T". The address Q.R.S.T is the subinterface address on the connected PE. For the following examples I will be showing only one side, a CE-PE relationship. The other side of the VPN is approximately the same, and functionally exactly the same. In real life, this is what you might see on a CE (if using Cisco's VPN Solution Center for provisioning) interface Serial1.101 point-to-point description Serial1.101 fr dlci=101 : Provisioned By VPNSC: Service Request Id# = 17 ip address 192.16.90.26 255.255.255.252 no ip directed-broadcast frame-relay interface-dlci 111 ! router rip version 2 network 192.16.90.0 no auto-summary And this is what you might see on the related PE: ip vrf V8:New_Ralph rd 20002:23007 route-target export 20002:25002 route-target import 20002:25002 route-target import 20002:25000 frame-relay switching ! interface Serial2/0.111 point-to-point description Serial2/0.111 fr dlci=111 : Provisioned By VPNSC: Service Request Id# = 17 ip vrf forwarding V8:New_Ralph ip address 192.16.90.25 255.255.255.252 frame-relay interface-dlci 111 Note that CE and PE are connected on the same subnet. There is no reference to a VRF at the CE, but there is a specific reference to a VRF on the related PE interface. The VRF named V8:New_Ralph has been created and connected to a specific PE interface using the ip vrf forwarding command (The actual name of the VRF is unimportant; I name all sorts of things Ralph, George, and Harry. Pay no attention....). Now let's go into some routing detail on the PE: router rip version 2 no auto-summary ! address-family ipv4 vrf V8:New_Ralph version 2 redistribute bgp 20002 metric transparent network 192.16.90.0 no auto-summary exit-address-family We see here that routing to the CE (ipv4 routing, normal IP stuff) is being done by RIP. However, it is being handled in a special way on the PE so that RIP is VPN-aware, and will only redistribute VRF information to BGP and only send ipv4 routing updates to the CE connected to a particular VRF. Since the VRF is connected to a specific interface, any traffic that comes in on that interface will be handled this way. And between the PEs: router ospf 100 network 10.1.1.0 0.0.0.255 area 0 network 200.200.200.0 0.0.0.255 area 0 ! router bgp 20002 neighbor 200.200.200.1 remote-as 20002 neighbor 200.200.200.1 update-source Loopback0 no auto-summary ! address-family ipv4 vrf V8:New_Ralph redistribute static redistribute rip no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 200.200.200.1 activate neighbor 200.200.200.1 send-community extended no auto-summary exit-address-family In this we see that OSPF is the routing protocol that runs inside the provider's network as the Interior Gateway Protocol (IGP). Nothing special here, normal OSPF operation. We also see within BGP that this PE will be looking for the loopback address of the far-end PE, not an interface address. Normal IGP routing (OSPF in this case) within the provider's network will show BGP the way to that loopback address. We also see that the RIP process is handing over the RIP routing updates for the VRF to BGP, and visa versa. We also see that BGP has a particular kind of session with the PE on the other end (address-family vpnv4). This is the MPLS VPN part, whereby BGP is being told to transfer the VRF routing information in a special way, via the extended community string within BGP so as to keep the VRF information separate from all other customer's information. The extended community string is nothing more than a variable area within BGP that most any information can be carried. Think of BGP as a truck and the extended community string as the empty box on the back of the truck. Again, on the other side of the provider's network things look about the same. I hope this helps in answering your question. If you need more specific information, let the group know. Roger Williams Resent-Date: Tue, 24 Dec 2002 23:13:17 -0500------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml |
|