mVPN solutions using P2MP TE as core tree protocol do not work and are not supported on virtual XR routers (XRv and XRv9k) currently.     Regards,   Luc ... View more

Just about all protocols support QOS, not just MPLS. If would be good if you can provide more details on the alternatives of MPLS. Regards, Luc ... View more

Hi Jonathan, The routing needs to be there end-to-end or PE-to-PE, so in overlay. BGP running between the PE routers takes care of that. So, the customer or VPN routes need to be advertised by BGP between the PE routers. So, the IGPs of the VPN, but euqally so the connected routes (PE-CE link) and static routes need to be advertised in this fashion. This is achived by redistributing the IGP, the connected or the static routes into BGP. When running BGP between the PE and CE routers, no redistribution is needed. The BGP routes from the CE are transported by the PE to the remote PE routers automatically. So, in your case, you'll need to "redistribute connected" or "redistribute static" into BGP on the PE router. regards, Luc ... View more

Hi, If I get it right, you're attempting to do mLDP in-band signalling in the global context. On which platform are you attempting it? Thanks, Luc ... View more

Hi, Slow peer in BGP is a feature that works in conjunction with BGP update groups. Update groups are formed automatically in BGP for iBGP and eBGP neighbors. Neighbors with the same outbound policy end up in the same update group. The BGP update is then created once and replicate to all other neighbors in the update group. This is more efficient than creating one BGP update for each neighbor seperately. Slow peer feature will detect if a peer is slowing in processing received BGP messages. That peer will be moved out of the update group. The reason is that one slow peer can slow down the whole update group, which has potentially many neighbors. So, the more neighbors in an update group, the effect will be greater of the slow peer feature. In the end, slow peer feature makes convergence go faster, if there is one or more slow BGP peer. This feature can benefit BGP everywhere, on RR, PE or any BGP router. Remember, the more BGP neighbors with the same outbound policy, the greater the effect can be. Likely, the RRs do not have different or any outbound policy on the iBGP sessions, so there it can be very useful. Also, it might benefit the PE-CE sessions, if you have more than one per VRF at least. Thanks, Luc ... View more

Hi Shreeram, IP can fragment OSPF packets. Here's two routers, R1 and R2 with both MTU 1500 on the ethernet interface between them. R1 has many OSPF-enabled interfaces, so that the Router LSA of R1 becomes bigger than 1500 bytes. R1#show ip int et 0/0 Ethernet0/0 is up, line protocol is up   Internet address is 10.1.1.1/24   Broadcast address is 255.255.255.255   Address determined by setup command   MTU is 1500 bytes      <<<<<< A capture on the wire when OSPF exchanges the router LSA of R1 shows: Frame 37 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: aa:bb:cc:00:01:00, Dst: 01:00:5e:00:00:05 Internet Protocol, Src Addr: 10.1.1.1 (10.1.1.1), Dst Addr: 224.0.0.5 (224.0.0.5)     Version: 4     Header length: 20 bytes     Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)     Total Length: 1500      <<<<<<     Identification: 0x0184 (388)      <<<<<<     Flags: 0x02         .0.. = Don't fragment: Not set         ..1. = More fragments: Set      <<<<<<     Fragment offset: 0     Time to live: 1     Protocol: OSPF IGP (0x59)     Header checksum: 0xa67e (correct)     Source: 10.1.1.1 (10.1.1.1)     Destination: 224.0.0.5 (224.0.0.5) Open Shortest Path First     OSPF Header         OSPF Version: 2         Message Type: LS Update (4)         Packet Length: 1528      <<<<<<         Source OSPF Router: 10.100.1.1 (10.100.1.1)         Area ID: 0.0.0.0 (Backbone)         Packet Checksum: 0xf490         Auth Type: Null         Auth Data (none) [Unreassembled Packet: OSPF] Frame 38 (82 bytes on wire, 82 bytes captured) Ethernet II, Src: aa:bb:cc:00:01:00, Dst: 01:00:5e:00:00:05 Internet Protocol, Src Addr: 10.1.1.1 (10.1.1.1), Dst Addr: 224.0.0.5 (224.0.0.5)     Version: 4     Header length: 20 bytes     Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)     Total Length: 68     Identification: 0x0184 (388)      <<<<<<     Flags: 0x00         .0.. = Don't fragment: Not set         ..0. = More fragments: Not set     Fragment offset: 1480     Time to live: 1     Protocol: OSPF IGP (0x59)     Header checksum: 0xcb5d (correct)     Source: 10.1.1.1 (10.1.1.1)     Destination: 224.0.0.5 (224.0.0.5) Data (48 bytes) 0000  0a c8 01 03 ff ff ff ff 03 00 00 01 0a c8 01 02   ................ 0010  ff ff ff ff 03 00 00 01 0a c8 01 01 ff ff ff ff   ................ 0020  03 00 00 01 0a 64 01 01 ff ff ff ff 03 00 00 01   .....d.......... The router LSA of R1 is bigger than 1500 bytes and was fragmented by IPv4. The router LSA of R1 will be stored on R2. We can see that the size of the LSA is bigger than 1500 bytes. R2#show ip ospf database router 10.100.1.1             OSPF Router with ID (10.100.1.2) (Process ID 1)                 Router Link States (Area 0)   LS age: 4   Options: (No TOS-capability, DC)   LS Type: Router Links   Link State ID: 10.100.1.1   Advertising Router: 10.100.1.1   LS Seq Number: 80000022   Checksum: 0x2CF4   Length: 1536      <<<<<<   Number of Links: 126 The difference between OSPF and ISIS is that OSPF runs on top of IP, while ISIS runs directly on Layer 2. ISIS builds one LSP per level per router. With OSPF, IP can fragment the packet. The OSPF LSA header does have a checksum field. The re-assembled LSA can be verified. RFC 2328: 4.3.  Routing protocol packets         The OSPF protocol runs directly over IP, using IP protocol 89.         OSPF does not provide any explicit fragmentation/reassembly         support.  When fragmentation is necessary, IP         fragmentation/reassembly is used.  OSPF protocol packets have         been designed so that large protocol packets can generally be         split into several smaller protocol packets.  This practice is         recommended; IP fragmentation should be avoided whenever         possible. A.1 Encapsulation of OSPF packets     OSPF does not define a way to fragment its protocol packets, and     depends on IP fragmentation when transmitting packets larger than     the network MTU. If necessary, the length of OSPF packets can be up     to 65,535 bytes (including the IP header). The issues with the OSPF adjacency not forming is related to a mismatch in MTU settings or another problem with the MTU. Either the MTU is set differently on either side of the link or there is a Layer 2 device in the middle with a lower MTU than what the routers have on the interface. In the example above, the router LSA of R1 is fragmented, but the OSPF adjacency forms fine. I hope this clarifies things. Thanks, Luc ... View more