GET VPN, it is all about group.


GET VPN uses a group security paradigm comparing to the traditional point-to-point security paradigm like DMVPN, GRE IPSec or SSL. Do not confuse with any-to-any mesh which is the result of n(n-1)/2 point-to-point security associations between n peers.

We are talking about group security association (SA), group states and group keys.

Because each group member doesn’t know in advance about other group members, a central entity named key server (KS) need to manage GET VPN control plane: group member registration, distribute group keys and do the rekeys (updating security policy and group keys).

Once a group member has registered with the KS to a group, it can take care of the data plane encrypted communication with any of the other group members using the received group key and group security policy.

GET VPN doesn’t create the VPN perimeter (like Frame Relay for example), all group members and the key server are supposed to be already in the same VPN.

This lab is not supposed to be a comprehensive GET-VPN reference. Because it is all about a stories and process dynamics, I opted for a more visual approach: less words, more pictures.

I included a table summarizing the key characteristics of GET-VPN comparing with traditional IPSec, followed by a step-by-step animation of the main processes of GET-VPN.

Only then, I provide some configurations of the core MPLS-VPN and GET-VPN key server and group member.

And finally the offline lab with a myriad of useful commands collected during a running session.

By rushing to the CLI, you can easily drown yourself in a cup of water 🙂 Better take the time to understand the overall process, then configuration and troubleshooting will be straightforward and more instructive.

Outline:

  • Comparison of GETVPN vs traditional IPSec.
  • Summary of the main concepts
  • Step-by-step GETVPN process
  • Lab details
    • MPLS-VPN configuration
      • Core
      • PE_CE
    • GET VPN configuration
      • Basic Group member template
      • Basic key server
  • Offline lab
  • Troubleshooting

Comparison table (IPSec GET vpn)

IPSec Crypto GET Crypto
Main concept Per link point-to-point security paradigm: each pair of devices establishes a separate security association.(figure3) Group-based security paradigm: allows a set of network entities to connect through a single group security association.
Encapsulation Requires the establishment of tunnel to secure the traffic between encrypting gateways.- a new header is added to the packet (figure4).- Limited QoS preservation (only ToS). Tuneless: does not use tunnels and preserves the original src/dst IP in the header of the encrypted packet for optimal routing (figure6).- Preserve same established routing path.- Preserve entire QoS parameter set.
Multicast – Traditional IPSec encapsulate multicast into encrypted PTP unicast GRE tunnels.- Alternatively, inefficient multicast replication at the HUB using DMVPN with many multicast deployment restrictions (RP, MA and multicast source location at the HUB). GET VPN is particularly suited for multicast traffic encryption with native support. The WAN multicast infrastructure is used to transport encrypted GET-VPN multicast traffic.
Infrastructure IPSec creates Overlay VPN and secures it over the Internet. • Relies on MPLS/VPLS Any-to-Any VPN.• Direct Flows between all CE.• Leverages Existing VPNs.- GET VPN suited for enterprises running over MPLS private networks.- GET-VPN ONLY secure an already established VPN (MPLS-VPN), it doesn’t create it
Management – Per-link security management: Each pair holds a security association for each other.- Resource consumption.- Alternative centralized HUB-based management with DMVPN though heterogeneous protocol suite (mGRE, NHRP)- Less scalable. – Full mesh direct communications between sites.Same group members hold a single security association; don’t care about others on the group.- Relies on centralized membership management through key servers :A centralized entity (Key Server manage the control plane) and not involved in the data plane communication.Data plane communications don’t require transport through a hub HUB entity.- Low latency/jitter.

– More scalable.

Security Perimeter Per-link All Sites within the same group.
Routing Two routing levels(figure5a):Core routing+Overlay routing between encrypting gateways Single end-to-end routing level with MPLS-VPN as the underlying VPN infrastructure(figure6a).
Traditional IPSec PTP SAs between GMs

Figure3- Traditional IPSec PTP SAs between GMs

Figure4- Traditional IPSec PTP Packet

Figure4- Traditional IPSec PTP Packet

Figure5a-Traditional IPSec routing overlay

Figure5a-Traditional IPSec routing overlay

Figure6- Get-VPN IPSec PTP Packet + TEK

Figure6- Get-VPN IPSec PTP Packet + TEK

Figure6a- GETVPN end-to-end routing

Figure6a- GETVPN end-to-end routing

 Summary of the main concepts

The key server manages the control operations (group member registration and rekey and policy distribution) on a different plane, initially, under the protection of IKE, after that, protected by a common key (KEK) (figure7/8).

Rekey process can be done using unicast (default) or multicast.

Any-to-any GM communications are performed on a separate data plane using the received TEK (Traffic Encryption Key) (figure9).

COOP (Co-operative key server protocol)

  • A Key Server redundancy feature allowing key server communication to synchronize the keying information.

GDOI protocol (Group Domain of Interpretation)

  • Used for policy & key deployment with group members.

Make sure to differentiate between registration vs rekey and between authentication vs authorization processes.

A-Registration process:

1- There is two types of KS-GM authentications):

  • Shared key (deployed on the lab): a simple secret key shared (hopefully out-of-band) by the KS and all GMs (or per-pair).
  • RSA (CA-based authentication): uses asymmetric encryption with public/private key pair and requires PKI infrastructure:
    • Enrollment phase:
      • Client (GM) gets CA certificate (CA public key signed with CA private key)
      • Client enrollment with CA
        • Client sends its own certificate (client public key signed with client private key)
        • CA signs the client certificate with its own (CA) public key and sends it to the client.
    • Peer-to-peer (GM-to-KS) authentication:
      • Peers exchanges and verify each other signatures using CA public key.

2- Authorization (during registration):

  • KS verifies the group id number of the GM: If this id number is a valid and the GM has provided valid Internet Key Exchange (IKE) credentials, the key server sends the SA policy and the Keys to the group member.

B-Rekey process (after registration): uses asymmetric encryption with public/private key pair:

  • The Primary KS uses the private & public keys (asymmetric) generated before the registration and export them to other secondary KSs.
  • Primary KS generates Group control / data plane keys, TEK and KEK (symmetric keys)
  • The KS signs TEK/KEK + policy with its own private key and sends them to GMs(figure7/8/9)
  • The KS distributes public key to all GMs.
  • GMs check the rekeys with the received KS public key
Figure7- Control plane: GM registration

Figure7- Control plane: GM registration

Figure8- Control plane: rekey using KEK key

Figure8- Control plane: rekey using KEK key

Figure9- GM data plane communications using TEK key

Figure9- GM data plane communications using TEK key

Step-by-step GET-VPN process


Click the picture below to browse the swf animation explaining GET-VPN interactions:
Selection_001_04_10

Lab details

Here is the lab topology, pretty straight forward, three group members and one key server with MPLS-VPN as the underlying VPN infrastructure.

Figure1- High-level lab topology

Figure1- High-level lab topology

Figure2- Low-level lab topology

Figure2- Low-level lab topology

GET VPN:

  • Customer equipments (CE) R9, R10 and R12 play the role of GETVPN group members (GM),
  • R11 plays the role of the key server.

MPLS_VPN:

  • R2, R3 and R5 are the MPLS-VPN PEs (Provider Edge equipment)

MPLS-VPN configuration:

Make sure the underlying MPLS-VPN topology works fine and all connectivity are successful before touching GET VPN.

For the sake of simplicity, a single MPLS core router (label switching router) R4 is used and static routing between CE_PE.

Figure2- Low-level MPLS-VPN lab infrastructure (MPLS LSR + PEs)

Figure2- Low-level MPLS-VPN lab infrastructure (MPLS LSR + PEs)

MPLS-VPN basic configuration with PE-CE static routing

  • R4 the MPLS core router (LSR) is configured as BGP route reflector.
  • Make sure PE equipments (wan interfaces and loopback rid’s) are reachable though MPLS core OSPF.
  • Enable MPLS on the interfaces facing PE’s.
  • Each PE (R2, R3 and R5) has similar configuration and a template can be used to scale client numbers.

Because this lab is not focused on MPLS-VPN, a simple PE-CE static routing is deployed. Each client has its interface and static route in the appropriate VRF. Generally multiple clients (VRFs) separately coexist in a single PE and the core transport is done through vpnv4 to and from other PE’s (figure2a)

Figure2a- MPLS-VPN PE Virtual Router Forwarding

Figure2a- MPLS-VPN PE Virtual Router Forwarding

With PE-CE static routing, only one-side redistribution is done, from static to vpnv4 address family.

You will find all details in the offline lab.

R4 (MPLS LSR router)

interface Loopback0ip address 10.0.0.4 255.255.255.255ip ospf 2345 area 0!

interface FastEthernet0/0

ip address 192.168.45.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

!

interface FastEthernet0/1

ip address 192.168.24.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

!

interface FastEthernet1/0

ip address 192.168.34.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

!

router ospf 2345

!

router bgp 2345

no synchronization

bgp router-id 4.4.4.4

network 192.168.24.0

network 192.168.34.0

network 192.168.45.0

neighbor 10.0.0.2 remote-as 2345

neighbor 10.0.0.2 route-reflector-client

neighbor 10.0.0.3 remote-as 2345

neighbor 10.0.0.3 route-reflector-client

neighbor 10.0.0.5 remote-as 2345

neighbor 10.0.0.5 route-reflector-client

no auto-summary

!

address-family vpnv4

neighbor 10.0.0.2 activate

neighbor 10.0.0.2 send-community extended

neighbor 10.0.0.2 route-reflector-client

neighbor 10.0.0.3 activate

neighbor 10.0.0.3 send-community extended

neighbor 10.0.0.3 route-reflector-client

neighbor 10.0.0.5 activate

neighbor 10.0.0.5 send-community extended

neighbor 10.0.0.5 route-reflector-client

exit-address-family

R4#sh ip bgp summBGP router identifier 4.4.4.4, local AS number 2345…10.0.0.2 4 2345 134 137 4 0 0 02:09:53 0

10.0.0.3 4 2345 134 137 4 0 0 02:09:43 0

10.0.0.5 4 2345 136 137 4 0 0 02:09:52 0

R4#

GET-VPN configuration:

Key server:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2!crypto isakmp key cisco address 192.168.103.10

crypto isakmp key cisco address 192.168.29.9

crypto isakmp key cisco address 192.168.125.12

!

crypto ipsec transform-set transform128 esp-aes esp-sha-hmac

!

crypto ipsec profile profile1

set security-association lifetime seconds 7200

set transform-set transform128

!

crypto gdoi group gdoi-group1

identity number 91011

server local

rekey algorithm aes 128

rekey retransmit 10 number 2

rekey authentication mypubkey rsa rekey-rsa

rekey transport unicast

sa ipsec 1

profile profile1

match address ipv4 getvpn-acl

address ipv4 192.168.115.11

!

interface FastEthernet0/0

ip address 192.168.115.11 255.255.255.0

!

ip access-list extended getvpn-acl

deny icmp any any

deny udp any eq 848 any eq 848

deny tcp any any eq 22

deny tcp any eq 22 any

deny tcp any any eq tacacs

deny tcp any eq tacacs any

deny tcp any any eq bgp

deny tcp any eq bgp any

deny ospf any any

deny eigrp any any

deny udp any any eq ntp

deny udp any eq ntp any

deny udp any any eq snmp

deny udp any eq snmp any

deny udp any any eq snmptrap

deny udp any eq snmptrap any

deny udp any any eq syslog

deny udp any eq syslog any

permit ip any any

You can recognize usual IPSec components: crypto policy, shared keys, transform-sets wrapped in an ipsec profile, followed by GETVPN GDOI group policy ( ipsec profile and group policy (group-id, symm. encr. Algorithm, asymmetric keys to use during rekey authentication and getvpn acl)

The GETVPN ACL defines what will not be encrypted; consider your own topology needs:

  • Exclude already encrypted traffic (https, ssh, etc.)
  • Exclude PE-CE routing protocols.
  • Exclude GETVPN control plane protocols( gdoi udp 848, tacacs, radius, etc.)
  • Exclude Management/monitoring protocols (snmp. syslog, device remote access, icmp, etc.)

Group member template:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2crypto isakmp key cisco address 192.168.115.11!

crypto gdoi group gdoi-group1

identity number 91011

server address ipv4 192.168.115.11

!

crypto map map-group1 10 gdoi

set group gdoi-group1

!

interface FastEthernet0/0

crypto map map-group1

All control plane parameters are controlled by the KS, GMs are dumb devices. All they have to know is how to initiate IKE phase1 for preshared or RSA authentication with the KSs to register and get the keys, which groups they want to join, to which KS they will talk (if many configured) and finally, the get crypto-map assigned to the outbound interface.

Troubleshooting:

When practicing or during tenacious data plane issues, a good idea is to use ESP-NULL, the null encryption, where the encryption process is engaged, but packets are not encrypted.

This will make much easier the packet content inspection and marking between GMs.

To facilitate the deployment and the troubleshooting, think about the topology in terms of separate technology sub-domains; make sure everything works fine before moving to the next sub-domain.

  • Layer2 MPLS
  • MPLS-VPN
  • Core routing
  • PE-CE routing
  • Core SSM multicast (if not unicast rekey)
  • CA infrastructure (if you are not using shared keys to authenticate GMs to the KS)
Possible issues Possible causes
key servers doesn’t exchange all announcements Bad buffer – default buffer is not enough for large nbr of gm
Reassembly timed out Some announcement fragments are dropped or lostICMP (packet too big) denied in the pathNo fragmentation because df bit setPresence of MTU bottlenecks, multipaths, firewalls.Not tuned tcp mss “ip tcp adjust-mss”
ike failure- failed negotiation Preshared key mismatchIKE parameters mismatchTransport issues between GMs and KSs
Nothing works just after GM registration. GETVPN acl policy cause routing traffic encryption: traffic not symmetrically excluded
KS not synchronizing Check KS-KS transport: avoid making KS-KS communications dependent on GET-VPN successful transport.Keys not exported or not imported
Rekey not delivered Issue with multicast infrastructure.Issue with mVPN service.

For more detailed GETVPN troubleshooting, I urge you to watch the excellent CiscoLive session by Wen Zhang https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78699&tclass=popup

Offline lab:

Click  the picture below to browse the flash app of the offline lab:

Selection_003_04_10

References:

http://www.cisco.com/c/en/us/products/security/group-encrypted-transport-vpn/index.html

http://www.cisco.com/c/en/us/products/collateral/security/group-encrypted-transport-vpn/deployment_guide_c07_554713.html

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78699&tclass=popup

http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Aug2013/CVD-GETVPNDesignGuide-AUG13.pdf

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=7907&backBtn=true

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t11/htgetvpn.html

http://tools.ietf.org/html/rfc3547

http://tools.ietf.org/rfc/rfc4534.txt

Advertisements

BGP for large scale networks


OVERVIEW

All along this lab we will try to practice BGP deployment and focus on main concepts behind inter-autonomous system communications as well as methods used to provide scalability for large networks like service providers.

Figure1: topology

Figure 1 depicts the BGP topology needed to be deployed as well as future deployment and expansion inside some autonomous systems.

PLANNING

Let’s Suppose that ASN 12345 was assigned the range 192.168.4.0/23 and ASN 11897 192.168.6.0/23 from which an address scheme will be planned, the upcoming table details the address scheme calculation and assignment.

Table1: ASN12345 address scheme

networks advertised by BGP 192.168.4.0/23
1100 0000.1010 1000.0000 0100.0000 0000

3 bits are taken for 6 subnets (23-2=6)

 
1100 0000.1010 1000.0000 0100.0000 0000

zero subnet – 192.168.4.0/26 

(not used) 

1100 0000.1010 1000.0000 0100.0100 0000

1st subnet – 192.168.4.64/26

 
1100 0000.1010 1000.0000 0101.1000 0000

penultimate subnet – 192.168.5.128/26 

 
1100 0000.1010 1000.0000 0101.1100 0000

Last subnet – 192.168.5.192/26 

(used for PTP segments) 

PTP segments 192.168.5.192/30 
1100 0000.1010 1000.0000 0101.1100 0000

4 bits are taken for 6 subnets (24-2=14)

 
1100 0000.1010 1000.0000 0101.1100 0000

zero subnet – 192.168.5.192/30 

(not used) 

1100 0000.1010 1000.0000 0101.1100 0100

1st subnet – 192.168.5.196/30

 
1100 0000.1010 1000.0000 0101.1111 1000

penultimate subnet – 192.168.5.184/30 

 
1100 0000.1010 1000.0000 0101.1111 1100

last subnet – 192.168.5.252/30 

 
IP address assignment 
Networks advertised by BGP 

POINT-TO-POINT interconnections Segments 

Segment 

Devices 

192.168.4.64/26 

192.168.5.196/30

R1-R5 

192.168.4.192/26 

192.168.5.200/30 

R4-R5 

192.168.5.0/26 

192.168.5.204/30 

R1-R3 

192.168.5.64/26 

192.168.5.208/30 

R1-R2 

192.168.5.128/26 

192.168.5.212/30 

R3-R7(ASN27000) 

 

Table2 : ASN11897 address scheme

networks advertised by BGP 192.168.6.0/23
1100 0000.1010 1000.0000 0110.0000 0000

4 bits are taken for 14 subnets (24-2=14)

 
1100 0000.1010 1000.0000 0110.0000 0000

zero subnet – 192.168.6.0/27 

(not used) 

1100 0000.1010 1000.0000 0110.0010 0000

1st subnet – 192.168.6.32/27

 
1100 0000.1010 1000.0000 0111.1100 0000

penultimate subnet – 192.168.5.128/27 

 
1100 0000.1010 1000.0000 0111.1110 0000

Last subnet – 192.168.6.224/27 

(used for PTP segments) 

PTP segments 192.168.6.224/30 
1100 0000.1010 1000.0000 0111.1110 0000

3 bits are taken for 6 subnets (23-2=6)

 
1100 0000.1010 1000.0000 0111.1110 0000

zero subnet – 192.168.6.224/30 

(not used) 

1100 0000.1010 1000.0000 0111.1110 0100

1st subnet – 192.168.6.228/30

 
1100 0000.1010 1000.0000 0111.1111 1000

penultimate subnet – 192.168.6.248/30 

 
1100 0000.1010 1000.0000 0111.1111 1100

last subnet – 192.168.6.252/30 

(not used) 

IP address assignment 
Networks advertised by BGP 

POINT-TO-POINT interconnections Segments 

Segment 

Devices 

192.168.6.32/27 advertized by R9 

192.168.6.228/30 

R12-R9 

192.168.6.64/27 advertized by R10

192.168.6.232/30 

R8-R9 

192.168.6.96/27 advertized by R11 

192.168.6.236/30 

R12-R10 

192.168.6.128/27 advertized by R8 

192.168.6.240/30 

R12-R11 

192.168.6.160/27 advertized by R12

192.168.6.244/30

R8-R10 

 

192.168.6.248/30

R8-R11 

 

Table3 : InterAS address scheme

PTP segments 192.168.11.0/24 
1100 0000.1010 1000.0000 1011.1100 0000

6 bits are taken for 62 subnets (26-2=62)

 
1100 0000.1010 1000.0000 1011.1100 0000

zero subnet – 192.168.11.192/30 

(not used) 

1100 0000.1010 1000.0000 1011.1100 0100

1st subnet – 192.168.11.196/30

 
1100 0000.1010 1000.0000 1011.1111 1000

penultimate subnet – 192.168.11.249/30 

 
1100 0000.1010 1000.0000 0111.1111 1100

last subnet – 192.168.11.252/30 

 
IP address assignment 
Networks advertised by BGP 

POINT-TO-POINT interconnections Segments

Segment 

Devices 

– 

192.168.11.196/30 

R6(ASN26000)-R5(ASN12345) 

– 

192.168.11.200/30 

R12(ASN11897)-R5(ASN12345) 

– 

192.168.11.204/30 

R8(ASN11897)-R5(ASN12345) 

– 

192.168.11.208/30 

R8(ASN11897)-R12(ASN11897) 

 

– ASN 27000 contains only router R7 which advertize network 192.168.8.64/26 and connects to R3 (ASN12345) through 192.168.5.212/30.

– ASN 26000 contains only router R6 which advertize network 192.168.0.0/24 and connects to R5 (ASN12345) through 192.168.11.196/30.

Figure2 :address scheme

 


ANALYSIS

The first part of the lab concerns the configuration of confederations inside AS12345 also interactions with AS27000 and AS26000.

The second part focuses on configuration of route reflector, inside AS11897, with redundancy.

  1. Part I:

Before continuing, here is some concepts around “confederations” to which we will refer as we moves through the configuration:

  • c1- inside confederation full iBGP is required.
  • c2- confederation AS-PATH is used to prevent loops between confederations.
  • c3- eBGP is needed between confederations (as between AS) and the default TTL=1 therefore we need to consider increasing TTL is loopback interfaces are used to refer to BGP peers.
  • c4- Not like between AS’s, between sub-AS’s (confederations) the attribute NEXT-HOP is not changed by default.
  • c5- When choosing best routes according to As-PATH attribute confederation AN are not considered.

Let’s proceed with the configuration of confederation CONFED ASN 65000 (note that confederation/ private AS numbers are from the range 64512-65535) on R1:

R1(config)#router bgp 65000

R1(config-router)#bgp router-id 10.10.1.1

R1(config-router)#bgp confederation identifier 12345

R1(config-router)#bgp confederation peers 65001

 

R5(config)#router bgp 65001

R5(config-router)#bgp router-id 10.10.5.1

R5(config-router)#bgp confederation identifier 12345

R5(config-router)#bgp confederation peers 65000

BGP confederation deployment requires the cut of the entire configuration inside AS, this means that if you have any previous BGP configuration you have to start by performing

Router(config-router)#no router bgp

Hence, a best practice is to plan and start with confederations to prepare for future expansion.

eBGP neighboring between R1 (CONCFED ASN65000) and R5 (CONFED ASN65001)

R5(config-router)#neighbor 10.10.1.1 remote-as 65000

R5(config-router)#neighbor 10.10.1.1 ebgp-multihop 2

R5(config-router)#neighbor 10.10.1.1 update-source Loopback0

R5(config-router)#neighbor 10.10.1.1 next-hop-self

 

R1(config-router)#neighbor 10.10.5.1 remote-as 65001

R1(config-router)#neighbor 10.10.5.1 ebgp-multihop 2

R1(config-router)#neighbor 10.10.5.1 update-source loo 0

R1(config-router)#neighbor 10.10.5.1 next-hop-self

Note that R1 and R5 change NEXT-HOP attribute so learned routes between the two confederations become reachable and can be included in routing tables, as a matter of fact in this point two possible methods for IGP routing appear:

  • The first is to separate routing between CONFED ASN65000 and CONFED ASN65001 and then NEXT-HOP attribute must be changed.
  • The second is to have a unique IGP (remember that inside AS IGP are used only to provide connectivity between routers for BGP routing).
    • A flat addressing protocol like RIPv2 or EIGRP.
    • OSPF protocol with each confederation considered as an area apart and the link between R1-R5 ,or any other future routers (figure3), is the backbone network. In this particular case, many options are available for area type, stubby, totally stubby or Not-So-Stubby.

Figure3: OSPF topology

R1(config-router)#router-id 10.10.1.1

R1(config-router)#area 23 stub no-summary

R1(config-router)#network 10.10.1.1 0.0.0.0 area 0

R1(config-router)#network 192.168.5.196 0.0.0.3 area 0

R1(config-router)#network 192.168.5.204 0.0.0.3 area 23

R1(config-router)#network 192.168.5.208 0.0.0.3 area 23

 

R2(config-router)#router-id 10.10.2.1

R2(config-router)#area 23 stub no-summary

R2(config-router)#network 10.10.0.0 0.0.0.255 area 23

R2(config-router)#network 192.168.5.208 0.0.0.3 area 23

 

R3(config-router)#router-id 10.10.3.1

R3(config-router)#area 23 stub no-summary

R3(config-router)#network 192.168.5.204 0.0.0.3 area 23

R3(config-router)#network 192.168.5.212 0.0.0.3 area 23

Note that OSPF area 23 is a totally stubby area this means that it doesn’t allow LSA3 (summary from other areas), LSA5 external routes from external domains (AS27000 in occurrence) and doesn’t allow ASBR routers (no LSA7).

including the external link 192.168.5.212 in the inside OSPF network allow routes received from ASN27000 to be included in the ASN12345 with a reachable NEXT-HOP attribute. Another option is to exclude this network from OSPF and change NEXT-HOP for the eBGP session from R7.

R5(config-router)#router-id 10.10.5.1

R5(config-router)#area 45 stub no-summary

R5(config-router)#network 10.10.5.1 0.0.0.0 area 0

R5(config-router)#network 192.168.5.196 0.0.0.3 area 0

R5(config-router)#network 192.168.5.200 0.0.0.3 area 45

It’s important for both R1 an R5 to announce respectively 10.10.1.1 and 10.10.5.1 through OSPF, for BGP-RID to be reachable to each other.

R4(config-router)#router-id 10.10.4.1

R4(config-router)#area 45 stub no-summary

R4(config-router)#network 192.168.5.200 0.0.0.3 area 45

with such configuration there is no need to change NEXT-HOP attribute for R1

R1(config-router)#no neighbor 10.10.5.1 next-hop-self

It is possible to perform the following command on R5:

R5(config-router)#no neighbor 10.10.1.1 next-hop-self

But we will have to include external links into OSPF network for external routes NEXT-HOP attribute to be available, and for security reason make those interfaces passive for OSPF. To avoid any additional complexity we will keep:

R5(config-router)#neighbor 10.10.1.1 next-hop-self

Inside the confederation ASN 65000 a iBGP full mesh is required between R1, R2 and R1, this is the split horizon rule that states that routes received from an iBGP neighbor will not be sent to another iBGP neighbor because all routers are supposed to be fully meshed.

R2(config-router)#neighbor 192.168.5.209 remote-as 65000

R2(config-router)#neighbor 192.168.5.205 remote-as 65000

 

R3(config-router)#neighbor 192.168.5.206 remote-as 65000

R3(config-router)#neighbor 192.168.5.210 remote-as 65000

 

R1(config-router)#neighbor 192.168.5.210 remote-as 65000

R1(config-router)#neighbor 192.168.5.205 remote-as 65000

Between R7(ASN27000) and R3(ASN26000) no routing is needed because default NEXT-HOP attributes of received routes are directly reachable, and R7 ip address is known to R3 because was included in OSPF.

The same method like the one deployed between R5(ASN12345) and R6(ASN26000), a default route from R6 that points to R5 and static route from R5 for the BGP RID ip 10.10.6.1 that points to 192.168.11.198

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.11.197

R5(config)#ip route 10.10.6.1 255.255.255.255 192.168.11.198

Here a test of connectivity between R7(ASN27000) and R6(ASN26000)

R7#sh ip route


192.168.8.0/26 is subnetted, 1 subnets

C 192.168.8.64 is directly connected, Loopback1

192.168.4.0/26 is subnetted, 2 subnets

B 192.168.4.64 [20/0] via 192.168.5.214, 00:38:05

B 192.168.4.192 [20/0] via 192.168.5.214, 03:40:28

192.168.5.0/24 is variably subnetted, 3 subnets, 2 masks

B 192.168.5.64/26 [20/0] via 192.168.5.214, 00:56:23

B 192.168.5.0/26 [20/0] via 192.168.5.214, 00:56:23

C 192.168.5.212/30 is directly connected, Serial1/0

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

B 10.10.0.0/24 [20/0] via 192.168.5.214, 00:21:39

C 10.10.7.1/32 is directly connected, Loopback0

B 192.168.0.0/24 [20/0] via 192.168.5.214, 00:40:29

R7#

R6:

R6#sh ip route


192.168.8.0/26 is subnetted, 1 subnets

B 192.168.8.64 [20/0] via 10.10.5.1, 00:57:08

192.168.11.0/30 is subnetted, 1 subnets

C 192.168.11.196 is directly connected, Ethernet0/0

192.168.4.0/26 is subnetted, 2 subnets

B 192.168.4.64 [20/0] via 10.10.5.1, 00:38:49

B 192.168.4.192 [20/0] via 10.10.5.1, 00:57:08

192.168.5.0/26 is subnetted, 2 subnets

B 192.168.5.64 [20/0] via 10.10.5.1, 04:24:17

B 192.168.5.0 [20/0] via 10.10.5.1, 01:56:53

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

B 10.10.0.0/24 [20/0] via 10.10.5.1, 00:22:23

C 10.10.6.1/32 is directly connected, Loopback0

C 192.168.0.0/24 is directly connected, FastEthernet1/0

S* 0.0.0.0/0 [1/0] via 192.168.11.197

R6#

 

R7#trace

Protocol [ip]:

Target IP address: 192.168.0.1

Source address: 192.168.8.66

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 192.168.0.1

 

1 192.168.5.214 152 msec 120 msec 108 msec

2 192.168.5.206 252 msec 212 msec 392 msec

3 192.168.5.197 664 msec 408 msec 420 msec

4 192.168.11.198 560 msec 560 msec 772 msec

5 192.168.0.1 [AS 26000] 616 msec 652 msec 700 msec

R7#

 

  1. Part II:

During the second part we will focus on Route Reflectors deployment and their benefits.

RR is a method of managing expanding mesh topology in large autonomous systems by selecting particular routers as focal points of iBGP.

SPLIT HORIZON rule:

Learned routes from iBGP neighbors will never be sent to another iBGP neighbor, because it is supposed to be a full mesh iBGP.

With n=10 routers, the number of iBGP sessions needed is n*(n-1)/2 = 45 iBGP sessions and with 100 routers (generally service providers) 100*99/2=4950 iBGP sessions in each routers!!!!

Route Reflector will break the law of split horizon and allow a particular router to sent received prefixes from one iBGP neighbor to another, this will significantly lessen the number of iBGP sessions the client is required to maintain and a route reflector processes once UPDATE messages for all peers rather than n times for each peer.

All other client that will be served by the RR are called “clients”, certainly the physical topology must follow the logic one (Figure4 with and without RR physic connectivity).

Figure4 RR physic connectivity:

A “cluster” is called a RR with its clients and a “non-client” is a peer of RR that doesn’t belong to the cluster.

Here is some benefits of route reflector:

– No need for full mesh iBGP;

– Route propagation.

– Neighbor relationship reduced.

– Possible RR (redundancy) deployment.

– RR redundancy should be complementary with physical redundancy.

– Minimal configuration (only on RR clients are assigned).

Special attributes are affected with RR deployments:

CLUSTER_ID: by default set to RR BGP RID

CLUSTER_LIST: the RR add the CLUSTER_ID to CLUSTER_LIST before sending update, further RR discard any received prefixes with its own CLUSTER_ID in CLUSTER_LIST.

ORIGINATOR_ID: The first iBGP BGP RID peer to advertize the route into the AS, an entry point to an AS, for a route will never be its exit point from the AS.

It’s recommended for the RR to have more resources for managing iBGP sessions with clients consequently choose a client (with less resources consumed) for handling eBGP connections.

R5 is connected to both R12 and R8 through eBGP using loopback interfaces so we decided to deploy EIGRP between ASN12345 and ASN11897 to prepare for further addition of other autonomous systems:

R12(config-router)#router eigrp 1258

R12(config-router)#no auto

R12(config-router)#net 192.168.11.200 0.0.0.3

R12(config-router)#net 10.10.12.1 0.0.0.0

R12(config-router)#

*Mar 1 07:22:42.654: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1258: Neighbor 192.168.11.202 (Serial1/0) is up: new adjacency

*Mar 1 07:24:59.042: %BGP-5-ADJCHANGE: neighbor 10.10.5.1 Up

 

R8(config-router)#router eigrp 1258

R8(config-router)#no auto

R8(config-router)#net 192.168.11.204 0.0.0.3

R8(config-router)#net 10.10.8.1 0.0.0.0

R8(config-router)#

*Mar 1 07:28:26.014: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1258: Neighbor 192.168.11.206 (Serial1/0) is up: new adjacency

*Mar 1 07:30:13.806: %BGP-5-ADJCHANGE: neighbor 10.10.5.1 Up

 

R5(config-router)#router eigrp 1258

R5(config-router)#no auto

R5(config-router)#net 192.168.11.200 0.0.0.3

R5(config-router)#net 192.168.11.204 0.0.0.3

R5(config-router)#net 10.10.5.1 0.0.0.0

*Mar 1 06:42:38.886: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1258: Neighbor 192.168.11.201 (Serial1/2) is up: new adjacency

*Mar 1 06:42:52.198: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1258: Neighbor 192.168.11.205 (Serial1/3) is up: new adjacency

*Mar 1 06:44:10.098: %BGP-5-ADJCHANGE: neighbor 10.10.8.1 Up

*Mar 1 06:44:24.130: %BGP-5-ADJCHANGE: neighbor 10.10.12.1 Up

According to the physical topology both R12 and R8 can be RR one primary and secondary so each one of them will establish an iBGP neighbor relationship with clients R9, R10 and R11 and if one RR have problem connecting to particular client it still have the possibility to reach it through the second RR through the second client interface, hence the use of loopback interfaces with “neighbor” command.

Figure5: (ASN11897 IGP)


For iBGP reachability we will deploy EIGRP with asn198 (figure5) for inside hosts as follow:

R8:

router eigrp 198

passive-interface Serial1/0

network 10.10.8.1 0.0.0.0

network 192.168.6.232 0.0.0.3

network 192.168.6.244 0.0.0.3

network 192.168.6.248 0.0.0.3

network 192.168.11.208 0.0.0.3

no auto-summary

R12:

router eigrp 198

passive-interface Serial1/0

network 10.10.12.1 0.0.0.0

network 192.168.6.228 0.0.0.3

network 192.168.6.236 0.0.0.3

network 192.168.6.240 0.0.0.3

network 192.168.11.208 0.0.0.3

no auto-summary

R9:

router bgp 11897

no synchronization

bgp log-neighbor-changes

network 192.168.6.32 mask 255.255.255.224

neighbor 10.10.8.1 remote-as 11897

neighbor 10.10.8.1 update-source Loopback0

neighbor 10.10.12.1 remote-as 11897

neighbor 10.10.12.1 update-source Loopback0

no auto-summary

R10:

router eigrp 198

network 10.10.10.1 0.0.0.0

network 192.168.6.236 0.0.0.3

network 192.168.6.244 0.0.0.3

no auto-summary

R11:

router eigrp 198

network 10.10.11.1 0.0.0.0

network 192.168.6.240 0.0.0.3

network 192.168.6.248 0.0.0.3

no auto-summary

Let’s take a look over the bgp table of one of RR client, R11 for instance:

R11#sh ip bgp

BGP table version is 5, local router ID is 10.10.11.1

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

* i192.168.0.0 10.10.5.1 0 100 0 12345 26000 i

* i 10.10.5.1 0 100 0 12345 26000 i

* i192.168.4.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.4.192/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.5.0/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.5.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i 10.10.9.1 0 100 0 i

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

* i 10.10.8.1 0 100 0 i

* i192.168.6.160/27 10.10.12.1 0 100 0 i

*>i 10.10.12.1 0 100 0 i

* i192.168.8.64/26 10.10.5.1 0 100 0 12345 27000 i

* i 10.10.5.1 0 100 0 12345 27000 i

R11#

The only prefixes marked as “best” are those with NEXT-HOP attributes included in the routing table, like 10.10.12.1, 10.10.9.1 and 10.10.8.1, BUT not those with NEXT-HOP=10.10.5.1 because there is no route to such ip in the routing table:

R11# sh ip route


192.168.11.0/30 is subnetted, 1 subnets

D 192.168.11.208 [90/2172416] via 192.168.6.250, 00:47:16, Serial1/0

[90/2172416] via 192.168.6.242, 00:47:16, Serial1/1

10.0.0.0/32 is subnetted, 5 subnets

D 10.10.9.1 [90/2809856] via 192.168.6.250, 00:56:26, Serial1/0

[90/2809856] via 192.168.6.242, 00:56:26, Serial1/1

D 10.10.8.1 [90/2297856] via 192.168.6.250, 00:47:13, Serial1/0

C 10.10.11.1 is directly connected, Loopback0

D 10.10.10.1 [90/2809856] via 192.168.6.250, 00:54:01, Serial1/0

[90/2809856] via 192.168.6.242, 00:54:01, Serial1/1

D 10.10.12.1 [90/2297856] via 192.168.6.242, 00:47:13, Serial1/1

192.168.6.0/24 is variably subnetted, 10 subnets, 2 masks

C 192.168.6.96/27 is directly connected, Loopback1

B 192.168.6.32/27 [200/0] via 10.10.9.1, 00:11:40

D 192.168.6.236/30 [90/2681856] via 192.168.6.242, 00:47:14, Serial1/1

D 192.168.6.232/30 [90/2681856] via 192.168.6.250, 00:47:14, Serial1/0

D 192.168.6.228/30 [90/2681856] via 192.168.6.242, 00:47:14, Serial1/1

C 192.168.6.248/30 is directly connected, Serial1/0

D 192.168.6.244/30 [90/2681856] via 192.168.6.250, 00:47:14, Serial1/0

C 192.168.6.240/30 is directly connected, Serial1/1

B 192.168.6.160/27 [200/0] via 10.10.12.1, 00:26:39

B 192.168.6.128/27 [200/0] via 10.10.8.1, 00:25:56

R11#

ip address 10.10.5.1 belongs to the peer ASN12345, so we can:

  • a)- Use floating static routes at RR clients that point to eBGP speakers R12 and R8 primary and secondary (different administrative distances), we can use default routes to R12 and R8, the unique exit and entry points to AS11897, this is a not scalable solution.
  • b)- inject by redistribution the route to the RID of the eBGP peer R5 from R12 and R8 RIGRP 1285 routing table into EIGRP 198 routing table, this is not scalable as we will have to do that with every new AS neighbor which make this solution prone to errors.
  • c)- Change NEXT-HOP attribute on eBGP speakers R12 and R8, the easiest and th most scalable solution.

Let’s try all of those solutions:

Solution (a):

R11(config)#ip route 0.0.0.0 0.0.0.0 10.10.12.1 5

R11(config)#ip route 0.0.0.0 0.0.0.0 10.10.8.1 10

 

R9(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.230 5

R9(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.234 10

 

R10(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.238 5

R10(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.246 10

 

R11(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.242 5

R11(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.250 10

R12 will be the primary choice and in case of a failure the second route will be considered.

From R11:

R11(config)#do sh ip bgp

BGP table version is 24, local router ID is 10.10.11.1

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

* i10.10.0.0/24 10.10.5.1 0 100 0 12345 i

*>i 10.10.5.1 0 100 0 12345 i

*>i192.168.0.0 10.10.5.1 0 100 0 12345 26000 i

* i 10.10.5.1 0 100 0 12345 26000 i

*>i192.168.4.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

*>i192.168.4.192/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

*>i192.168.5.0/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

*>i192.168.5.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i 10.10.9.1 0 100 0 i

*>i192.168.6.64/27 10.10.10.1 0 100 0 i

* i 10.10.10.1 0 100 0 i

*> 192.168.6.96/27 0.0.0.0 0 32768 i

Network Next Hop Metric LocPrf Weight Path

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

* i 10.10.8.1 0 100 0 i

* i192.168.6.160/27 10.10.12.1 0 100 0 i

*>i 10.10.12.1 0 100 0 i

* i192.168.8.64/26 10.10.5.1 0 100 0 12345 27000 i

*>i 10.10.5.1 0 100 0 12345 27000 i

R11(config)#

Now all networks seem to be are available and reachable and this is confirmed by the result of “trace” command:

R11(config)#do trace

Protocol [ip]:

Target IP address: 192.168.8.65

Source address: 192.168.6.97

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 192.168.8.65

 

1 192.168.6.242 72 msec 120 msec 48 msec

2 192.168.11.202 292 msec 504 msec 324 msec

3 192.168.5.198 516 msec 404 msec 812 msec

4 192.168.5.205 560 msec 492 msec 588 msec

5 192.168.5.213 864 msec 924 msec 564 msec

R11(config)#

the path taken by tICMP traffic is R12->R5->R1->R3->R7

Solution (b):

Before continuing let’s revoke changes concerning the solution (a):

 

R9(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.230 5

R9(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.234 10

 

R10(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.238 5

R10(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.246 10

 

R11(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.242 5

R11(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.250 10

 

R11(config)#do sh ip route 10.10.5.1

% Subnet not in table

R11(config)#

 

R8#sh ip route 10.10.5.1

Routing entry for 10.10.5.1/32

Known via “eigrp 1258”, distance 90, metric 2297856, type internal

Redistributing via eigrp 1258

Last update from 192.168.11.206 on Serial1/0, 03:21:56 ago

Routing Descriptor Blocks:

* 192.168.11.206, from 192.168.11.206, 03:21:56 ago, via Serial1/0

Route metric is 2297856, traffic share count is 1

Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

 

R8#

EIGRP 1258 routing table is distinct from EIGRP 198 (figure5) that’s why R8 and R12 know about 10.10.5.1 but nor R9, R10 and R11.

This is the routing table of R11 before redistribution:

R11(config)#do sh ip bgp

BGP table version is 31, local router ID is 10.10.11.1

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

* i10.10.0.0/24 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.0.0 10.10.5.1 0 100 0 12345 26000 i

* i 10.10.5.1 0 100 0 12345 26000 i

* i192.168.4.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.4.192/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.5.0/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.5.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i 10.10.9.1 0 100 0 i

*>i192.168.6.64/27 10.10.10.1 0 100 0 i

* i 10.10.10.1 0 100 0 i

*> 192.168.6.96/27 0.0.0.0 0 32768 i

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

* i 10.10.8.1 0 100 0 i

* i192.168.6.160/27 10.10.12.1 0 100 0 i

*>i 10.10.12.1 0 100 0 i

* i192.168.8.64/26 10.10.5.1 0 100 0 12345 27000 i

* i 10.10.5.1 0 100 0 12345 27000 i

R11(config)#

Let’s redistribute this route from EIGRP 1258 into EIGRP 198:

R8#sh access-list

Standard IP access list R5ID

10 permit 10.10.5.1

R8#sh route-map

route-map R5ID-EIGRP1258-to-EIGRP198, permit, sequence 10

Match clauses:

ip address (access-lists): R5ID

Set clauses:

Policy routing matches: 0 packets, 0 bytes

R8(config)#router eigrp 198

R8(config-router)#redistribute EIGRP 1258 route-map R5ID-EIGRP1258-to-EIGRP198 metric 1544 100 255 1 1500

And now the R11 BGP table after redistribution:

R11(config)#do sh ip bgp

BGP table version is 38, local router ID is 10.10.11.1

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

* i10.10.0.0/24 10.10.5.1 0 100 0 12345 i

*>i 10.10.5.1 0 100 0 12345 i

*>i192.168.0.0 10.10.5.1 0 100 0 12345 26000 i

* i 10.10.5.1 0 100 0 12345 26000 i

*>i192.168.4.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

*>i192.168.4.192/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

*>i192.168.5.0/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

*>i192.168.5.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i 10.10.9.1 0 100 0 i

*>i192.168.6.64/27 10.10.10.1 0 100 0 i

* i 10.10.10.1 0 100 0 i

*> 192.168.6.96/27 0.0.0.0 0 32768 i

Network Next Hop Metric LocPrf Weight Path

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

* i 10.10.8.1 0 100 0 i

* i192.168.6.160/27 10.10.12.1 0 100 0 i

*>i 10.10.12.1 0 100 0 i

* i192.168.8.64/26 10.10.5.1 0 100 0 12345 27000 i

*>i 10.10.5.1 0 100 0 12345 27000 i

R11(config)#

Now NEXT-HOP 10.10.5.1 is reachable and in the EIGRP 198 routing table:

R11(config)#do sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

 

Gateway of last resort is not set

 

192.168.8.0/26 is subnetted, 1 subnets

B 192.168.8.64 [200/0] via 10.10.5.1, 00:02:48

192.168.11.0/30 is subnetted, 1 subnets

D 192.168.11.208 [90/2172416] via 192.168.6.250, 03:10:49, Serial1/0

[90/2172416] via 192.168.6.242, 03:10:49, Serial1/1

192.168.4.0/26 is subnetted, 2 subnets

B 192.168.4.64 [200/0] via 10.10.5.1, 00:02:48

B 192.168.4.192 [200/0] via 10.10.5.1, 00:02:48

192.168.5.0/26 is subnetted, 2 subnets

B 192.168.5.64 [200/0] via 10.10.5.1, 00:02:48

B 192.168.5.0 [200/0] via 10.10.5.1, 00:02:48

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks

B 10.10.0.0/24 [200/0] via 10.10.5.1, 00:02:48

D EX 10.10.5.1/32 [170/2195456] via 192.168.6.250, 00:02:55, Serial1/0

D 10.10.9.1/32 [90/2809856] via 192.168.6.250, 03:20:00, Serial1/0

[90/2809856] via 192.168.6.242, 03:20:00, Serial1/1

D 10.10.8.1/32 [90/2297856] via 192.168.6.250, 03:10:47, Serial1/0

C 10.10.11.1/32 is directly connected, Loopback0

D 10.10.10.1/32 [90/2809856] via 192.168.6.250, 03:17:35, Serial1/0

[90/2809856] via 192.168.6.242, 03:17:35, Serial1/1

D 10.10.12.1/32 [90/2297856] via 192.168.6.242, 03:10:48, Serial1/1

192.168.6.0/24 is variably subnetted, 11 subnets, 2 masks

C 192.168.6.96/27 is directly connected, Loopback1

B 192.168.6.64/27 [200/0] via 10.10.10.1, 00:50:30

B 192.168.6.32/27 [200/0] via 10.10.9.1, 02:35:14

D 192.168.6.236/30 [90/2681856] via 192.168.6.242, 03:10:48, Serial1/1

D 192.168.6.232/30 [90/2681856] via 192.168.6.250, 03:10:47, Serial1/0

D 192.168.6.228/30 [90/2681856] via 192.168.6.242, 03:10:48, Serial1/1

C 192.168.6.248/30 is directly connected, Serial1/0

D 192.168.6.244/30 [90/2681856] via 192.168.6.250, 03:10:47, Serial1/0

C 192.168.6.240/30 is directly connected, Serial1/1

B 192.168.6.160/27 [200/0] via 10.10.12.1, 02:50:13

B 192.168.6.128/27 [200/0] via 10.10.8.1, 02:49:30

B 192.168.0.0/24 [200/0] via 10.10.5.1, 00:02:50

R11(config)#

and the result:

R11(config)#do trace

Protocol [ip]:

Target IP address: 192.168.8.65

Source address: 192.168.6.97

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 192.168.8.65

 

1 192.168.6.250 100 msec 4 msec 340 msec

2 192.168.11.206 712 msec 744 msec 232 msec

3 192.168.5.198 404 msec 500 msec 332 msec

4 192.168.5.205 700 msec 576 msec 620 msec

5 192.168.5.213 668 msec 636 msec 776 msec

R11(config)#

 

Solution (c):

Let’s revoke the redistribution:

R8(config-router)#no redistribute EIGRP 1258 route-map R5ID-EIGRP1258-to-EIGRP198 metric 1544 100 255 1 1500

and change NEXT-HOP attribute on both R8 and R12:

R12(config)#router bgp 11897

R12(config-router)#neighbor 10.10.9.1 next-hop-self

R12(config-router)#neighbor 10.10.10.1 next-hop-self

R12(config-router)#neighbor 10.10.11.1 next-hop-self

 

R8(config-router)#router bgp 11897

R8(config-router)#neighbor 10.10.9.1 next-hop-self

R8(config-router)#neighbor 10.10.10.1 next-hop-self

R8(config-router)#neighbor 10.10.11.1 next-hop-self

The result is R8 and R12 BGP RID as NEXT-HOP:

R11(config)#do sh ip bgp

BGP table version is 52, local router ID is 10.10.11.1

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

* i10.10.0.0/24 10.10.12.1 0 100 0 12345 i

*>i 10.10.8.1 0 100 0 12345 i

*>i192.168.0.0 10.10.8.1 0 100 0 12345 26000 i

* i 10.10.12.1 0 100 0 12345 26000 i

*>i192.168.4.64/26 10.10.8.1 0 100 0 12345 i

* i 10.10.12.1 0 100 0 12345 i

*>i192.168.4.192/26 10.10.8.1 0 100 0 12345 i

* i 10.10.12.1 0 100 0 12345 i

*>i192.168.5.0/26 10.10.8.1 0 100 0 12345 i

* i 10.10.12.1 0 100 0 12345 i

*>i192.168.5.64/26 10.10.8.1 0 100 0 12345 i

* i 10.10.12.1 0 100 0 12345 i

* i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i 10.10.9.1 0 100 0 i

*>i192.168.6.64/27 10.10.10.1 0 100 0 i

* i 10.10.10.1 0 100 0 i

*> 192.168.6.96/27 0.0.0.0 0 32768 i

Network Next Hop Metric LocPrf Weight Path

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

* i 10.10.8.1 0 100 0 i

* i192.168.6.160/27 10.10.12.1 0 100 0 i

*>i 10.10.12.1 0 100 0 i

* i192.168.8.64/26 10.10.12.1 0 100 0 12345 27000 i

*>i 10.10.8.1 0 100 0 12345 27000 i

R11(config)#

Here is the result of “trace” command:

R11(config)#do trace

Protocol [ip]:

Target IP address: 192.168.8.65

Source address: 192.168.6.97

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 192.168.8.65

 

1 192.168.6.250 44 msec 216 msec 76 msec

2 192.168.11.206 216 msec 212 msec 408 msec

3 192.168.5.198 308 msec 248 msec 436 msec

4 192.168.5.205 604 msec 740 msec 536 msec

5 192.168.5.213 960 msec 844 msec 592 msec

R11(config)#

– All we have done through solutions (a), (b) and (c) is to provide connectivity when deploying RR

on R12 and R8 so they can serve clients R9, R10 and R11 and advertise iBGP prefixes to them ignoring this way the rule of SPLIT-HORIZON:

R8#sh ip bgp neighbor 10.10.12.1 advertised-routes

BGP table version is 19, local router ID is 10.10.8.1

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

*> 10.10.0.0/24 10.10.5.1 0 12345 i

*> 192.168.0.0 10.10.5.1 0 12345 26000 i

*> 192.168.4.64/26 10.10.5.1 0 12345 i

*> 192.168.4.192/26 10.10.5.1 0 12345 i

*> 192.168.5.0/26 10.10.5.1 0 12345 i

*> 192.168.5.64/26 10.10.5.1 0 0 12345 i

*>i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i192.168.6.64/27 10.10.10.1 0 100 0 i

*>i192.168.6.96/27 10.10.11.1 0 100 0 i

*> 192.168.6.128/27 0.0.0.0 0 32768 i

*> 192.168.8.64/26 10.10.5.1 0 12345 27000 i

 

Total number of prefixes 11

R8#

 

R12(config-router)#do sh ip bgp neighbor 10.10.9.1 ad

BGP table version is 19, local router ID is 10.10.12.1

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

*> 10.10.0.0/24 10.10.5.1 0 12345 i

*> 192.168.0.0 10.10.5.1 0 12345 26000 i

*> 192.168.4.64/26 10.10.5.1 0 12345 i

*> 192.168.4.192/26 10.10.5.1 0 12345 i

*> 192.168.5.0/26 10.10.5.1 0 12345 i

*> 192.168.5.64/26 10.10.5.1 0 0 12345 i

*>i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i192.168.6.64/27 10.10.10.1 0 100 0 i

*>i192.168.6.96/27 10.10.11.1 0 100 0 i

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

*> 192.168.6.160/27 0.0.0.0 0 32768 i

*> 192.168.8.64/26 10.10.5.1 0 12345 27000 i

 

Total number of prefixes 12

 

R12(config-router)#do sh ip bgp neighbor 10.10.10.1 ad

BGP table version is 19, local router ID is 10.10.12.1

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

*> 10.10.0.0/24 10.10.5.1 0 12345 i

*> 192.168.0.0 10.10.5.1 0 12345 26000 i

*> 192.168.4.64/26 10.10.5.1 0 12345 i

*> 192.168.4.192/26 10.10.5.1 0 12345 i

*> 192.168.5.0/26 10.10.5.1 0 12345 i

*> 192.168.5.64/26 10.10.5.1 0 0 12345 i

*>i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i192.168.6.64/27 10.10.10.1 0 100 0 i

*>i192.168.6.96/27 10.10.11.1 0 100 0 i

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

*> 192.168.6.160/27 0.0.0.0 0 32768 i

*> 192.168.8.64/26 10.10.5.1 0 12345 27000 i

 

Total number of prefixes 12

 

R12(config-router)#do sh ip bgp neighbor 10.10.11.1 ad

BGP table version is 19, local router ID is 10.10.12.1

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

*> 10.10.0.0/24 10.10.5.1 0 12345 i

*> 192.168.0.0 10.10.5.1 0 12345 26000 i

*> 192.168.4.64/26 10.10.5.1 0 12345 i

*> 192.168.4.192/26 10.10.5.1 0 12345 i

*> 192.168.5.0/26 10.10.5.1 0 12345 i

*> 192.168.5.64/26 10.10.5.1 0 0 12345 i

*>i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i192.168.6.64/27 10.10.10.1 0 100 0 i

*>i192.168.6.96/27 10.10.11.1 0 100 0 i

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

*> 192.168.6.160/27 0.0.0.0 0 32768 i

*> 192.168.8.64/26 10.10.5.1 0 12345 27000 i

 

Total number of prefixes 12

R12(config-router)#

For example the route 192.168.6.128 which is local to R8 has been advertised to R12 which in turn advertised it to R9, R10 and R11.

==> And no need at all for full meshed iBGP inside ASN11897.

%d bloggers like this: