How can I diagnose a bridging (ethernet) loop?

You will probably have MAC addresses flapping between ports.. look for MAC_MOVE_NOTIFICATION (or similar) errors in:
sh logg

Now to find the port:
sh int g0/1 controller
look for out of ordinary Multicast and Broadcast numbers. Any collisions are a bad sign.

Last but not least, you can't log in, because the CPU is pwned :)
sh proc cpu
How is the switch doing here? If it's an L2 switch only, you don't want anything above ~10%



Enable storm control on the ports to limit broadcast

Distribution-Sw1(config)#int  range f0/21 - 24
Distribution-Sw1(config-if)#storm-control multicast level  5
Distribution-Sw1(config-if)#storm-control broadcast level  5

Drop broadcast o multicast level if they are more than 5% of the bandwidth

An alternative action could be  to shutdown the ports:
storm-control action shutdown

Facts to remember about IPSEC VPN

If you are trying to configure GRE over IPSec (tunnel encapsulation first then encryption), then you can do this with one of the 2 configuration options,

1.  Using crypto map and apply the crypto map to the physical egress interface for the GRE encapsulated tunnel packets,  
2. Using ipsec profiles with tunnel protection. With crypto map on the tunnel interface

If you are trying to configure IPSec over GRE (encryption first then encapsulation), then apply crypto map on the tunnel interface


This is the diagram used for the examples

IPsec VPNs with Crypto Maps

• Configure an IPsec VPN between R7 and R8. The first step is verify reachability between R7 and R8 with a ping
• EIGRP has been enabled on R7, R6, R3, R5, R8. OSPF between R7 and R9,  R9 loopback0 is advertised into OSPF. OSPF between R8 and R10, R10 loopback0 is advertised into OSPF. 
• The tunnel endpoints (R9 and R10) and the devices behind them (R7 and R8) require default routing to reach destinations over the IPsec tunnel that's why a "default-information originate" command under the OSPF process on R7 and R8 propagates a default route on R9 and R10, R7 has two static default routes toward R6 and R3
• R7 has now two default routes so it advertises itself as default gateway to R9 into the OSPF process with the command "default-information originate". R8 advertises as a default gateway to R10 with the same command into OSPF process
• Because R7 has multiple connections to the transit network (one to R3 and one to R6), the IPsec tunnel should be sourced off an interface independent of these links, such as its Loopback0
• This is the Phase one IPsec (ISAKMP - part of IKE, it is a framework for authentication and key exchange) and Phase 2 SA (security association) on R7 and R8

R7:    
crypto isakmp policy 10   (define the isakmp policy with id 10)
 encr aes 256             (define encryption protocol)
 hash sha512              (define integrity protocol)
 authentication pre-share (define authentication with pre known password)
 group 24                 (define key strenght during exchange process)
!
crypto isakmp key CISCO address 155.1.58.8  (remote peer and password)   
!
crypto ipsec transform-set ESP-AES-192-SHA-384 esp-aes 192 esp-sha384-hmac (encryption and integrity protocols during the transmission)
 mode tunnel        (ESP transform set is running in tunnel mode Phase 2)
!
ip access-list extended R9_TO_R10  (Proxy ACL - ips through tunnel)
 permit ip host 150.1.9.9 host 150.1.10.10  (src R9 l0, dst R10 l0 )
 permit ip host 150.1.9.9 155.1.10.0 0.0.0.255 (src R9 l0, dst R8-10 net) 

!

crypto map R7_TO_R8 local-address Loopback0  (tunnel source definition)
!
crypto map R7_TO_R8 10 ipsec-isakmp    (isakmp settings)
 set peer 155.1.58.8                   (remote peer)
 set transform-set ESP-AES-192-SHA-384 (transform set previously defined)
 match address R9_TO_R10               (Proxy ACL previously defined)
!
interface G0/3
 crypto map R7_TO_R8                   (linking cryto map with interface)
!
interface G0/1
 crypto map R7_TO_R8                   (linking crypto map with interface)

R8:
crypto isakmp policy 10
 encr aes 256
 hash sha512
 authentication pre-share
 group 24
!
crypto isakmp key CISCO address 150.1.7.7     
!
crypto ipsec transform-set ESP-AES-192-SHA-384 esp-aes 192 esp-sha384-hmac 
 mode tunnel
!
ip access-list extended R10_TO_R9
 permit ip host 150.1.10.10 host 150.1.9.9
 permit ip host 150.1.10.10 155.1.9.0 0.0.0.255
 permit ip 155.1.10.0 0.0.0.255 host 150.1.9.9
 permit ip 155.1.10.0 0.0.0.255 155.1.9.0 0.0.0.255
!
crypto map R7_TO_R8 10 ipsec-isakmp 
 set peer 150.1.7.7
 set transform-set ESP-AES-192-SHA-384 
 match address R10_TO_R9
!
interface G0/2
 crypto map R7_TO_R8
!

GRE Tunnel

Configure OSPF area 0 between R7 and R9, and advertise all links on R9 into OSPF.

Configure OSPF area 0 between R8 and R10, and advertise all links on R10 into OSPF.

There is no need to do default routing, GRE tunnel support dynamic routing

Configure a GRE tunnel between R7 and R8 as follows:

• Source the tunnel from Loopback0 addresses.
• Use the IP subnet 169.254.78.0/24, with host addresses .7 and .8 respectively.
• Enable OSPF area 0 on the tunnel.

R7:
interface Tunnel0
 ip address 169.254.78.7 255.255.255.0
 ip ospf 1 area 0
 tunnel source Loopback0
 tunnel destination 150.1.8.8

R8:
interface Tunnel0
 ip address 169.254.78.8 255.255.255.0
 ip ospf 1 area 0
 tunnel source Loopback0
 tunnel destination 150.1.7.7
!

GRE over IPsec with Crypto Maps

• Traffic is encrypted after it is GRE encapsulated between the tunnel endpoints
• The ESP transform set is running in Transport mode, which means that an extra GRE IP header is not needed, only the additional ESP IP header
• The Proxy ACL used needs only a single entry to specify all GRE traffic (IP protocol 47)
• IP MTU on the tunnel interface is used to stop the router from having to do fragmentation after IPsec encryption
• The TCP Adjust MSS feature is used to have the router edit the payload of a TCP three-way handshake if the MSS exceeds the configured value and avoid fragmentation

R7:
interface Tunnel0
 ip address 169.254.78.7 255.255.255.0
 ip mtu 1400

 ip ospf 1 area 0
 ip tcp adjust-mss 1360
 tunnel source Loopback0
 tunnel destination 150.1.8.8
!
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 5
!
crypto isakmp key CISCO address 150.1.8.8     
!
crypto ipsec transform-set ESP-AES-128-SHA-1 esp-aes esp-sha-hmac 
 mode transport
!
ip access-list extended GRE_FROM_R7_TO_R8
 permit gre host 150.1.7.7 host 150.1.8.8
!
crypto map GRE_OVER_IPSEC local-address Loopback0
!
crypto map GRE_OVER_IPSEC 10 ipsec-isakmp 
 set peer 150.1.8.8
 set transform-set ESP-AES-128-SHA-1 
 match address GRE_FROM_R7_TO_R8
!
interface GigabitEthernet1.37
 crypto map GRE_OVER_IPSEC
!
interface GigabitEthernet1.67
 crypto map GRE_OVER_IPSEC

R8:
interface Tunnel0
 ip address 169.254.78.8 255.255.255.0

 ip ospf 1 area 0
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source Loopback0
 tunnel destination 150.1.7.7
!
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 5
!
crypto isakmp key CISCO address 150.1.7.7     
!
crypto ipsec transform-set ESP-AES-128-SHA-1 esp-aes esp-sha-hmac 
 mode transport
!
crypto map GRE_OVER_IPSEC local-address Loopback0
!
ip access-list extended GRE_FROM_R8_TO_R7
 permit gre host 150.1.8.8 host 150.1.7.7
!
crypto map GRE_OVER_IPSEC 10 ipsec-isakmp 
 set peer 150.1.7.7
 set transform-set ESP-AES-128-SHA-1 
 match address GRE_FROM_R8_TO_R7
!
interface GigabitEthernet1.58
 crypto map GRE_OVER_IPSEC

GRE over IPsec with Crypto Profiles

• Configuration is simplified compared to GRE over IPsec with Crypto Maps. In both cases the IPsec Phase 1 (ISAKMP) negotiation is identical
• For IPsec Phase 2, the IPsec Transform Set is called from a Crypto IPsec Profile.
• The IPsec Profile is applied to the Tunnel interface
• Because the Tunnel already specifies the source and destination, there is no need to set the peer address as in the Crypto Map-based configuration
• No Proxy ACL is needed, because all GRE traffic between the tunnel endpoints is subject to the IPsec encryption and authentication

R7:
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 5
!
crypto isakmp key CISCO address 150.1.8.8     
!
crypto ipsec transform-set ESP-AES-128-SHA-1 esp-aes esp-sha-hmac 
 mode transport
!
crypto ipsec profile GRE_OVER_IPSEC_PROFILE
 set transform-set ESP-AES-128-SHA-1 
!
interface Tunnel0
 ip address 169.254.78.7 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip ospf 1 area 0
 tunnel source Loopback0
 tunnel destination 150.1.8.8
 tunnel protection ipsec profile GRE_OVER_IPSEC_PROFILE

IPsec Virtual Tunnel Interfaces (VTIs)

• VTI behaves very similar to a GRE tunnel, except the encapsulation overhead is lower (24 bytes lower that GRE over IPsec with ESP in Tunnel Mode).
• VTI is a tunnel where the payload is directly encapsulated in ESP without the need of another transport header.
• One key point to remember though is that since the payload is directly encapsulated into IPsec, which is an IP-only encapsulation, other non-IP payloads are not supported. This means that non-IP protocols like the IS-IS routing protocol could not run over an IPv4 VTI.
• The configuration of a VTI is identical to a GRE over IPsec tunnel with a Crypto IPsec Profile, except that the tunnel mode is set to IPsec IPv4 or IPsec IPv6
• Phase 2, the Proxy Identities (what would normally be configured as the Proxy ACL) are automatically negotiated as IP any any.
• The IPsec Transform Set must run in Tunnel Mode, because there is no other transport header such as GRE that adds additional IP encapsulation

R7:
crypto isakmp policy 10
 encr aes 192
 hash sha384
 authentication pre-share
 group 15
!
crypto isakmp key CISCO address 150.1.8.8     
!
crypto ipsec transform-set ESP-3DES-ESP-MD5 esp-3des esp-md5-hmac
 mode tunnel
!
crypto ipsec profile VTI_PROFILE
 set transform-set ESP-3DES-ESP-MD5 
!
interface Tunnel0
 ip address 169.254.78.7 255.255.255.0
 ip tcp adjust-mss 1406
 ip ospf 1 area 0
 tunnel source Loopback0
 tunnel destination 150.1.8.8
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI_PROFILE

Facts to remember about EIGRP

EIGRP Filtering with Passive Interface

• The passive-interface command in EIGRP, stops the sending of updates out an interface. Unlike RIPv2, however, passive-interface in EIGRP will prevent forming of an adjacency on the interface because it stops sending EIGRP Hello packets as well
• The passive-interface default command can be used to make all interfaces passive, and then interfaces can have the passive feature selectively disabled with the no passive-interface command

R9:
router eigrp 100
 passive-interface default
 no passive-interface GigabitEthernet1.79

EIGRP MD5 & SHA-256 Authentication

• MD5 authentication in classic mode is applied at link level

SW1:
key chain SW1_KEY
 key 0
   key-string SW!_Key
!
interface Vlan121
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 SW1_KEY
!

• MD5 authentication in Multi-AF (Named) Mode is applied at the af-interface mode 
• SHA-256 authentication can also be applied in name mode but it didn't support "key chains"
• In EIGRP Named Mode options applied to all links at the same time can be configured at the "af-interface default". Within the scope of authentication, this can be used to configure a default key for all interfaces, or a default fallback key for interfaces that do not have a specific key applied:

key chain MD5_KEYS
 key 1
   key-string MD5_PASS
!
router eigrp MULTI-AF
 !
 address-family ipv4 unicast autonomous-system 100
  !
  af-interface Tunnel0
   authentication mode hmac-sha-256 SHA_KEY
  exit-af-interface
  !
  af-interface GigabitEthernet1.146
   authentication mode md5
   authentication key-chain MD5_KEYS
  exit-af-interface

router eigrp MULTI-AF
 !
 address-family ipv4 unicast autonomous-system 100
  !
  af-interface default
   authentication mode hmac-sha-256 SHA_DEFAULT
  exit-af-interface
  !

Facts to remember about WAN technologies

PPPoE

Verification commands: show ppp all, show pppoe session

Configure a PPPoE connection between CPE (Client) and ISP.(server)

• Configure a Broadband Aggregation (BBA) group which will handle incoming PPPoE connection attempts and the pool of addresses (don't include virtual template ip)

          ISP(config)# bba-group pppoe MyGroup

          ISP(config-bba-group)# virtual-template 1
          ISP(config)# ip local pool MyPool 10.1.13.4 10.1.13.254

• Create the virtual interface to represent the point-to-point connection and link the pool of addresses

           ISP(config)# interface virtual-template 1
           ISP(config-if)# ip address 100.1.13.3 255.255.255.0
           ISP(config-if)# peer default ip address pool MyPool

• Enable our PPPoE group on the interface facing the customer network

           ISP(config)# interface f0/0
           ISP(config-if)# no ip address
           ISP(config-if)# pppoe enable group MyGroup
           ISP(config-if)# no shutdown

• On the client side create a dialer interface and tie it to the physical interface which provides the transport. The PPP header adds 8 bytes of overhead to each frame. Assuming the default Ethernet MTU of 1500 bytes, we'll want to lower our MTU on the dialer interface to 1492 to avoid unnecessary fragmentation.

           CPE(config)# interface dialer1
           CPE(config-if)# dialer pool 1
           CPE(config-if)# encapsulation ppp
           CPE(config-if)# ip address negotiated
           CPE(config-if)# mtu 1492

           CPE(config)# interface f0/0
           CPE(config-if)# no ip address
           CPE(config-if)# pppoe-client dial-pool-number 1
           CPE(config-if)# no shutdown


PPPoE Authentication

• Configure PPP CHAP authentication over the PPPoE session between R1 and R3.
• The routers should use their hostname and a password of RSv5 to authenticate each other.

R1:
username R3 password RSv5
!
interface Dialer13
 ppp authentication chap


R3:
username R1 password RSv5
!
interface Virtual-Template13
 ppp authentication chap

Facts to remember about LAN Switching

Etherchannel (Portchannel)

• Bundles individual links (up to 8) into a channel group to create a single logical link 
• All members have to share same features: speed, duplex mode, switchport mode (access, trunk)
• STP will treat it as a one single link, if one link fails there is no STP reconvergence
• Traffic is distributed between members of the port channel if one of them fails
• Etherchannel gives you more pipes for your data but does not increase your transfer speeds
• Established by LACP (active, pasive), PAgP (desirable, auto), Static ( on - persistent)
• Etherchannel verification "show etherchannel summary"

Configure SW1 and SW2 as a portchannel numbered 12, SW1 active mode, SW2 passive mode

SW1:
interface FastEthernet0/23
 channel-group 12 mode active
!
interface FastEthernet0/24
 channel-group 12 mode active

SW2:
interface FastEthernet0/23
 channel-group 12 mode passive
!
interface FastEthernet0/24
 channel-group 12 mode passive




Trunking

• Trunking verification "show interface trunk"

Configure SW1and SW2 portchannels as static 802.1q trunk links

SW1:
interface Port-channel12
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
SW2:
interface Port-channel12
 switchport trunk encapsulation dot1q
 switchport mode trunk

VTP

• VTP verification "show vtp status"

Configure SW1 as a VTP server in the domain CCIE., SW2 should be VTP client. Configure VLANs 21, 22, 121, 122, 124, 221, 222, and 239 on SW1. After that SW2 should learn these VLANs via VTP

SW1:
vtp domain CCIE                       
vtp mode server                       
!
vlan 21,22,121,122,124,221,222,239

SW2:
vtp mode client

Portfast 

• Skips listening and learning stages cause it is supposed these ports will be directly connected to end stations and not to another switch so they will not create bridging loops in the network
• It is also known as Edge port
• The switch will not generate TCNs (topology change notificactions) throughout the spanning-tree domain if interface goes down/up. BEWARE CAUSE TCN NOTIFICATIONS WILL CAUSE EVERY SWITCH IN RSTP FLUSH THEIR MAC ADDRESS TABLES AND RE-LEARNED THEM AGAIN
• If it receives a BPDU immediately loses its edge port status and becomes a normal spanning tree port
• It can be configured in access ports "spanning-tree portfast"or trunk ports "spanning-tree portfast trunk"
• Portfast can be enable by default at global level configuration

SW1:
spanning-tree portfast default
!

Spanning-Tree

• Enable Per-VLAN Rapid Spanning Tree on SW1, SW2
• Configure SW1 as the RPVST root bridge for all configured VLANs.
• Ensure that no topology change notifications are sent throughout the spanning-tree domain if SW1's FastEthernet0/1 interface goes down/up.

SW1:
spanning-tree mode rapid-pvst
spanning-tree vlan 1-4094 priority 0
!
interface FastEthernet0/1
 spanning-tree portfast trunk

SW2:
spanning-tree mode rapid-pvst

STP BPDU Guard

• It is used to enforce access layer security on the termination of the STP domain (access switch)
• When BPDU Guard enable interface receives a BPDU (STP packet), it is transitioned into err-disable state.
• This ensures that unauthorized switches cannot be plugged in to the network (man in the middle attack)
• If configured, the errdisable recovery feature can then be used to bring the interface out of err-disable state automatically after a configured interval
• To verify if bpdu guard is enable, interfaces in err-disable state and time interval "show errdisable recovery" 
• BPDU Guard can also be enabled by default, at the global level to work with Portfast

SW4:
default interface range FastEthernet0/23 - 24
!
interface range FastEthernet0/23 - 24
 channel-group 34 mode active
!
interface Port-channel34
 switchport mode access
 switchport access vlan 10
 spanning-tree bpduguard enable
!
errdisable recovery cause bpduguard
errdisable recovery interval 120

Enabled at global level by default with PorFast

SW4:
spanning-tree portfast bpduguard default 
spanning-tree portfast default

RootGuard

• Like "BPDU Guard", it blocks superior BPDUs (better cost to the root bridge)
• The interface is only logically disabled (via Root Inconsistent state).The switch automatically recovers the port from Root Inconsistent and starts negotiating the new port state and role, as soon as superior BPDUs are no longer received inbound.
• Is is not for access swicthes, It must be configured in all the ports of the ROOT BRIDGE cause all of them are designated ports
• It prevents a Designated port from becoming Non-Designated port
• It can be enabled only at the port level 
• Generally root guard is enable for all VLANS

SW1:
interface range FastEthernet0/19 - 20
 spanning-tree guard root

LoopGuard

• Loop Guard prevents a Non-Designated port from becoming Designated, thus it is the opposite of Root Guard; for this reason Root Guard and Loop Guard cannot be actively enabled at the same time on the same ports
• Blocking states ports can transition to the forwarding state if they don't receive BPDUs from designated ports ( maybe a unidirectional problem). LoopGuard prevents this transisition the port in Loop Inconsistent
• Switch will automatically recover the port from Loop Inconsistent state when it starts receiving BPDUs and the STP port state is re-negotiated.
• Just like Root Guard, although is enabled for a port, Loop Guard takes actions on a per-VLAN level; for example if a trunk port is in blocking state and stops receiving BPDUs for VLAN 2 from the designated port on the segment, it transitions the port into Loop Inconsistent only for VLAN 2
• It can be enabled at global configuration level or interface configuration level

SW1 - SW2:
spanning-tree loopguard default

SW3 - SW4:
interface range FastEthernet0/19 - 20
 spanning-tree guard loop

Facts to remember about MPLS - Part 2

PE-CE Routing with OSPF

PE-CE Routing with EIGRP

• An address family must be configured per VRF under the routing process
• For every address-family you must configure an AS number using the command autonomous-system N

R5:
no router ospf 100
!
router eigrp 100
 address-family ipv4 vrf VPN_A
  autonomous-system 100
  network 155.1.58.5 0.0.0.0
  redistribute bgp 100 metric 1 1 1 1 1
!
router bgp 100
 address-family ipv4 vrf VPN_A
  redistribute eigrp 100










Facts to remember about MPLS - Part 1

VRF Lite

• VRF (Virtual Routing and Forwarding) tables turn a single router into multiple virtual routers
• Any router interface can be assigned to a VRF using the command "ip vrf forwarding <VRF_NAME>", this command will erase any ip address in the interface
• To create a new VRF, issue the command "ip vrf <VRF_NAME>"
• After this initial step, you must define a route distinguisher (RD) for this particular VRF using the command "rd X:Y", where X and Y are 32-bit numbers.
• A Route Distinguisher is a special 64-bit prefix prepended to every route in the respective VRF routing table. This is done for the purpose of distinguishing the prefixes inside the router and avoiding collisions if two VRFs contain the same prefixes.
• The syntax for a VRF-bound static route is "ip route vrf <NAME> PREFIX MASK [interface] [next-hop]", where [next-hop] is an IP address resolvable through the VRF

R6:
ip vrf VPN_A
 rd 100:1
!
ip vrf VPN_B
 rd 100:2
!
interface GigabitEthernet1.67
 ip vrf forwarding VPN_A
 ip address 155.1.67.6 255.255.255.0
!
interface GigabitEthernet1.76
 ip vrf forwarding VPN_B
 ip address 155.1.76.6 255.255.255.0
!
ip route vrf VPN_A 192.168.7.0 255.255.255.0 GigabitEthernet1.76 155.1.76.7
ip route vrf VPN_B 172.16.7.0 255.255.255.0 GigabitEthernet1.67 155.1.67.7




MPLS LDP

• Use the interface level configuration command "mpls ip" to enable MPLS in a interface
• If OSPF is the IGP then "mpls ldp autoconfig" will enable MPLS in all the OSPF interfaces
• At he begining the multicast address 224.0.0.2 on port 646 is used to find valid neighbors. after that a TCP connection is established on port 646
• "mpls ldp router-id <interface> force" will change  LDP Router IDs which is the highest loopback ip address by default
• "mpls ldp discovery transport-address interface" will use the physical ip address of the interface to establish the TCP connection if neighbor loopback  unreachable
• The hashing key is defined per-neighbor by using the command "mpls ldp neighbor <IP> password <password>". The IP address here is the neighbor’s LDP Router ID. To make the use of passwords mandatory, you need the global command "mpls ldp password required"
• After the transport connection has been established, the routers exchange prefix and label bindings, resulting in LFIB population. The exchange is performed over the TCP connection established previously

mpls ip
!
mpls ldp router-id Loopback0 force
!
interface GigabitEthernet1.146
 mpls ldp discovery transport-address interface
!
router ospf 1
 mpls ldp autoconfig
!
mpls ldp password required
mpls ldp neighbor 150.1.5.5 password CISCO
mpls ldp neighbor 150.1.6.6 password CISCO




MPLS Label Filtering

By default, LDP will generate and advertise labels for every prefix found in the local routing table. If you want to change this behavior and generate labels only for specific prefixes, you may use an access-list to select the prefixes eligible for label generation

R4, R5, R6:
access-list 10 permit 150.1.0.0 0.0.255.255
!
no mpls ldp advertise-labels
mpls ldp advertise-labels for 10

MP-BGP VPNv4

• The purpose of MPLS VPNs is to establish a full-mesh of dynamic MPLS LSRs between the PE (Provider Edge) routers and use those for tunneling VPN packets across the network core
• Two labels in the MPLS stack; one label (the topmost) is the transport label, which is being swapped along the entire path between the PEs, and the other label (innermost) is the VPN label, which is used to select the proper outgoing VRF CEF entry.
• A new special MP-BGP (multiprotocol BGP) address family named VPNv4 (VPN IPv4) has been added to BGP along with a new NLRI format. Every VPNv4 prefix has the RD associated with it and the corresponding MPLS label, in addition to the normal BGP attributes.
•  By default, when you create a new BGP neighbor using the command "neighbor <IP> remote-as <NR>", the default IPv4 unicast address-family is activated for this neighbor. If for some reason you don’t want this behavior and only need the VPNv4 prefixes to be sent, you may disable the default behavior via the command "no bgp default ipv4-unicast".
• There are special limitations for iBGP peering sessions that you want to enable for VPNv4 prefix exchange. First, they must be sourced from a Loopback interface, and second, this interface must have a /32 mask (this is not a strict requirement on all platforms)
• To inject a particular VRF’s routes into BGP, you must activate the respective address-family under the BGP process and enable route redistribution (such as static or connected). All the respective routes belonging to that particular VRF will be injected into the BGP table with their RDs and have their VPN labels generated. The import process is a bit more complicated and is based on the concept of Route Targets.
• A Route Target is a BGP extended community attribute. These BGP attributes are transitive and encoded as 64-bit values (as opposed to normal 32-bit communities). They are used for enhanced tagging of VPNv4 prefixes. The need for route-target arises from the fact that you cannot just use Route Distinguishers for prefix importing/exporting, because routes with the same RD may eventually belong to multiple VRFs, when you share their routes.
•  By default, all prefixes redistributed from a VRF into a BGP process are tagged with the extended community X:Y specified under the VRF configuration via the command "route-target export X:Y". On the receiving side, the VRF will import the BGP VPNv4 prefixes with the route-targets matching the local command "route-target import X:Y."

Enable VPN route exchange between R5 and R6, using R4 as the BGP route-reflector. R6 was already configured with the VRF

R4:
router bgp 100
 no bgp default ipv4-unicast
 neighbor 150.1.5.5 remote-as 100
 neighbor 150.1.5.5 update-source Loopback0
 neighbor 150.1.6.6 remote-as 100
 neighbor 150.1.6.6 update-source Loopback0
!
address-family vpnv4 unicast
 neighbor 150.1.5.5 activate
 neighbor 150.1.6.6 activate
 neighbor 150.1.5.5 send-community extended
 neighbor 150.1.6.6 send-community extended
 neighbor 150.1.5.5 route-reflector-client
 neighbor 150.1.6.6 route-reflector-client

R5:
ip vrf VPN_A
 rd 100:1
 route-target both 100:1
!
ip vrf VPN_B
 rd 100:2
 route-target both 100:2
!
interface GigabitEthernet1.58
 ip vrf forwarding VPN_A
 ip address 155.1.58.5 255.255.255.0
!
interface GigabitEthernet1.5
 ip vrf forwarding VPN_B
 ip address 155.1.5.5 255.255.255.0

R6:
ip vrf VPN_A
 rd 100:1
 route-target both 100:1
!
ip vrf VPN_B
 rd 100:2
 route-target both 100:2

R5 , R6:
router bgp 100
 no bgp default ipv4-unicast
 neighbor 150.1.4.4 remote-as 100
 neighbor 150.1.4.4 update-source Loopback0
!
address-family vpnv4 unicast
 neighbor 150.1.4.4 activate
 neighbor 150.1.4.4 send-community extended
!
 address-family ipv4 vrf VPN_A
  redistribute connected
  redistribute static
! 
 address-family ipv4 vrf VPN_B
  redistribute connected
  redistribute static

MP-BGP Prefix Filtering

• [import|export] map <ROUTE_MAP_NAME> allows a more granular control over route tagging than route-target
• export/import maps are configured under the VRF configuration context and they could match prefixes based on the prefix-lists, access-lists, or extended-communities.
• All routes not permitted in an export/import route-map are not exported/import into the BGP process

R6:
interface Loopback102
 ip vrf forwarding VPN_B
 ip address 192.168.6.6 255.255.255.0
!
ip prefix-list LO102 permit 192.168.6.0/24
!
route-map VPN_B_EXPORT permit 10
 match ip address prefix-list LO102
 set extcommunity rt 100:66
!
route-map VPN_B_EXPORT permit 20
 set extcommunity rt 100:2
!
ip vrf VPN_B
 export map VPN_B_EXPORT
 route-target import 100:55

PE-CE Routing with RIP

• With RIPv2, you may enable the respective address family under the process configuration mode using the command address-family ipv4 vrf <VRF_NAME>
• You can't create a separate RIP process for each VRF, the whole RIP process is shared among VRF's
• To redistribute MP-BGP routes into RIP, use the command "redistribute bgp <N> metric [X|transparent]" under the respective address family. Here, N is the BGP process number (AS#) and X is the metric assigned to the RIP routes. With the keyword transparent, the RIP metrics will be recovered from the BGP MED attribute, which in turn is copied from RIP metrics learned at the remote site. This allows for transparent preservation of RIPv2 metric values across the VPN and better path selection in case of backdoor links

R6:
router rip
 version 2
 address-family ipv4 vrf VPN_B
  redistribute bgp 100 metric transparent
  network 155.1.0.0
  network 192.168.6.0
!
router bgp 100
 address-family ipv4 vrf VPN_B
  redistribute rip

PE-CE Routing with OSPF

• When using OSPF as the PE-CE routing protocol in combination with MP-BGP, the ISP MPLS VPN backbone is considered by OSPF as a “super area 0” or "OSPF Super backbone area"
• The result is we can have non-zero OSPF areas at different sites connecting via the MP-BGP mesh without the need for area 0 at any site
•  All OSPF routes redistributed into MP-BGP are treated as inter-area routes as they enter the super-backbone from other areas even if they belong to the same area number at different sites because all PEs are seen as Area Border Router (ABR) from the CE router perspective
•  MP-BGP uses three extended communities in order to transparently transport OSPF prefix over the MPLS VPN backbone which are implemented automatically after you configure route redistribution between a VRF process and BGP.

OSPF domain-id: It is the OSPF process number on PE It is assumed that you configured all OSPF process number for the same VPN using the same process number. If the domain-id is different, OSPF will interpret all such prefixes as if they are Type-5 External LSAs

OSPF Route Type which has 3 significant fields: source area, route-type and option and has the following format: X:Y:Z.. X represents the area number and Y represents the LSA type (LSA 3, 5,7). Z is the option field and defines the metric type for LSA Type-5 or Type-7 (E1, E2, N1, N2). This attribute helps the BGP process to track the originating OSPF LSA type in order to make the correct redistribution from MP-BGP into OSPF. So if the origination LSA is type 5, MP-BGP will encode that and when doing redistribution on the other end of the MPLS VPN backbone, the PE will know that it should redistribute this route has LSA Type-5 E2 into OSPF.

OSPF router ID. Identifies the router ID of the PE in the relevant VRF instance of OSPF.

• The BGP MED attribute is used to carry the OSPF metric
•  OSPF implements some basic loop prevention rules. Down bit and Route Tagging
  

Down bit
If a router receives a summary-LSA with the down bit set on an interface that belongs to a VRF, it simply drops this LSA. In the example PE-3 has to choose between a prefix learned by iBGP and another one learned by OSPF (VRF interface), It will choose OSPF cause a lower AD. Here comes the loop cause R3 will redistribute the prefix again into BGP

However, this feature may have an undesirable effect when you have a CE router configured with multiple VRFs. In this case, you may want to enter the OSPF process command "capability vrf-lite" on the CE router. This will disable the default loop-prevention capability. Some IOS versions do not support this feature (such as older IOSs or some Catalyst IOS revisions). If you have such a router configured for multi-VRF and experience route black holing, configure the PE routers with different domain-IDs; this will force all redistributed routes to become external and bypass the down-bit check

Route Tagging
The DN bit helps preventing routing loops when summary Type-3 LSAs are redistributed, but not when external routes are announced (the DN bit is not set on LSA Type 5/7). All routes redistributed via a particular PE will carry the OSPF route tag which by default is the BGP AS number.
This tag is preserved when the external route is propagated across the entire OSPF domain (including redistribution into another OSPF domains). When another PE receives this route and it sees that the local AS number matches the AS number in the tag, it will ignore this LSA. Use the OSPF command "redistribute bgp N subnets tag Y"

OSPF Sham-Link
Situation/problem description: when there is a backup link between sites (backdoor), this link will be always used for inter-site traffic because intra-area routes (LSAs received via backdoor) are preferred to the inter-area (LSA 3 received from PE).
The solution to this problem is the usage of OSPF sham-links = special tunnel similar to virtual-links between PE routers and configured in the same area as the PEs.

Sham-links have the following characteristics:

• OSPF adjacency established via MPLS cloud
• Routes in the OSPF database are now seen as intra-area (even though they are received via the super-backbone)
• The information across the sham-link is ONLY used for SPF calculations – the actual forwarding is being done based on the info learned via MP-BGP
• Sham endpoints IP addresses (usually loopback interfaces) should be advertised into the VRF by means other than OSPF (commonly via BGP) – known before creating the sham-links.

R5:
router ospf 100 vrf VPN_A
 area 1 sham-link 150.1.55.55 150.1.66.66 cost 1
 no network 0.0.0.0 255.255.255.255 area 1
 network 155.1.58.5 0.0.0.0 area 1
!
interface Loopback 200
 ip vrf forwarding VPN_A
 ip address 150.1.55.55 255.255.255.255
!
router bgp 100
 address-family ipv4 vrf VPN_A
  network 150.1.55.55 mask 255.255.255.255