[c-nsp] Can not establish MP-BGP sessions

Aaron dudepron at gmail.com
Mon Nov 16 11:09:50 EST 2009


What is the HW on both ends? Possible one has a bug that is causing
headaches.

On Mon, Nov 16, 2009 at 08:51, Andy Saykao <
andy.saykao at staff.netspace.net.au> wrote:

> Hi Alex,
>
> 1/ When "mpls ip" is ON on both Gi4/0/1 and Gi0/2 - I can not ping from
> PE2 > PE1 BUT I can ping from PE1 > PE2. That's my real problem why
> MP-BGP won't come up bc I don't seem to have two way comms bt PE
> routers' BGP update-source lo99 address.
>
> POP1 [PE1 (lo99:172.16.99.13) --> P1 ] --switched ethernet-->  POP2 [P2
> --> PE2 (lo99:172.16.99.4)]
>
> Eg: Ping PE1 > PE2 (OK!)
> PE1#ping 172.16.99.4
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 172.16.99.4, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms
>
> Eg: Ping PE2 > PE1 (NOT OK!)
> PE2#ping 172.16.99.13
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 172.16.99.13, timeout is 2 seconds:
> .....
> Success rate is 0 percent (0/5)
>
> Ping PE2 > P1 (OK!)
> Ping P2 > P1 (OK!)
>
> *** Seems like I can't get any traffic/labels beyond P1 to get to
> PE1.***
>
> Forwarding table entry for PE1(lo99) looks ok on P1.
>
> P1#sh mpls forwarding-table 172.16.99.13 32
> Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
> Label  Label or VC   or Tunnel Id      Switched      interface
> 8668   Pop Label     172.16.99.13/32   158269119     Gi0/0.152
> 203.17.102.113
>
> 2/ When "mpls ip" is ON on both Gi4/0/1 and Gi0/2 - BGP does not come
> up.
>
> PE1#sh ip bgp vpnv4 all summary
> BGP router identifier 203.17.101.20, local AS number 4854
> BGP table version is 11983, main routing table version 11983
> 15 network entries using 2115 bytes of memory
> 15 path entries using 1020 bytes of memory
> 6/3 BGP path/bestpath attribute entries using 840 bytes of memory
> 2 BGP rrinfo entries using 48 bytes of memory
> 1 BGP AS-PATH entries using 24 bytes of memory
> 1 BGP community entries using 24 bytes of memory
> 2 BGP extended community entries using 48 bytes of memory
> 0 BGP route-map cache entries using 0 bytes of memory
> 0 BGP filter-list cache entries using 0 bytes of memory
> BGP using 4119 total bytes of memory
> BGP activity 1539/1500 prefixes, 6326/6263 paths, scan interval 15 secs
>
> Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
> State/PfxRcd
> 172.16.99.4     4  4854  147048  148587        0    0    0 06:48:13
> Active
> 172.16.99.5     4  4854  147196  148642        0    0    0 06:48:08
> Active
> 172.16.99.7     4  4854  147468  148593        0    0    0 06:48:16
> Active
> 172.16.99.9     4  4854  146473  148502        0    0    0 06:48:01
> Active
> 172.16.99.14    4  4854  147066  149123    11983    0    0 10:43:13
> 7
> 172.16.99.16    4  4854  146464  148574        0    0    0 06:47:52
> Active
> 172.16.99.19    4  4854  149509  151673    11983    0    0 10:43:59
> 5
> 172.16.99.20    4  4854  149448  151672    11983    0    0 10:43:58
> 2
>
> If I disable "mpls ip" on either Gi4/0/1 and Gi0/2, BGP does come up but
> ofcourse I have no mpls vpn traffic because those links no are no longer
> mpls enabled.
>
> Note that all Active BGP peers are PE devices which sit on the POP2
> side. So all BGP peers on POP1 can establish BGP sessions with each
> other but not to BGP peers at POP2. Like wise PE's at POP2 can establish
> BGP sessions with each other and not with PE's located at POP1.
>
> The forwarding table from PE2 > P2 > P1 looks ok - so not sure why you
> can't ping PE2 > PE1.
>
> PE2#sh mpls forwarding-table 172.16.99.13 32
> Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
> Label  Label or VC   or Tunnel Id      Switched      interface
> 617    3034          172.16.99.13/32   0             Gi0/0.11
> 203.10.110.211
>
> P2#sh mpls forwarding-table 172.16.99.13 32
> Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
> Label  Label or VC   or Tunnel Id      Switched      interface
> 3034   8668          172.16.99.13/32   1582342       Gi4/0/1
> 203.17.96.97
>
> P1#sh mpls forwarding-table 172.16.99.13 32
> Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
> Label  Label or VC   or Tunnel Id      Switched      interface
> 8668   Pop Label     172.16.99.13/32   158253163     Gi0/0.152
> 203.17.102.113
>
> The fact that PE's at POP2 can not communicate with PE's at POP1 is why
> I think  BGP isn't coming up between PE1 and PE2. I don't know why mpls
> traffic/labels are not being swapped and forwarded beyond P1 to reach
> PE1. MPLS config, ldp, mpls forwarding table and bindings all look ok to
> me - any ideas??? Like I said we haven't changed any config except
> moving from our existing circuit to a new protected switched ethernet
> circuit.
>
> Thanks.
>
> Andy
>
>
>
>
> -----Original Message-----
> From: Alex [mailto:ecralar at hotmail.com]
> Sent: Monday, 16 November 2009 5:52 PM
> To: Andy Saykao; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Can not establish MP-BGP sessions
>
> Hi Andy,
> Couple of questions:
> 1/ Can you ping between PE1 and PE2 _loopbacks_ across the circuit when
> "mpls ip" is ON on both Gi4/0/1 and Gi0/2?
> 2/ Can you establish BGP session between _interface_ addresses when
> "mpls ip" is ON on both Gi4/0/1 and Gi0/2?
> Rgds
> Alex
>
> --------------------------------------------------
> From: "Andy Saykao" <andy.saykao at staff.netspace.net.au>
> Date: 16 November 2009 04:31
> To: <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] Can not establish MP-BGP sessions
>
> > Hi All,
> >
> > We migrated a link between two pops onto a Switched Ethernet circuit
> > and since then we can't pass MPLS VPN traffic between those two pops
> > from
> > PE1 to PE2 because PE1 and PE2 can not establish a MP-BGP session.
> >
> > -------------------------
> > BGP log on PE1:
> > -------------------------
> > Nov 16 14:26:48.693 AEDT: %BGP-5-ADJCHANGE: neighbor 172.16.99.4 Down
> > BGP Notification sent Nov 16 14:26:48.693 AEDT: %BGP-3-NOTIFICATION:
> > sent to neighbor
> > 172.16.99.4 4/0 (hold time expired) 0 bytes
> >
> > -------------------------
> > Topology:
> > -------------------------
> > POP1 [PE1 (lo99:172.16.99.13) --- Switched Ethernet --> P1 ] -->  POP2
> > [P2 --> PE2 (lo99:172.16.99.4)]
> >
> > -------------------------
> > P1:
> > -------------------------
> > interface GigabitEthernet4/0/1
> > description Connection to P2
> > bandwidth 150000
> > ip address 203.17.96.x 255.255.255.252 load-interval 30 negotiation
> > auto mpls ip
> >
> > -------------------------
> > P2:
> > -------------------------
> > interface GigabitEthernet0/2
> > description Connection to P1
> > bandwidth 150000
> > ip address 203.17.96.x 255.255.255.252 load-interval 30 media-type
> > gbic speed auto duplex auto negotiation auto mpls ip
> >
> > Interesting thing to note is that if I remove "mpls ip" from P1's
> > interface, the MP-BGP sessions are formed between PE1 and PE2 and stay
>
> > up. When I put "mpls ip" back on the interface, the MP-BGP session
> > times out with the error messgage in the BGP log above.
> >
> > The only thing that has changed is the introduction of the new
> > Switched Ethernet circuit. I was thinking that it might have something
>
> > to do with jumbo frames but our UpStream Providers tells me that they
> > have configured jumbo frames on either end of the link plus I can ping
>
> > end from P1 to P2 with  byte sizes larger than 8000 bytes.
> >
> > Has anyone got any ideas as to why the MP-BGP sessions all of a sudden
>
> > can no longer stay up and what further debug/troubleshooting i can do?
> >
> > Thanks.
> >
> > Andy
> >
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> are addressed.
> > Please notify the sender immediately by email if you have received
> > this email by mistake and delete this email from your system. Please
> > note that any views or opinions presented in this email are solely
> > those of the author and do not necessarily represent those of the
> organisation.
> > Finally, the recipient should check this email and any attachments for
>
> > the presence of viruses. The organisation accepts no liability for any
>
> > damage caused by any virus transmitted by this email.
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list