Top Banner
Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120 1 Configuring Inter-AS VPN Option C in Multivendor Environment
27

Inter as vpn option c

Jun 18, 2015

Download

Engineering

This Document shows how to configure Inter-AS VPN option C in a multivendor (Cisco/Juniper) Environment
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

1

Configuring Inter-AS VPN Option C in Multivendor Environment

Page 2: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

2

Introduction: In This document we are going to see how to configure Inter-AS VPN option C in a multivendor environment (Juniper/Cisco). Before we start discovering Option C details , let’s take a look at the physical topology we are going to use during this document

We have the following regarding this topology:

1) Green Provider is a Juniper based provider 2) Blue provider is a Cisco based provider 3) CE1 is a Cisco router 4) CE2 is a Juniper router 5) The IPs are shown on the diagram 6) Both Service providers are using OSPF area 0 7) We can use any PE-CE routing protocol , but here we are going to use BGP (at both providers) 8) The below table includes all the loopbacks of all routers in the topology as the following 9) Here we are going to have LDP inside each AS for label distribution .

Page 3: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

3

Router loopback Vendor

CE1 11.11.11.11 Cisco

PE1 192.168.1.10 Juniper

P1 192.168.1.11 Juniper

ASBR1 192.168.1.12 Juniper

ASBR2 172.16.1.12 Cisco

P2 172.16.1.11 Cisco

PE2 172.16.1.10 Cisco

CE2 22.22.22.22 Juniper

Also before we start Option C , let’s remind how Option A/B are working Option A:

We are going to configure regular BGP VPNv4 peering inside each AS , and at each ASBR we are going to configure a VRF for each customer .

Between the ASBRs we have any IGP and each ASBR act as a CE to the other ASBR . and regular IP routes are going to be transferred between the ASBRs

Page 4: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

4

This Solution is not scalable at all , and we will have a lot of configurations . Option B:

O

p

t

i

o

n

B

:

Here we are going to configure BGP session between the ASBRs used to carry VPNv4 routes .

Here we are not going to configure VRFs at the ASBRs

Here we have to take care if the ASBRs are not route reflectors , so we have to override the BGP default feature of route target filtering , as by default if the router is not a Route-Reflector it is not going to keep VPNv4 routes if it has no corresponding VRF . to override this

At Cisco: R(config-router)#no bgp default route-target filter At Juniper: root@PE1# show | compare [edit] protocols { bgp { group VPNv4 { keep all; family inet-vpn { unicast; }

Page 5: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

5

Option C: Before we start in the configuration details let’s take a look at the general concept of Option C

Here we are going to have two major BGP sessions between the two ASs one of them (Always referred as BGP session 1 ) is used to carry the VPNv4 routes and this session is EBGP multihop session and can be configured between each PE in every AS or can be configure between the VPNv4 Route-Reflectors in each AS (We will check both configuration option later)

Another BGP session (Always referred as BGP session 2) is used to carry the internal routes of each provider (mainly the loopbacks of the Route reflectors or the PEs) where this session is used to carry labels for the internal IPV4 routes (BGP labelled unicast family ) . this BGP session is configured between the ASBRs inside each AS

Here in this Option we need to have an end-to-end LSP either between the PEs inside each AS or the BGP VPNv4 route reflectors

Option C Configurations Options: I ) EBGP Session 1 between PEs + label distribution inside each AS using BGP labeled unicast:

Page 6: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

6

Here is in option we are going to have the following setup : 1 ) EBGP session between the PEs used to carry the VPNv4 routes (Routes of the Customer + VPN label ) 2) EBGP session between each ASBR , where for example ASBR1 will advertise to ASBR2 the IPV4 address of PE1 + label (IPv4 labeled unicast family) 3) IBGP session inside each AS between ASBR1 and P1 and PE1 and BGP sessions between ASBR2 and PE2 and P2 , where this IBGP session is used to carry labeled unicast family and used so that each PE has a label for the other remote PE Configurations (Here we are going to skip unnecessary configurations to avoid long document ): CE1#show run | section bgp router bgp 300 bgp log-neighbor-changes neighbor 10.10.10.2 remote-as 100 neighbor 10.10.10.2 timers 100 3000 3000 This command is used as during implementation peers were Flapping so I increased the Hold timer than default ! address-family ipv4 no synchronization network 10.10.10.0 mask 255.255.255.252 used to advertise the Direct connection between PE and CE into BGP network 11.11.11.11 mask 255.255.255.255 used to advertise the CE loopback into BGP neighbor 10.10.10.2 activate no auto-summary exit-address-family root@PE1> show configuration routing-instances RED (Normal VRF configuration where BGP used as PE -CE) instance-type vrf; interface em0.0; route-distinguisher 100:1; vrf-target { import target:100:1; export target:100:1; } protocols { bgp { group RED { type external; peer-as 300; as-override; We used this Option as the two CE sites are using Same AS# neighbor 10.10.10.1 { hold-time 3000; } } } }

Page 7: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

7

root@CE2> show configuration protocols bgp group EBGP { type external; hold-time 3000; family inet { unicast; } export EXP; peer-as 200; neighbor 10.10.10.6; } root@CE2> show configuration policy-options policy-statement EXP term 1 { from { route-filter 22.22.22.22/32 exact; route-filter 10.10.10.4/30 exact; } then accept; } term 2 { then reject; } PE2#show running-config | sec bgp router bgp 200 address-family ipv4 vrf RED no synchronization neighbor 10.10.10.5 remote-as 300 neighbor 10.10.10.5 timers 100 3000 3000 neighbor 10.10.10.5 activate neighbor 10.10.10.5 as-override exit-address-family

Now let’s check the sessions between the ASBRs: root@ASBR1> show configuration protocols bgp group EBGP-LABEL type external; hold-time 3000; family inet { labeled-unicast { rib { inet.3; Here we used rib inet.3 so that the routes received from ASBR2 used to populate table inet.3 so that we have end-to-end LSPs } } } export ASBR2; peer-as 200; neighbor 10.9.9.2;

Page 8: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

8

root@ASBR1> show configuration policy-options policy-statement ASBR2 term 1 { from { route-filter 192.168.1.11/32 exact; route-filter 192.168.1.10/32 exact; this is the loopback address of PE1 } then accept; } term 2 { then reject; } ASBR2#show run | section bgp router bgp 200 bgp log-neighbor-changes neighbor 10.9.9.1 remote-as 100 neighbor 10.9.9.1 timers 100 3000 3000 address-family ipv4 no synchronization network 172.16.1.10 mask 255.255.255.255 loopback address of PE2 network 172.16.1.11 mask 255.255.255.255 neighbor 10.9.9.1 activate neighbor 10.9.9.1 send-label this command is used so that to enable send labeled unicast family so that to have end-to-end LSP neighbor 10.9.9.1 soft-reconfiguration inbound (This command is used so that we can see the received routes from the neighbor) no auto-summary exit-address-family

Now let’s check the routes received from each session: root@ASBR1> show route receive-protocol bgp 10.9.9.2 inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.10/32 10.9.9.2 21 200 I * 172.16.1.11/32 10.9.9.2 11 200 I root@ASBR1> show route 172.16.1.10/32 detail inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 172.16.1.10/32 (1 entry, 1 announced) *BGP Preference: 170/-101 Next hop type: Router Next-hop reference count: 3 Source: 10.9.9.2 Next hop: 10.9.9.2 via em4.0, selected Label operation: Push 18 Label TTL action: prop-ttl

Page 9: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

9

State: <Active Ext> Local AS: 100 Peer AS: 200 Age: 2:24 Metric: 21 Task: BGP_200.10.9.9.2+37639 Announcement bits (2): 2-Resolve tree 1 4-BGP RT Background AS path: 200 I Accepted Route Label: 18 Localpref: 100 Router ID: 172.16.1.12

From the previous command we see that 1) Routes received from ASBR2 are installed in inet.3 with protocol BGP 2) Label value of 18 is advertised from ASBR2 to ASBR1

root@ASBR1> show route advertising-protocol bgp 10.9.9.2 192.168.1.10/32 detail inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) * 192.168.1.10/32 (1 entry, 1 announced) BGP group EBGP-LABEL type External Route Label: 300560 Nexthop: Self Flags: Nexthop Change MED: 1 AS path: [100] I

ASBR2#show bgp ipv4 unicast neighbors 10.9.9.1 received-routes BGP table version is 53, local router ID is 172.16.1.12 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 192.168.1.10/32 10.9.9.1 1 0 100 i *> 192.168.1.11/32 10.9.9.1 1 0 100 i Total number of prefixes 2 ASBR2#show bgp ipv4 unicast 192.168.1.10/32 BGP routing table entry for 192.168.1.10/32, version 53 Paths: (1 available, best #1, table default) Advertised to update-groups: 19 100, (received & used) 10.9.9.1 from 10.9.9.1 (192.168.1.12) Origin IGP, metric 1, localpref 100, valid, external, best mpls labels in/out 22/300560

Page 10: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

10

Here till this point we have the following : root@PE1> show route 172.16.1.10 inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.10/32 *[BGP/170] 00:04:53, MED 21, localpref 100, from 192.168.1.12 AS path: 200 I > to 192.168.1.2 via em1.0, Push 300592, Push 299792(top) PE2#show ip route 192.168.1.10 Routing entry for 192.168.1.10/32 Known via "bgp 200", distance 200, metric 1 Tag 100, type internal Last update from 172.16.1.12 00:21:10 ago Routing Descriptor Blocks: * 172.16.1.12, from 172.16.1.12, 00:21:10 ago Route metric is 1, traffic share count is 1 AS Hops 1 Route tag 100 MPLS label: 22 PE2#show ip cef 192.168.1.10 (Same As show route forwarding table in Junos) 192.168.1.10/32 nexthop 172.16.1.5 Ethernet1/1 label 17 22

As per previous output We have established an end-to-end LSP between the two PEs so that we can establish EBGP session between Them to exchange VPNv4 routes Before establishing this BGP session , let’s take a look at this end-to-end LSP as the following For PE1 to reach PE2 to will push two labels Push 300592, Push 299792(top)

root@P> show route forwarding-table label 299792 Routing table: default.mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif 299792 user 0 192.168.1.6 Pop 556 2 em3.0

So ASBR1 will receive packet with single label 300592

root@ASBR1> show route forwarding-table label 300592 Routing table: default.mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif 300592 user 0 10.9.9.2 Swap 18 560 2 em4.0

Page 11: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

11

Router ASBR2 will receive a labeled packet with a Single label 18 ASBR2#show mpls forwarding-table labels 18 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 18 16 172.16.1.10/32 0 Et1/0 172.16.1.2 P2#show mpls forwarding-table labels 16 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 16 Pop Label 172.16.1.10/32 15818 Et1/1 172.16.1.6 Let’s check the LSP used from the other side (from PE2 to reach PE1) PE2#show ip cef 192.168.1.10/32 192.168.1.10/32 nexthop 172.16.1.5 Ethernet1/1 label 17 22 P2#show mpls forwarding-table labels 17 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 17 Pop Label 172.16.1.12/32 40472 Et1/0 172.16.1.1 ASBR2#show mpls forwarding-table labels 22 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 22 300560 192.168.1.10/32 13330 Et1/4 10.9.9.1 root@ASBR1> show route forwarding-table label 300560 Routing table: default.mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif 300560 user 0 192.168.1.5 Swap 299776 557 2 em3.0 root@P> show route forwarding-table label 299776 Routing table: default.mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif 299776 user 0 192.168.1.1 Pop 553 2 em1.0 299776(S=0) user 0 192.168.1.1 Pop 554 2 em1.0

Page 12: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

12

At this step we saw the end-to-end LSP between the two PEs , now let’s check to configure the EBGP multihop session between the e PEs in order to exchange the VPNv4 routes PE2#show ip route 192.168.1.10 Routing entry for 192.168.1.10/32 Known via "bgp 200", distance 200, metric 1 Tag 100, type internal Last update from 172.16.1.12 00:39:50 ago Routing Descriptor Blocks: * 172.16.1.12, from 172.16.1.12, 00:39:50 ago Route metric is 1, traffic share count is 1 AS Hops 1 Route tag 100 MPLS label: 22 root@PE1> show route table inet.0 172.16.1.10 At this point we have a problem , from Cisco side we don’t have two routing table inet.0 and inet.3 , we only have a single table in which the routes are reachable , but in Junos the routes are not reachable in inet.0 so the BGP session can’t be formed root@PE1> show bgp summary | match 172.16.1.10 172.16.1.10 200 0 0 0 0 18:08 Active root@PE1> ping 172.16.1.10 PING 172.16.1.10 (172.16.1.10): 56 data bytes ping: sendto: No route to host Why this Behavior happens ?? Let’s take a detailed look for the routes exchanged between the ASBR root@ASBR1> show route receive-protocol bgp 10.9.9.2 inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.10/32 10.9.9.2 21 200 I * 172.16.1.11/32 10.9.9.2 11 200 I root@ASBR1> show route advertising-protocol bgp 10.9.9.2 inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.1.10/32 Self 2 I * 192.168.1.11/32 Self 1 I inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path

Page 13: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

13

* 192.168.1.10/32 Self 1 I * 192.168.1.11/32 Self 1 I We see that Cisco router is only advertising label IPv4 unicast prefixes while the Juniper router is advertising both the labeled IPv4 unicast prefixes and the unlabeled IPv4 prefixes . To fix this issue we need to copy the BGP routes from inet.3 to inet.0 in all the Juniper routers (this rib group must be configured on the Juniper routers not only on the ASBR) because when the routes are copied from inet.3 to inet.0 at the ASBR it will be used for forwarding only and can’t be used to be advertised to PE1 and P1 So the following configurations will be applied on all the routers to fix this issue root@ASBR1# show | compare [edit routing-options] + rib-groups { + BGP { + import-rib [ inet.3 inet.0 ]; rib group to copy routes from inet.3 to inet.0 + } + } [edit protocols bgp group EBGP-LABEL family inet labeled-unicast] + rib-group BGP; Here we determine that the labeled BGP routes will be copied to the RIB-Group BGP root@ASBR1> show route table inet.0 protocol bgp inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.10/32 *[BGP/170] 00:01:27, MED 21, localpref 100 AS path: 200 I > to 10.9.9.2 via em4.0, Push 18 172.16.1.11/32 *[BGP/170] 00:01:27, MED 11, localpref 100 AS path: 200 I > to 10.9.9.2 via em4.0, Push 17

Note: If we have the two ASBRs routers as Juniper as may not face this issue as they will exchange both inet.0 and inet.3 Now let’s the BGP session between the PEs root@PE1> show route table inet.0 protocol bgp 172.16.1.10/32 inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.10/32 *[BGP/170] 00:04:21, MED 21, localpref 100, from 192.168.1.12 AS path: 200 I > to 192.168.1.2 via em1.0, Push 301216, Push 299856(top)

Page 14: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

14

root@PE1> ping 172.16.1.10 source 192.168.1.10 rapid PING 172.16.1.10 (172.16.1.10): 56 data bytes !!!!! --- 172.16.1.10 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 13.290/16.907/20.206/2.195 ms

At this point we have full reachability between the PEs including both IP and end-to-end LSP root@PE1> show configuration protocols bgp group EBGP-VPN type external; multihop; local-address 192.168.1.10; family inet-vpn { unicast; } peer-as 200; neighbor 172.16.1.10 { hold-time 3000; } PE2#show running-config | sec bg router bgp 200 bgp log-neighbor-changes neighbor 192.168.1.10 ebgp-multihop 255 neighbor 192.168.1.10 update-source Loopback0 neighbor 192.168.1.10 timers 100 3000 3000 ! address-family vpnv4 neighbor 192.168.1.10 activate neighbor 192.168.1.10 send-community both exit-address-family root@PE1> show bgp summary 172.16.1.10 200 26 6 0 0 8:04 Establ RED.inet.0: 2/2/2/0 bgp.l3vpn.0: 2/2/2/0

Page 15: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

15

root@PE1> show route table RED protocol bgp next-hop 172.16.1.10 RED.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.4/30 *[BGP/170] 00:00:42, localpref 100, from 172.16.1.10 AS path: 200 300 I > to 192.168.1.2 via em1.0, Push 21, Push 301216, Push 299856(top) 22.22.22.22/32 *[BGP/170] 00:00:42, localpref 100, from 172.16.1.10 AS path: 200 300 I > to 192.168.1.2 via em1.0, Push 22, Push 301216, Push 299856(top)

PE2#show bgp vpnv4 unicast all BGP table version is 27, local router ID is 172.16.1.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf RED) *> 10.10.10.0/30 192.168.1.10 0 100 i r> 10.10.10.4/30 10.10.10.5 0 300 i *> 11.11.11.11/32 192.168.1.10 0 100 300 i *> 22.22.22.22/32 10.10.10.5 0 300 i PE2#show bgp vpnv4 unicast all 11.11.11.11/32 BGP routing table entry for 100:1:11.11.11.11/32, version 23 Paths: (1 available, best #1, table RED) Advertised to update-groups: 9 100 300 192.168.1.10 (metric 21) from 192.168.1.10 (192.168.1.10) Origin IGP, localpref 100, valid, external, best Extended Community: RT:100:1 mpls labels in/out nolabel/299936 PE2#show ip cef vrf RED 11.11.11.11/32 11.11.11.11/32 nexthop 172.16.1.5 Ethernet1/1 label 17 21 299936 As per the below outputs , we see that three labels are pushed Outer Most Label : LDP label to reach the ASBR Middle Label: the label learned via BGP to reach the remote PE Inner Most label : VPN label advertised be the remote PE

Page 16: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

16

Finally to test the reachability between the CE customers CE1#ping 22.22.22.22 source 11.11.11.11 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds: Packet sent with a source address of 11.11.11.11 !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 44/57/80 ms root@CE2> ping 11.11.11.11 source 22.22.22.22 rapid PING 11.11.11.11 (11.11.11.11): 56 data bytes !!!!! --- 11.11.11.11 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 12.825/16.802/19.811/2.755 ms

Before we see the other options that can be used to configure Option-C , let’s remember to core points to make this option work

1) BGP session between the ASBRs in order to exchange labels for the Internal loopbacks 2) End-to-End LSP between the remote PEs 3) EBGP session between the PEs in order to exchange the VPNv4 routes .

Note: The traffic between the ASBRs is labeled traffic while we are not running LDP between the ASBRs so we have to enable the following commands at the ASBR from Cisco side on the interface facing the other ASBR ASBR2#show run interface Ethernet 1/4 interface Ethernet1/4 ip address 10.9.9.2 255.255.255.252 duplex half mpls bgp forwarding end While from Juniper side ,we have to enable protocol MPLS and family MPLS on the interface facing the other ASBR

Next we are going to check other options to configure Option-C

Page 17: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

17

II ) EBGP Session 1 between VPNv4 Route-reflectors at each AS + label distribution inside each AS using BGP labeled

unicast:

Here we have the same infrastructure as the previous option but different implementation as the following

root@PE1> show configuration protocols bgp group IBGP-VPN type internal; local-address 192.168.1.10; family inet-vpn { unicast; } peer-as 100; neighbor 192.168.1.11; PE2#show running-config | section bgp router bgp 200 bgp log-neighbor-changes neighbor 172.16.1.11 remote-as 200 neighbor 172.16.1.11 update-source Loopback0

Page 18: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

18

address-family vpnv4 neighbor 172.16.1.11 activate neighbor 172.16.1.11 send-community both exit-address-family root@P> show configuration protocols bgp group IBGP-VPN type internal; local-address 192.168.1.11; family inet-vpn { unicast; } cluster 192.168.1.11; peer-as 100; neighbor 192.168.1.10; root@P> show configuration protocols bgp group EBGP-VPN type external; multihop; local-address 192.168.1.11; hold-time 3000; family inet-vpn { unicast; } peer-as 200; neighbor 172.16.1.11;

P2#show running-config | sec bgp router bgp 200 bgp log-neighbor-changes neighbor 172.16.1.10 remote-as 200 neighbor 172.16.1.10 update-source Loopback0 neighbor 192.168.1.11 remote-as 100 neighbor 192.168.1.11 ebgp-multihop 255 neighbor 192.168.1.11 update-source Loopback0 neighbor 192.168.1.11 timers 100 3000 3000 ! address-family vpnv4 neighbor 172.16.1.10 activate neighbor 172.16.1.10 send-community both neighbor 172.16.1.10 route-reflector-client neighbor 192.168.1.11 activate neighbor 192.168.1.11 send-community both exit-address-family

Page 19: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

19

root@PE1> show route table bgp.l3vpn bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100:1:10.10.10.4/30 *[BGP/170] 00:01:05, localpref 100, from 192.168.1.11 AS path: 200 300 I > to 192.168.1.2 via em1.0, Push 299920 100:1:22.22.22.22/32 *[BGP/170] 00:01:05, localpref 100, from 192.168.1.11 AS path: 200 300 I > to 192.168.1.2 via em1.0, Push 299936 PE2#show bgp vpnv4 unicast all 11.11.11.11/32 BGP routing table entry for 100:1:11.11.11.11/32, version 39 Paths: (1 available, best #1, table RED) Advertised to update-groups: 12 100 300 192.168.1.11 (metric 21) from 172.16.1.11 (172.16.1.11) Origin IGP, metric 0, localpref 100, valid, internal, best Extended Community: RT:100:1 mpls labels in/out nolabel/299904

Here we can see the protocol next-hop is the route-reflector it’s self as the next-hop is changes when the routes are exchanged between the two AS . In this topology this is not a problem , but this may causes to a sub-optimal routing in case that the Route-reflector is already not in the forwarding path , so to fix this problem we are going to apply the following on the two route-reflectors . At Juniper root@P# show | compare [edit protocols bgp group EBGP-VPN multihop] + no-nexthop-change; At Cisco: P2(config-router)#address-family vpnv4 unicast P2(config-router-af)#neighbor 192.168.1.11 next-hop-unchanged

Page 20: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

20

Now let’s check again , root@PE1> show route table RED 22.22.22.22/32 detail RED.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) 22.22.22.22/32 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 100:1 Next hop type: Indirect Next-hop reference count: 3 Source: 192.168.1.11 Next hop type: Router, Next hop index: 580 Next hop: 192.168.1.2 via em1.0, selected Label operation: Push 20, Push 301280, Push 299856(top) Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Protocol next hop: 172.16.1.10 Push 20 Indirect next hop: 8f5c870 131072 State: <Secondary Active Int Ext> Local AS: 100 Peer AS: 100 Age: 26 Metric2: 1 Task: BGP_100.192.168.1.11+56132 Announcement bits (2): 0-KRT 1-BGP RT Background AS path: 200 300 I Communities: target:100:1 Import Accepted VPN Label: 20 VPN Label TTL action: vrf-propagate-ttl Localpref: 100 Router ID: 192.168.1.11 Primary Routing Table bgp.l3vpn.0 PE2#show bgp vpnv4 unicast all 11.11.11.11/32 BGP routing table entry for 100:1:11.11.11.11/32, version 45 Paths: (1 available, best #1, table RED) Advertised to update-groups: 12 100 300 192.168.1.10 (metric 21) from 172.16.1.11 (172.16.1.11) Origin IGP, metric 0, localpref 100, valid, internal, best Extended Community: RT:100:1 mpls labels in/out nolabel/16 root@PE1> show route table bgp.l3vpn bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100:1:10.10.10.4/30 *[BGP/170] 00:00:50, localpref 100, from 192.168.1.11 AS path: 200 300 I

Page 21: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

21

> to 192.168.1.2 via em1.0, Push 19, Push 301280, Push 299856(top) 100:1:22.22.22.22/32 *[BGP/170] 00:00:50, localpref 100, from 192.168.1.11 AS path: 200 300 I > to 192.168.1.2 via em1.0, Push 20, Push 301280, Push 299856(top)

Note: If we take a look at the labels they have been changed as the next-hop has been changed Finally let’s check the reachability now CE1#ping 22.22.22.22 source 11.11.11.11 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds: Packet sent with a source address of 11.11.11.11 !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 36/61/92 ms root@CE2> ping 11.11.11.11 source 22.22.22.22 rapid PING 11.11.11.11 (11.11.11.11): 56 data bytes !!!!! --- 11.11.11.11 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 13.602/16.354/19.107/1.923 ms

Next we are going to check final Configuration option as the following

Page 22: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

22

II ) EBGP Session 1 between VPNv4 Route-reflectors at each AS + label distribution inside each AS using LDP:

This Option is not a very good and not very scalable one , but it can be used as following

Here in this option we have removed the IBGP sessions that used to propagate the labels for the routes learned from the other AS . root@P# run show route table inet.3 inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.10/32 *[LDP/9] 00:20:50, metric 1 > to 192.168.1.1 via em1.0 192.168.1.12/32 *[LDP/9] 00:20:57, metric 1 > to 192.168.1.6 via em3.0 P2#show ip route bgp Codes: L - local, 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

Page 23: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

23

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, H - NHRP + - replicated route, % - next hop override Gateway of last resort is not set

Here at each ASBR we need to redistribute the routes learned from the other ASBR into IGP which is not very scalable ,and also in case of Cisco this may be easier as following ASBR2#show ip route bgp 192.168.1.0/32 is subnetted, 2 subnets B 192.168.1.10 [20/1] via 10.9.9.1, 00:20:16 B 192.168.1.11 [20/1] via 10.9.9.1, 00:20:16 ASBR2(config)#router ospf 100 ASBR2(config-router)#redistribute bgp 200 subnets (subnets is added so that not only classfull networks are redistributed )

For Cisco this may be the only required step as P2#show ip route 192.168.1.11 Routing entry for 192.168.1.11/32 Known via "ospf 100", distance 110, metric 1 Tag 100, type extern 2, forward metric 10 Last update from 172.16.1.1 on Ethernet1/0, 00:02:22 ago Routing Descriptor Blocks: * 172.16.1.1, from 172.16.1.12, 00:02:22 ago, via Ethernet1/0 Route metric is 1, traffic share count is 1 Route tag 100 P2#show ip cef 192.168.1.11 192.168.1.11/32 nexthop 172.16.1.1 Ethernet1/0 label 20 As we can see this happens because the default behavior of Cisco which assign labels for all the routes in the routing table . For Juniper let’s check root@ASBR1> show configuration | compare rollback 1 [edit protocols ospf] + export OSPF-EXP; [edit policy-options] + policy-statement OSPF-EXP { + term 1 { + from protocol bgp; + then accept; + }

Page 24: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

24

+ } root@P# show route table inet.0 172.16.1.11 inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.11/32 *[OSPF/150] 00:00:18, metric 11, tag 0 > to 192.168.1.6 via em3.0 root@P> show route table inet.3 172.16.1.10 At this point we have only IP reachability but we don’t have an End-to-End LSP the VPNv4 peering will not work root@P> show route table bgp.l3vpn hidden bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 100:1:10.10.10.4/30 [BGP/170] 00:03:06, localpref 100, from 172.16.1.11 AS path: 200 300 I Unusable 100:1:22.22.22.22/32 [BGP/170] 00:03:06, localpref 100, from 172.16.1.11 AS path: 200 300 I Unusable

The previous output is due to the protocol next-hop is not resolved to an LSP in inet.3 ,so to fix this issue we make the following at ASBR1 root@ASBR1# show | compare [edit protocols ldp] + egress-policy LDP; here we configured LDP egress policy in order to modify the default label assignment [edit policy-options] + policy-statement LDP { + term 1 { + from { + route-filter 192.168.1.12/32 exact; We must include the loopback of the local router in this policy + route-filter 172.16.1.11/32 exact; + route-filter 172.16.1.10/32 exact; + } + then accept; + } + term 2 { + then reject; + } + }

Page 25: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

25

root@P> show route table inet.3 172.16.1.10 inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.10/32 *[LDP/9] 00:00:08, metric 1 > to 192.168.1.6 via em3.0, Push 301376 root@P> show route table bgp.l3vpn bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100:1:10.10.10.0/30 *[BGP/170] 00:18:52, localpref 100, from 192.168.1.10 AS path: I > to 192.168.1.1 via em1.0, Push 16 100:1:10.10.10.4/30 *[BGP/170] 00:05:49, localpref 100, from 172.16.1.11 AS path: 200 300 I > to 192.168.1.6 via em3.0, Push 21, Push 301376(top) 100:1:11.11.11.11/32 *[BGP/170] 00:18:52, MED 0, localpref 100, from 192.168.1.10 AS path: 300 I > to 192.168.1.1 via em1.0, Push 16 100:1:22.22.22.22/32 *[BGP/170] 00:05:49, localpref 100, from 172.16.1.11 AS path: 200 300 I > to 192.168.1.6 via em3.0, Push 22, Push 301376(top) root@PE1> show route table RED 22.22.22.22/32 RED.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 22.22.22.22/32 *[BGP/170] 00:01:53, localpref 100, from 192.168.1.11 AS path: 200 300 I > to 192.168.1.2 via em1.0, Push 22, Push 299952(top)

To test the reachability CE1#ping 22.22.22.22 source 11.11.11.11 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds: Packet sent with a source address of 11.11.11.11 !!!!!!!!!!

Page 26: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

26

Success rate is 100 percent (10/10), round-trip min/avg/max = 48/72/108 ms

Note: This last solution may be not very scalable due to the following 1) We have to redistribute from BGP to IGP . 2) In Case of Juniper based networks the default behavior is only to assign labels for /32 loopbacks only , so we

may need to change this using LDP egress policy .

Page 27: Inter as vpn option c

Document prepared by George Micheal JNCIE-SP#2150/CCIE-SP#44120

27