winfred.nl

 

>

> Nice that’s clever.

> And since you are using CSR1000v you don’t need to worry about the

> cost of HW for RRs.

 

Yes, the CSR1000v’s are workhorses.

 

 

> I see, so RRs do the routing decision on behalf of the PE routers in a

> particular PoP.

 

Correct, but in some cases, the routing decision is done in a completely different country/continent/cluster, before that final decision is pushed down to the RR which has the target edge router. Either way, the result is always the same, since the destination traffic was headed toward that different country/continent anyway.

 

 

> Since RR cluster is local to the PoP the AS-exit proximity is

> accurate, in other words what is good for the RR has to be good for

> the PEs within the PoP.

 

Yes, and this is a very important point that you note. Having iBGP sessions to RR’s not in the same physical PoP can lead to sub-optimal routing for devices in that PoP, as by default, RR’s base best-path selection for IGP metrics on the local IGP metric, while the iBGP neighbor would be remote.

 

BGP-ORR, covered in “draft-ietf-idr-bgp-optimal-route-reflection-09”, is trying to fix this. But I don’t know of anyone shipping code yet.

 

 

> But still you’d have to use add-path to advertise backup paths from

> RRs to PEs in a local PoP whereas with MP-BGP you’d just use unique RDs.

 

You might find it strange but I do neither :-).

 

Each cluster has 2x RR’s. Each iBGP client has 2x sessions to each RR for all address families.

 

Based on our hardware, we’ve modeled convergence performance for BGP routing and found it to be reasonably quick across the network.

Considering the additonal overhead Add-Paths and such would bring, it has been a calculated decision to keep things simple, and rely on Next-Hop Address Tracking tech. in Cisco and Juniper to speed up convergence. BFD for IS-IS has also been very helpful, as we’ve found BGP to be a lot more stable in a steady-state.

 

We are still watching this, and will decide if physically installing additional paths is a good idea. For now, it’s not hurting overall network performance.

 

>

>

> I see it as more of a good practice not to hold default route or full

> inet table on a peering box but as I said before peer pointing a

> default at you is rather a corner case I guess.

 

Hehe, depends. Some folk point default toward you at peering points because they don’t know better. Others do because they are chancers.

Either way, avoid the risk.

 

We have dedicated peering routers in each PoP. We carry neither a full table nor a default route on those. In fact, we null-route default routes on every peering box.

 

 

>

>

> Yeah been doing EoMPLS PW to provide full internet feed to customers

> behind MEs didn’t have the confidence to use the table-map/SRD 🙂

 

You should try BGP-SD, works great over here :-).

 

Tunnels or eBGP-Multihop is too much for me for passing full feeds to customers :-).

 

When configuring REP with trunk in place on ASR903 , I cannot use xconnect (Cisco TAC) So my only option is vfi

 

You need to configure l2vpn vfi instead of l2vpn xconnectTake a look at http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l2_vpns/configuration/xe-3s/asr903/mp-l2-vpns-xe-3s-asr903-book/mp-vpls.html

 

I’d use the following config for the service instances and the L2VPNI guess you can’t use the service instance in the L2VPN, because of the bridge-domain command inside the service instance.

service instance 1 ethernet  encapsulation dot1q 100,200,300  rewrite ingress tag pop 1 symmetric l2vpn xconnect context L2VPNmember GigabitEthernet0/0/0 service instance 1member GigabitEthernet0/1/0 service instance 1member pseudowire 20 Maybe the trunk keyword in the service instance plays some role..

 

 

 

 

 

 

This is how it would look like using the “old-style”

 

ASR903

interface GigabitEthernet0/0/0

service instance trunk 1 ethernet

encapsulation dot1q 100,200,300

rewrite ingress tag pop 1 symmetric

xconnect 2.2.2.2 20 encapsulation mpls

! interface GigabitEthernet0/1/0

!  service instance trunk 1 ethernet

!    encapsulation dot1q 100,200,300

!    rewrite ingress tag pop 1 symmetric

!    xconnect 2.2.2.2 40 encapsulation mpls

! — config related to backup PW–

Also on ME I’d recommend using xconnect under the service instance rather than attaching the service instance to a BD and configuring xconnect under the VLAN interface. Because if you attach a service instance to a BD by default MAC learning is in place and you don’t want that for a simple p2p PW (MAC learning can be disabled using cmd: ” no mac learning” under the BD config).

ME3600

interface GigabitEthernet0/x

service instance trunk 1 ethernet

encapsulation dot1q 100,200,300

rewrite ingress tag pop 1 symmetric

xconnect 1.1.1.1 20 encapsulation mpls

!     backup peer 1.1.1.1 40 encapsulation mpls

! — config related to backup PW–

 

 

 

 

 

> ASR903

> interface GigabitEthernet0/0/0

>  description Connected-To-AS1-G0/2

>  no ip address

>  negotiation auto

>  rep segment 20 edge primary

>  rep preempt delay 30

>  rep block port 3 vlan 1-4094

>  service instance trunk 1 ethernet

>   encapsulation dot1q 100,200,300

>   rewrite ingress tag pop 1 symmetric

>   bridge-domain from-encapsulation

>

>

> interface GigabitEthernet0/1/0

>  description Connected-To-AS2-G0/2

>  no ip address

>  negotiation auto

>  rep segment 20 edge preferred

>  rep preempt delay 30

>  service instance trunk 1 ethernet

>   encapsulation dot1q 100,200,300

>   rewrite ingress tag pop 1 symmetric

>   bridge-domain from-encapsulation

>

> interface pseudowire 20

> encapsulation mpls

> neighbor 2.2.2.2 20

>

> l2vpn xconnect context L2VPN

> member GigabitEthernet0/0/0 –> When I tried to put service-instance ,

> it did

> not accept the command

> member pseudowire 20

>

> ME3600

> interface vlan 100

> no ip address

> xconnect 1.1.1.1 20 encapsulation mpls

>

> Now , the xconnect came up as shown in the output below

>

> ME3600X#show mpls l2transport vc 20

>

> Local intf     Local circuit              Dest address    VC ID      Status

> ————-  ————————– ————— ———-

> ———-

> Vl100          Eth VLAN 100               1.1.1.1         20         UP

>

> ASR903#sh xconnect all

> Legend:    XC ST=Xconnect State  S1=Segment1 State  S2=Segment2 State

>   UP=Up       DN=Down            AD=Admin Down      IA=Inactive

>   SB=Standby  HS=Hot Standby     RV=Recovering      NH=No Hardware

>

> XC ST  Segment 1                         S1 Segment 2                         S2

> ——+———————————+–+———————————+–

> UP pri mpls 2.2.2.2:20                   UP   ac Gi0/0/0:6(Ethernet)          UP

>

> No ping between the two sites , I tried to modify the MTU vlaue on the

> interfaces going to the CE side , and the xconnect is down directly

> I have tested L3VPN using the exact same setup (without modifying the

> MTU

> values on any interface) and it worked fine

>

> Any ideas?