LAB 1 mpls backbone sham link config

mpls ldp router-id lo0

ip vrf vpnA
 rd 100:1
 route-target export 100:1
 route-target import 100:1
!
interface Loopback1
 ip vrf forwarding vpnA
 ip address 7.7.100.5 255.255.255.255
!
interface FastEthernet0/0
 mpls label protocol ldp
 tag-switching ip
!
interface FastEthernet0/1
 ip vrf forwarding vpnA
 ip address 7.7.0.130 255.255.255.224
 !
router ospf 1 vrf vpnA
 router-id 7.7.5.5
 area 0 sham-link 7.7.100.5 7.7.100.4
 area 51 virtual-link 7.7.7.7
 redistribute bgp 100 subnets
 network 7.7.0.130 0.0.0.0 area 51
!
router bgp 100
 no bgp default ipv4-unicast
 neighbor 7.7.4.4 remote-as 100
 neighbor 7.7.4.4 update-source Loopback0
 !
 address-family vpnv4
 neighbor 7.7.4.4 activate
 exit-address-family
 !
 address-family ipv4 vrf vpnA
 redistribute ospf 1 match internal external 1 external 2
 network 7.7.100.5 mask 255.255.255.255
 exit-address-family


R5#s ip bgp vpnv4 all sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
7.7.4.4         4   100      21      31      190    0    0 00:11:49       20

R5#s ip ospf ne

Neighbor ID     Pri   State           Dead Time   Address         Interface
7.7.4.4           0   FULL/  -           -        7.7.100.4       OSPF_SL3
7.7.7.7           0   FULL/  -           -        7.7.0.129       OSPF_VL2
7.7.7.7           1   FULL/DR         00:00:37    7.7.0.129       FastEthernet0/1 




tclsh
foreach address {
7.7.1.1
7.7.2.2
7.7.3.3
7.7.7.7
7.7.8.8
7.7.9.9
7.7.10.10
} {ping vrf vpnA $address rep 3}










 

BGP and IGP next hop alignment

When overlaying BGP onto an IGP topology you need to mindful that the next hop addresses align with the igp routing of those next hops. If there are differences then routing loops may occur.

R5#trace 200.200.200.200

Type escape sequence to abort.
Tracing the route to 200.200.200.200

  1 7.7.70.3 16 msec 16 msec 20 msec
  2 7.7.70.3 !H  *  !H


before changing next hop

router bgp 4
 no synchronization
 bgp log-neighbor-changes
 neighbor 7.7.3.3 remote-as 44
 neighbor 7.7.3.3 ebgp-multihop 10
 neighbor 7.7.3.3 update-source Loopback0
 neighbor 7.7.3.3 soft-reconfiguration inbound
 neighbor 7.7.3.3 route-map SETLP in
 neighbor 7.7.3.3 route-map SETMED out
 neighbor 7.7.4.4 remote-as 4
 neighbor 7.7.4.4 update-source Loopback0
 neighbor 7.7.4.4 next-hop-self
 neighbor 7.7.4.4 soft-reconfiguration inbound
 neighbor 7.7.4.4 route-map nh1 in
 no auto-summary

route-map nh1 permit 10
 set ip next-hop 7.7.70.4


Need this because

R5#s ip route | inc 7.7.4.0
D EX    7.7.4.0 [170/26140160] via 7.7.70.3, 07:08:35, Serial0/0
R5#

logon

FOR REMOTE-ACCESS TO LAB
cisco.ccieguru.com port 2100
user name:  richard
password : win3net

Deleting BGP Communities

BGP communities are passed between bgp peers when the 'send community' attribute is set with the neighbor. However what if there is a requirement to delete one of the communities from a list associated with a route!?

Consider the topology below. The route 1.1.1.0/24 is advertised by R1 to R2 and the route has community attributes 'no-advertise' and 'internet'.    R2 has an iBGP peering with R3 and the send-community attribute is set.   Initially by default R3 does not receive the route as a direct result of the no-advertise community.  The requirement is for R3 to have the BGP route 1.1.1.0/24 with only the internet attribute.

The solution relies on the 'set comm-list' command. This enables communities matched by the community-list to be removed.  Below i attach the working config from R2.

R2

ip community-list standard RIC permit no-advertise

route-map RIC permit 10
 set comm-list RIC delete

router bgp 1
 neighbor 192.168.12.1 remote-as 2
 neighbor 192.168.12.1 route-map RIC in

OSPF Distance command

The OSPF distance command can be used in a number of different ways.   I found the first one is well documented on the doc cd in the ospf routing section. However  the next three are strangely absent therein.  There is some info under the general distance command but this does not detail its use in OSPF.

I) distance ospf {external/inter-area/intra-area} AD

II) distance AD - this sets the distance for all routes

III) distance AD {ip-address wild-card-mask} - this sets the distance for all routes learned from a specific source-router. The source router is the RID of the link-state router that origininated the route!!!

IV) distance AD (ip-address wild-card0mask} ACL  identical to the previous command but it is applied to only a subset of routes that match the ACL.

IPV6 Multicast

IPv6 multicast rears its head on V4 of the CCIE blueprint.  If you know the basics of IPv4 multicast then the basics of IPv6 multicast should be pretty straightforward.   In fact with IPv6 its not even  necessary to define interfaces as multicast capable! Once ipv6 multicast routing is enabled on the router the interfaces become multicast enabled as well.

Here is a config example between just 2 routers connected via an ethernet interface: R1---R2. The basic steps are
i) enable ipv6 multicast routing
ii) define the rp
iii) join an interface with a multicast group

R1

Ipv6 multicast-routing

ipv6 pim rp-address 2002::2

R2

Ipv6 multicast-routing

Int lo0

   ipv6 mld join-group FF04::2

ipv6 pim rp-address 2002::2

With the above configuration an IPV6 PIM neighbourship forms between R1 and R2

The show ipv6 pim group-map command can be used to see a that a multicast address is associated with the RP.

Finally i test the multicast group with a ping

BGP adjacency problem

In this post i detail a recent problem encountered with a flapping BGP adjacency and a number of ways to resolve.

R1 has a BGP adjacency with R2. However this is continually flapping (see below).

The routers are peering using Loopback 0s that are reachable via OSPF.     The issue arises because as the BGP peering comes up the Loopback prefixes are advertised over the BGP adjacency.  OSPF AD is 110 whereas the eBGP route AD is 20. Hence the Loopback routes becomes preferred over the BGP adjacency. This is a type of recursive loop and not allowed (Just as learning the destination of the tunnel over the tunnel itself).     The adjacency is dropped and the whole process starts again.

I have detailed three solutions to the problem here

1) Block the Loopback prefixes from being received

On R2

ip prefix-list ric seq 5 deny 1.1.1.1/32
ip prefix-list ric seq 10 permit 0.0.0.0/0 le 32

router bgp 2
    neighbor 1.1.1.1 prefix-list ric in

2) Modify the distance of OSPF to be preferred over an eBGP route

router ospf 1
distance  ospf intra-area 19

3) Make use of the BGP backdoor command to raise the AD of the BGP route to 200.

router bgp 1
net 2.2.2.2 mask 255.255.255.255 backdoor

Once the command is used the route to 2.2.2.2 shows up in the BGP table as a RIB failure.  Use of the show ip bgp rib command completes the verification.