• Home   /  
  • Archive by category "1"

6-5 Bgp Case Study

Background
The International Travel Agency (ITA) needs both its core network and its Travel Data Providers (TDP) network set up. Configure each network to run EIGRP, and use BGP to advertise routes between the two.

Note: This lab uses Cisco 1841 routers with Cisco IOS Release 12.4(24)T1 and the Advanced IP Services image c1841 -advipservicesk9-mz.124-24.T1 .bin. The switch is a Cisco WS-C2960-24TT-L with the Cisco IOS image c2960-lanbasek9-mz.122-46.SE.bin, You can use other routers (such as a 2801 or 2811), switches (such as a 2950), and Cisco IOS Software versions if they have comparable capabilities and features. Depending on the router or switch model and Cisco IOS Software version, the commands available and output produced might vary from what is shown in this lab.

Notes:
__________________________________________________________________________________
Router Interface Summary Table

Tcl Script Verification (Instructor Version)
The Tcl script will fail for some remote AS addresses because the pings are sourced by default from the closest interface, which the end router might not have a route back to. If you want to see successful pings to a remote AS address, you source the ping from a loopback interface using the source argument to the ping or use an extended ping.

The syntax for a ping with a source argument is ping address source interface.

In addition to this, most remote AS physical interfaces will fail because they are not being advertised via the local EIGRP process or BGP. This is normal.

The following Tcl scripts were run with the advertised loopback source interface specified. All pings to all addresses are successful for routers R1, R2, and R3. Router R4 pings fail to the AS 65001 internal WAN link interface addresses because they are not advertised.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

tclsh

foreachaddress{

10.1.1.1

10.2.2.2

10.20.0.1

10.20.1.1

10.20.2.1

10.20.3.1

10.3.3.3

172.16.0.1

172.16.4.1

172.16.8.1

172.16.12.1

10.1.102.1

10.1.102.2

10.1.103.1

10.1.103.3

10.1.203.2

10.1.203.3

192.168.14.1

192.168.14.2

192.168.34.1

192.168.34.2

}{

ping$address source Loopback1}

R1#tclsh

R1(tcl)#

R1(tcl)#foreach address {

+>(tcl)#10.1.1.1

+>(tcl)#10.2.2.2

+>(tcl)#10.20.0.1

+>(tcl)#10.20.1.1

+>(tcl)#10.20.2.1

+>(tcl)#10.20.3.1

+>(tcl)#10.3.3.3

+>(tcl)#172.16.0.1

+>(tcl)#172.16.4.1

+>(tcl)#172.16.8.1

+>(tcl)#172.16.12.1

+>(tcl)#10.1.102.1

+>(tcl)#10.1.102.2

+>(tcl)#10.1.103.1

+>(tcl)#10.1.103.3

+>(tcl)#10.1.203.2

+>(tcl)#10.1.203.3

+>(tcl)#192.168.14.1

+>(tcl)#192.168.14.2

+>(tcl)#192.168.34.1

+>(tcl)#192.168.34.2

+>(tcl)#} {

+>(tcl)#ping $address source Loopback1}

Type escape sequence toabort.

Sending5,100-byteICMP Echos to10.1.1.1,timeout is2seconds:

Packet sent withasource address of10.1.1.1

!!!!!

Success rate is100percent(5/5),round-trip min/avg/max=1/1/1ms

Type escape sequence toabort.

Sending5,

BGP route-reflectors (RRs) are considered a scalability tool that allows network designers to steer away from BGP full mesh requirements. Classical iBGP split horizon rules mandate that updates received on eBGP sessions should be forwarded on all iBGP and eBGP sessions, but updates received on an iBGP session should be forwarded only on all eBGP sessions. This requires the BGP edge or boundary router (ASBR) to send updates to all other BGP-enabled routers in its own AS directly through individual iBGP sessions to each BGP router. RRs modify the iBGP split horizon rule and allow a specific router, under certain conditions, to forward all incoming iBGP updates to an outgoing iBGP session. This router is called a route-reflector.

Figure 6-5 shows a typical MPLS VPN-based network where, in the absence of RRs, whenever a new PE is introduced, each existing PE in the service provider network will require an additional BGP neighbor command associating it to the new PE. In BGP, updates received by a peer in an AS are not allowed to be forwarded to another peer within the same AS. Therefore, a BGP network must be fully meshed, with all peers adjacent to one another, as far as BGP routing updates are concerned. If the number of PEs becomes substantial enough to make this operation impractical (that is, adding neighbor commands in every PE), BGP RRs are recommended. RRs obviate the need to fully mesh the BGP peers and avoid the addition of neighbor commands to each PE. With RRs, the PEs would only require neighbors defined for each RR. Any updates, including VRF information, would be sent to the RR alone. The RRs are then responsible for propagating information received from PEs to all other PEs. Each time a new Edge LSR or PE is added, a neighbor statement pointing to the RR needs to be added on the new PE router, and on the RR, a neighbor statement pointing to the PE must be added.

Figure 6-5. RRs

RRs are also useful in the event of a route change in the customer network. Without RRs, the PE that locally terminates that portion of the customer network would have to update every PE peer participating in that VPN. RRs, therefore, help remove the burden of BGP updates from the PE.

RR Deployment Methods

In MPLS-based VPN networks, RRs can be deployed in several ways.

Option 1 – Using PE Router as VPNv4 RR

In this option, the PE device is used as a RR. This type of setup is not recommended due to additional constraints of memory and CPU imposed on the PE router, which is handling both the functions of providing services to client edge routers as well as reflecting routes to several other PEs in the same MPLS domain. Figure 6-6 provides an illustration of PE routers, PE6-RR1 and PE7-RR2, which are being used as VPNv4 RRs.

Figure 6-6. PE Routers as RRs

 

Option 2 – Using P Router as IPv4 and VPNv4 RR

In this scenario, the provider (P) router is used both as an IPv4 and VPNv4 RR. The P router, in this case, handles not only the function of route reflection for IPv4 and VPNv4 routes, but also performs data forwarding operations for IPv4 traffic and VPNv4 traffic. Figure 6-7 shows a scenario in which the P routers, P1-RR1 and P2-RR2, are IPv4 RRs for the ISP's IPv4 network, which provides Internet services for Customer C and D. At the same time, those RRs serve as IPv4 and VPNv4 RR for the MPLS-enabled network, routing VPNv4 prefixes for VPNA and VPNB sites, as well as providing Internet services to those VPN sites. This scenario may not scale well in large MPLS VPN environments due to memory and CPU constraints imposed on the RR that not only provides IPv4 and VPNv4 routing services but also data forwarding functionality.

Figure 6-7. P Routers as IPv4 and VPNv4 RRs

 

Option 3 – Using P Router as RR Only for VPNv4

In this scenario, the P router is used only as a VPNv4 RR. The P router will forward both control and data plane forwarding for VPN sites only.

Figure 6-8 shows the scenario in which RRs P1-RR1 and P2-RR2 are used for reflecting only VPNv4 routes and forwarding all data traffic between VPN client sites. This implementation can be used in large-scale MPLS VPN environments in which the provider network wants to isolate IPv4 functionality on the VPNv4 RR; however, this can increase the provider's cost to maintain a dedicated RR for IPv4 routing and a dedicated RR for VPNv4 routes.

Figure 6-8. P Router Reflecting Only VPNv4 Routes

 

Option 4 – Dedicated Router as RR for IPv4 and VPNv4

In this scenario, an additional router performs the function of reflecting IPv4 and VPNv4 routes. The router does not perform any data forwarding functions.

Figure 6-9 highlights the scenario in which P1-RR1 and P2-RR2 perform the function of reflecting VPNv4 and IPv4 routes and not that of data forwarding. This also increases the provider's operational costs because the provider has to dedicate routers as RRs for IPv4 and VPNv4 prefixes as well as ensure their PE routers have physical connectivity with each other for data forwarding functionality or are connected to a dedicated P router, which will perform data forwarding functionality.

Figure 6-9. Dedicated IPv4 and VPNv4 RR for Control Plane Functionality

 

Option 5 – Dedicated Router as RR for Only VPNv4

In this approach, the RR performs the task of reflecting only VPNv4 routes and not that of data forwarding. This approach also requires a dedicated router that can handle this functionality.

Figure 6-10 shows an MPLS environment adopting this approach. RR1 and RR2 reflect only VPNv4 routes and perform no data forwarding function. Using this approach, considerable savings in CPU and performance improvements can be realized but at the cost of additional routers providing provider router functionality and increased cost in providing physical connectivity between PE to P routers.

Figure 6-10. Dedicated VPNv4 RR for Control Plane Functionality

 

Option 6 – Partitioned RRs

This scenario is used primarily in large-scale environments in which using the dedicated VPNv4 RR does not scale to the demands of a large provider carrying a large number of VPNv4 prefixes.

In this approach, as shown in Figure 6-11, RR1 reflects VPNv4 routes only for VPNA, and RR2 reflects VPNv4 routes only for VPNB. There are no mandatory requirements that the RR in this approach should not perform the data forwarding function. However, the decision to forward data traffic or not should be made after evaluating future network growth. The drawback would be the additional cost of maintaining separate routers for performing P router functionality and the cost of connectivity between PE and P routers. The complexity of the network could increase with the use of partitioned RRs.

Figure 6-11. Route Partitioning Using RRs

 

Configuring P Router as RR Only for VPNv4 Prefixes (Option 3)

The objective of this configuration scenario is to demonstrate the RR configuration when the P router serves as an RR and performs both the control plane and data forwarding functionality for VPNv4 prefixes only (option 3). To implement this configuration, the network topology shown in Figure 6-1 is used except that P1-AS1-RR (for this configuration, the scenario hostname for P1-AS1 in Figure 6-1 is P1-AS1-RR) is configured as a RR peering with PE routers PE1-AS1 and PE2-AS1. PE routers will be configured to peer with the RRs only.

Configuration Flowchart for P Router as RR for Only VPNv4 Prefixes

The configuration flowchart for implementing this scenario is shown in Figure 6-12.

Figure 6-12. Configuration Flowchart to Implement RR

 

Configuration Step for PE Routers PE1-AS1 and PE2-AS1

To configure BGP peering on the PE routers PE1-AS1 and PE2-AS1 with the RR P1-AS1-RR, BGP routing on the PE routers must be configured and BGP neighbors activated. Enable global BGP routing on PE1-AS1 and PE2-AS1 routers and activate the BGP RR neighbors on the PE routers for VPNv4 route exchange only. Example 6-10 shows the configuration for defining P1-AS1-RR as the BGP neighbor on the PE router PE1-AS1. Use the same steps to configure PE2-AS1.

Example 6-10. Configure BGP Routing on PE Routers and Activate BGP Neighbors

PE1-AS1(config)#router bgp 1 PE1-AS1(config-router)#neighbor 10.10.10.100 remote-as 1 PE1-AS1(config-router)#neighbor 10.10.10.100 update-source Loopback0 PE1-AS1(config-router)#no bgp default ipv4-unicast PE1-AS1(config-router)# address-family ipv4 PE1-AS1(config-router-af)#no neighbor 10.10.10.100 activate PE1-AS1(config-router-af)#address-family vpnv4 PE1-AS1(config-router-af)#neighbor 10.10.10.100 activate PE1-AS1(config-router-af)#neighbor 10.10.10.100 send-community extended PE1-AS1(config-router-af)#exit-address-family

 

Configuration Step for P Router as RR for Only VPNv4 Prefixes

To configure the RR P1-AS1-RR, configure the P router as VPNv4 RR. Enable global BGP routing on the P router, P1-AS1-RR. Example 6-11 shows the configuration procedure to enable global BGP routing, define the BGP relationship with PE routers PE1-AS1 and PE2-AS1, activate them for VPNv4 route-exchange, and configure the PE routers as clients for the route-reflection process.

Example 6-11. Configure Provider Router as VPNv4 RR

P1-AS1-RR(config)#router bgp 1 P1-AS1-RR(config-router)#neighbor 10.10.10.101 remote-as 1 P1-AS1-RR(config-router)#neighbor 10.10.10.101 update-source Loopback0 P1-AS1-RR(config-router)#neighbor 10.10.10.102 remote-as 1 P1-AS1-RR(config-router)#neighbor 10.10.10.102 update-source Loopback0 P1-AS1-RR(config-router)#no bgp default ipv4-unicast P1-AS1-RR(config-router)#address-family ipv4 P1-AS1-RR(config-router-af)#no neighbor 10.10.10.101 activate P1-AS1-RR(config-router-af)#no neighbor 10.10.10.102 activate P1-AS1-RR(config-router-af)#exit P1-AS1-RR(config-router)#address-family vpnv4 P1-AS1-RR(config-router-af)#neighbor 10.10.10.102 route-reflector-client P1-AS1-RR(config-router-af)#neighbor 10.10.10.102 route-reflector-client P1-AS1-RR(config-router-af)#neighbor 10.10.10.101 activate P1-AS1-RR(config-router-af)#neighbor 10.10.10.102 activate

 

CE Configurations

Refer to Example 6-4 for CE configurations.

P1-AS1-RR, PE1-AS1, and PE2-AS1 Final Configuration for MPLS VPN Using RRs

Example 6-12 outlines the final relevant configurations for PE1-AS1, PE2-AS1, and P1-AS1-RR implementing MPLS VPN for sites using the P router as a VPNv4 RR. Refer to Example 6-5 for the remaining configurations pertaining to each router.

Example 6-12. Relevant Configurations

hostname PE1-AS1 ! !For the remainder configuration refer to example 6-5 ! router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community extended exit-address-family __________________________________________________________________________ hostname PE2-AS1 ! !For the remainder configuration refer to example 6-5 ! router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community extended exit-address-family __________________________________________________________________________ hostname P1-AS1-RR ! !For the remainder configuration refer to example 6-5 ! router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 route-reflector-client exit-address-family

 

Verifying MPLS VPNs Using RRs

The steps to verify MPLS VPNs using RRs are

Step 1.

Verify BGP neighbor relationship on PE1-AS1 and PE2-AS1 – Verify the BGP neighbor relationship. Example 6-13 shows PE1-AS1 and PE2-AS1 have a BGP relationship with the CE routers for VRF VRF-BGP and have received prefixes from those peers.
 

Example 6-13. Verify BGP Neighbor Relationship

P1-AS1-RR#show ip bgp vpnv4 all summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.10.10.101 4 1 26 26 9 0 0 00:03:10 2 10.10.10.102 4 1 17 19 9 0 0 00:03:20 2  

Step 2.

Verify BGP VPNv4 routing table on P1-AS1-RR and PE1-AS1 – Check the BGP VPNv4 routing table to see if the routes are received as expected. Example 6-14 shows that P1-AS1-RR and PE1-AS1 receive the routes as expected.
 

Example 6-14. Verify BGP VPNv4 Routing Table on P1-AS1-RR and PE1-AS1

P1-AS1-RR#show ip bgp vpnv4 all BGP table version is 9, local router ID is 10.10.10.100 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 *>i172.16.10.0/24 10.10.10.101 0 100 0 65001 i *>i172.16.20.0/24 10.10.10.102 0 100 0 65002 i Route Distinguisher: 1:200 *>i192.168.10.0 10.10.10.101 0 100 0 65001 i *>i192.168.20.0 10.10.10.102 0 100 0 65001 i _______________________________________________________________________________ PE1-AS1#show ip bgp vpnv4 all BGP table version is 15, local router ID is 10.10.10.101 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 (default for vrf Cust_A) *> 172.16.10.0/24 172.16.1.2 0 0 65001 i *>i172.16.20.0/24 10.10.10.102 0 100 0 65002 i Route Distinguisher: 1:200 (default for vrf Cust_B) *> 192.168.10.0 192.168.1.2 0 0 65001 i *>i192.168.20.0 10.10.10.102 0 100 0 65001 i  

Step 3.

Verify end-to-end connectivity via ping – Verify end-to-end connectivity between the Customer A sites as well as Customer B sites. Example 6-15 shows the result of the ping.
 

Example 6-15. Verify End-to-End Connectivity via Ping

CE1-A#ping 172.16.20.1 source 172.16.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds: Packet sent with a source address of 172.16.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/84 ms ________________________________________________________________________ CE1-B#ping 192.168.20.1 source 192.168.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: Packet sent with a source address of 192.168.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/80 ms  

Partitioned RRs

Existing RRs carrying VPNv4 routes will not scale to meet the demands of continually expanding MPLS VPN networks. Large MPLS VPN providers might have to resort to partitioning or segregating VPNv4 prefixes based on route targets or any other BGP attributes, for example, standard BGP communities, to accommodate a large number of VPNv4 routes.

Figure 6-13 shows a basic MPLS VPN network in which P1-RR accepts only VPN-A VPNv4 prefixes with a route-target value of 1:100, and P2-RR accepts only VPN-B VPNv4 prefixes with a route-target value of 1:200.

Figure 6-13. Route Partitioning

In order to receive all the routing information required for proper operation, all PE routers may need to have BGP sessions with all RRs. Further resource optimization can be achieved if the PE routers peer only with the relevant RRs. This deployment, although optimal, may lead to the providers incurring additional management and configuration complexity. Partitioning of RRs can be achieved by configuring

  • Outbound or inbound filters – Outbound filters on the PE routers or inbound filters on RRs. In both cases, the filtering can be performed with a route-map, matching routes on any BGP attribute that is usually on route target or standard BGP community. Outbound filters (ORF) on the PE routers reduce bandwidth utilization and CPU utilization of the RRs. The disadvantage with outbound filters is that the service providers may incur additional operational burden due to constant maintenance required for these filters on all PE routers. On the other hand, inbound filters on RRs are optimal from a maintenance perspective, but may increase the CPU utilization of the RRs.
  • BGP RR groups – Configure the inbound route-target filter on the BGP RR by using the bgp rr-group command. This command performs the same function as a route-map. However, it is configured under the BGP routing process and applies to all BGP neighbors. Also, another important operational detail is that the extended community access-list maintained on the RR is downloaded as an outbound filter to the PE routers through the ORF functionality. The route-map based input filter cannot be downloaded via ORF functionality.

As an alternate solution, the VPNv4 routing information can also be partitioned based on standard BGP communities. In the first design, outbound updates on the PE routers are filtered. Because the PE routers have to attach standard BGP community to the VPNv4 routes, the filtering of outbound VPNv4 routing updates based on the standard BGP community does not represent an additional maintenance burden.

The second design is to attach standard BGP communities to the VPNv4 routes on the PE routers and perform the filtering on the RRs, either in the inbound or outbound direction. This design achieves a clear separation of the marking of customer routes from the partitioning of VPNv4 routing information. Inbound filtering is preferred, because it reduces the volume of VPNv4 routing information on RRs.

RR Partitioning Using BGP Inbound Route-Target Filters

Figure 6-14 is similar to Figure 6-1 except that a second RR (P2-AS1-RR2) has been added to the topology. P1-AS1-RR1 and P2-AS1-RR2 perform both control and data plane functionality for VPNA and VPNB sites. As previously demonstrated, the configured route targets on PE1-AS1 and PE2-AS1 for VPNA and VPNB are 1:100 and 1:200, respectively. To demonstrate route partitioning, P1-AS1-RR1 will accept routes only for VPN-A (Cust_A) and P2-AS1-RR2 will accept routes only for VPN-B (Cust_B).

Figure 6-14. MPLS Network Implementing Route Partitioning Using Inbound Route-Target Filters

Figure 6-15 shows the flowchart to configure route partitioning using inbound route-target filters on RRs.

Figure 6-15. Configuration Steps for Partitioning Routes Using Inbound Route-Target Filters

 

Route-Partitioning Configuration Steps on the P Routers P1-RR and P2-RR

The configurations steps for the RRs are the same as those demonstrated in the section "Configuring P Router as RR Only for VPNv4 Prefixes (Option 3)." In addition to those steps, the following steps are required to configure route partitioning on the RRs:

Step 1.

Create an extended-community access-list – The first step is to create an extended-community access-list on the RR that permits routes with the appropriate route-target value. P1-AS1-RR1 accepts only VPNv4 routes with the route target 1:100, and P2-AS1-RR2 accepts only VPNv4 prefixes with a route-target value of 1:200. Example 6-16 illustrates the configuration steps for creating an extended-community access-list.
 

Example 6-16. Create an Extended-Community Access-List

P1-AS1-RR1(config)#ip extcommunity-list standard VPNA P1-AS1-RR1(config-extcomm-list)#permit rt 1:100 ________________________________________________________________ P2-AS1-RR2(config)#ip extcommunity-list standard VPNB P2-AS1-RR2(config-extcomm-list)#permit rt 1:200  

Step 2.

Define the route-target based inbound filter – In this step, you configure the bgp rr-group command under the BGP routing process on the RRs. The extended-community list number should match that of the access-list configured in Step 1. Example 6-17 illustrates the steps to define the route-target based inbound filter on P1-AS1-RR1 and P2-AS1-RR2.
 

Example 6-17. Define the Route-Target Based Inbound Filter

P1-AS1-RR1(config)#router bgp 1 P1-AS1-RR1(config-router)#address-family vpnv4 P1-AS1-RR1(config-router-af)#bgp rr-group VPNA ________________________________________________________________ P2-AS1-RR2(config)#router bgp 1 P2-AS1-RR2(config-router)#address-family vpnv4 P2-AS1-RR2(config-router-af)#bgp rr-group VPNB  

PE1-AS1, PE2-AS1, P1-AS1-RR1, and P2-AS1-RR2 Final Configuration for Partitioned RRs

Example 6-18 shows only the additional configurations on PE1-AS1, PE2-AS1, and P1-AS1-RR1. The complete configuration is shown for P2-AS1-RR2. For the remaining configurations, refer to Example 6-5.

Example 6-18. PE1-AS1, PE2-AS1, P1-AS1-RR1, and P2-AS1-RR2 Final Configurations for Partitioned RRs

hostname PE1-AS1 ! !Refer to example 6-5 for the rest of the configuration router bgp 1 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community extended exit-address-family __________________________________________________________________________ hostname PE2-AS1 ! !Refer to example 6-5 for the rest of the configuration router bgp 1 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community extended exit-address-family __________________________________________________________________________ hostname P1-AS1-RR1 ! !Refer to example 6-5 ! router bgp 1 no bgp default ipv4-unicast neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 route-reflector-client neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community extended neighbor 10.10.10.103 route-reflector-client bgp rr-group VPNA exit-address-family ! ip extcommunity-list standard VPNA permit rt 1:100 __________________________________________________________________________ hostname P2-AS1-RR2 ! mpls ldp router-id Loopback0 ! interface Loopback0 ip address 10.10.10.103 255.255.255.255 ! interface Serial0/0 ip address 10.10.10.10 255.255.255.252 mpls ip ! interface Serial1/0 ip address 10.10.10.14 255.255.255.252 mpls ip ! interface Serial2/0 ip address 10.10.10.18 255.255.255.252 mpls ip ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no bgp default ipv4-unicast neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 route-reflector-client neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community extended neighbor 10.10.10.100 route-reflector-client bgp rr-group VPNB exit-address-family ! ip extcommunity-list standard VPNB permit rt 1:200

 

Verifying Partitioned RRs

The steps to verify partitioned RRs are

Step 1.

Verify BGP VPNv4 routing table on P1-AS1-RR1 and P2-AS1-RR2 – Verify the BGP VPNv4 routing table on P1-AS1-RR1 and P2-AS1-RR2. Example 6-19 shows that P1-AS1-RR1 shows VPNv4 routes for VPNA and P2-AS1-RR2 sees VPNv4 routes for VPNB.
 

Example 6-19. Verify BGP VPNv4 Routing Table on P1-AS1-RR1 and P2-AS1-RR2

P1-AS1-RR1# show ip bgp vpnv4 all BGP table version is 3, local router ID is 10.10.10.100 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 *>i172.16.10.0/24 10.10.10.101 0 100 0 65001 i *>i172.16.20.0/24 10.10.10.102 0 100 0 65002 i ______________________________________________________________________________ P2-AS1-RR2#show ip bgp vpnv4 all BGP table version is 23, local router ID is 10.10.10.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:200 *>i192.168.10.0 10.10.10.101 0 100 0 65001 i *>i192.168.20.0 10.10.10.102 0 100 0 65001 i  

Step 2.

Verify end-to-end connectivity via ping – Ping the edge customer networks from CE1-A to CE2-A and CE1-B to CE2-B. Example 6-20 shows the successful ping outputs.
 

Example 6-20. Verify End-to-End Connectivity via Ping

CE1-A#ping 172.16.20.1 source 172.16.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds: Packet sent with a source address of 172.16.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/81/88 ms ________________________________________________________________________ CE1-B#ping 192.168.20.1 source 192.168.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: Packet sent with a source address of 192.168.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/82/88 ms  

RR Partitioning Using Standard BGP Communities

This configuration scenario demonstrates RR partitioning using standard BGP communities. The same topology as what's shown in Figure 6-14 is used for this scenario. The objective is to ensure that P1-AS1-RR1 will accept routes only for VPNA (Cust_A) and P2-AS1-RR2 will accept routes only for VPNB (Cust_B).

Figure 6-16 shows the steps to configure route partitioning using standard BGP communities.

Figure 6-16. Configuration Flowchart for Partitioning Routes Using Standard BGP Communities

 

Configuration Steps on the PE Routers PE1-AS1 and PE2-AS1

On the PE routers, set the community for the CE1-A and CE1-B prefixes on PE1-AS1 and for CE2-A and CE2-B on PE2-AS1. Example 6-21 shows the additional relevant configuration on PE1-AS1. Repeat the same steps on PE2-AS1.

Example 6-21. PE1-AS1 Configuration

PE1-AS1(config)#router bgp 1 PE1-AS1(config-router)#address-family vpnv4 PE1-AS1(config-router-af)#neighbor 10.10.10.100 send-community both PE1-AS1(config-router-af)#neighbor 10.10.10.100 route-map allow1 out PE1-AS1(config-router-af)#neighbor 10.10.10.103 send-community both PE1-AS1(config-router-af)#neighbor 10.10.10.103 route-map allow2 out PE1-AS1(config-router-af)#exit-address-family PE1-AS1(config-router)#exit PE1-AS1(config)#ip bgp-community new-format PE1-AS1(config)#access-list 10 permit 172.16.10.0 0.0.0.255 PE1-AS1(config)#access-list 20 permit 192.168.10.0 0.0.0.255 PE1-AS1(config)#route-map allow2 permit 10 PE1-AS1(config-route-map)# match ip address 20 PE1-AS1(config-route-map)# set community 1:200 PE1-AS1(config-route-map)#exit PE1-AS1(config)#route-map allow1 permit 10 PE1-AS1(config-route-map)# match ip address 10 PE1-AS1(config-route-map)# set community 1:100

 

Configuration Steps on the P Routers P1-AS1-RR1 and P2-AS1-RR2

The configuration steps for the RRs are the same as demonstrated in the section "Configuration Step for PE Routers PE1-AS1 and PE2-AS1." In addition to that step, the following steps are required to configure route partitioning on the RRs using standard BGP communities:

Step 1.

Create a community access-list and route-map policy – Create a community access-list that permits the route with the route-target value that is to be accepted by the RR. P1-RR is accepting only VPNv4 with the route target 1:100, and P2-RR is accepting only VPNv4 prefixes with the route-target value of 1:200. Prior to this, make sure that the routers are configured with ip bgp-community new-format. Example 6-22 shows the relevant configuration on the RRs.
 

Example 6-22. Create a Community Access-List and Route-Map Policy

P1-AS1-RR1(config)#ip community-list 1 permit 1:100 P1-AS1-RR1(config)#route-map allow-VPNA permit 10 P1-AS1-RR1(config-route-map)#match community 1 ________________________________________________________________ P2-AS1-RR2(config)#ip community-list 1 permit 1:200 P2-AS1-RR2(config)#route-map allow-VPNB permit 10 P2-AS1-RR2(config-route-map)#match community 1  

Step 2.

Apply the route-map to the BGP PE neighbor – In this step, apply the route-map to the relevant BGP neighbors. This is shown in Example 6-23.
 

Example 6-23. Apply the Route-Map to the BGP Neighbors

P1-AS1-RR1(config)#router bgp 1 P1-AS1-RR1(config-router)#address-family vpnv4 P1-AS1-RR1(config-router-af)#neighbor 10.10.10.101 route-map allow-VPNA in P1-AS1-RR1(config-router-af)#neighbor 10.10.10.102 route-map allow-VPNA in P1-AS1-RR1(config-router-af)#neighbor 10.10.10.103 route-map allow-VPNA in ______________________________________________________________________________ P2-AS1-RR2(config)#router bgp 1 P2-AS1-RR2(config-router)#address-family vpnv4 P2-AS1-RR2(config-router-af)#neighbor 10.10.10.101 route-map allow-VPNB in P2-AS1-RR2(config-router-af)#neighbor 10.10.10.102 route-map allow-VPNB in P2-AS1-RR2(config-router-af)#neighbor 10.10.10.100 route-map allow-VPNB in  

PE1-AS1 and PE2-AS1 Final Configuration for Partitioned RRs

Example 6-24 shows the relevant configuration on the PE1-AS1, PE2-AS1, and P routers.

Example 6-24. Relevant Configuration on the PE1-AS1, PE2-AS1, and P Routers

!PE1-AS1 Router Configuration router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community both neighbor 10.10.10.100 route-map allow1 out neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community both neighbor 10.10.10.103 route-map allow2 out exit-address-family ! ip bgp-community new-format ! access-list 10 permit 172.16.10.0 0.0.0.255 access-list 20 permit 192.168.10.0 0.0.0.255 ! route-map allow1 permit 10 match ip address 10 set community 1:100 ! route-map allow2 permit 10 match ip address 20 set community 1:200 ________________________________________________________________ !PE2-AS1 Router Configuration router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community both neighbor 10.10.10.100 route-map allow1 out neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community both neighbor 10.10.10.103 route-map allow2 out exit-address-family ! ip bgp-community new-format ! access-list 10 permit 172.16.20.0 0.0.0.255 access-list 20 permit 192.168.20.0 0.0.0.255 ! route-map allow1 permit 10 match ip address 10 set community 1:100 ! route-map allow2 permit 10 match ip address 20 set community 1:200 ________________________________________________________________ !P1-RR Router Configuration router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community both neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.101 route-map allow-VPNA in neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community both neighbor 10.10.10.102 route-reflector-client neighbor 10.10.10.102 route-map allow-VPNA in neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community both neighbor 10.10.10.103 route-map allow-VPNA in exit-address-family ! ip bgp-community new-format ip community-list 1 permit 1:100 ! route-map allow-VPNA permit 10 match community 1 ________________________________________________________________ !P2-RR Router Configuration router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community both neighbor 10.10.10.100 route-map allow-VPNB in neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community both neighbor 10.10.10.101 route-reflector-client neighbor 10.10.10.101 route-map allow-VPNB in neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community both neighbor 10.10.10.102 route-reflector-client neighbor 10.10.10.102 route-map allow-VPNB in exit-address-family ! ip bgp-community new-format ip community-list 1 permit 1:200 ! route-map allow-VPNB permit 10 match community 1

 

Verifying Partitioned RRs Using Standard BGP Communities

The steps to verify partitioned RRs using standard BGP communities are

Step 1.

Verify BGP VPNv4 routing table on P1-RR and P2-RR – Example 6-25 shows the VPNv4 routing table on P1-AS1-RR1 and P2-AS1-RR2.
 

Example 6-25. show ip bgp vpnv4 all on P1-AS1-RR1 and P2-AS1-RR2

P1-AS1-RR1# show ip bgp vpnv4 all BGP table version is 3, local router ID is 10.10.10.100 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 *>i172.16.10.0/24 10.10.10.101 0 100 0 65001 i *>i172.16.20.0/24 10.10.10.102 0 100 0 65002 i _______________________________________________________________________________ P2-AS1-RR2#show ip bgp vpnv4 all BGP table version is 3, local router ID is 10.10.10.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:200 *>i192.168.10.0 10.10.10.101 0 100 0 65001 i *>i192.168.20.0 10.10.10.102 0 100 0 65001 i  

Step 2.

Verify connectivity via ping – Example 6-26 demonstrates this step.
 

Example 6-26. Verify Connectivity via Ping

CE1-A#ping 172.16.20.1 source 172.16.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds: Packet sent with a source address of 172.16.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/84 ms __________________________________________________________________________ CE1-B#ping 192.168.20.1 source 192.168.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: Packet sent with a source address of 192.168.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/84 ms  

RRs and Peer Groups

A BGP peer group is a collection of BGP neighbors that share the same outbound policies. Instead of configuring each neighbor with the same policy individually, peer groups allow the user to group the policies that can be applied to individual peers. Using BGP peer groups reduces the amount of system resources (CPU and memory) used by allowing the routing table to be checked only once and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. The reduction in system resources, however, depends on the number of peer group members, the number of prefixes in the table, and the number of prefixes that are being advertised or being imported. The other benefit of peer groups is also to help in simplifying the BGP configuration.

Figure 6-17 shows an MPLS VPN network where P1-AS1-RR and P2-AS1-RR are RRs for PE1-AS1 and PE2-AS1 PE routers. PE1-AS1 and PE2-AS1 are both members of peer group group1 and group2 on P1-AS1-RR and P2-AS1-RR, respectively.

Figure 6-17. PE1-AS1 and PE2-AS1 Members of Peer Group group1 and group2

Figure 6-18 shows the steps to configure peer groups in a RR-based MPLS VPN network.

Figure 6-18. Configuration Steps for RRs with Peer Groups

 

Configuring Peer Groups on P Routers P1-AS1-RR1 and P2-AS1-RR2

The steps to configure peer groups on P routers P1-AS1-RR1 and P2-AS1-RR2 are

Step 1.

Define the peer groups on P1-AS1-RR1 and P2-AS1-RR2 – The first step in configuring the peer groups is to define the peer group name on the P1-AS1-RR1 and P2-AS1-RR2 routers, as displayed in Example 6-27.
 

Example 6-27. Define Peer Groups

P1-AS1-RR1(config)#router bgp 1 P1-AS1-RR1(config-router)#neighbor group1 peer-group ________________________________________________________________ P2-AS1-RR2(config)#router bgp 1 P2-AS1-RR2(config-router)#neighbor group2 peer-group  

Step 2.

Configure the remote AS for the peer group – In this step, the remote BGP AS is defined for the peer group. Example 6-28 shows the relevant steps.
 

Example 6-28. Configure the Remote AS for the Peer Group

P1-AS1-RR1(config-router)#neighbor group1 remote-as 1 ________________________________________________________________ P2-AS1-RR2(config-router)#neighbor group2 remote-as 1  

Step 3.

Associate the peer group with remote BGP PE neighbors – In this step, associate the peer group with the remote BGP PE neighbors in the VPNv4 address-family. This configuration step is shown in Example 6-29.
 

Example 6-29. Associate the Peer Group with Remote BGP PE Neighbors

P1-AS1-RR1(config-router)#address-family vpnv4 P1-AS1-RR1(config-router-af)#neighbor 10.10.10.101 peer-group group1 P1-AS1-RR1(config-router-af)#neighbor 10.10.10.102 peer-group group1 ______________________________________________________________________ P2-AS1-RR2(config-router)#address-family vpnv4 P2-AS1-RR2(config-router-af)#neighbor 10.10.10.101 peer-group group2 P2-AS1-RR2(config-router-af)#neighbor 10.10.10.102 peer-group group2
In this case, the router is configured to serve only as a VPNv4 RR to reflect VPNv4 prefixes and, as a result, configuring the neighbor peer-group command in the VPNv4 address-family would result in the Example 6-30 configuration to be inserted in the P1-AS1-RR1 and P2-AS1-RR2 configuration.
 

Example 6-30. neighbor Peer Group Command

address-family ipv4 neighbor group1 activate no neighbor 10.10.10.101 activate no neighbor 10.10.10.102 activate  

Step 4.

Configure the routers to function as RRs – To enable the routers for RR functionality, you need to enter the VPNv4 address-family configuration mode and use the neighbor route-reflector-client command. Example 6-31 demonstrates this configuration step.
 

Example 6-31. Configure the Routers to Function as RRs

P1-AS1-RR1(config-router)#address-family vpnv4 P1-AS1-RR1(config-router-af)# neighbor group1 route-reflector-client _____________________________________________________________________ P2-AS1-RR2(config-router)#address-family vpnv4 P2-AS1-RR2(config-router-af)# neighbor group2 route-reflector-client
Another key point to note is that the peer groups need not be activated under the VPNv4 address-family. They are automatically activated when peer-group parameters are defined. The message in Example 6-32 is shown if the peer group is activated under the VPNv4 address-family.
 

Example 6-32. Message if the Peer Group Is Activated Under the VPNv4 Address-Family

P1-AS1-RR12(config-router)#address-family vpnv4 P1-AS1-RR12(config-router-af)#neighbor group1 activate % Peergroups are automatically activated when parameters are configured  

P1-AS1-RR1 and P2-AS1-RR2 Final RR Configurations with Peer Groups

Example 6-33 shows the relevant configuration on P1-AS1-RR1 and P2-AS1-RR2.

Example 6-33. P1-AS1-RR1 and P2-AS1-RR2 Configuration

!P1-AS1-RR1 Router Configuration router bgp 1 no bgp default ipv4-unicast neighbor group1 peer-group neighbor group1 remote-as 1 neighbor group1 update-source Loopback0 neighbor 10.10.10.101 peer-group group1 neighbor 10.10.10.102 peer-group group1 neighbor 10.10.10.103 remote-as 1 neighbor 10.10.10.103 update-source Loopback0 ! address-family vpnv4 neighbor group1 send-community extended neighbor group1 route-reflector-client neighbor 10.10.10.101 activate neighbor 10.10.10.102 activate neighbor 10.10.10.103 activate neighbor 10.10.10.103 send-community extended exit-address-family ________________________________________________________________ !P2-AS1-RR2 Router Configuration router bgp 1 no bgp default ipv4-unicast neighbor group2 peer-group neighbor group2 remote-as 1 neighbor group2 update-source Loopback0 neighbor 10.10.10.100 remote-as 1 neighbor 10.10.10.100 update-source Loopback0 neighbor 10.10.10.101 peer-group group2 neighbor 10.10.10.102 peer-group group2 ! address-family ipv4 no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor group2 send-community extended neighbor group2 route-reflector-client neighbor 10.10.10.100 activate neighbor 10.10.10.100 send-community extended neighbor 10.10.10.101 activate neighbor 10.10.10.102 activate exit-address-family

 

Verifying Peer Groups and RRs

The steps to verify peer groups and RRs are

Step 1.

Verify peer group formation – Verify if PE1-AS1 and PE2-AS1 are part of the BGP peer groups group1 and group2. Example 6-34 shows that PE1-AS1 and PE2-AS1 are part of peer group group1 on P1-AS1-RR1 and part of group2 on P2-AS1-RR2.
 

Example 6-34. Verify Peer Group Formation

P1-AS1-RR1#show ip bgp peer-group group1 BGP peer-group is group1, remote AS 1 BGP version 4 Default minimum time between advertisement runs is 5 seconds For address family: VPNv4 Unicast BGP neighbor is group1, peer-group internal, members: 10.10.10.101 10.10.10.102 Index 0, Offset 0, Mask 0x0 Route-Reflector Client Update messages formatted 0, replicated 0 Number of NLRIs in the update sent: max 0, min 0 ________________________________________________________________ P2-AS1-RR2#show ip bgp peer-group group2 BGP peer-group is group2, remote AS 1 BGP version 4 Default minimum time between advertisement runs is 5 seconds For address family: VPNv4 Unicast BGP neighbor is group2, peer-group internal, members: 10.10.10.101 10.10.10.102 Index 0, Offset 0, Mask 0x0 Route-Reflector Client Update messages formatted 0, replicated 0 Number of NLRIs in the update sent: max 0, min 0  

Step 2.

Verify BGP VPNv4 routing table on P1-AS1-RR1 – Check the BGP VPNv4 routing table to see if routes are received as expected. Example 6-35 shows that P1-AS1-RR1 and PE1-AS1 receive the routes as expected.
 

Example 6-35. Verify BGP VPNv4 Routing Table on P1-AS1-RR

P1-AS1-RR1#show ip bgp vpnv4 all BGP table version is 5, local router ID is 10.10.10.100 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 * i172.16.10.0/24 10.10.10.101 0 100 0 65001 i *>i 10.10.10.101 0 100 0 65001 i * i172.16.20.0/24 10.10.10.102 0 100 0 65002 i *>i 10.10.10.102 0 100 0 65002 i Route Distinguisher: 1:200 * i192.168.10.0 10.10.10.101 0 100 0 65001 i *>i 10.10.10.101 0 100 0 65001 i * i192.168.20.0 10.10.10.102 0 100 0 65001 i *>i 10.10.10.102 0 100 0 65001 i ________________________________________________________________________________ PE1-AS1#show ip bgp vpnv4 all BGP table version is 9, local router ID is 10.10.10.101 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 (default for vrf Cust_A) *> 172.16.10.0/24 172.16.1.2 0 0 65001 i * i172.16.20.0/24 10.10.10.102 0 100 0 65002 i *>i 10.10.10.102 0 100 0 65002 i Route Distinguisher: 1:200 (default for vrf Cust_B) *> 192.168.10.0 192.168.1.2 0 0 65001 i * i192.168.20.0 10.10.10.102 0 100 0 65001 i *>i 10.10.10.102 0 100 0 65001 i  

Step 3.

Verify end-to-end connectivity via ping – Verify end-to-end connectivity between the Customer A sites as well as Customer B sites. Example 6-36 shows the result of the ping.
 

Example 6-36. Verify End-to-End Connectivity via Ping

CE1-A#ping 172.16.20.1 source 172.16.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds: Packet sent with a source address of 172.16.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/84 ms _______________________________________________________________________ CE1-B#ping 192.168.20.1 source 192.168.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: Packet sent with a source address of 192.168.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/80 ms  

BGP Confederations

BGP confederation is another BGP scalability tool that can reduce the iBGP mesh inside an AS. In BGP confederation, an AS is divided into multiple autonomous systems or sub autonomous systems, and these are assigned to a single confederation. Each sub AS will be fully iBGP meshed. Each sub AS will also have connections to other autonomous systems inside the confederation. Each sub AS will be eBGP peered with other sub autonomous systems. Although the sub autonomous systems will be eBGP peered to other autonomous systems within the confederation, they will exchange routing as if they were using iBGP; next hop, metric, and local preference information will be preserved. To the outside world, the confederation (the group of autonomous systems) will look like a single AS.

Figure 6-19 shows a provider network, AS 1, which is divided into multiple sub autonomous systems, AS 100, AS 101, and AS 102. Each sub AS is iBGP fully meshed, and there is eBGP peering between the sub autonomous systems. To BGP CE neighbors, the confederation (the group of autonomous systems, AS 100, 101, and 102) will look like a single BGP AS 1.

Figure 6-19. BGP Confederation

Figure 6-20 shows an MPLS VPN network in which BGP AS 1 is divided into three sub autonomous systems, AS 100, AS 101, and AS 102. P1-AS1, PE1-AS1, and PE2-AS1 are in AS 100, AS 101, and AS 102.

Figure 6-20. MPLS VPN Network Using BGP Confederations

 

Configuration Flowchart to Implement BGP Confederations

Figure 6-21 shows the configuration flowchart to implement BGP confederation in the provider core.

Figure 6-21. Configuration Flowchart to Implement BGP Confederations

 

Configuring BGP Confederation for P Routers PE1-AS1, PE2-AS1, and P1-AS1

The steps to configure BGP confederation for the topology shown in Figure 6-20 are as follows. The steps are shown for PE1-AS1 and PE2-AS1. Configure P1-AS1 similarly:

Step 1.

Define BGP confederation identifier and peers – The first step is to configure the BGP confederation identifier and peers. Example 6-37 demonstrates the step.
 

Example 6-37. Define BGP Confederation Identifier and Peers

PE1-AS1(config)#router bgp 101 PE1-AS1(config-router)# bgp confederation identifier 1 PE1-AS1(config-router)# bgp confederation peers 100 102 ________________________________________________________________ PE2-AS1(config)#router bgp 102 PE2-AS1(config-router)# bgp confederation identifier 1 PE2-AS1(config-router)#bgp confederation peers 100 101  

Step 2.

Define BGP neighbors – In this step, the remote BGP AS for the peer group is defined. Example 6-38 shows the relevant steps.
 

Example 6-38. Define BGP Neighbors

PE1-AS1(config-router)# neighbor 10.10.10.102 remote-as 102 PE1-AS1(config-router)# neighbor 10.10.10.102 ebgp-multihop 2 PE1-AS1(config-router)# neighbor 10.10.10.102 update-source Loopback0 PE1-AS1(config-router)# neighbor 10.10.10.200 remote-as 100 PE1-AS1(config-router)# neighbor 10.10.10.200 ebgp-multihop 2 PE1-AS1(config-router)# neighbor 10.10.10.200 update-source Loopback0 _______________________________________________________________________ PE2-AS1(config-router)# neighbor 10.10.10.101 remote-as 101 PE2-AS1(config-router)# neighbor 10.10.10.101 ebgp-multihop 2 PE2-AS1(config-router)# neighbor 10.10.10.101 update-source Loopback0 PE2-AS1(config-router)# neighbor 10.10.10.200 remote-as 100 PE2-AS1(config-router)# neighbor 10.10.10.200 ebgp-multihop 2 PE2-AS1(config-router)# neighbor 10.10.10.200 update-source Loopback0  

Step 3.

Activate the BGP neighbors for VPNv4 exchange – In this step, activate the BGP neighbors to exchange VPNv4 prefixes. Example 6-39 demonstrates this configuration step.
 

Example 6-39. Activate the BGP Neighbors for VPNv4 Exchange

PE1-AS1(config-router)# address-family vpnv4 PE1-AS1(config-router-af)# neighbor 10.10.10.102 activate PE1-AS1(config-router-af)# neighbor 10.10.10.102 next-hop-self PE1-AS1(config-router-af)# neighbor 10.10.10.200 activate PE1-AS1(config-router-af)# neighbor 10.10.10.200 next-hop-self __________________________________________________________________ PE2-AS1(config-router)# address-family vpnv4 PE2-AS1(config-router-af)# neighbor 10.10.10.101 activate PE2-AS1(config-router-af)# neighbor 10.10.10.101 next-hop-self PE2-AS1(config-router-af)# neighbor 10.10.10.200 activate PE2-AS1(config-router-af)# neighbor 10.10.10.200 next-hop-self
To ensure that the router sends and receives only VPNv4 prefixes, use the configuration shown in Example 6-40 in BGP router configuration mode.
 

Example 6-40. Ensuring That the Router Sends and Receives Only VPNv4 Prefixes

PE1-AS1(config)#router bgp 101 PE1-AS1(config-router)# no bgp default ipv4-unicast PE1-AS1(config-router)# no address-family ipv4  

Final BGP Confederation Configuration on PE1-AS1, P1-AS1, and PE2-AS1

Example 6-41 shows the relevant configuration on PE1-AS1, P1-AS1, and PE2-AS1.

Example 6-41. PE1-AS1, P1-AS1, and PE2-AS1 Configuration

hostname PE1-AS1 !Refer to examples on VRF, interface, and OSPF configuration ! router bgp 101 no bgp default ipv4-unicast bgp log-neighbor-changes bgp confederation identifier 1 bgp confederation peers 100 102 neighbor 10.10.10.102 remote-as 102 neighbor 10.10.10.102 ebgp-multihop 2 neighbor 10.10.10.102 update-source Loopback0 neighbor 10.10.10.200 remote-as 100 neighbor 10.10.10.200 ebgp-multihop 2 neighbor 10.10.10.200 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 next-hop-self neighbor 10.10.10.200 activate neighbor 10.10.10.200 send-community extended neighbor 10.10.10.200 next-hop-self exit-address-family ! address-family ipv4 vrf Cust_B neighbor 192.168.1.2 remote-as 65001 neighbor 192.168.1.2 activate neighbor 192.168.1.2 as-override no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf Cust_A neighbor 172.16.1.2 remote-as 65001 neighbor 172.16.1.2 activate no auto-summary no synchronization exit-address-family __________________________________________________________________________ hostname P1-AS1 !Refer to examples on VRF, interface, and OSPF configuration> ! router bgp 100 no bgp default ipv4-unicast bgp log-neighbor-changes bgp confederation identifier 1 bgp confederation peers 101 102 neighbor 10.10.10.101 remote-as 101 neighbor 10.10.10.101 ebgp-multihop 2 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.102 remote-as 102 neighbor 10.10.10.102 ebgp-multihop 2 neighbor 10.10.10.102 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 next-hop-self neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended neighbor 10.10.10.102 next-hop-self exit-address-family __________________________________________________________________________ hostname PE2-AS1 !Refer to examples on VRF, interface, and OSPF configuration> ! router bgp 102 no bgp default ipv4-unicast bgp log-neighbor-changes bgp confederation identifier 1 bgp confederation peers 100 101 neighbor 10.10.10.101 remote-as 101 neighbor 10.10.10.101 ebgp-multihop 2 neighbor 10.10.10.101 update-source Loopback0 neighbor 10.10.10.200 remote-as 100 neighbor 10.10.10.200 ebgp-multihop 2 neighbor 10.10.10.200 update-source Loopback0 ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended neighbor 10.10.10.101 next-hop-self neighbor 10.10.10.200 activate neighbor 10.10.10.200 send-community extended neighbor 10.10.10.200 next-hop-self exit-address-family ! address-family ipv4 vrf Cust_B neighbor 192.168.2.2 remote-as 65001 neighbor 192.168.2.2 activate neighbor 192.168.2.2 as-override no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf Cust_A neighbor 172.16.2.2 remote-as 65002 neighbor 172.16.2.2 activate no auto-summary no synchronization exit-address-family

 

Verifying BGP Confederations

The steps to verify BGP confederations are

Step 1.

Verify BGP neighbors – Example 6-42 shows that PE1-AS1 has established a BGP neighbor relationship with PE2-AS1 in AS 102 and P1-AS1 in AS 100.
 

Example 6-42. Verify BGP Neighbor Between BGP Confederations

PE1-AS1#show ip bgp vpnv4 all summary BGP router identifier 10.10.10.101, local AS number 101 BGP table version is 21, main routing table version 21 4 network entries using 532 bytes of memory 4 path entries using 272 bytes of memory 6/4 BGP path/bestpath attribute entries using 648 bytes of memory 3 BGP AS-PATH entries using 72 bytes of memory 2 BGP extended community entries using 48 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 1572 total bytes of memory BGP activity 4/0 prefixes, 8/4 paths, scan interval 15 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.10.10.102 4 102 34 34 19 0 0 00:00:25 2 10.10.10.200 4 100 27 46 19 0 0 00:00:47 0 172.16.1.2 4 65001 22 25 17 0 0 00:17:04 1 192.168.1.2 4 65001 22 25 17 0 0 00:17:03 1  

Step 2.

Verify the BGP VPNv4 routing table on PE routers – Check the BGP VPNv4 routing table to see if routes are received as expected. Example 6-43 shows that PE1-AS1 and PE2-AS1 receive the routes as expected.
 

Example 6-43. Verify BGP VPNv4 on PE Routers

PE1-AS1#show ip bgp vpnv4 all BGP table version is 9, local router ID is 10.10.10.101 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 (default for vrf Cust_A) *> 172.16.10.0/24 172.16.1.2 0 0 65001 i *> 172.16.20.0/24 10.10.10.102 0 100 0 (102) 65002 i Route Distinguisher: 1:200 (default for vrf Cust_B) *> 192.168.10.0 192.168.1.2 0 0 65001 i *> 192.168.20.0 10.10.10.102 0 100 0 (102) 65001 i _______________________________________________________________________________ PE2-AS1#show ip bgp vpnv4 all BGP table version is 9, local router ID is 10.10.10.102 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1:100 (default for vrf Cust_A) *> 172.16.10.0/24 10.10.10.101 0 100 0 (101) 65001 i *> 172.16.20.0/24 172.16.2.2 0 0 65002 i Route Distinguisher: 1:200 (default for vrf Cust_B) *> 192.168.10.0 10.10.10.101 0 100 0 (101) 65001 i *> 192.168.20.0 192.168.2.2 0 0 65001 i  

Step 3.

Verify end-to-end connectivity via ping – Verify end-to-end connectivity between the Customer A sites and the Customer B sites. Example 6-44 shows the result of the ping.
 

Example 6-44. Verify End-to-End Connectivity via Ping

CE1-A#ping 172.16.20.1 source 172.16.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds: Packet sent with a source address of 172.16.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/84 ms __________________________________________________________________________ CE1-B#ping 192.168.20.1 source 192.168.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: Packet sent with a source address of 192.168.10.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/80 ms  

MPLS Overview

Basic MPLS Configuration

Basic MPLS VPN Overview and Configuration

PE-CE Routing Protocol-Static and RIP

PE-CE Routing Protocol-OSPF and EIGRP

Implementing BGP in MPLS VPNs

Inter-Provider VPNs

Carrier Supporting Carriers

MPLS Traffic Engineering

Implementing VPNs with Layer 2 Tunneling Protocol Version 3

Any Transport over MPLS (AToM)

Virtual Private LAN Service (VPLS)

Implementing Quality of Service in MPLS Networks

MPLS Features and Case Studies

show all menu

One thought on “6-5 Bgp Case Study

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *