Tags: ,


Notable Replies

  1. Can you confirm if this is my correct reading of this route-map
    Networks from Protocol B ‘Jack’ are untagged until they enter Protocol A where they are Tagged - (The first statement is ignored because they are not Tagged)

    Jack(config)#route-map TAG permit 20
    Jack(config-route-map)#set tag 1 
    

    When these now Tagged routes hit ‘John’ Still in Protocol A they are denied from re-entering Protocol B via the First statement.

     route-map TAG deny 10
        John(config-route-map)#match tag 1
    

    But as you say the route-map has to deny the Tagged routes first or it will allow all routes that is why the deny comes before the permit?

  2. Hello Rene,

    I have intlo0 with ip address of 1.1.1.1/24

    I have access-list 1 permit 1.1.1.1 0.0.0.0 and route map route-map TST permit
    route-map TST
    set tag 222

    match ip address 1
    set tag 111

    and redistribute into ospf from eigrp

    redistribute eigrp 100 subnets route-map TST

    but at the destination router I only see tag 222 for the prefix 1.1.1.1 instead of 111

    as son as I change the access list wild card mask to 0.0.0.255 the destination router sees the correct tag of 111

    Could you please explain this why with wilcard 0.0.0.0 the correct tag is not shown but with 0.0.0.255 the correct tag is shown?

    Best Regards,
    -Rouzbeh

  3. Hi Rene,
    Please please help me out regarding redistribution. when redistributing mutually between ospf and bgp by tagging and i m getting an error

    % “TAG1” used as redistribute ospf into bgp route-map, set tag not supported"

    route-map TAG1 deny 10
    match tag 1
    route-map TAG1 permit 20
    set tag 1

    image

    according to the topology, I have to redistribute mutually bet OSPF and BGP at R3 and R4. I have to advertise 10.2.0.0/16 from R3 and R4 towards R1 and R2. simple redistribution shows 10.2.0.0/16 as “OE2” route in OSPF domain. but it should be “O” route for OSPF domain.
    Also, need to redistribute mutually at R5 (Betw OSPF and BGP) and R6 (Betw EIGRP and BGP). Kindly give an idea how to do the redistribution so that no loop occurs.
    Not clear how to prevent the redistributed route from bgp to ospf back to bgp again by ospf redistribution in bgp.
    Your prompt reply highly appreciated regarding this issue.

  4. Hi Abdus,

    Route tagging when redistributing into BGP is not supported. That’s why you get that error:

    R1(config)#route-map SET_TAG permit 10
    R1(config-route-map)#set tag 10
    
    R1(config)#router bgp 1
    R1(config-router)#redistribute ospf 1 route-map SET_TAG
    % "SET_TAG" used as redistribute ospf into bgp route-map, set tag not supported
    

    You can use something else in BGP to “tag” redistributed routes, like a community value. Between OSPF and EIGRP, you can use tags to prevent routing loops.

    Let’s think about the things that could go wrong in a topology like this if you redistribute between OSPF-EIGRP, OSPF-BGP, and EIGRP-BGP:

    * Everything you redistribute into OSPF will always show up as an external route. Even if a route that originated in OSPF gets redistributed in OSPF, this won’t cause any issues since an O (inter-area) route is always preferred over an external (O E1 or O E2) route. You do have to watch out if you have O E1 or O E2 routes that originated in your OSPF domain.
    * Everything you redistribute into EIGRP will always show up as an external route. Even if the route originated in EIGRP, it won’t be a problem since EIGRP external routes have a higher AD than internal routes. You do have to watch out when you redistribute EIGRP external routes that originated in your EIGRP domain.
    * Routes that originated in BGP could be redistributed into OSPF > EIGRP and get back to BGP, or the other way around, into EIGRP > OSPF > BGP.

    If you don’t have OSPF external routes that originated in OSPF or EIGRP external routes that originated in EIGRP, then you don’t really have to worry about OSPF or EIGRP. You should ensure that BGP routes don’t loop around though.

    If you redistribute from BGP into OSPF on R3/R4 then you can set a tag. Configure R5 to deny everything that is tagged when you redistribute into BGP. This prevents the EIGRP domain from learning BGP routes that originated in the BGP domain.

    Do the same thing on R7, tag the routes you receive and that are redistributed into EIGRP. Configure R6 to deny routes that are tagged from being redistributed from EIGRP into BGP.

    This prevents your BGP domain from receiving any prefixes that originated there. The only downside to this solution is that the EIGRP domain can’t use the OSPF as a backup path to get to the BGP domain (or the other way around, from OSPF > EIGRP > BGP).

    If you want this, then you could do something like this:

    - Configure R1/R2 to advertise a community value for all internal BGP prefixes to R3/R4.
    - Configure R3/R4 to redistribute OSPF and set a tag for the prefixes with the community value.
    - R5 can redistribute from OSPF to BGP and set a community value based on the tag.
    - R6 can redistribute from BGP into EIGRP, set a tag based on the community value.
    - R7 can redistribute from EIGRP into BGP, denying everything that has the tag.

    This prevents from feeding BGP prefixes going from OSPF > EIGRP > BGP while allowing the EIGRP domain to use the OSPF domain to get to the BGP domain. You can do the same thing for BGP prefixes that go from R8 > R7 > R6 > R5 > R3/R4 > R1/R2.

    I hope this helps! Redistribution with three redistribution points and three routing protocols can get complex :slight_smile:

  5. This would have been a lesson that a functioning topology would have been really nice. I had created one myself and had some issues and had a ten mile post but I figured out what my issue was. I basically didnt have a completed route-map configuration on R2. I have fixed that now and everything is working.

    Basically I was interested in the path of the traffic and the incomplete configuration on R2 was making it where nothing made sense but after I added the exact same configuration route-map wise on R2 everything was good.

    Capture

    and topology:
    Capture

    below is how the traffic flows and it makes sense now Blue is the 192.168.2.0 goes from R2>R4 to R1 where it is picked up but will deny any tag that matches 1. So it denies 192.168.2.0 from R2 thus preventing issues.

    Red traffic 192.168.1.0 does same thing R1 redistributes the RIP route into OSPF and Tags it with 1 which then travels to R4 and then to R2 where R2 will deny it.

    R1(config)#route-map TAG deny 10
    R1(config-route-map)#match tag 1
    R1(config-route-map)#exit
    R1(config)#route-map TAG permit 20
    R1(config-route-map)#set tag 1

    Basically this method allows R3 and R4 to get all the traffic that needs to be redistributed but it keeps other issues from happening.

    The only curious thing is that it still shows up with the TAG even though its denied. I would have thought since it was Denied it would not show up in the routing table but it seems to show up in the route even though its denied. Else if that was not the case we would not be seeing the TAG 1 and we know where it comes from because the IP route x.x.x.x tells us its path.

    so using Follow the Path trouble shooting that says that must be the case?

    If I have this wrong please let me know.

    Capture

Continue the discussion forum.networklessons.com

24 more replies!

Participants